Article · 10-min video

Do DORA metrics still work with AI-generated code?

Oren Keinan, founder of Aidealy · Published October 11, 2026 · Updated November 10, 2026

By pressing "Play on YouTube", you agree to load this video from YouTube, a Google service. Google then receives data such as your IP address and may store data in your browser.
Details in our Cookie Policy and Privacy Policy.

Also available with audio in Arabic, French, German, Hebrew, Italian, Japanese, Korean, and Portuguese: choose one in the player's settings.

Watch on YouTube (Opens in a new tab)More from Oren Keinan on YouTube (Opens in a new tab)Read the transcript

In short

The DORA metrics still work now that AI writes a large share of the code, but only in pairs. Read a speed number, such as how often you deploy, only next to a stability number, such as how often a deployment fails.

AI now writes a large share of the code.
DORA's own reports from 2024 and 2025 show why reading a single delivery number on its own has stopped working.
DORA, short for DevOps Research and Assessment, is Google's research program on how companies build and ship software.
What follows covers what changed between those reports, which DORA metric misleads when read alone, and 3 changes for your next quarterly review.

Did AI make software delivery faster or less stable?

Both: DORA's 2025 report found that AI adoption is now linked to more delivery output and, at the same time, to less delivery stability.

DORA's 2025 report, State of AI-assisted Software Development, is based on survey answers from nearly 5,000 technology professionals. In DORA's 2025 survey, 90% said they use AI at work. Its announcement puts the result this way: "we observe a positive relationship between AI adoption on both software delivery throughput and product performance". It adds: "AI adoption does continue to have a negative relationship with software delivery stability."

Throughput means how many changes reach production in a period. Stability means how often a change fails and has to be fixed or rolled back.

JetBrains, a maker of programming tools, surveyed more than 15,000 developers in mid-2026. On average, the developers in JetBrains' 2026 survey said AI agents fully write about 47% of their code. Measured data on public code shows how fast AI help spread before that. Researchers at the Complexity Science Hub in Vienna checked public code on GitHub and reported in the journal Science in 2026. In the US, about 5% of Python functions were written with substantial AI help in 2022, and an estimated 29% by the end of 2024.

What were the DORA metrics built to tell you?

The DORA metrics are engineering metrics for how fast and how safely changes to a piece of software reach its users. They were always meant to be read together.

DORA's official guide to the metrics says they "are best suited for measuring one application or service at a time". For years DORA was known for 4 of them, often called the 4 key metrics or simply the DORA metrics. The latest version of the guide, updated in January 2026, lists 5. It describes the change as "shifting from the original four keys to the current five-metric model".

The guide groups 3 of them under throughput. Change lead time measures how long a change takes to go from a developer's finished code to running in production, in front of real users. Deployment frequency is how often you release a new version. When a deployment fails, failed deployment recovery time tells you how fast you recovered.

The guide groups the other 2 under instability. Change fail rate counts how often a deployment needs an urgent fix or a rollback. Deployment rework rate, the metric added to the original 4, counts the deployments nobody planned. The guide defines it as "the ratio of deployments that are unplanned but happen as a result of an incident in production".

The same guide explains why the metrics belong together: "speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams." Teams that shipped more often were usually also more stable. That link made the metrics a useful diagnosis: if speed rose and stability did not, something was wrong.

What changed between DORA's 2024 and 2025 reports?

DORA's 2024 and 2025 reports disagree about speed and agree about stability. AI adoption was linked to slightly lower throughput in 2024, to higher throughput in 2025, and to lower stability in both years.

The 2024 report, Accelerate State of DevOps Report 2024, was DORA's 10th annual report, published in October 2024. It opened its finding on AI adoption with "Contrary to our expectations, our findings indicate that AI adoption is negatively impacting software delivery performance." DORA's 2024 report estimated that every 25% increase in AI adoption was linked to 1.5% less delivery throughput. In the same 2024 estimate, it was also linked to about 7% less delivery stability. These are estimates from survey data, and DORA says so.

The report's explanation was the size of each change: "since AI allows respondents to produce a much greater amount of code in the same amount of time, it is possible, even likely, that changelists are growing in size." A changelist is one batch of code changes, like a pull request. The report adds that "DORA has consistently shown that larger changes are slower and more prone to creating instability". It also reminds readers of what it calls "the importance of small batch sizes".

The 2025 report reversed the first part of the 2024 finding and kept the second. AI adoption was now linked to higher throughput, and it was still linked to lower stability.

