More than three out of four engineers now use AI for at least one daily task, according to Google’s 2024 DORA report, the largest running study of how software actually gets delivered. That is the headline most leadership decks stopped at. The number in the same report that nobody put on a slide: for every 25 percent jump in AI adoption, the researchers estimated that delivery stability dropped by 7.2 percent and delivery throughput dropped by 1.5 percent.
Read that again, because it inverts the story most teams are telling themselves. The tools that make it faster to produce code are, on average, making it slower and riskier to actually ship that code to customers. The bottleneck did not disappear. It moved, and it got worse.
Writing code was never the constraint
Here is the assumption buried inside “AI makes engineering faster”: that the time cost of building a product lives at the keyboard, in the act of typing code. For a decade of delivery research that has not been where the cost lives. Work spends most of its life waiting, in review, in integration, in testing, in the queue for a release slot. Speeding up authorship while leaving everything downstream untouched is like widening one lane of a highway and being surprised the traffic jam simply relocated to the next merge.
The DORA data names the mechanism plainly. When AI enters the coding process, batch size goes up. It becomes cheap to generate more code, so people generate more code, and larger changesets are harder to review, harder to test, and harder to diagnose when something breaks. DORA’s summary of the finding is blunt about the through-line of their research: the way you improve delivery performance is to ship smaller changes, and AI is quietly pushing teams in the opposite direction. The productivity gain is real at the individual level, and 39 percent of respondents reported little to no trust in the AI-generated code they were shipping. More output, less trust, bigger batches. That is not a recipe for faster delivery. It is a recipe for more rework.
The verification work did not get cheaper
There is a reason this catches good teams off guard. For years the delivery research told a genuinely optimistic story: speed and stability are not a trade-off. The teams that deploy most often also fail least, because the practices that produce speed, small batches and automation and fast feedback, are the same practices that produce stability. That is the core finding DORA has replicated across tens of thousands of teams, and it held for a decade. I wrote about the operational version of it in why the big, carefully batched release is usually the riskiest way to ship.
AI is the first input in years to pull those two lines apart, and the reason is instructive. Faster authorship increases the volume of change flowing into a system whose verification capacity stayed fixed. Review, testing, and integration are still done at the same rate by the same people. When you pour more change through a pipe of the same width, the pipe does not run faster. It backs up, and the pressure shows up as instability: more failed changes, longer recovery, more time spent untangling which of the many things in a large changeset actually broke.
I saw the non-AI version of this years before the current tools existed. On a fractional COO engagement, a team adopted a code-generation and scaffolding setup that roughly doubled how fast they could stand up new functionality. Everyone celebrated the velocity. Two months later their incident rate had climbed and their releases were arriving late, because the same three reviewers were now the choke point for twice the volume, and nobody had funded that side of the equation. The tool made the cheap part cheaper and the expensive part more expensive. The delivery numbers told the truth long before the retrospective did.
What product managers actually own here
This is a delivery problem, which means it is not something to hand entirely to engineering and walk away from. The batch size that DORA is warning about is downstream of decisions product managers make every week: how work is sliced, how much gets bundled into a release, whether a feature ships in provable increments or waits until every piece is done. AI changes the economics of one input, not the physics of flow. The product manager’s job is to make sure the team does not spend its new authoring speed on bigger, riskier batches.
Three moves keep the gain from turning into instability.
Protect batch size on purpose. If AI lets the team produce a feature’s worth of code in a day, resist the temptation to ship a feature’s worth of change in one release. The same discipline that made small releases safe before AI makes them safe now, and it is worth revisiting how limiting what a team starts at once protects delivery. Faster typing is not permission to widen the batch.
Fund the verification side, not just the authoring side. If the team’s output capacity doubled and its review and testing capacity did not, you have engineered a bottleneck on purpose. That might mean more automated test coverage, more review capacity, or simply accepting that the human parts of delivery now gate more work and staffing accordingly.
Measure what shipped, not what got written. Lines of code produced, tickets closed, and story points burned all look better with AI in the loop while the thing customers actually feel, working software in their hands, gets no faster. This is the same trap I described in why rising velocity can mean nothing ships faster. Watch change failure rate and time to restore, not authoring throughput.
The 2024 data is a snapshot, not a verdict on AI. Every one of those downstream effects is fixable, and the teams that fix them will get both the speed and the stability. But it only happens if someone treats delivery as a whole system rather than cheering the one part that got faster. The AI wrote the code in half the time. Whether that turns into a product your customers can rely on is still a decision, and it is largely yours.