The finding that AI adoption correlates with both lower delivery throughput and lower delivery stability is real, frequently cited, and belongs to a specific report: DORA’s 2024 Accelerate State of DevOps Report. The 2025 report — published as the State of AI-assisted Software Development — reversed half of it.
That distinction is the whole story, and it gets lost constantly. “DORA says AI hurts delivery” is now a year out of date on one axis and still accurate on the other, which is worse than being simply wrong, because it is repeatable in a meeting and hard to correct on the spot. So: each year, separately, with the numbers attached.
The 2024 Finding, Exactly As Stated
DORA’s 2024 report modeled AI adoption against the delivery outcomes and found that a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability.
The same report found that the individual-level experience was strongly positive. Roughly 75.9% of respondents reported relying on AI for at least part of their job responsibilities, and about 75% reported productivity gains. Only 39% expressed confidence in AI-generated output.
Hold those two results next to each other, because the gap between them is the actual finding: developers experienced AI as making them faster while the system’s delivery performance moved slightly the other way. DORA’s own reading pointed at larger, less manageable change sets — code produced faster, batched bigger, and pushed through a review and release process that was never sized for that volume.
Note the magnitudes honestly. A 1.5% throughput decrease for a 25% adoption increase is a small effect. The 7.2% stability decrease is nearly five times larger. Even in 2024, the finding was less “AI slows you down” than “AI degrades stability meaningfully and throughput marginally,” and the headline flattened that.
The 2025 Report Reversed the Throughput Half — and Only That Half
DORA’s 2025 research, built on a survey of nearly 5,000 technology professionals plus more than 100 hours of qualitative interviews and Bayesian modeling, found that AI adoption now shows a positive relationship with software delivery throughput — a direct reversal of the prior year — while continuing to correlate with increased delivery instability.
So the current state of the evidence, cited properly, is: as of the 2025 report, teams adopting AI are shipping more, and shipping less stably. The throughput objection has expired. The stability objection has survived two consecutive report cycles with the sign unchanged, which is the more interesting result — a finding that persists while its neighbor flips is a finding worth taking seriously.
The mechanism DORA describes is that friction relocates rather than disappearing. Effort moves off manual implementation and onto deciding what to accept and verifying that it is correct. If a team’s review, testing, and release capacity did not expand to absorb that shift, the additional volume lands somewhere — and it lands in change failures and rework.
“Amplifier” Is the Useful Frame
The 2025 report’s central characterization is that AI acts as an amplifier: it magnifies an organization’s existing strengths and its existing dysfunctions rather than substituting for either. Organizations getting throughput gains without the stability penalty are, in DORA’s account, the ones that had strong foundational practices before adding AI to the pipeline.
This is a more actionable claim than it first sounds, because it makes the diagnostic question specific. The question is not “is AI good for delivery.” It is “what does our system do with 30% more change volume.” A team with fast, trustworthy automated tests, small batch sizes, and a working rollback path absorbs that and ships more. A team whose release process already depended on a slow manual review as its real quality gate gets the volume without the gate scaling, and the failure rate follows.
DORA published an accompanying AI Capabilities Model alongside the 2025 report, aimed at exactly this: identifying which organizational capabilities determine which side of that split a team lands on.
Rework Rate, and the Limits of the Original Four
Reporting on the 2025 research describes a fifth delivery metric entering the frame — rework rate — alongside deployment frequency, lead time for changes, change failure rate, and time to restore service.
The reasoning is sound whether or not you adopt the metric formally. The classic four measure how fast changes move and how often they break. None of them cleanly captures work that shipped, did not technically fail, and had to be substantially redone. That category is precisely where AI-accelerated output would be expected to accumulate: code that passes review and tests, goes out, and then gets rewritten because it was not right. A team measuring only the original four can see stable change-failure numbers while its engineers spend a growing share of their time redoing recent work.
What This Means for Instrumenting Your Own Team
Two caveats belong on all of the above before anyone acts on it. These are correlational findings from self-reported survey data, not causal results from controlled trials — DORA is careful about this and consumers of DORA usually are not. And they are population-level: they describe what happens across thousands of teams, not what will happen to yours.
Which is the argument for measuring your own. The practical version:
Cite the year, always. “DORA 2024 found X, DORA 2025 found Y” is the only form of this citation that survives contact with someone who has read both. Report years matter because the findings genuinely changed.
Track stability separately from throughput and expect them to move in opposite directions. A dashboard that reports a single composite “delivery health” number will hide exactly the effect both reports found.
Measure rework explicitly. Whatever proxy fits your tooling — commits reverting recent commits, PRs touching code merged in the last sprint, tickets reopened after close. If AI adoption is going to cost you somewhere, current evidence says this is where.
Assess the foundation before expanding the tooling. If test suites are slow or flaky, if batches are large, if rollback is manual, the amplifier finding says AI adoption will make those worse before it makes anything better. That is a sequencing conclusion, not an argument against adoption.
