DevOps Metrics in 2026: What to Measure When AI Writes the Code

A guide for chief information officers, chief technology officers, engineering leaders and transformation sponsors. What DevOps metrics still measure correctly, what they miss once AI writes a large share of the code, and what evidence a finance function will actually accept.

The short answer

The trap in 2026 is not that teams lack metrics. It is that AI moves the two numbers executives watch most in opposite directions. Google's DORA research programme found that AI adoption has a positive relationship with software delivery throughput and product performance, and at the same time a negative relationship with software delivery stability. A dashboard showing more deployments and shorter lead times is therefore not evidence that AI is working. It is consistent with AI working, and equally consistent with a team shipping faster than its safeguards can absorb.

Everything below is about telling those two situations apart.

Why "DevOps metrics" is now the wrong question

The framing has moved, and the clearest evidence comes from the research programme that defined the field. In 2025, DORA renamed its annual publication from the Accelerate State of DevOps Report to the State of AI-assisted Software Development report. The measurement discipline did not disappear. The category it sat inside stopped being the useful unit of analysis.

That matters for how you scope a measurement programme. "DevOps metrics" describes an engineering practice. The question an executive is now asked to answer is broader: the organisation has bought AI tooling, engineers report that it helps, and someone has to establish whether that belief survives contact with evidence. DORA's 2025 research, drawn from roughly 5,000 technology professionals and more than 100 hours of interviews, found that around 90% of respondents use AI at work and more than 80% believe it has increased their productivity. It also found that about 30% report little or no trust in the code AI generates.

Hold those two findings together. A large majority believe they are more productive. A substantial minority do not trust the output. Both can be true at once, and neither is a measurement. That gap is the reason this article exists.

What the DORA metrics actually are in 2026

There are five, not four. This is the single most common factual error in current writing on the subject, including the earlier version of this article, and it matters because two of the five were introduced specifically to catch the failure modes AI makes more likely.

Two details are worth pulling out, because most secondary summaries get them wrong. First, DORA groups failed deployment recovery time under throughput, not stability. Recovery speed is a property of how fast your delivery system moves, not of how often it breaks. Second, deployment rework rate exists because change fail rate was acting as a proxy for something else: the volume of unplanned work a team is absorbing. Separating them was a deliberate correction, and it is the metric most likely to expose an AI-accelerated team that looks fast and is quietly running on repair work.

If your dashboard still reports four metrics and calls the fourth one MTTR, it is measuring the 2022 version of this problem.

Three things AI breaks in your measurement

1. The instability tax

DORA's ROI of AI-Assisted Software Development report, published in 2026, names this directly: organisations underestimate the instability tax that arrives when deployment volume rises faster than the safeguards around it. Review capacity, test coverage, release gating and on-call load were all sized for the previous rate of change. AI raises the rate of change first and the capacity of those systems second, if at all.

This is why throughput improvements should never be reported without the two instability metrics attached. A 40% rise in deployment frequency alongside a rising deployment rework rate is not a productivity gain. It is a queue moving from one place to another, and the fix is a flow-design problem rather than a measurement one: see where work in progress limits belong once AI does the work.

2. The perception gap

Self-reported productivity is the weakest evidence in this entire domain, and there is unusually direct research on the point. In July 2025, METR ran a randomised controlled trial with 16 experienced open-source developers across 246 tasks. Developers took 19% longer to complete tasks when allowed to use AI tools, while estimating afterwards that AI had made them roughly 20% faster.

That result has been quoted very widely, and it is now quoted incorrectly. In February 2026, METR published an update withdrawing the design, not the honesty of the original measurement. Selection effects had compromised the signal: developers increasingly declined to participate without AI access, and those who did participate avoided submitting the tasks where AI would help most. METR's own conclusion is that "the true speedup could be much higher among the developers and tasks which are selected out of the experiment."