DORA's 2025 explanation is that "AI accelerates software development, but that acceleration can expose weaknesses downstream." Downstream means later in the delivery process, after the code is written. Without strong safeguards, which DORA calls control systems, "an increase in change volume leads to instability". DORA gives strong automated testing, mature version control practices and fast feedback loops as examples of such safeguards. Fast feedback means learning quickly when something breaks.

What DORA reported	DORA 2024 report	DORA 2025 report
Delivery throughput	1.5% lower for every 25% increase in AI adoption (an estimate)	Higher with more AI adoption (a positive relationship)
Delivery stability	About 7% lower for every 25% increase in AI adoption (an estimate)	Still lower with more AI adoption (a negative relationship)
DORA's explanation	Changes are probably growing in size	More change volume without strong control systems
Data behind it	Survey estimates, in DORA's 10th annual report	Survey answers from nearly 5,000 technology professionals

Which DORA metric misleads when you read it alone?

A speed number, such as deployment frequency, misleads when you read it alone. Read it only next to a stability number, and read the stability number next to the safeguards behind it, such as your automated tests.

If your dashboard shows deployment frequency rising and you call that good news, you're reading only the number that improved. The number you're not reading is stability, and that's the one that shows the incidents. A metric that used to tell you what was wrong now only tells you where to look.

The likely reason for lower stability, as DORA's 2024 report suggested, is the size of each change. In 2026, researchers at Carnegie Mellon and Stanford measured it at one mid-sized company with 802 developers. The company had committed to doubling merged pull requests per engineer since mid-2025.

In that 2026 study, after developers started to use AI coding tools, their average pull request was about 37% larger. Each reviewer's load roughly doubled, and pull requests written with AI took about 20% longer from the first human review to merge. Pull requests got larger and their review took longer, which is the mechanism DORA's 2024 report suspected. Merge and revert rates held steady there, so the study shows the strain on review, not more failures.

In the same 2026 study, the share of pull requests with at least one human review fell from 89% to 68%. Over the same time, the share with a review by an AI tool rose from about 19% to about 84%.

Quality is the other half. Another 2026 study from Carnegie Mellon University used data from the code itself instead of a survey. Its researchers followed about 800 open-source projects that started to use the AI coding tool Cursor. They compared them with almost 1,400 similar projects that did not. In the first month, the projects added 3 to 5 times more lines of code, and after 2 months that gain was gone. In that study, warnings from code-checking tools rose 30%, code complexity rose 41%, and both stayed high.

An engineering analytics company looked at tool data from 22,000 developers for its 2026 report. It says something DORA doesn't: "High-performing engineering organizations, those with mature DevOps practices, high DORA metrics scores, and disciplined delivery processes, are experiencing the same downstream deterioration as everyone else." It gives this reason: "Perception lags reality. Telemetry does not." A survey records how people feel, and feelings change later than the facts. Numbers taken from the tools show the change as it happens.

DORA published its own warning next to its 2025 report. The companion document, the DORA AI Capabilities Model, names 7 capabilities a company needs, from a "clear and communicated AI stance" to a "user-centric focus". It finds that "in the absence of a user-centric focus, AI adoption can have a negative impact on team performance." I read that as a sign that adopting AI is a decision for the whole organization. Reading a single number on its own is a fast way to get that decision wrong.

I disagree with one part of how DORA describes what AI does to teams. Its 2025 report calls AI an amplifier: "AI doesn't fix a team; it amplifies what's already there." Good teams get better and struggling teams get worse. That's the strongest version of the idea, and it's mostly right.

But one engineering analytics company measured the good teams getting worse too. So I think the amplifier idea is true and also dangerous, because it lets a strong team believe it's safe. My rule: look at your stability numbers even when your team is good, and especially then.

3 changes for your next quarterly review

Make 3 changes: pair every speed number with a stability number, split numbers by AI help, and check your safeguards before buying more AI tools.

First, never report deployment frequency on its own. Put change fail rate right next to it, every time, so speed and stability are always read together. If your dashboard does not record change fail rate, someone has to link each failed deployment, urgent fix or rollback to the deployment that caused it.

Second, split your delivery numbers by whether AI helped write the change. Do it per service or per repository, the level DORA built these metrics for. That limit is DORA's own rule. Its 2024 report says the metrics "should be used at the application and service levels" and not to compare teams, "and certainly not to compare individuals." That rule is about delivery metrics, which describe a service, not the work of a person.

Splitting the numbers by AI help is the hard change. It needs 2 numbers your dashboard probably doesn't have. The first is which merged changes were written with AI help. The second is how many of those had to be corrected soon after.

I founded Aidealy, which makes software that measures the work engineering teams ship. Delivery tools measure how fast and how often you ship, and Aidealy shows that too. But its main focus is the people and AI agents who do the work, and the quality and lasting impact of what they ship, including the bugs that surface later. So a question such as which repositories had the most AI-assisted changes corrected within 30 days this quarter has an answer.

