DORA metrics in the AI era: what engineering leaders should actually measure

What the research found

Google's DORA team surveyed nearly 5,000 technology professionals for its 2025 report, retitled the State of AI-assisted Software Development¹. Some headline figures from Google's summary²:

• AI adoption among software professionals reached 90%, with a median of two hours a day spent working with it.
• Over 80% said AI had improved their productivity.
• Trust is lower: 24% reported a great deal or a lot of trust in AI output, while 30% reported a little or none.

The central finding is that AI works mainly as an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones¹. Reviews of the report note that AI adoption is now associated with higher delivery throughput, but still with lower delivery stability⁵⁶.

What changed in the metrics

For years, DORA's four keys were deployment frequency, lead time for changes, change failure rate and time to restore service. The 2025 work added a fifth, rework rate: unplanned deployments made to fix user-facing problems in production, relative to all deployments⁴⁶. It also replaced the old low, medium, high and elite tiers with seven team profiles, built from a wider set of measures that include wellbeing and friction as well as delivery⁴⁵.

Rework rate is the metric I would add first if a team tracks nothing else. AI-generated code that ships quickly and then needs hot fixes looks like productivity on a throughput chart. Rework rate shows the cost.

Capabilities, not tools

DORA's companion AI Capabilities Model identifies seven practices that amplify AI's benefits. Google's summary includes a clear and communicated AI stance, healthy data ecosystems, quality internal platforms and a strong user-centric focus among them³. None of these is a tool purchase. They are the same foundations that made teams good before AI: small batches, strong version control, good platforms, clear policy.

It is also what I look for in technical due diligence. A team with trunk-based development, fast CI and decent test coverage is positioned to benefit from AI coding tools. A team without them risks producing more code than it can safely review.

How I set up measurement

1. Baseline before rollout. Capture the five delivery metrics for a quarter before changing tools or policies, so improvements are real rather than remembered.
2. Measure from systems, not surveys. Derive metrics from version control, CI/CD and incident tooling. Use surveys for friction and wellbeing, which systems can't see.
3. Pair every speed metric with a stability metric on the same dashboard, so no one can celebrate one without seeing the other.
4. Write the AI stance down: which tools, which data they may see, how AI-written code is reviewed. Record it as an architecture decision record.
5. Review at team level, never individual. DORA metrics describe systems. Used to rank people, they get gamed within weeks.
6. Tie it to product outcomes. Faster delivery of the wrong thing is still waste. Track whether shipped work moves the metrics the business cares about.

What to tell the board

The honest answer to "are we faster?" is a pair of numbers: throughput and stability, before and after, with the trend in rework. If both improve, the investment is working. If throughput rose and stability fell, the next investment is in foundations such as tests, platform and review practice, not more tools. That framing turns AI spending into an engineering decision the board can follow.

How I can help

As a fractional CTO I set up delivery measurement, define AI coding policy and fix the foundations that decide whether AI tools help or hurt. Or analyse your challenge and bring the result to a call.