Draw the software development lifecycle on a whiteboard from memory. Idea, requirements, design, code, review, test, deploy, operate. Arrows left to right, a couple of loops back.
Now ask what every one of those boxes is actually for.
Requirements exist because writing code was expensive and you didn’t want to write the wrong thing. Design reviews exist because rework was expensive. Estimation exists because engineering hours were the scarce input you had to allocate. Batching into sprints exists because coordinating expensive humans has overhead. Code review exists because the person who typed the code was the only one who understood it. Phase gates exist because the cost of finding a defect late was catastrophic compared to finding it early.
Every box on that diagram is a rationing mechanism. The SDLC is not a description of how software gets made. It is an inventory-control system for one scarce, expensive resource: a human being turning intent into working code.
That resource stopped being scarce.
Not “will stop.” Stopped. Stripe merges more than 1,000 fully agent-produced pull requests every week through a central harness. The Government of Alberta scanned 466 million lines of code in 20 hours — work that would have consumed a security team for a year. 84% of developers now use AI tools, and agent usage doubled year over year. The generation problem is, for practical purposes, solved.
And we are still running the rationing system.
When execution becomes cheap and abundant, every process built to conserve it becomes overhead. Worse: it becomes camouflage, because the process still produces green dashboards while the real constraints go unmanaged.
This is the first piece in a series. Fourteen articles, one per part of the lifecycle, and one argument running through all of them: we are not adding AI to the SDLC. We are redesigning the SDLC around an agentic production system with humans as governors. I’m going to be specific about what changes, what replaces it, and what stays human forever.
Let me start with why the old model held together for so long, and what exactly snapped.
The old lifecycle was a compression algorithm for expensive typing#
Here is the assumption that sat underneath every process decision in software engineering from roughly 1970 to roughly 2024: the marginal cost of producing a unit of working software is high, and roughly constant.
Everything followed from that. If code is expensive, you specify before you build. If code is expensive, you batch changes to amortize coordination. If code is expensive, you estimate, because you’re allocating a scarce input. If code is expensive, you review it line by line, because that’s the cheapest place to catch a defect. If code is expensive, you protect the people who produce it, because they are the bottleneck and everything queues behind them.
The whole discipline is a monument to that one number. Agile didn’t challenge it — it just shortened the batches. DevOps didn’t challenge it — it automated everything around the expensive part. Even the best practices we’re proudest of are optimizations against a constraint we assumed was permanent.
I want to be clear that this was correct. It wasn’t superstition. For fifty years, the cost of turning intent into code dominated every other cost in the system, and processes that respected that fact beat processes that didn’t. DORA spent a decade proving it with data.
The assumption is now false. And when the load-bearing assumption goes, the building doesn’t fall down immediately. It develops cracks in places nobody is inspecting.
Map the phases against what agents already do#
Take the classic sequence and ask, honestly, who does each part in an organization that has actually deployed agents. Not a pilot. Production.
Idea → Requirements. Still human, and this is where the new bottleneck lives. More on that in a moment.
Requirements → Design. Increasingly shared. An agent will produce three architectures, name the tradeoffs, and cite prior art in your own repo faster than a human can book the meeting. Choosing among them is judgment. Producing them isn’t.
Design → Code. Agent. Overwhelmingly, and the share is still climbing. This is the box everyone talks about and it’s the least interesting one.
Code → Review. Broken. Not “changed” — broken. Faros telemetry shows agent-heavy teams producing 98% more PRs, 154% larger, waiting 4.6x longer for a reviewer to even pick them up. The review model assumed a human wrote the code and a human could read it in comparable time. Both halves of that assumption are gone.
Review → Test. Agent, and this one is quietly dangerous. An agent that writes both the implementation and its tests has produced a closed loop with no independent verification in it. We shipped that pattern by default and called it coverage.
Test → Deploy. Mostly automated already, which is why teams think this phase is fine. It isn’t. Deterministic pipelines were designed to execute fixed scripts for changes a human understood. They have no capacity to reason about a change they’ve never seen.
Deploy → Operate. Split, and the split is widening. Agents already triage, correlate, roll back, right-size, and quarantine. Humans authorize the consequential calls. This is the shape everything else is converging on, which is why I’ve spent so long arguing for Agentic Overwatch as an operating model rather than a tool.
Look at that list. Two boxes are still human-dominated: deciding what should exist, and taking responsibility for what does. Everything between them has either moved to machines or is currently jammed.
That’s not “AI helps with coding.” That’s a different production system wearing the old diagram’s clothes.
The assumptions that are already dead#
Name them plainly, because most process arguments in 2026 are people defending one of these without knowing they’re doing it.
- “Writing code is the expensive part.” It’s now among the cheapest parts. Understanding, verifying, and owning code are the expensive parts, and they scaled with nothing.
- “A ticket is a sufficient specification.” A ticket was a sufficient prompt for a human who shared your context. Hand the same ticket to an agent and you find out how much of the spec was living in someone’s head. Stack Overflow’s data has 66% of developers naming “almost right but not quite” as their top frustration. That’s not a model failure. That’s an intent-fidelity failure.
- “Estimation allocates the scarce resource.” Agent capacity is elastic. You cannot estimate your way to a plan when the constraint is how much judgment your organization can apply per week.
- “More output is better.” 180% more code shipping only about 30% more software is the whole industry converting cheap generation into expensive inventory.
- “Reviewing every change is diligence.” Reviewing every change is now a throughput cap set by your most conscientious engineer’s reading speed.
- “Test coverage means verified.” When generating ten thousand tests costs almost nothing, a coverage percentage measures how much test code exists, not how much behavior is proven.
- “The pipeline’s job is to execute what it’s told.” A pipeline that can’t reason about risk applies the same ceremony to a typo fix and a schema migration.
- “Permissions are for people.” Your IAM model assumes a human is behind every request. There isn’t one.
- “Faster delivery means better delivery.” DORA’s own research is explicit that AI amplifies whatever foundation it lands on. Amplification is directionless.
Each of those assumptions has a whole article behind it, and each gets one in this series.
What actually broke, with numbers#
I’m pro-AI. I lead AI transformation for a global SaaS platform and I run autonomous systems in production — agents that investigate bugs, write and review code, validate changes, and run operational workflows. I want more of this, not less. Which is exactly why I refuse to argue from vibes.
The data on the last two years says something specific, and it isn’t “AI doesn’t work.”
METR ran a randomized controlled trial with experienced open-source developers and found them about 19% slower with AI tools while believing they were 20% faster. LinearB’s telemetry across 8.1 million PRs in 4,800 organizations found the same shape at scale: teams feel 20% faster, merge-to-production runs 19% slower. Plandek’s 2026 benchmarks across more than 2,000 teams show the bottleneck cleanly relocating downstream into review, testing, and integration, with bottom-quartile teams taking 35+ hours to merge a pull request.
On quality, a January 2026 study of autonomous coding agents found static-analysis warnings up 18% and cognitive complexity up 39%, describing “sustained agent-induced technical debt even when velocity advantages fade.” Veracode ran 80 curated tasks across more than 100 models and found risky security flaws in 45% of them. GitGuardian detected 28.6 million new secrets in public commits in 2025, up 34% year over year, with AI-assisted commits leaking at roughly twice the baseline rate.
And on the honest limits of the machines themselves: Cognition’s FrontierCode benchmark scores agent PRs on whether a senior maintainer would actually merge them — correctness, test quality, scope discipline, regression safety. Every frontier model passes fewer than half of the hard tasks.
Read those together and the story is not “the tools are bad.” Every one of those numbers is what you’d predict if you dropped unlimited generation capacity into a system whose verification, integration, and ownership capacity stayed exactly where it was.
We uncapped one stage of a pipeline and left the rest at 2023 throughput. Then we measured the uncapped stage and called it progress.
The inversion, stated precisely#
Here’s the frame I keep coming back to, and it’s the spine of this whole series.
The old SDLC had one binding constraint: human execution capacity. Optimize that and everything improved.
The new system has five, and they are all upstream or downstream of the part that got cheap:
1. Intent quality. How precisely can your organization state what should exist, what must not exist, and how you’ll know? An agent will execute a vague instruction flawlessly and produce the wrong system. Ambiguity used to be absorbed by a human who’d sat in the meeting. Now ambiguity is a defect that ships.
2. Context fidelity. How accurate is the information your agents act on? Docs, runbooks, architecture notes, conventions, tool inventories. Humans read documentation with suspicion; agents read it as ground truth. Your wiki became a runtime input, which means a stale page is now an outage class.
3. Verification strength. Can you prove a change does what was intended, and nothing else, without a human reading it? Not “did tests pass.” Proof. This is the single biggest gap in most organizations, and it’s the one that decides whether high autonomy is leverage or roulette.
4. Architectural judgment. Which system should exist, where do boundaries go, what do we refuse to build. Machines can check that code is consistent with itself. They cannot check that it’s consistent with reality, your business, or your five-year plan.
5. Control. Permissions, blast radius, autonomy tiers, kill switches, audit trails. The ability to bound what agents can do and to stop them. Almost every organization granted autonomy by accident — inherited from a vendor default — and calls it strategy.
Notice what those five have in common. Not one of them gets better when you buy a stronger model. Every one of them is an organizational design problem.
That’s the uncomfortable part. The industry keeps treating the next model release as the answer, because a purchase is easier than a redesign. But if intent, context, verification, judgment, and control are the constraints, then a better model just executes your unclear intent faster, against your stale context, with weaker verification, inside a wider blast radius.
Strong teams get enormous leverage from this. Weak process plus high autonomy is a high-speed way to ship garbage and incidents. Same tools. Opposite outcomes. That’s not a paradox — that’s what “amplifier” means.
The part that will annoy some people#
Two groups are going to dislike this series, for opposite reasons.
The maximalists will hear the words verification, governance, and control and read it as a brake. It isn’t. Every control surface in this series exists to let you raise autonomy safely. The reason most orgs can’t go faster isn’t caution — it’s that they have no mechanism to earn confidence, so they oscillate between rubber-stamping and panic.
The skeptics will hear “execution is cheap” and reach for the studies showing AI code is worse. Those studies are real and I cite them above. But “the output needs verification” is an argument for building verification, not for keeping a human in the typing seat. We didn’t answer the manual-QA bottleneck by hiring more testers. We built CI and turned verification from a virtue into a system property. Same move, one layer up.
The engineers who lose in this transition won’t be the ones who refused to use AI. They’ll be the ones whose entire claim to value was execution speed, defended right up until execution stopped being scarce. The ones who win are the ones who make their judgment legible — writing down the constraints, the failure modes, the boundaries, the “never do this,” so that it can be encoded, enforced, and scaled across a fleet.
Throughput is legible. Judgment is invisible. That asymmetry is the central career risk of this decade, and it’s an org-design problem before it’s a personal one.
Where this series goes#
Fourteen pieces, following the lifecycle it’s replacing.
Requirements become intent packages — intent, context, constraints, and verification, in a form both a human and an agent can execute. The engineer becomes a system governor. Review becomes risk-based adjudication of evidence instead of line-by-line reading. Testing becomes proof of behavior instead of coverage theater. The pipeline stops executing scripts and starts choosing verification strategies. Infrastructure and operations get redesigned for a non-human primary operator. Incidents get explicit autonomy tiers. Observability gets built for machine consumption first. Technical debt gets repriced, and AI debt gets named. Metrics move off DORA’s old constraint. Security confronts the agent as an identity with credentials and decision rights. Management becomes capacity and judgment allocation across mixed human-agent teams. And the last piece assembles all of it into one end-to-end picture: the agentic software factory and every control surface in it.
Each article stands alone. Read them in any order. But they’re arguing one thing.
The diagram was never the point#
Here’s what I want you to take from this first piece.
The SDLC was never sacred. It was a set of intelligent responses to one expensive constraint, and it earned its place by working. Respect it enough to understand why each box exists — and then be honest that the reason is gone.
What survives the inversion isn’t the process. It’s the craft underneath it: knowing what should exist, refusing what shouldn’t, proving behavior instead of assuming it, and standing behind the result when it reaches a customer. Those were always the engineering. The typing was just how we expressed them.
The agent writes the code. The engineer owns the outcome. The whole rest of this series is about building an organization where that sentence is operationally true instead of merely inspiring.
So before the next article: pull up your team’s lifecycle, whatever form it takes — the Jira workflow, the definition of done, the release checklist. Find one gate that exists purely because writing code used to be expensive. Then ask what that gate is protecting you from now, and what it’s costing you to keep.
If the honest answer is “nothing, and a lot” — you’ve found where to start.
I lead AI transformation for a global SaaS platform and run autonomous systems in production: agents that investigate bugs, write and review code, validate changes, and handle operational workflows. This series is my working model for the lifecycle that replaces the one we inherited. If you’re rebuilding any part of it — or you think I’m wrong about which constraint binds — I want the argument. Find me on X, LinkedIn, or Telegram.