Coding got cheap. Judgment got expensive: the SDLC framework

The keyboard is gone. That was never the point.

Somewhere on every engineering team right now, someone isn't mentioning how much of their last pull request an agent actually wrote. Not because the work is bad, often it's better than what they'd have shipped alone, but because saying so invites a specific kind of dismissal: well, the AI did it. The skill gets discounted. The credit evaporates. So people either hide the agent's contribution, or make the opposite mistake: they under-use a capable collaborator, running it like autocomplete, because using it properly starts to feel like it isn't really their work anymore.

Underneath that guilt sits a louder, more confident claim, and it's the one this piece is actually built to argue against: that agents now write code better than most humans can, so the keyboard, the actual mechanical act of typing software into existence, is functionally gone, and with it most of what used to make engineering hard. If that's true, why bother with elaborate planning and review? Ship the vibe. Let the agent iterate. Move on.

Both reactions are responding to the same real event, a huge share of the mechanical labor of coding has been automated, and both draw the wrong conclusion from it. In 1986, Fred Brooks split software difficulty into two kinds: accidental complexity, the friction of expressing a solution in a formal language (syntax, boilerplate, plumbing), and essential complexity, the difficulty of the problem itself: what the software should do, and the tradeoffs baked into that decision. Agents are very good at collapsing accidental complexity. They are not the thing that decides what should exist and why. That decision was never bottlenecked by typing speed. Making it faster to type the wrong thing doesn't make it right, it makes you wrong with more confidence and better formatting.

Which is the actual case for a more disciplined lifecycle, not "agents can't be trusted with code," but that the bottleneck moved, and most teams' process hasn't caught up. When code was expensive to produce, process was the overhead you cut under deadline pressure, because code was the scarce thing and anything slowing it down was suspect. When code is cheap to produce, that same cut becomes the mistake: unconstrained on the one axis that was never actually scarce, and undisciplined on the one that always was.

The Agentic Software Development Life Cycle

Fourteen checkpoints, in two mirrored halves of seven. The first half, Define, ends in a frozen contract. The second, Build & Verify, ends in a signed-off release. The symmetry isn't decorative, it's the mechanism the rest of this piece rests on: ownership flips between the halves. Humans author Define, an agent audits it. An agent authors Build & Verify, humans audit it.

DEFINE
Product Plan → Product Scope → Rationale → System Design → Agentic Review (Design) → Freeze Design → TRD
                                                                                          |
                                                                                          v
BUILD & VERIFY
Agentic Coding → Agentic Testing → Agentic Review (Audit) → PR → Human Review → Human QA → Signoff & Release

Every checkpoint that fails routes backward, not forward. A failed audit sends work back to the phase responsible for it, not to a hurried patch bolted onto the front of the queue. The lifecycle only moves forward when the thing it's checking is actually settled.

The same shape shows up outside code review too. Production agent systems doing consequential work, not just writing it, tend to converge on the same idea: an agent proposes the action, and something with real stopping power, a human-in-the-loop approval gate, reviews it before it executes. That's the same authorship-versus-audit split as Human Review at the PR stage above, just running inside the agent's own execution path instead of a pull request.

What actually changes

None of the fourteen checkpoints above is interesting on its own. What's structural, and different from bolting an AI step onto an existing SDLC, are four decisions underneath them.

Authorship and audit trade places. In Define, a human authors the system design and an agent audits it before anyone commits to freezing it, running the design against edge cases, prior failures, and inconsistencies, exhaustively and without fatigue. In Build & Verify, the roles invert: an agent authors the code, a human audits it. The two halves are mirror images for a reason. Authorship is where intent gets set; audit is where you catch what the author couldn't see in their own work.

Freeze is a gate, not a milestone. In most SDLCs, "design sign-off" is a soft event, a meeting, a thread, a doc that gets nodded at and quietly revised for six weeks while the code marches on regardless. Freeze Design isn't that. No TRD, no Agentic Coding, until the design is explicitly frozen, and once frozen, a change to it is a decision to reopen the gate, not a comment on a pull request. The point isn't bureaucracy. It's that agentic coding is fast enough to outrun a design that's still moving, and a fast build against a moving target just means you converge on the wrong thing faster.

