For a decade, DORA's four key metrics — deployment frequency, lead time for changes, mean time to recover, and change failure rate — gave engineering teams the closest thing the industry had to an objective scorecard. They weren't perfect, but they were directionally honest: teams that deployed more often with lower failure rates genuinely built better software. That relationship is breaking down, and the 2024 and 2025 DORA reports contain the evidence.
Here's the sharp version: AI coding assistants have decoupled deployment frequency from engineering quality. Teams are shipping faster while accumulating structural debt invisible to every DORA dashboard in production. If your engineering health program still centers on the classic four metrics, you are optimizing for signals that no longer reliably point at outcomes.
This isn't a contrarian hot take. It's the conclusion DORA's own researchers are inching toward — even if they won't say it that bluntly. The 2025 report replaced the familiar low/medium/high/elite performance tiers with seven team archetypes. That's not an incremental update. That's an admission that linear performance ranking no longer describes how software delivery actually works.
Start with the most damning finding in the 2024 DORA report. Nathen Harvey, Google's DORA team lead, stated publicly that when teams increase their AI adoption, it is "actually detrimental to their software delivery performance metrics." The numbers behind that statement: a 25% increase in AI adoption correlates with only a 2.1% individual productivity gain, a 1.5% decrease in delivery throughput, and a 7.2% decrease in delivery stability.
Read that again. More AI, less stable software. And yet 76% of software development professionals now rely on AI for at least one daily professional responsibility. The tools are everywhere. The outcomes are declining.
7.2%
Decrease in delivery stability correlated with increased AI adoption — Google DORA 2024 Report
Faros AI's telemetry across 10,000+ developers in 2025 sharpens the paradox. Individual output metrics spike dramatically — 21% more tasks completed, 98% more pull requests merged. Organizational delivery metrics stay flat. They coined a name for it: The AI Productivity Paradox. Individual contributors look extremely productive by any line-item measure. The system delivers nothing faster.
The review queue is where the paradox becomes a crisis. Faros's 2026 dataset of 22,000 developers found median time in PR review is up 441%. And 31% more PRs are merging with no review at all. So you have more code, reviewed more slowly, with a growing fraction bypassing review entirely. Deployment frequency goes up. Quality signal goes dark.
RedMonk analyst Rachel Stephens invoked the theory of constraints in her 2024 DORA analysis, and it's the right frame. The throughput of any system is limited by its bottleneck. For most engineering organizations, writing code has never been the bottleneck — review, integration, testing, and deployment pipeline capacity have been. AI-assisted code generation accelerates the input into an already-constrained system. You're loading more freight onto a bridge that hasn't changed structurally.
This is exactly why platform engineering adoption in the 2024 DORA data showed a counterintuitive result: teams that adopted internal developer platforms saw throughput decrease by 8% and change stability fall by 14%. Not because platforms are bad architecture — they're not — but because shipping faster without addressing downstream constraints doesn't improve the system. It stresses it.
441%
Increase in median PR review time in AI-augmented engineering teams — Faros AI Engineering Report 2026
GitClear's longitudinal analysis of 211 million lines of code from 2020 to 2024 makes this concrete at the code level. Code duplication rose from 8.3% to 12.3% of changed lines — approximately 4x growth. Refactored "moved" lines collapsed from 25% of changed lines in 2021 to under 10% in 2024. Code churn (lines revised within two weeks of authoring) grew from 3.1% in 2020 to 5.7% in 2024, on track to double versus the pre-AI 2021 baseline.
What that means in practice: AI tools like Copilot and Cursor generate boilerplate and test scaffolding that inflates deploy counts without improving architecture. Teams are shipping duplicated, fragile code faster than ever, then returning to patch it within days. None of this registers on a DORA dashboard. Deployment frequency stays high. Change failure rate may even improve in the short window before technical debt compresses into incidents.
There's a human layer under the data layer. The 2024 DORA survey found that 39% of respondents reported little to no trust in AI-generated code. Sonar's 2025 survey found developers estimate 42% of their committed code is AI-assisted. Cross those two numbers: you have teams where nearly half the committed code comes from a source that nearly half the team doesn't trust, and traditional DORA tracking has no visibility into which tools drove which results or created which risks.
This is a new category of risk that DORA's original framework simply wasn't designed to surface. The classic metrics assume a relatively homogeneous code authorship model. When a meaningful fraction of your codebase is generated by stochastic models with known tendencies toward hallucination, duplication, and context collapse, change failure rate becomes a lagging indicator so lagged it's practically useless as a corrective signal.
"AI doesn't fix a team; it amplifies what's already there." — Google Cloud Blog, 2025 DORA Report Announcement
That line from Google's own announcement of the 2025 report is the most honest thing they published. It also quietly concedes that DORA metrics never measured team quality — they measured team output. In a world where AI can dramatically inflate output while degrading quality, output measurement is insufficient.
The shift from four tiers to seven archetypes in the 2025 DORA report deserves more attention than it received. The original elite/high/medium/low model implied a single axis of performance: go faster, fail less, recover quicker, and you climb the ladder. The archetype model acknowledges that teams exist in genuinely different configurations that can't be ranked on a single axis.
The 2025 data reinforces this: only 16.2% of organizations achieve on-demand deployment frequency (the former "elite" threshold), while 23.9% deploy less than once per month. That bimodal distribution doesn't describe a continuous improvement curve. It describes two fundamentally different operating models coexisting in the same industry. A framework that scores both on the same rubric is telling you something, but not the thing you need to know.
The 2025 report also identifies platform quality — not tool choice, not deployment frequency — as the primary determinant of AI value. 90% of organizations have adopted at least one internal platform. The variance in outcomes comes from platform maturity, not from whether teams use Claude or GPT-4o or Gemini. That finding should restructure how mid-market engineering leaders allocate attention. The tool debate is largely a distraction from the systems work that actually determines delivery quality.
Abandoning DORA metrics entirely is the wrong move. The framework still captures real signal at the extremes — a team deploying once a month with a 40% change failure rate has a genuine problem. The issue is using DORA as the primary health signal in AI-augmented environments. Here's what to instrument alongside it:
Track code duplication rate and refactoring ratio over rolling 90-day windows. GitClear's data shows these diverge from deployment frequency in AI-augmented teams before incidents surface. A rising duplication rate with flat or increasing deployment frequency is a leading indicator of future instability, not a sign of health. Tools like SonarQube and CodeClimate expose this at the repo level.
The Faros data — 31% more PRs merging with no review, median review time up 441% — indicates that code review is collapsing under volume pressure. Instrument the ratio of reviewed-to-unreviewed merges by team, and flag trend lines, not thresholds. A team that reviewed 95% of PRs six months ago and reviews 70% today is moving in a direction that will eventually show up in your change failure rate, but DORA won't tell you it's coming.
Raw deployment frequency counts all deployments equally. Churn-adjusted throughput discounts deployments that patch code written in the prior two-week window. GitClear's code churn metric (lines revised within 14 days of authoring) is the most honest single-number proxy for "are we shipping durable work or are we patching our own AI-generated mistakes." Rising churn with rising deployment frequency is the fingerprint of an AI productivity paradox in your own data.
The 2025 DORA report's finding — that platform quality drives AI value more than tool selection — implies you need visibility into where your delivery pipeline actually constrains throughput. Map cycle time by stage (code → review → integration → staging → production) and identify which stage has the longest median and highest variance. This is basic theory-of-constraints analysis. The stage with the longest queue is your bottleneck; no amount of AI code generation improves anything until that constraint is addressed.
4×
Growth in AI-assisted code duplication from 2020 to 2024, per GitClear analysis of 211 million lines of code
Run this four-question diagnostic against your current engineering telemetry:
If you answer these questions and find your DORA numbers look strong while the underlying signals are deteriorating, you're not in a high-performing organization. You're in an organization with a well-instrumented illusion of performance. The gap between those two things is where incidents live.
The teams that navigate this correctly aren't abandoning measurement — they're adding depth to it. They're treating DORA as a floor check rather than a ceiling, instrumenting structural debt and review integrity alongside cycle time, and making platform quality a first-class engineering concern rather than an infrastructure afterthought. That's the architecture of a delivery organization that will still be reliable in 2027, when the code volume generated by AI will make the current numbers look modest.
The kind of engineering pod that builds this instrumentation layer for you doesn't start with a dashboard. It starts with a constraint map — where does your system actually break, and what does "broken" look like before it becomes a production incident. That's the work. Deployment frequency is just a number.
No — discard the dashboard and you lose the floor check. DORA metrics still surface extreme dysfunction: a team deploying once a month with a 40% change failure rate has a real problem. The mistake is treating DORA as a ceiling rather than a floor. In AI-augmented teams, layer structural debt velocity, review integrity rate, and churn-adjusted throughput on top of the classic four. DORA alone gives you speed; the additional signals tell you whether speed is building or destroying the system.
Because AI-assisted workflows can produce that exact profile while accumulating invisible structural debt. GitClear's longitudinal study of 211 million lines of code found duplication rising 4x and refactoring collapsing, even as teams shipped faster. Code churn — lines revised within two weeks of authoring — doubled from 2020 to 2024. Change failure rate is a lagging indicator. By the time incidents surface, the debt has already compounded. Instrument duplication and churn rates now, not after the incident.
The 2024 DORA data found platform engineering adoption decreased throughput by 8% and change stability by 14% on average. The cause isn't that platforms are bad architecture — it's that adding velocity input into a constrained system stresses the constraint. Platforms accelerate code authorship; if your bottleneck is review, integration, or staging, you've made the queue longer, not shorter. Run a cycle-time map by pipeline stage first. Build or optimize the platform against the actual constraint, not the assumed one.