The correct reading is narrower than either camp wants. The 19% figure should not be cited as evidence that AI slows developers down. What survives is the finding that matters more for governance: in that trial, self-assessment and measured completion time pointed in opposite directions. Perception was not a reliable proxy for performance. If your evidence base is a developer survey, you have a sentiment reading, and you should label it as one.

3. Code volume as a proxy

Lines of code, commits, pull requests and percentage of code AI-generated are the metrics most readily available and the least informative. They were weak proxies for output when humans wrote every line. When a tool can generate volume on demand, they stop being proxies at all and become a measure of tool usage.

DORA's framing in the ROI report is the useful correction: value comes not from the code AI writes, but from the bottlenecks it clears. That reframing is what makes the second measurement layer necessary.

A three-layer measurement model for enterprises

This section is MASSIVUE practitioner guidance rather than published research. It exists because DORA's work gives engineering organisations a rigorous value model, and boards ask for a different artefact than the one engineering produces.

Layer 1: the delivery system

Owner: engineering leadership. Evidence: instrumented, not surveyed. This is DORA's five metrics, reported as throughput and instability together, never separately. The purpose of this layer is not to prove value. It is to establish whether the system is stable enough that any value claim above it is credible. A team with a rising rework rate has not yet earned the right to make a productivity claim.

Layer 2: engineering economics

Owner: engineering leadership jointly with finance. Evidence: cost data and constraint analysis. Two things belong here. The first is the full cost denominator: licences plus consumption-based inference costs plus the governance, review and security capacity added to absorb the new volume. Seat cost alone understates it. The second is constraint: which specific bottleneck in your delivery flow has moved, and by how much. If no constraint moved, the tooling produced local speed and no system throughput, which is the most common quiet outcome.

Layer 3: business outcome

Owner: the accountable business sponsor. Evidence: outcomes with a stated counterfactual. Cycle time to a released customer-facing capability, cost per unit of delivered change, incident cost, or revenue attached to features that shipped earlier than they otherwise would have. The counterfactual is the part enterprises skip, and it is the part a finance function will ask for first. "Faster than last year" is not a claim. "Faster than the same team on comparable work before adoption, with the baseline recorded before the tools arrived" is.

The layers are sequential in credibility. A layer 3 claim built on an unstable layer 1 will not survive scrutiny, and should not.

What the evidence supports, and what it does not

Search results on this topic are saturated with confident benchmark figures published by vendors selling measurement tooling. Specific multipliers for return on investment, percentages of AI-authored code and hours saved per developer per week circulate widely without traceable methodology. Treat them as marketing until a method is published.

The table below separates what is currently supported by primary research from what is not.

One figure deserves particular care. DORA's ROI report includes a worked model for a 500-person engineering organisation showing roughly 11.6 million dollars of first-year value against 8.4 million dollars of investment, giving a 39% return and an eight-month payback. That is an illustrative model demonstrating a method. It is not an observed average, and quoting it as a benchmark for your own organisation misrepresents the source.

The J-curve: why year-one numbers mislead

DORA's ROI report describes value realisation as a J-curve. Performance dips before it rises, driven by learning curves, the verification overhead of checking AI output, and downstream processes that have not yet been redesigned around the new rate of change.

The governance consequence is specific. If you measure at a single point inside the trough and treat the result as a verdict, you will withdraw funding from an initiative that was behaving exactly as the research predicts. DORA lists this as one of the common mistakes organisations make, alongside pursuing headcount reduction instead of retraining, and neglecting the process redesign that makes the gains available in the first place.

The practical instruction: fix the measurement cadence and the review point before you start, and commit to a horizon long enough to contain the dip. Deciding the horizon after seeing the first bad number is not measurement, it is negotiation.

How to build the baseline

Five steps, in order. The sequence matters more than the sophistication.

