The SDLC Was Built for Expensive Code

Part 3 of 3. When code was scarce, review gates were cheap. Agents flipped that, and the gate is now the bottleneck worth redesigning.

Ted Lasso arrives at AFC Richmond knowing almost nothing about English football. The club is steeped in tradition, the dressing room is skeptical, and the obvious move for a confident outsider is to bulldoze the place and install his own playbook. Lasso does the opposite. He learns the rituals and wins over Roy, Rebecca, and the dressing room before he touches anything.

Only then does he change the one thing holding the club back, and the change sticks because it was earned. Delivery leaders bringing coding agents into a client's SDLC face the same choice between conforming and redesigning. The answer is a sequence, not a side.

Agents are arriving inside lifecycles that were never designed for them. The instinct to conform collides with the evidence that the labs redesigned their process rather than fitting agents into the old one. The labs' real advantage is not a better model; it is a delivery process built for cheap code.

Process Debt, Not Just Technical Debt

The usual explanation for why AI labs move faster is technical debt: they have young codebases and enterprises do not. That is true, and it is the smaller half of the story. The labs also have no process debt. When agents began producing changes faster than the old machinery could absorb, they rebuilt the machinery, including review tiers, source control, and when testing happens, around the new reality.

Most enterprise delivery processes were designed under the opposite assumption. Writing code was the slow, expensive part, so a review gate on every change was cheap by comparison, and a story-sized ticket matched what one engineer could build in a few days. Agents flip that ratio. Code is now the cheap part, and every gate designed for scarcity becomes a queue.

Dropping agents into an unchanged lifecycle does not remove the bottleneck. It relocates it from the keyboard to the approval queue.

Anthropic's own numbers show how fast this happens. DevOps.com reports that daily merged changes rose from 2,500 to more than 30,000 in four months, and that source control, not coding, became the constraint. Now picture the same surge landing on a client's pull request process, where the humans leaders hoped agents would relieve are the ones buried. Nobody gets a promotion for shortening an approval queue, which explains why so few enterprises have touched theirs. BCG Platinion, a firm that sells agentic delivery services and so has a stake in the view, warns that applying agents to a broken process simply automates chaos.

Three Changes Worth Recommending

Redesign does not mean rewriting the whole lifecycle. Three specific changes carry most of the value.

Three changes have real evidence behind them. The first and most valuable is risk-tiered review. Instead of the same approval on every change, a classifier, rules, or both decide the tier from the change itself: documentation and changes behind a flag can merge with automated checks, ordinary changes need one person, and anything touching authentication, payments, or regulated data keeps full review. The rule that makes it safe is simple and worth adopting word for word: an agent's approval never counts as a human's.

Tier by the change, not the author, because risk lives in what the code touches rather than in who typed it.

The second is moving ownership up from the story to the epic. When agents compress a two-month epic into two weeks, five engineers working stories inside it start colliding. One engineer owning a whole epic, sliced into a handful of buildable pieces, keeps the work coherent and the review legible.

The third is moving checks to where volume can be absorbed: automated testing after merge and before deploy, paired with circuit breakers that tighten approval automatically when revert or incident rates rise. The most advanced lab in this space says it does not have those circuit breakers yet. An enterprise can design them in from the start.

A published framework for regulated domains proposes the same three-tier shape of oversight. Treat its productivity estimates with care, because they are analytical rather than drawn from production data.

In Regulated Shops, the Gap Is the Opening

Banks and insurers often read all of this as something they cannot do. The current guidance suggests the opposite. When the Federal Reserve, the OCC, and the FDIC replaced their model risk guidance with SR 26-2 in April 2026, they placed generative and agentic AI outside its scope and told banks to govern it under their existing risk and governance practices. There is no regulatory template for agent-written code yet, which means the firm that brings a defensible one is filling a vacuum rather than fighting a rule.

In a regulated shop, a defensible design is not a concession to oversight. It is the product.

Risk-tiered review is that kind of design. It keeps a named human approver on every change that falls within an audit's scope, which is how many firms already implement their change-management controls. It produces an evidence trail by construction, because every tier decision, every spec, and every approval is a recorded artifact. The narrower change, a lighter path only for the lowest-risk class of change, is something a control owner can evaluate on its merits.

Validate the design with the firm's own risk and compliance owners before it goes anywhere near production.

The Counterargument Worth Taking Seriously

The strongest objection is that recommending process change in a regulated enterprise is the fastest way for an outside advisor to lose the room. Process change is slow and political, conforming to the client's lifecycle is the safe professional default, and the evidence that agent-written code holds up in large, long-lived codebases is still thin. Practitioners who tried running with minimal oversight report maintainability problems, and the most advanced lab admits it is still missing basic safety mechanisms.

All of that argues for sequence, not silence. Conform first, and instrument the process so you can see where agent output is waiting on people. Propose the narrowest change with the lowest risk, a lighter path for one low-risk class of change, with a named human approver kept on everything else. Expand only when the measurements, reverts, incidents, and cycle time, say it is working.

The One Gate

Lasso changed one thing at Richmond after earning the right to, and the leader's job is to find the one gate worth redesigning and earn the right to change it.

The labs' real lead is a process designed for cheap code, and an enterprise can close much of that gap without a greenfield rewrite by redesigning one gate at a time, starting with review. This quarter, find the gate where agent work waits longest, measure it, and earn the right to change it.