DORA metrics were built for a bottleneck that AI has moved

Why DORA metrics, the delivery numbers we've trusted for a decade, tell us less than they used to, and what engineering leaders should watch instead.

At Bitrise, we run mobile CI/CD workflows for thousands of teams, so we see the raw material behind thousands of DORA dashboards, down to every commit, every pull request, every build, and every green check and red X.

A few weeks ago I pulled a simple comparison of the same group of more than 2,000 paying teams in October 2024 and October 2026, and on paper it looks like the best two years those teams have ever had. They opened 46% more pull requests and ran 52% more builds, the median build still took about nine minutes, and the share of builds that failed dropped from almost one in five to about one in eight. Three years ago I would have put that on a slide with a little rocket emoji.

When I looked underneath, the biggest change was in how the code was being written. In October 2024, fewer than one build in ten thousand ran on a commit that an AI agent had signed as co-author, but this October it was about one in fifteen, and that undercounts it, because plenty of AI tools don't add a co-author line to the commit. Our The State of Mobile Development 2026 tracks the same trend across more than 19 million builds. Almost all of the extra volume arrived in the last twelve months, and it didn't land evenly:

At the agent-heavy teams, CI usage nearly tripled in a single year, and the number of builds stuck waiting for a free CI slot went up tenfold. Yet within the same repositories, agent-signed pull requests failed CI about as often as everything else (11% of builds versus 10%), which suggests CI was checking far more work of about the same quality. I suspect the same was true for the people reviewing it. None of that shows up on a DORA dashboard, because DORA is answering a question that's no longer the most important one.

I've been a DORA fan for years, so this isn't a post I expected to write. But I've come to believe that in an engineering organization that runs on AI, DORA metrics are losing their value as a measure of how well we're doing, even though the ideas behind them have never mattered more.

What DORA taught us, and what's changing

Over more than a decade, DORA's research gave our industry a way to measure delivery, plus evidence that speed and stability aren't a trade-off, and it pushed many of us toward small batches, trunk-based development, test automation and CI/CD. Those practices made us better, and if your teams can't deploy on demand yet, I'd fix that before acting on anything else in this post, because AI tends to make that pain worse.

But every metric is a proxy, every proxy carries assumptions about where the hard part of the work is, and AI is now testing some of DORA's. DORA was designed around a specific bottleneck: getting a change that a human already wrote into production safely, through integration, testing, approvals and deployment. That's where most organizations were slow and fragile when the research started, and it's what the metrics measure. DORA defines change lead time as the time it takes a change to go from "committed to version control" to "deployed in production," which means the clock starts at the commit.

AI hasn't removed that bottleneck, but it is moving where the hard work happens, because producing a change has become much cheaper: one engineer running a couple of agents can now open as many pull requests as a small team used to. What's getting more important is everything around the code, from deciding what's worth building to checking that what got built is right and keeping enough human understanding of the system to run it. The research so far points the same way:

• DORA's own 2025 research found that 90% of respondents use AI at work and more than 80% believe it made them more productive. AI adoption is now linked to higher delivery throughput, but it still has a negative relationship with delivery stability. DORA's one-line summary: AI "improves throughput, but often at the cost of stability if your foundation isn't solid."
• Faros AI's 2025 telemetry from more than 10,000 developers found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, while PR review time rose 91%. But across throughput, DORA metrics and quality KPIs, those team-level gains didn’t show up at the company level.

Teams are producing more, but not every organization is delivering more, and that gap is where I'd look next, because it's one DORA wasn't designed to see.

Early signs of strain in code review

If the hard work is moving from writing code to checking it, code review is where I'd expect the strain to show up first. Our build data can't see inside review queues, but in open source, where review happens in public, the signs are already visible.

Earlier this year, Rémi Verschelde, one of the maintainers of the Godot game engine, said that "AI slop" pull requests "are becoming increasingly draining and demoralizing for Godot maintainers," adding, "I don't know how long we can keep it up." In January, tldraw's creator, Steve Ruiz, started automatically closing pull requests from outside contributors, saying most AI-generated ones came with "incomplete or misleading context" and little follow-up from their authors. His explanation is a good reminder of what a review costs the people doing it: "An open pull request represents a commitment from maintainers: that the contribution will be reviewed carefully and considered seriously for inclusion."

In October, a Linux Foundation survey of 234 open-source contributors and maintainers put numbers on it: on projects with more than 50 contributors, 64% of maintainers said AI-assisted contributions had made reviews take longer, and burnout was their number-one concern (63%), ahead even of contribution quality (60%).

