DORA metrics when agents write most of the changes

Stefan-Iulian Tesoi · 30 October 2026 · 7 min read

Yes, but DORA metrics stop describing the team and start describing the pipeline. Deployment frequency and lead time for changes improve almost automatically once a coding agent commits, so they flatter. Change failure rate and recovery time can still get worse, and they deserve the attention. None of the four sees whether a change was worth making.

The research behind them has already measured the shift. DORA's 2024 report estimated that as AI adoption increased, delivery throughput fell by 1.5% and delivery stability by 7.2%. In the 2025 report, drawn from nearly 5,000 respondents, the throughput relationship had turned positive. The stability one had not.

What do DORA metrics measure once a coding agent commits?

The same things they always measured: how often change reaches production, how long it takes, how often it breaks and how long recovery takes. The four key metrics describe a delivery pipeline, not the people feeding it, which is why they survive agents better than velocity or lines of code.

DORA's own metrics guide now lists five, in two groups:

Two changes to the set matter here. In 2023 the old mean time to restore was redefined as failed deployment recovery time, so that it separates failures a change caused from outages with an outside cause. In 2024 DORA added rework rate, because change failure rate had been acting as a proxy for the rework a team has to do.

Which two improve almost by themselves?

Deployment frequency and lead time for changes. Both reward small changes that move fast, and a coding agent produces small changes quickly as a matter of course.

Deployment frequency rises because an agent finishes an item in minutes and the pipeline ships it. A team that deployed twice a day can be deploying eight times a day within a fortnight of switching agents on, with no change to its testing, its review or its judgement about what to build.

Lead time for changes shortens for a less obvious reason. DORA's clock starts at the commit. An agent commits late in an item's life, after the waiting to be specified and the waiting to start, so the slowest parts of the work now happen before the clock runs at all. What is left inside it is review and the pipeline. The full split is worked through in lead time vs cycle time when agents do the building.

Neither number is wrong. Both now measure the pipeline's speed rather than the team's, and a team that reports them alone is reporting that something was switched on.

Why is change failure rate the one to watch?

Because it is the only one of the four that can catch a faster producer making worse changes. It is also a ratio, and a ratio can improve while the thing it counts gets worse.

Take an illustrative month. Before agents, a team ships 40 deployments and 2 need immediate intervention: a change failure rate of 5%. With agents, it ships 160 deployments and 6 fail: 3.75%. The rate improved by a quarter. The number of incidents tripled, and each of those six was a page, a rollback or a customer who saw an error.

The fix is cheap. Report the count of failed deployments next to the rate, and read rework rate alongside both. A team that fixes forward with another fast agent change often never records the first deployment as failed, because nothing was rolled back. The fix is still unplanned work caused by an incident, which is exactly what rework rate counts.

Recovery time deserves the same attention for a different reason. Diagnosis is still done by a person, and with agents the person on call often did not write the failing change and cannot ask whoever did. Recovery that relied on someone remembering why the code looks the way it does gets slower when nobody remembers.

A change failure rate that falls while deployments quadruple is a smaller share of a larger number. Count the failures too.

Google's announcement of the 2025 DORA report makes the same point in its own terms: without strong automated testing, mature version control and fast feedback loops, "an increase in change volume leads to instability." The checks that let changes through are worth auditing on the same schedule, and quality gates that fail quietly lists the ways they pass work they never inspected.

What do DORA metrics not see?

Everything before the commit, and everything about a deployment that did not break. DORA metrics measure whether change reaches production safely, not whether it was the right change.

• Time before the first commit. Specification, waiting for a decision, waiting to start. With agents this is most of an item's life.
• Whether the change did what was asked. A deployment that meets none of its acceptance criteria but breaks nothing counts as a success.
• Whether anyone wanted it. An agent that builds a could-have nobody decided to own raises deployment frequency.
• Review hours. The scarcest resource on most teams running agents appears in none of the five.

That gap is not a flaw in the research. DORA was designed to measure software delivery, and it does. The mistake is reading a delivery measure as a product measure, which is easy when the delivery numbers are the only ones that moved.

Reading the four key metrics next to a product metric

Each DORA number goes on the report with a partner that falls when the work is bad, and the set sits next to one product outcome. The pairing is what stops the two flattering numbers from carrying the report.

Then add one product metric the quarter's work was meant to move: activation, retention, a support-ticket count. If the four key metrics improve and the product metric does not, the team is shipping faster towards nothing in particular.

Accepted items need a definition the author cannot satisfy alone. In Laimonade, a coding agent hands work back as In Review with its evidence, and no tool lets it move its own item further. An accepted item is one a person closed against its criteria, or that Laimon closed with the closure stamped as its own. The agent-side numbers that explain the supply are in coding agent metrics worth tracking, and the wider stack is in engineering metrics that still work once agents build.

Frequently asked questions

Is DORA's rework rate worth adding?

Yes, and more so with agents. When a fix takes an agent ten minutes, teams fix forward instead of rolling back, and the deployment that caused the incident often goes unrecorded as a failure. Rework rate counts the unplanned deployments an incident forced, so it catches what change failure rate lets through. DORA added it in 2024 for this reason.

Should agent commits be measured separately from human ones?

For diagnosis, yes; for reporting, no. Tagging each deployment with whether an agent wrote it shows whether one source fails more often, which is worth knowing when choosing a model or a configuration. On the report, keep team totals. Many changes are mixed, an agent's draft edited by a person, and a split report invites an argument about attribution instead of a fix.

What is an elite DORA rating worth with agents?

Less than it was. Two of the four key metrics now improve because an agent was switched on, so an elite band on deployment frequency and lead time mostly says the pipeline is fast. Change failure rate and recovery time still carry information. DORA's guide says the goal is "not to compete against other teams or organizations", and that matters more now.