Third, before you buy more AI tools, check whether your automated tests and your rollback process can absorb much more change. No dashboard number answers this: the team has to review its tests and its rollback process by hand. DORA's 2025 finding is that without strong control systems, more change volume leads to instability. Its AI Capabilities Model also found that AI-assisted teams perform better when they use rollback often.

What the DORA metrics and reports cannot tell you

The numbers from DORA and the other studies cannot tell you what will happen in your organization, or whether the work was worth doing.

DORA's 2025 numbers are survey answers from nearly 5,000 people, and its 2024 figures are estimates. Both show that AI adoption and lower delivery stability moved together. The Carnegie Mellon studies measure code instead of asking people, but one company and a set of open-source projects are not the whole industry. I don't know whether these findings describe your team. Neither do their authors.

Your own stability number next to your own speed number is the only evidence here that's about your team. Even that only tells you how the work went. Whether the work was worth doing is a different question, and that judgment stays with you.

Sources

Watch the video on YouTube: https://www.youtube.com/watch?v=m37kcUhJXGM

More from the blog

Transcript

Show the full transcript

0:00 Faster and less stable, in the same report

According to DORA's 2025 survey, nine out of ten people who build software now use AI at work. By the way, DORA is Google's research program on how companies build and ship software. And in that same survey, software delivery got faster. And less stable. I know how that sounds. If you're hoping for a sales pitch built around the DORA metrics you already use, this isn't that video.

Here's why this matters now. DX is a company that measures engineering teams. According to its data from more than five hundred companies, AI was writing more than half of all code by the middle of 2026. By the end of this video, you'll know which DORA metric you can still read on its own. And which one misleads you when it stands alone.

And there's one finding from DORA's 2025 research that I haven't seen anyone quote. It's about teams that adopt AI without paying attention to their users. I'll come back to it in a few minutes. So let's talk about DORA properly.

0:56 What the DORA measures were built to tell you

The name stands for DevOps Research and Assessment. It's a research team inside Google, and every year it surveys thousands of people who build software. For about ten years, DORA has been known for four numbers that describe how well software gets delivered. Meaning how fast and how safely changes reach the users. People call them the four key metrics, or simply the DORA metrics.

And they were always meant to be read together. The first DORA metric is called change lead time. It measures how long a change takes from a developer's finished code to running in production, which means live in front of real users. The second metric is deployment frequency. A deployment is when you put a new version of the software live, so this is simply how often you ship.

Once a month, or ten times a day. The third one is called failed deployment recovery time. That's how fast you recover when a deployment goes wrong. Those three metrics are about throughput, meaning how much work gets through to production. Then there's the fourth metric, change fail rate. It counts how often a deployment needs an urgent fix or a rollback, and a rollback means putting the old version back.

And there's a fifth one now. DORA publishes an official guide to these metrics, and the latest version from January 2026 lists a fifth metric called deployment rework rate. It counts the deployments nobody planned, because something broke in production and forced them. Those last two metrics are about instability. For most teams, throughput and stability moved together. Teams that shipped more often were also more stable, because the habits that let you ship often are the same habits that catch problems early.

DORA's guide says it plainly: speed and stability aren't tradeoffs, meaning you don't have to give up one to get the other. That connection is what made the DORA metrics useful as a diagnosis, a way to spot what's wrong. If your speed went up but your stability didn't, you knew something was wrong. That connection is what AI broke.

3:01 Why 2024 and 2025 disagree

Let's go back to DORA's 2024 report. That year, DORA found something it called contrary to its expectations. More AI adoption went together with worse delivery. For every 25 percent rise in AI adoption, throughput dropped by about one and a half percent. And stability dropped by more. Those are estimates from survey data, and DORA says so. DORA's explanation was that people were producing a lot more code in the same time.

So each change was probably getting bigger. And bigger changes have always been slower and more likely to break. Back in 2024, Google's DORA research estimated that every 25 percent rise in AI adoption went with about seven percent lower delivery stability. Then the 2025 report came out, and half of that picture reversed. AI adoption now went with higher delivery output, meaning more work getting through.

But the other half didn't reverse. AI adoption still went with lower stability, meaning more failures. Two years, one research program. Same warning. Faster, and less stable. So your dashboard shows deployment frequency going up, and you call that good news. You're reading half the story. The half you're not reading is the stability half, and that's the half that produces the incidents.