1. Record the baseline before the tools arrive. Capture all five DORA metrics for a defined set of teams over a period long enough to be representative. Once adoption is under way this is unrecoverable, and retrofitted baselines are the most common reason a value case cannot be defended.
2. Name the constraint you expect to move. Write it down in advance: review latency, environment provisioning, test cycle time, defect rework. A prediction made beforehand is evidence. An explanation constructed afterwards is not.
3. Build the full cost denominator with finance. Licences, inference consumption, and the added review, security and governance capacity. Agree it jointly so it is not relitigated at the review point.
4. Set the cadence and the horizon before you start. Decide the reporting rhythm and the point at which a genuine funding decision is made, with the J-curve explicitly accounted for.
5. Report throughput and instability together, always. Make it structurally impossible to present a speed improvement without the stability position beside it. This single reporting rule prevents most of the failure modes in this article.

Two failure modes are worth naming explicitly, because they survive good intentions. Metrics attached to individual performance review stop measuring anything within a quarter, since every one of these numbers can be influenced by the people being measured. And treating the measurement programme as an engineering deliverable rather than a joint one with finance produces a report that is technically sound and commercially unusable.

Work with MASSIVUE

MASSIVUE is a consulting and academy firm working across AI, sustainability and enterprise transformation. The reason we treat measurement and capability as one problem is the reason set out above: the J-curve dip is largely a capability gap, and organisations that respond to it by cutting rather than training convert a temporary trough into a permanent one.

• AI Transformation covers operating model design, governance and the decision rights that determine who owns a value claim, built on the Protum AI operating model framework.
• AI Workforce Transformation addresses the capability side of the J-curve directly, with role-specific training rather than general awareness sessions.

Two MASSIVUE Academy micro-credentials map to this topic specifically. AI-Powered Program & Delivery Management covers using AI in delivery without fooling yourself about the productivity gains, which is the discipline this article describes. Total Economic Impact of AI covers how AI value is quantified: benefits, costs, risk adjustment, and building a model a finance function will accept.

Related reading: Closing the AI ROI Gap, What Is an AI Operating Model?, Why Enterprise AI Pilots Stall Before Production, and Does Kanban Still Work When AI Does the Work?.

Frequently asked questions

What are the DORA metrics?

DORA's five software delivery performance metrics are change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. The first three are grouped as throughput and the last two as instability. Many sources still refer to four metrics, which reflects the framework as it stood before deployment rework rate was added in 2024.

Are DevOps metrics still relevant when AI writes the code?

Yes, and they become more important rather than less, because they are the only layer that is instrumented rather than self-reported. What changes is sufficiency. They describe the health of the delivery system but say nothing about cost or business outcome, which are the two questions asked when AI spend is being reviewed.

How do you measure the ROI of AI coding tools?

Establish a pre-adoption baseline of delivery metrics, build a cost denominator that includes consumption and governance costs rather than licences alone, identify the specific constraint you expect to move, and measure against a stated counterfactual over a horizon long enough to contain the initial productivity dip. DORA's 2026 ROI report provides a published method for the value model.

Did a study show AI makes developers slower?

METR's July 2025 randomised trial found experienced open-source developers took 19% longer with AI tools, but METR published an update in February 2026 stating that selection effects made the result an unreliable measure of current productivity effects, and that the true speedup could be higher among excluded developers and tasks. The durable finding is that developer self-assessment diverged from measured performance, not that AI slows people down.

What percentage of our code should be AI-generated?

This is not a useful target. The share of AI-authored code measures tool usage, not value, and setting it as a goal creates an incentive to generate volume. DORA's framing is more useful: assess AI by the bottlenecks it clears in your delivery flow, not by the code it produces.

Who should own AI productivity measurement in an enterprise?

Ownership should be split by layer. Engineering leadership owns delivery system metrics, engineering and finance jointly own the cost and constraint layer, and an accountable business sponsor owns the outcome claim. Assigning the whole programme to engineering produces a technically correct report that finance cannot use, which is the most frequent structural failure.