Coverage isn't correctness. Agentic Testing should aim for something close to full coverage, unit, integration, functional UI, and non-functional requirements alike, because an agent generating exhaustive tests at near-zero marginal cost has no excuse not to. But coverage measures surface area, not truth. A self-graded test suite can pass with weak assertions, over-mocked dependencies, or a test that verifies the code does what the code does rather than what it was supposed to do. That's why the lifecycle doesn't stop at a coverage number, it still ends in Human QA, checking actual business intent, UX, and the bugs that are only bugs because a person knows what "right" was supposed to look like. Coverage answers "did we test enough of it." Only a human, at the end, answers "did we test the right thing."

Review has two altitudes, not one. Most teams collapse "code review" into a single event. This framework doesn't. Human Review, at the PR stage, checks conformance: does this match the frozen design, does it pass the deterministic gated checks, is it structurally sound. Human QA, later, checks correctness against the business: does this actually work the way it was meant to, would a real user hit a wall the tests didn't catch. Merging the two either makes the check too shallow to catch structural issues, or too slow to be a real gate. Splitting them means each happens at the altitude where a human is actually good at spotting the problem.

This isn't Waterfall with extra steps

Fourteen sequential-looking phases invite the comparison. It's worth answering directly: Waterfall's real failure was never that it had phases, it was that revising an earlier phase was too expensive to actually do, so teams pretended requirements were final and paid for that fiction at the end.

That expense is exactly what agents remove on the Define side. Regenerating a design review or a TRD costs minutes, not weeks, so freezing a design isn't a six-month commitment, it's a checkpoint you can reopen within a day's work if it's wrong. And this cycle runs per feature or per slice of work, not once for an entire system. Run fourteen times a month, across small increments, this looks nothing like the Waterfall it superficially resembles on a whiteboard.

You don't need more developers

If Agentic Coding and Agentic Testing genuinely put out a hundred times the throughput of a person typing alone, the constraint on how much a team can safely ship was never going to be coding capacity again. It becomes how much experienced judgment exists to gate all that throughput before it reaches Freeze Design, PR, and Signoff. Hiring more developers doesn't fix a judgment shortage, it just produces more code for the same small number of people who can review it well to fall behind on.

Call the role that actually scales a Feature Owner: someone senior enough to hold System Design and Rationale in the same head, because on the Define side of this lifecycle, product judgment and system judgment were always going to sit with one person anyway, the framework just hadn't given that person a name. What a Feature Owner isn't is a single person quietly doing both Human Review and Human QA on their own feature. Wearing more hats doesn't mean auditing your own decision. A Feature Owner who wrote the System Design still needs someone else's eyes at the PR and QA gates, for the same reason authorship and audit stay in different hands everywhere else in this lifecycle: a checkpoint a person holds on their own work isn't really a checkpoint.

What changes, then, isn't the shape of the gates. It's who's qualified to hold the Define-side ones. "System Engineer" and "Product Owner" used to be separate ladders because the volume of decisions either one could personally push through was naturally capped by how fast a team could code. Remove that cap, and the bottleneck moves to whoever is making the calls in Product Plan, Rationale, System Design, and Freeze Design, and a team that keeps those as three separate, junior, hand-off roles will bottleneck exactly there. The teams that get real leverage from a hundredfold increase in build throughput won't be the ones that hired more coders. They'll be the ones that developed fewer, more senior generalists, capable of holding system and product as two sides of one judgment, and treated that scarcity, not engineering headcount, as the real constraint on how fast they can safely ship.

Where the value actually is now, and how to prove it

Which brings this back to the opening scene. If the only visible unit of engineering work is "who typed the code," agents have already won that argument, and credit defaults to whichever tool was fastest. But look at the fourteen checkpoints again: nine of them are named, attributable human decisions, Product Plan, Product Scope, Rationale, System Design, Freeze Design, Human Review, Human QA, Signoff. None of those show up in a diff. All of them show up in this lifecycle, as a checkpoint someone specifically owns and is accountable for.

That's not incidental. A framework like this isn't only risk management, it's an attribution ledger. It makes the highest-leverage work in the process the most visible work in the process, instead of the least.

Nobody can credibly say the AI did it about the decision to freeze a design, or the judgment call at signoff. Naming the phase is what makes the judgment visible. The guilt evaporates once "using the agent well" has a name, a gate, and an owner, instead of being an unstated shortcut someone has to either hide or apologize for.

Vibe coding treats the agent as a way to skip the parts of engineering that used to be hard. This treats it as a way to spend the time that mechanical labor used to eat on the parts that were always the actual job: deciding what to build, catching what shouldn't ship, and being accountable, on the record, for both.

PS: This is a framework, not a mandate. Adapt the gate names to your own org, but keep the shape: author and audit trade places, freeze is a real gate, coverage is not correctness, and review happens at two altitudes.