Beyond Code Generation
AI can generate, explain, refactor, and test code — roughly 20% of the lifecycle. Tickets, docs, infrastructure, review, deploys, rollbacks, and monitoring still consume the rest. In a controlled study the gain did not just fail to show up: developers who felt 20% faster were measured 20% slower, because a lifecycle built on waiting absorbs whatever the coding box gives back.
Ask most teams what "AI in the SDLC" means and they'll point at the editor: the model writes code, explains code, refactors code, generates tests, suggests fixes. All real. All useful. And all of it covers roughly a fifth of what it takes to ship software.
The other eighty percent
Walk through a feature's actual life and count what still happens by hand:
- Tickets — something breaks, a human writes the Jira issue, links it, triages it
- Docs — updated after the fact, when anyone remembers
- Infrastructure — a human runs Terraform or Pulumi from a terminal, context-switching out of the editor to do it
- Architecture review — humans in a meeting
- Deploy and rollback — a human watches the pipeline, and a human decides to roll back
- Monitoring — dashboards, alerts, and a human on call to interpret them
None of this is coding, and none of it went away when the coding got fast. AI coding is not software delivery. The gap between the two is measured in context switches — editor to Jira to Terraform to Grafana and back — and every switch is a human carrying state between tools that don't talk to each other.
The measurement that comes before the argument
That is an argument. Before accepting it, it is worth looking at what happens when someone measures instead.
Anupam Mishra opens an AWS re:Invent session on this exact question with two numbers, neither of them his own. ThoughtWorks put the practical velocity gain from building software with AI at 10 to 15%. And the evaluation nonprofit METR ran a controlled experiment: sixteen open-source developers on a repository they knew, split into two teams of eight, roughly 250 issues between them. One team was given AI tooling. The other was asked not to use it.
The developers who used AI were asked how much faster they had been. Cold, they said about 23%. Asked again after reflecting, they revised it down to 20%. Then the two teams were compared against each other.
The team using AI was measured 20% less productive than the team without it.
Where the time actually goes
The reason a real coding gain can arrive as a measured loss is not mysterious once you look at where the hours sit. Mishra puts the question to the room — do you spend most of your day writing code? — and nobody raises a hand. Most of them raise it for meetings.
His diagnosis is structural rather than cultural: "it is not by design, but this is how we have landed in a world where everybody waits for everybody." Security gatekeeps the release and asks where the threat model is. Operations waits on development to cut a build. QA waits on the same build to test against. Those dependencies are not a line, they are a cycle — and cycles resolve into meetings. The escalation meeting, the alignment meeting, the meeting where something already built turns out to be wrong and gets backed out.
"In SDLC generally, it is not by design, but this is how we have landed in a world where everybody waits for everybody."
"A lot of people think that if we make coding faster, everything becomes faster. That's not true."
Waiting has a second cost the diagram never shows: it is asynchronous. Mishra's example is an email to a colleague, which may come back in five minutes or in ten days, and there is no way to know which. Work blocked on a human is not slow in a predictable way — it is slow in a way you cannot plan around, which is why the queue exists at all.
The gain is absorbed, not lost
Put those two things together and the arithmetic is unforgiving. If the coding box is a fifth of the elapsed time and everything around it is unchanged, then tripling the speed of the box returns a few percent of the whole — and returns it into a queue where it waits for a person.
The speakers land it in one phrase: what teams get is "a small step increment," not "the paradigm leap." Nothing was lost. The gain was real and then it was absorbed — spent in the waiting that was already there.
This is Amdahl's law, arriving from the direction of practice rather than theory, and it is the reason this pillar exists. It also sets the bar for anything that claims to fix it: an intervention that only touches the coding box cannot clear it, no matter how good the intervention is.
And then the downstream gets worse
Migration downstream is the optimistic version. Raja SP's observation is that the pressure does not just move — it compounds, because the phases now run at different speeds against a shared clock.
Everything up to and including unit tests gets fast. CI/CD does not. So a backlog builds on the development side while the pipeline meters releases at its old rate. By the time staging reports a defect, or production reports something not working, development has moved several versions past the code the report is about. The feedback still arrives; it arrives against a version nobody is working on any more.
There is a matching arithmetic on quality. Mishra's version: suppose you now do a month of work in a week, and suppose your team averaged one bug a month. The same work, done in a quarter of the time, at the same defect rate per unit of work, gives you a bug a week. Holding quality constant is not a neutral outcome at higher throughput — it is a regression in everything downstream of the bug.
Neither remedy is exotic, which is rather the point. Invest the time the coding gain gave you into the pipeline that is now the constraint: comprehensive unit and integration tests, and a dev/integration environment that actually works — including for your dependencies, not just your own service.
The tests do double duty. They are the definition of done the agent reads to know whether it is finished, and the signal it uses mid-run to notice it has gone down a path it should not have. A suite that only reports at the end is a grade; a suite the agent can run is a course correction.
Why "add more copilots" doesn't fix it
The obvious move is to automate the other phases the same way: a ticket bot, a deploy bot, a docs bot. But bolt-on automation per phase reproduces the original problem at a new level — you get islands of automation, each with its own context, none aware of the others. The human stops doing the work and starts doing something arguably worse: ferrying context between bots.
This is the state of most "AI-forward" teams today: Copilot in the editor, an AI summarizer in the PR, maybe an AI triage rule in PagerDuty — three disconnected islands. The coding assistant doesn't know what the incident bot learned last night. The PR summarizer doesn't know what the ticket said. Every seam between them is patched by a human copy-pasting.
The real requirement
What the lifecycle needs isn't more assistants — it's continuity: agents that hand work to each other, carrying context forward, with humans stationed at the points where judgment matters. Not a faster editor. A different lifecycle.
And one more thing, carried forward from the measurement at the top of this sheet. Whatever you change, the claim that it worked has to survive the instrument that already caught sixteen experienced developers being wrong by forty points about their own week. Which means a baseline, measured end to end, before you start.