DORA Metrics in 2026: Artificial Intelligence Speeds Up Delivery, and Stability Pays for It
Adopting artificial intelligence in software delivery correlates with more throughput and more instability. Production telemetry shows why: most failures come from capacity limits, not from the model. What that changes in DORA metrics and for whoever owns the platform.
For two years the conversation about artificial intelligence in software development has been a conversation about speed. Ship faster, write faster, review faster. That part held up, and it is measured.
What is also measured, and travels far less, is what happens on the other side. The same research that records the speed gain records, year after year, that delivery stability does not keep pace. And production telemetry shows exactly where it is lost.
What changed in the industry's reference report
DORA, the research programme that has measured software delivery performance for over a decade, changed both its name and its method in 2025. It became the State of AI-assisted Software Development, and it dropped the performance clusters everyone used to quote, the four tiers from low to elite, replacing them with seven archetypes built on eight measures.
The change is not cosmetic. Tiers described teams along a single axis, from worst to best. Archetypes accept that a team can ship a great deal and be unstable, or be stable and slow, and that these are different situations rather than degrees of the same one.
Anyone still quoting "elite performer" from 2025 data is quoting a category that no longer exists.
Adoption is no longer the interesting variable
When almost everyone adopts a practice, adoption stops explaining differences in outcome. The useful question becomes a different one: what separates the organisations where artificial intelligence produced a sustained gain from those where it produced a gain followed by more incidents.
The pattern that does not go away with more adoption
The 2025 research is consistent on one uncomfortable point. Use of artificial intelligence correlates positively with delivery throughput, with perceived individual effectiveness, and with organisational performance. And it correlates, at the same time, with greater delivery instability.
Worth pausing here, because the easy reading of that result is wrong. It does not say artificial intelligence degrades code quality. It says the volume and cadence of change rise faster than the system's capacity to absorb them safely.
The conclusion the report itself draws is that the defining challenge is no longer speed. It is stability.
What production telemetry shows, and surveys do not
The figures above come from a survey. What follows comes from direct observation, which gives it a different weight.
This is the figure that changes the nature of the problem. Most artificial intelligence failures in production are not a model problem. They are a problem of quotas, rate limits, concurrency and sizing. In other words, infrastructure.
There is a second detail in the same source that makes the arithmetic worse. Seven in ten organisations run three or more models in parallel, which multiplies the points where a limit can be hit, and spreads responsibility across different vendors with different rules.
Why it is a platform problem, not a model problem
Put what the two sources say side by side, and the picture closes.
The survey says delivery accelerates and stability suffers. The telemetry says that when the artificial intelligence layer fails in production, the dominant cause is capacity. Both point to the same place: the architecture serving the models, not the models it serves.
That has an uncomfortable practical consequence for whoever decides investment. The answer to instability associated with artificial intelligence is not switching model, tuning prompts, or waiting for the next release. It is platform engineering work: explicit limits, controlled degradation when a quota runs out, isolation between services sharing the same vendor, and instrumentation that tells a model failure apart from a capacity failure.
None of that comes with a subscription.
The metric that now decides
DORA metrics organise along two axes. Throughput, which brings together deployment frequency, lead time for changes, and since 2024 also time to restore service. And stability, which brings together change failure rate and the more recent rework rate.
What usually goes unnoticed is a change of vocabulary with real meaning. The old mean time to restore, known as MTTR, was repositioned as failed deployment recovery time. These are not the same thing. The first measures how long it takes to bring a service back, whatever the cause. The second measures specifically the ability to undo what was just done.
In an operation where change cadence has risen because of artificial intelligence, this second metric separates those who absorb the cost of instability from those who suffer it. Shipping five times faster is only a gain if rolling back still takes minutes.
Where operational discipline comes in
None of this is an argument against adopting artificial intelligence in development. The throughput gains are measured and they are real.
It is an argument about where the next investment has to go. An organisation that accelerated delivery without reinforcing the platform underneath it bought speed on credit, and the bill arrives as incidents.
The concrete work usually looks like this, in order of return:
- Instrument the distinction between model failure and capacity failure. Without it, every failure looks like a model problem, and the response is always the wrong one.
- Define and test controlled degradation. What happens when the quota runs out mid-afternoon, and who decides what gets dropped.
- Measure failed deployment recovery time, not just deployment frequency. The first metric protects; the second impresses.
- Isolate services that share a vendor. Three models in parallel under one account limit are not three independent paths.
When this is not yet the priority
It is worth saying when this subject is not the most urgent one, so that everything does not become a priority.
If artificial intelligence use in the operation is marginal, or not yet in production with real customer traffic, the risk described above is theoretical. In that case the priority remains the reliability of the existing operation: tested recovery, clear ownership of critical systems, and defined service objectives.
The problem described in this article shows up when delivery cadence has already risen and the platform is still sized for the previous rhythm.
Frequently asked questions
Does artificial intelligence make delivery inherently less reliable? No. The research shows correlation between adoption and instability, not direct causation from the model. The observed mechanism is one of volume: more changes, faster, on platforms sized for the previous rhythm.
What is the new DORA recovery metric? The old mean time to restore was repositioned as failed deployment recovery time. It measures specifically how long it takes to undo a change that went wrong, not the restore time of any outage.
How do you tell a capacity failure from a model failure? Through instrumentation. Rate limit error codes, queue wait time, and quota rejection rate are capacity signals. Malformed or incorrect responses are model signals. Without separating the two in observability, everything reads as a model problem.
Is it still valid to quote DORA performance tiers? Not from 2025 onward. The four tiers were replaced by seven archetypes built on eight measures. Quoting "elite" with recent data means quoting a category the report no longer uses.
Does this require a dedicated team? It requires dedicated competence, which is not the same as permanent headcount. The work is platform engineering and reliability, and it can be internal, reinforced, or run as managed dedicated capacity.
Conclusion
The question this article opens with has an answer. Artificial intelligence does make delivery faster, and that is measured. What is also measured is that stability does not follow on its own, and that most production failures come from capacity limits rather than from the model.
Whoever owns a platform has a rare argument here: a reliability investment that does not compete with the artificial intelligence agenda, it sustains it. On what to do when the reliability function has no owner, it is worth reading when it pays to build an in-house reliability team and when it pays to buy capacity, and why having copies of the data is not the same as being able to operate again.
To understand where the current platform absorbs the rise in cadence and where it breaks, xGrowth starts with a short, no-commitment call about reliability and operations: Book a Clarity Session.