Inside a company the strain is easier to miss, because the pull requests come from colleagues and their agents rather than from strangers, but the load looks similar: Faros found pull requests getting 154% bigger at teams with high AI adoption, and in most teams I know, the extra reviewing falls on the same handful of senior engineers.

To DORA, all of this is just time on the clock: lead time includes the hours a pull request waits for review, but not the attention the review takes or the understanding it builds, so on the dashboard a ten-second approval looks better than an hour of careful review. I don't know yet whether this pressure eases as tools and habits mature or becomes the new normal, but I wouldn't wait to find out, because a reviewer who is burning out unnoticed can keep your delivery numbers looking healthy right up until they leave.

Should you still track DORA metrics?

Yes, but demote them, because measuring what AI does to your team is harder than it looks. In 2025, METR ran a randomized controlled trial with experienced open-source developers and found that with AI tools they took 19% longer to finish their tasks, even though afterwards they believed AI had made them 20% faster. When METR tried to repeat the study with newer tools later that year, the experiment itself started to break, because more and more developers declined to take part rather than work without AI. Between 30% and 50% said they were holding back some tasks they didn't want to do without it, and for developers running several agents at once, METR's time-per-task measurements stopped being reliable. Its conclusion, published in February 2026, was that developers are probably faster now than in early 2025, but that the data is only "very weak evidence" of how much. So don't trust feelings, including your own, and don't trust any single number either.

DORA's annual report has been renamed from "Accelerate State of DevOps" to "State of AI-assisted Software Development," a sign of how far the focus has moved. Look at the seven capabilities in DORA's AI Capabilities Model: a clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, a user-centric focus, and quality internal platforms. Several of those are classic DORA lessons that matter more when the volume of change goes way up.

What engineering leaders should measure instead

1. Demote DORA from scoreboard to smoke detector. Keep collecting it, but stop leading your exec reviews with it, and never use it as proof that your AI investment is paying off, because rising throughput is now the default rather than an achievement.
2. Move the clock. Measure from "we decided to do this" to "customers are using it," because if you only measure commit to deploy, you're timing the part of the process AI made least interesting.
3. Treat review as capacity, not courtesy. Budget reviewer time explicitly, the way you budget on-call, and put size limits on agent-generated pull requests. Tier review by risk: let AI handle the mechanical pass, and save human attention for intent, architecture, security and anything that touches money or customer data. I'd also make "merged without human review" a written policy about where it's allowed, so it isn't something that just happens at 6pm on a Friday.
4. Invest in the verification layer. When generating code is cheap, your ability to verify it becomes your throughput, and fast CI, tests you trust, preview environments, feature flags, progressive rollouts and solid observability are the plumbing that makes cheap code safe. If your CI load doubled overnight, would you notice before your developers did? For the most agent-heavy teams we see at Bitrise, it nearly tripled in a single year. Bitrise Insights shows queue times and CI usage per app, so you can spot it early.
5. Make understanding non-negotiable. You merge it, you own it. Whoever approves a change should be able to explain it without the agent in the room, and for risky changes I'd ask for a short written rationale. Rotate people through the parts of the system that agents wrote most of, and run your game days there.
6. Write down your AI stance. It's the first capability in DORA's model for a reason: people need to know what's encouraged, what's off-limits, where human ownership is mandatory, and how success will be judged. Leave it ambiguous and you tend to get recklessness or paralysis, often both on the same team.
7. Watch your people as closely as your builds. Look out for senior engineers drowning in review, juniors who ship a lot and learn less, and the tedious work of fixing output that's "almost right, but not quite," which was developers' top AI frustration (66%) in Stack Overflow's 2025 survey. Ask people "where did your time go this week?" instead of "how much faster are you?" and then check what they tell you against system data, because the two don't always agree.
8. Change the conversation upward. When your CEO asks how much faster AI has made you, don't answer with deployment frequency or "percent of code written by AI," but with what shipped, what it did for customers, what it cost, and whether quality is holding. It's a harder slide to make, but it's also the only one that will still be true next year.

The question has changed

A green DORA dashboard used to mean "this team is great at delivering software," but today it mostly means "this team's CI/CD works," which is still worth knowing, even if it's no longer the most important question.

I don't think anyone has this fully figured out yet, me included, so I'm curious: what have you added to your dashboard since your teams went all-in on AI, and what did you stop looking at along the way?