DORA won't run its annual survey this year. DORA said so on LinkedIn in early September and LeadDev reported it on 26 October, and the timing is awkward. The yearly benchmark is gone just as AI coding tools have made the old numbers easy to inflate.
DORA metrics are five measures of software delivery performance from Google's DORA research programme: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. They still work, but which of them you should trust has changed. When agents write a large share of the code, throughput goes up almost by itself, so deployment frequency and lead time stop telling you much. Change fail rate and rework rate are where you find out whether AI is paying for itself. And there's one number DORA never asked for that we'd add: how many merged changes were checked against the running product by something other than their author.
What happened to the DORA metrics survey
The research programme isn't dead. LeadDev reports that DORA will continue in some other form, and a Google spokesperson told it the company is "exploring how we can best support the future needs of developers". No replacement has been named. dora.dev still tells visitors to wait for the 2026 survey.
So the metrics, the definitions and every past report are still there. What's missing is the annual benchmark that told you whether your numbers were good, which means each team now has to decide for itself what good looks like.
The five DORA metrics
DORA splits software delivery performance into throughput and instability.
| Metric | Group | What it measures |
|---|---|---|
| Change lead time | Throughput | Time from commit to running in production |
| Deployment frequency | Throughput | How often you deploy |
| Failed deployment recovery time | Throughput | How long it takes to recover from a deployment that needed immediate intervention |
| Change fail rate | Instability | Share of deployments that need a rollback or hotfix |
| Deployment rework rate | Instability | Share of deployments that are unplanned and happen because of an incident in production |
Rework rate deserves the most attention right now. It catches the unplanned deploy that follows a production incident, which would otherwise count as extra throughput.
Why AI breaks the way teams read them
The 2025 DORA report already showed the split. AI adoption had a positive relationship with throughput and, in the report's words, "continue[s] to have a negative relationship with software delivery stability."
It makes sense once you look at what the throughput metrics count. A merged PR is a merged PR whether a person spent a day on it or an agent produced it in four minutes. When the cost of writing a change falls, deployment frequency rises without anything else about the team improving.
Vilhelm von Ehrenheim, our co-founder and Chief AI Officer, put the hidden part of this well at a CTO Craft session in September: "it might be hidden times in there where you have merged something and then you need to open a new PR and do a fix on those things." That follow-up PR shows up as more throughput, and when it's fixing something users already hit, it's rework.
Some leaders feel this before they can measure it. A VP of R&D at a marketing-tech scale-up told us his organisation had shrunk by about 10% while output went up by 35 to 40%, and in the same breath that his reassurance strategy was "not where I want to be." Vilhelm said much the same at a CTO Craft talk in Amsterdam in October: "the change confidence is going down dramatically."
And most teams aren't measuring it at all. In LeadDev's Engineering Team Performance Report 2026, only 31% of organisations measure the impact of their AI developer tools, and 52% say the biggest bottleneck is now code review and validation.
Hours saved isn't a return
When companies do try to put a number on AI, time is the favourite unit. The Wharton and GBK Collective AI adoption report from October found hours saved is the most common way departments judge AI's return, picked by 40% of them.
For engineering that's an input. An hour saved writing a feature that comes back as an incident just moves to the on-call rota. Daniel Mauno Pettersson, our co-founder and CEO, put the cost side as a question in an internal discussion: "if you spend $5 generating a PR, should you spend 5 cents, $5, $50 to test it? I don't know." It's the right question, and you can't even start on it if the only number you track is how fast PRs arrive.
What a good AI result looks like
The cleanest public example so far comes from the team building Claude Code. In a post on how they review code, they report that merged pull requests more than doubled between June and September while the share that had to be reverted fell by more than 40%.
Look at what they chose to publish: a throughput number and a stability number, side by side, both moving the right way. That pairing is the test. If your throughput doubled and your revert rate doubled with it, the extra volume is costing you.
Between the agent and production they put six layers of checks, with rollback under all of them. Separate agents vote on each bug a reviewer reports, a classifier sets the risk tier from the change itself, and a bot's approval never replaces a required human's. Every layer after the first is run by something other than the author, which is the idea behind proof-carrying pull requests.
The metric DORA doesn't have
Change fail rate and rework rate tell you what went wrong after deploy. By then your users have found it. We'd add a leading indicator that sits before the merge: the share of merged changes that were verified against the running product by something other than their author.
"Tests passed" doesn't count. If the agent that wrote the change also wrote the tests, a green run tells you the code agrees with itself. Verified here means a separate check opened the build, used the changed flows the way a user would, and returned a pass or a fail. That verdict needs room for a third outcome, couldn't verify, alongside pass and fail.
The third one is the one to watch. A rising "couldn't verify" rate means changes are going out that nobody checked, with no red build to warn you. A dashboard that only counts red and green files it with the passes.
Track it next to the DORA five. If verified-before-merge goes down while deployment frequency goes up, expect change fail rate to follow.
A scorecard for teams shipping with agents
| Metric | What it tells you | Where it comes from |
|---|---|---|
| Deployment frequency, change lead time | Whether work is flowing. Expect these to rise with AI; on their own they prove little | Your CI/CD system |
| Change fail rate | How often a deploy needs a rollback or hotfix | Incident and deploy records |
| Deployment rework rate | How much of your deploy volume is unplanned clean-up after production incidents | Deploy records tagged by cause |
| Verified before merge | Share of merged changes checked against a running build by a separate verifier | PR checks history |
| Couldn't-verify rate | Share of changes where the check ran but couldn't reach the change | PR checks history |
| Escaped defects | Bugs found by users or support that a pre-merge check should have caught | Bug tracker |
You don't need all six on day one. If you only add one this quarter, add rework rate. If you add two, add verified before merge.
Where QA.tech fits
Our product won't calculate your DORA metrics. Those still come from your deploy pipeline and incident records. It covers the pre-merge half. QA.tech, an AI testing platform built for high-velocity engineering teams, runs dynamic PR testing on every pull request: it reads the change, picks the existing test cases that cover the user-facing parts, writes test cases for what's missing, runs them against the PR's preview build, or against staging after merge when there's no preview, and posts a pass, fail or unable-to-verify verdict on the PR. Over a month, pre-merge passes and fails give you verified-before-merge, and pre-merge unable-to-verify results give you the couldn't-verify rate. Runs against staging after merge don't count toward the first one.
If you want the deeper argument for why the checker shouldn't be the author, it's in who gates the merge now that agents review every PR.
FAQ
What are the DORA metrics?
Five measures of software delivery performance from Google's DORA research programme. Three measure throughput: change lead time, deployment frequency and failed deployment recovery time. Two measure instability: change fail rate and deployment rework rate.
Is DORA being discontinued?
No. The metrics and definitions stay. DORA said it won't run its annual survey this year, and Google hasn't named a replacement. The definitions and past reports are still published on dora.dev, and teams can keep tracking the five metrics themselves.
Do DORA metrics still work for AI-generated code?
Yes, but read them differently. AI lifts throughput almost automatically, so deployment frequency and lead time say less than they used to. Change fail rate and rework rate show whether the extra volume is actually landing well.
How do you measure the ROI of AI coding tools?
Pair a throughput number with a stability number and watch them together. Merged PRs going up while reverts and rework go down is a return. Merged PRs going up with reverts rising is cost moving downstream. Hours saved on its own doesn't tell you which one you have.
What is deployment rework rate?
The share of deployments that are unplanned and happen because something broke in production. It catches the follow-up fixes that would otherwise count as extra throughput.
What should engineering teams measure before merge?
The share of changes checked against a running build by something that didn't write them, and how often that check couldn't reach the change at all.