DORA's own explanation is in the 2025 report. AI speeds up development, and that extra speed exposes weaknesses later in the delivery process. More changes flowing through turn into more instability, unless you've got strong safeguards in place. DORA calls those safeguards control systems and names three of them: automated testing, version control and fast feedback. Fast feedback means finding out quickly when something breaks.

So here's the change in how you read the DORA metrics from now on.

4:47 Read speed only next to stability

Each metric now needs a partner. A throughput number only makes sense next to a stability number. And a stability number only makes sense next to the safeguards behind it, like your automated tests. A metric that used to tell you what was wrong now only tells you where to look. The partner matters because of the size of each change.

LinearB is a company that tracks software delivery, and its 2026 benchmarks cover about eight million pull requests from nearly five thousand teams. Three out of four pull requests written with AI help stay under about four hundred lines. Pull requests written without AI stay under about a hundred and sixty. And when the whole pull request was written by an AI agent, meaning an AI working without a developer.

It waited almost eighteen hours before anyone started reviewing it. Pull requests written without AI waited about three and a half hours. So the changes got bigger, the waits got longer. And the reviewers stayed the same. That's the mechanism DORA guessed at in 2024, now measured. Faros AI is another company that measures engineering work, and it checked the same thing a different way.

Not with a survey. Faros pulled the numbers out of the engineering tools themselves. Over two years, across twenty-two thousand developers. As companies moved from low to high AI use, bugs per developer went up by more than half. And pull requests merged with no review at all went up by nearly a third. Then Faros says something DORA doesn't.

Companies with good DORA metrics got worse just like everyone else. Faros puts it bluntly. Perception lags reality. In plain words, a survey tells you how people feel. And feelings catch up late. The measured numbers don't wait. Now, here's the finding I promised you earlier. Alongside its 2025 report, DORA published a companion document it calls the AI Capabilities Model.

It names seven things a company needs to be good at, from a clear position on AI to a focus on its users. And it says that without a focus on the users, adopting AI can hurt a team's performance. To me, that says adopting AI is a decision for the whole organisation. And the fastest way to get that decision wrong?

Read one number on its own. This is where I disagree with the way DORA describes all this. DORA's 2025 report calls AI an amplifier, meaning it makes good teams better and struggling teams worse. That's the strongest version of the idea, and honestly it's mostly right. But remember what Faros measured: the good teams got worse too. So I think the amplifier idea is true, and also dangerous.

It lets a strong team believe it's safe. My rule? Look at your stability numbers even when your team is good. Especially then.

7:33 Three changes for your next quarterly review

So, three things you can change before your next quarterly review. First, never report deployment frequency on its own. Put change fail rate right next to it, every single time. So speed and stability are always read together. Second, split your delivery numbers by whether AI helped write the change. Do that per service or per repository, meaning for each piece of software.

Never per person. That part is DORA's own rule. The third change comes before you buy more AI tools. Check whether your automated tests and rollback process can absorb much more change. If they can't, more AI will make your numbers worse.

[On screen: illustrative example, not real customer data]

That second change is the hard one, because it needs two numbers your dashboard probably doesn't have. Which merged changes were written with AI help? And how many of those had to be corrected soon after? That gap is the one thing I'll say about Aidealy, the company I run. Delivery tools measure how fast and how often you ship, and Aidealy shows that too.

But its main focus is different. It measures the workforce, meaning the people and the AI agents. On the quality and lasting impact of what they ship. That includes the bugs that surface later. So a question like which repositories had the most AI-assisted changes corrected within thirty days this quarter has an answer.

8:53 What these numbers cannot tell you

Here's what none of this tells you. DORA's 2025 numbers are survey answers from nearly five thousand people, and the 2024 figures are estimates. Both show that two things moved together, AI adoption and delivery stability. They don't tell you what will happen in your organisation. Faros measures real tool data instead of asking people, but one dataset isn't the whole industry.

I do not know which of the two describes your team. And neither do they. That's exactly why reading the metrics in pairs matters. Your own stability number next to your own speed number is the only evidence in this video that's about you. And even that only tells you how the work went. Whether the work was worth doing is a different question.

That judgment stays with you.

9:36 What to watch next

So yes, the DORA metrics still work. For ten years you could read them as one package, and any single number on its own still told you something. Now they only work as two pairs. And a speed number on its own is the most misleading thing on your dashboard. The next video to watch is called Why measuring developer productivity keeps failing.

It's about why counting how busy people are fails as a way to measure productivity. Subscribe if you want it. The reports I mentioned are linked below, so read them yourself before you take my word for any of this.

See what your R&D is really doing.

Tell us what you're trying to figure out, and we'll get you set up to answer it on your own R&D: your engineers, your AI agents, and the code they ship together.