The SDLC is turning into an ADLC. Here's what changes.

This one is an opinion, from someone who just built a five-app product mostly by directing an AI. Argue with it in the comments.

I think the software development life cycle we all learned (requirements, design, build, test, deploy, maintain) is turning into something I'd call an AI development life cycle. Not because the phases disappear, but because the weight moves. The phases that used to be expensive got cheap, and the cheap ones got expensive.

Where the effort went

In the SDLC, build is the big phase. Most of the hours, most of the people.

Building ParkEase, build was the fast part. An agent could write a feature in an hour. What took the time was everything around it:

• Context. Writing down the rules, decisions and constraints the agent works under, and keeping them current.
• Choosing. Picking between rendered design options, reviewing a plan, deciding what not to build.
• Verifying. Proving the output was right: tests, reviews, a real build against a real API.
• Harvesting. Turning every mistake into a rule so it doesn't happen next session.

The ADLC, as I'd draw it

1. Context engineering replaces requirements gathering. Requirements still exist, but the real deliverable is the context the agent reads: instruction files, decision records, task files. If it isn't written down, the agent doesn't know it.
2. Direction replaces design. The human picks from options the AI generates, rather than drawing from scratch.
3. Generation replaces build. Fast, cheap, and not to be trusted on its own.
4. Verification replaces testing, and gets bigger. Tests are no longer just checking code someone carefully wrote; they're the contract that generated code has to meet. Evidence before any "done".
5. Harvest is new. Every session ends by capturing what was learned into files the next session reads. In the SDLC that was a retro once a sprint. In the ADLC it's continuous, because the model forgets everything every time.
6. Deploy and operate stay much the same, and are where generated code meets reality. My first deploy found three bugs every test had agreed with.

What this means for engineers

If I'm right, the scarce skills shift:

• Writing precise constraints matters more than typing speed.
• Judgment and taste ("that one, not those two") matter more than producing the first draft.
• Verification design (knowing what proves correctness) becomes a core engineering skill, not QA's job.
• Systems thinking matters more, because the AI is very good locally and has no idea what your system is supposed to be.

None of that is less engineering. It's engineering with the typing moved to a machine.

Where I might be wrong

One project, one person, one five-week build. On a large team with a legacy codebase, context engineering might be the whole job, and that might not look like a "cycle" at all. And models are improving fast enough that today's verification burden could shrink.

But I'd bet on the direction. The teams that win won't be the ones whose AI writes the most code. They'll be the ones whose AI writes code they can trust, and that's a process problem, not a model problem.

---

Next: the verification half, in detail. How tests were written, run and enforced, from the four mandatory suites to the race of 100 drivers for 10 slots.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease