Accelerating code production without changing the rest of the process doesn't speed up delivery; it speeds up the arrival of problems in production. A development team's speed isn't measured by how fast they write code, but by how quickly they can safely make changes, and those two things have become increasingly decoupled over the past two years.
It is a measured phenomenon, not a suspicion.
Google Cloud's 2024 DORA report, which surveyed some 39,000 professionals, found that a 251% increase in AI adoption correlated with a drop in 1.5% in delivery throughput and from 7.2% in stability. The explanation offered by the authors themselves is not that the code is worse, but that the size of the change batches is increasing: more is sent at once, it is reviewed less thoroughly, and it is deployed with more risk.
The METR study from July 2025 added a further layer. In a controlled trial with 16 experienced developers on 246 real-world tasks, participants took 191 TP3Ts longer using AI assistance, even though they expected to be 241 TP3Ts faster and, after the test, still believed they had been 201 TP3Ts faster. It's worth noting that METR itself reviewed that design in 2026 for potential selection bias, and a larger cohort showed a much smaller difference: the exact result is under debate.
What is not in dispute is the secondary finding, and it is the important one for any direction: The perception of speed and the actual speed are separate.. A team may feel like it's moving much faster, even though the system takes longer to reach production.
The size of the change is the hidden variable behind most delivery problems. A small change is thoroughly reviewed, fully tested, deployed quickly, and if it fails, the cause can be identified in minutes. A large change doesn't allow for any of that.
Variable | Small change | Big change |
|---|---|---|
Quality of the review | It is fully understood | «"It seems reasonable"» |
Test coverage | Verifiable | Partial in practice |
Diagnostic time if it fails | Minutes | Hours or days |
Cost of reversing | Low | Stop: It's dragging other things along. |
Deployment risk | Limited | Accumulated |
Until recently, the effort of writing code acted as a natural limit on batch size. With that limit gone, batch size grows unless someone explicitly decides to restrict it. That decision—limiting the size of changes—is probably the most cost-effective intervention available to a development team today.
Measuring lines of code, completed tasks, or "productivity per developer" actively worsens the situation because it rewards the very behavior that causes the problem. The four DORA metrics remain the reasonable standard:
Deployment frequency. How often is something taken into production? High frequency implies small batches.
Delivery time for the change. From the moment it's written until it's in production. It measures the entire process, not just the writing itself.
Change failure rate. What percentage of deployments results in an incident? This is the counterweight to speed.
Service restoration time. How long does it take to recover? It measures the actual capacity to operate.
The first two measure speed, the last two stability, and they must be considered together. A team that improves the first two but worsens the last two hasn't improved: it has simply shifted the work to the future and the support team.
Limit the size of the changes. The simplest and most effective measure. It forces the work to be broken down into understandable units and restores quality to the review.
Invest in testing before speed. As more code is generated, the safety net matters more, not less. Without reliable testing, throttlebacking is a repeated gamble.
Automate deployment and rollback. If deployment is expensive, the team will accumulate changes until it's worthwhile, and the large batch will return.
Measure stability with the same visibility as speed. If the committee dashboard only shows deliveries, the team will optimize deliveries.
Do not reward isolated speed. Incentives produce behavior. If what is sent is celebrated rather than what is endured, more is sent and less is endured.
The expectation within many committees is that AI assistance should translate into delivering twice the amount within the same timeframe. This expectation is what generates the pressure that undermines stability.
The honest conversation has two parts. First: code generation has indeed accelerated in a real and measurable way. Second: delivery is a broader process—understanding, reviewing, testing, integrating, deploying, and operating—and it only accelerates when the whole package is addressed.
Translated into a sentence that works in a council: We have reduced the cost of one part of the process, not the entire process.. Taking advantage of that improvement requires investing in the rest, not demanding double the same.
This is the same conclusion reached from the architectural perspective, and that is why the debate has returned to design rather than execution, as we discussed in The bottleneck is once again architecture
It accelerates code generation, but not necessarily delivery. The 2024 DORA report found that a 25% increase in AI adoption correlated with a 1.5% drop in throughput and a 7.2% drop in stability, attributed to the growth in change batch sizes.
Because it determines the quality of the review, the actual coverage of the tests, the time it takes to diagnose when something fails, and the cost of reverting. The effort of writing code acted as a natural limit on size; with that limit gone, it must be explicitly restricted.
The four DORA metrics are: deployment frequency, change delivery time, change failure rate, and service restoration time. The first two measure speed, and the last two measure stability; they should be read together.
A 2025 METR trial measured a 19% delay in experienced developers who expected to accelerate by 24%. METR itself later reviewed the design for potential biases, and a larger cohort showed a smaller difference. The consistent finding is that perceived speed and actual speed diverge.
Reliable automated testing, automated deployment and rollback, and an explicit limit on the size of changes. As the volume of changes increases, the safety net and the ability to roll back become more important, not less.
Because they reward the behavior that causes the problem: producing more volume without ensuring that it reaches production reliably. The incentive determines the behavior, and measuring output instead of results shifts the cost to support and future needs.
Does your team deliver faster or just produce more? We analyze the entire delivery process —review, testing, deployment and operation— and tell you where the real bottleneck is. Let's talk →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
