By Nnenna Ndukwe, Developer Relations Lead @ Qodo
Last week, an engineering director told me their deployment frequency was up since adopting AI coding tools.
"Congratulations!" I said. "What about your change failure rate?"
Awkward silence.
"Also up."
I hear a version of that conversation every month.
AI made code cheap to write, so more of it waits in review, and review sits right inside three of the five DORA metrics. So let's go back to basics, covering what DORA measures, what the 2026 data says, and which metrics AI code review can actually move.
TL;DR
- DORA tracks five delivery metrics in two groups. Lead time, deployment frequency and recovery time measure throughput; change failure rate and rework rate measure instability.
- Review is the bottleneck. 25.8% of developers name reviewing and validating AI-generated code as their primary delivery constraint (State of AI Code Quality 2026 from Qodo, the AI code review platform, August 2026).
- Clean-looking AI code still breaks. 94% of tech leaders rated AI-written code as higher quality at review, yet 78% reported more production incidents (New Relic survey of 200 US tech leaders, June 2026).
- AI code review moves three of the five. Lead time, change failure rate and rework sit at the review step. Deployment frequency and recovery time belong mostly to the pipeline.
What Are DORA Metrics?
DORA, the DevOps Research and Assessment program, defines software delivery performance in two groups. Throughput covers how many changes move through the system, and instability covers how well deployments go (DORA metrics guide).
- Change lead time (throughput). Time from commit to running in production.
- Deployment frequency (throughput). How often you deploy, or the time between deploys.
- Failed deployment recovery time (throughput). Time to recover from a deployment that needs immediate intervention.
- Change failure rate (instability). The share of deployments that need a rollback or hotfix.
- Deployment rework rate (instability). The share of deployments that are unplanned and caused by a production incident.
DORA started with four keys, added rework rate, and replaced mean time to restore with failed deployment recovery time. Older dashboards still use the four-key names, so check which version yours shows.
DORA also says the metrics work best for one service at a time, and that speed and stability aren't trade-offs for most teams. A team watching only throughput can celebrate a quarter in which change failure rate climbed behind the scenes.
Are DORA Metrics Still Relevant in 2026?
Yes. DORA announced in September 2026 that it wouldn't publish a 2026 State report, and its publications page still lists the 2025 report as the newest. The five definitions haven't changed.
DORA's April 2026 ROI guide describes AI adoption as a J-curve, with a dip driven partly by a verification tax, the time people spend checking AI output. Review is where most of that tax gets paid.
Why AI Is Hitting Your Review Queue
A Harvard Business School working paper with Jellyfish data (January 2026, revised November 2026) found AI coding agents raised the number of PRs and the review time per PR across hundreds of firms, while resolved work barely moved. More code reaches review, and each change takes longer there.
DORA's March 2026 insights piece gives four pieces of review advice. Give the author AI feedback while they write, use context-aware review agents that check organizational standards, work in small batches, and revisit how your team runs async reviews (DORA Insights, March 2026).
How AI Code Review Improves Each Metric
Lead Time for Changes
A PR that waits a day for its first human review adds a day to lead time, however fast the code was written. An AI first pass lands within minutes, so the author fixes the obvious problems before a human looks, and the human starts from findings instead of a blank diff.
Batch size matters as much as wait time. Smaller PRs clear review on their own. No 2026 cross-company dataset measures how AI review changes lead time, so measure your own and treat claimed percentages with care.
Change Failure Rate
Review is the last check before deploy. Across 33,580 agentic PRs, 2.66% contained at least one reverting commit, and the top causes were unintended side effects and functional incorrectness (MSR 2026 mining challenge study, April 2026).
Side effects are hard to spot in a diff, because the code that breaks lives somewhere else. A reviewer needs cross-repo context to flag them.
Deployment Rework Rate
DORA's rework rate counts unplanned deploys after an incident. 74% of leaders say at least a quarter of AI-generated code needs significant rework (New Relic, June 2026). Fixes made before merge never become unplanned deploys, so review is the cheapest place for that rewriting.
Rework only drops if people act on the findings. Count accepted findings, not comments.
Deployment Frequency and Recovery Time
Both belong mostly to the pipeline, which means build times, tests, feature flags, on-call and rollback tooling. Smaller, cleaner PRs help teams deploy often, and a PR with a clear summary is easier to roll back under pressure. I wouldn't claim a frequency or recovery gain from review alone.
Where Qodo Fits
Qodo works on the three metrics review controls, which are lead time, change failure rate and rework. A reviewer separate from the writing agent brings its own context, so it's less likely to share the author's blind spots.
Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, the review stage is where teams can move lead time, change failure rate and rework the most.
Choose Qodo When Change Failure Rate Is the Number to Move
Qodo reviews each PR with cross-repo context, so a change that breaks a related repository gets a finding before it becomes a revert. Review presets let a team lean toward Recall when failures matter most, or Precision when noise does.
Choose Qodo When You Want Feedback Before the PR
The Agentic Toolbox runs Qodo's review on local changes before a PR exists, through the CLI, the Claude Code and Codex plugins or a Kiro Power, which is the author-side feedback DORA recommends. Dave compares tools for that step in Review Before the PR.
Choose Qodo When Rules Should Come From Your Team
On GitHub, GitLab and Azure DevOps, Qodo's rules detection agent turns review comments your developers accepted into rules, so the defects that caused last quarter's rework become checks on next quarter's PRs. Qodo flags; your team decides what changes and what merges.
Every team gets the same outcome, agent code merged sooner with fewer rollbacks.
- Enterprise engineering teams get one rule set across many repos and agents, and exportable review data next to their DORA dashboard.
- High-velocity teams keep the rule files they already have, and Qodo checks them on every PR, with setup measured in minutes, so small PRs keep moving.
Read Review Data Next to Your DORA Dashboard
- Median time to merge next to lead time. If time to merge drops while lead time doesn't, the bottleneck has moved to the pipeline. Qodo's median time to merge has data from 29 September 2026, so start the comparison there.
- Where findings were raised next to lead time. A growing share caught locally is the author-side shift DORA describes.
- High-severity acceptance rate next to change failure rate. A falling acceptance rate is an early warning.
- Cross-repo findings next to rework rate. Each accepted cross-repo finding is a break caught before it could become an unplanned deploy.
For the wider list of metrics, Dave's list of code review metrics pairs well with these four.
Five Mistakes When Measuring DORA With AI in the Loop
- Scoring individuals. DORA metrics describe a service and a team, and ranking developers invites gaming.
- Reading deployment frequency alone. More deploys with a climbing change failure rate is worse delivery.
- Blending services. An average across a mobile app and a mainframe tells you little about either.
- Expecting gains in month one. Budget for the J-curve dip.
- Treating comments as impact. Count findings people act on.
Record a baseline per service, change one thing at a time, and read all five metrics together.
The Bottom Line
AI made velocity gains feel easy, and the instability side is where the bill arrives. Review sits inside lead time, change failure rate and rework, so a reviewer with system context and findings people act on is the fix. The fix isn't "deploy less." The fix is "review better."
FAQ
What are the 5 DORA metrics?
The five DORA metrics are change lead time, deployment frequency, failed deployment recovery time, change failure rate and deployment rework rate. DORA groups the first three as throughput and the last two as instability.
Can AI code review improve DORA metrics?
AI code review can improve lead time, change failure rate and rework rate, because review sits between commit and deploy. Qodo's analytics show median time to merge and accepted high-severity findings, so you can see review improve before the DORA numbers move.
Can quicker review raise change failure rate?
Quicker review can raise change failure rate if quicker means less scrutiny. Aim for quicker first feedback with the same defect catch or better, and watch accepted high-severity findings next to change failure rate.
Is Qodo a test generation tool?
Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, that focus is what moves the review-side DORA metrics.
Top comments (0)