DORA Metrics Weren't Built for the AI Era — Here's What They're Missing

---

DORA metrics — deployment frequency, lead time, change failure rate, time to restore — have been the closest thing engineering has to a shared scoreboard for a decade. They're not wrong. They're just answering a question that made more sense before half your commits had an AI co-author.

In 2025, DORA's own research team acknowledged the gap directly: the framework captures how fast software moves through a pipeline, but AI-assisted development has changed what's happening inside that pipeline in ways the four keys don't see.

What the data actually shows

Here's the pattern researchers are now documenting: AI-assisted development increases throughput by roughly 30–40%, which looks unambiguously good on a DORA dashboard. But the same body of research finds code churn roughly doubles, and deployment stability drops by about 7%. A team can hit "Elite" DORA velocity numbers while quietly accumulating rework and instability that the four keys were never designed to flag — because DORA measures the pipe, not what's flowing through it.

That's blind spot number one: DORA can't distinguish AI-generated risk from normal variance. Bug density is measurably higher in codebases with unreviewed AI-generated code, but "bug density by code origin" isn't a DORA metric. A spike in change failure rate looks the same on the dashboard whether it came from a junior engineer's Friday-afternoon PR or an agent that generated 400 lines nobody actually read before merging.

Two more gaps worth naming

DORA doesn't capture trust. Developer trust in AI-generated code fell roughly 11 percentage points in 2026, per recent industry surveys, even as adoption climbed. That's a leading indicator of where review rigor is breaking down — teams that don't trust the output tend to review it less carefully anyway, out of fatigue, which is the opposite of what should happen. None of that shows up in lead time or deploy frequency.

DORA can't tell you if the fast thing was worth shipping. Reducing mean time to restore from four hours to one, on a system generating meaningful revenue per hour, has a real dollar value — but DORA reports "MTTR improved," full stop. Translating engineering speed into business impact is still a manual, after-the-fact exercise at most companies, which means the metric that's easiest to report is disconnected from the outcome leadership actually cares about.

What a more complete picture looks like

None of this is an argument to drop DORA — it's still the right shared vocabulary for delivery pipeline health. It's an argument for pairing it with metrics DORA was never designed to produce:

• AI attribution by PR, not just aggregate adoption percentage — which code is AI-authored, and how much human editing it actually received before merge
• Defect rate segmented by code origin, so a rising incident count can be traced back to where it's concentrated
• Zero-edit-commit rate, as a proxy for how much AI output is getting a real review versus a rubber stamp
• Business-value translation layered on top of the operational numbers, so "MTTR improved" comes with a "and here's what that was worth"

The takeaway for engineering leadership

If your dashboard still treats deployment frequency and AI adoption as two separate line items, you're missing the story where they intersect — which, in 2026, is most of the story. The teams getting ahead of this aren't replacing DORA. They're building the layer DORA was never meant to cover: attribution, trust, and business translation, sitting alongside the four keys instead of replacing them.