DORA 2026: The ROI of AI in Software Development Runs Through Code Review

AI is already part of the daily workflow for many engineering teams. And to me, the more interesting discussion is no longer whether it helps developers write code faster. That is becoming increasingly clear.

The real question is what happens to that speed afterward.

That is what stood out to me most in the DORA 2026 report, “The ROI of AI-assisted Software Development.” Instead of stopping at individual productivity, the report looks at the entire delivery flow and tries to understand when the use of AI actually turns into returns for the team and the business.

Because writing more code and opening PRs faster does not, by itself, mean the company is delivering more value.

If the rest of the process cannot keep up, the gains start showing up elsewhere as costs: more changes waiting for review, more rework, more broken tests, and more risk reaching production.

That is why I do not see AI as something that eliminates bottlenecks. In many cases, it simply moves the problem to the next stage.

And that is where code review becomes even more important.

If the team increases its code output but keeps reviewing changes the same way, with limited context and few clear risk signals, part of the speed gained during development gets lost during validation.

The change reaches the PR faster, but it can still get stuck in review, testing, approval, or later show up as a problem in production.

In this article, I will share the main insights I took from the report. I hope they are useful to you.

AI amplifies what the team already has

One of the most interesting ideas in the report is that AI should be treated as an amplifier.

In a team with solid tests, small PRs, accessible technical context, and a healthy delivery flow, AI tends to expand delivery capacity. In a team with slow reviews, fragile tests, too many manual approvals, and poorly documented architecture, it tends to amplify the problems that already exist.

The report also points out something simple but easy to overlook: code can become a liability. More code means more to maintain, review, secure, and operate. So when AI increases code volume without a proportional verification layer, the team pays for it later. It pays through rework, incidents, technical debt, and engineering time tied up in fixes.

For engineering leaders, measuring the return on AI requires looking beyond the cost of the license. The time spent understanding, validating, and correcting the code it produces also needs to be part of the equation.

The J-Curve explains the initial drop in productivity

The report uses the idea of the J-Curve to explain AI adoption in software development. At first, it is normal for the team to experience a temporary drop in productivity before it starts capturing value.

That drop usually comes from very practical issues:

• time spent learning how to use the tools more effectively;
• adjustments to the workflow;
• additional effort to review AI-generated code;
• more pressure on tests, pipelines, and approvals.

DORA refers to part of this as the verification tax: the additional effort required to check whether AI-generated code is reliable, secure, and aligned with the system architecture.

This matters because it prevents teams from misreading the adoption process. If leadership expects immediate returns, it may interpret that initial drop as a failure. But in many cases, it is the cost of learning how to operate AI within the engineering system. The problem begins when that cost was not planned for and no one is measuring where it shows up.

Code review has become an ROI lever

When AI accelerates code generation, code review becomes even more important for managing risk and maintaining consistency across changes.

It still protects quality, of course. That was already part of the job: catching issues related to logic, architecture, security, readability, and production impact.

But with AI, code review also starts protecting the return on the investment.

If a change sits for days waiting for review, the speed gained during development does not turn into delivery. If large PRs are approved without enough context or clear risk signals, that speed can later show up as rework, incidents, and instability.

In both cases, the value created by AI is lost before it reaches production.

The report connects this to two dimensions of software delivery: throughput and instability. Throughput reflects the volume and speed of changes moving through the system. Instability reflects the cost when those changes fail, cause incidents, or require recovery.

In practice, the goal is not to have the team open more PRs just to look faster. The goal is to increase throughput without driving instability up at the same time.

Metrics need to cover the entire flow

One thing I have seen quite often in AI adoption is teams measuring impact only by the amount of time saved per developer. That number helps, of course, but on its own it does not tell you whether engineering is delivering better outcomes.

A developer may save an hour a day with AI. But if that speed leads to larger PRs, slower reviews, and more rework, the gain does not translate into business results. It gets lost in the process.

That is why returns need to be measured across the entire software delivery flow. For engineering teams, a few signals can help show whether the speed gained is actually turning into delivery:

• lead time for changes;
• deployment frequency;
• change failure rate;
• failed deployment recovery time;
• average time in review;
• PR size;
• rework rate after review;
• volume of repetitive comments in PRs.

These metrics help separate real gains from a simple feeling of speed. And I think that distinction matters, because AI can make the process feel faster very early on.

You write faster and move more changes into review, but that does not necessarily mean the team is delivering better outcomes. The gain only becomes real when the rest of the flow keeps up and the change reaches production without creating additional rework, instability, or cost later.

The report’s financial example shows how AI ROI gets lost in the flow

The report includes an ROI calculator with illustrative numbers. It should not be copied as a benchmark, but it helps explain the underlying logic.

In the example, an organization with 500 technical employees estimates a net time gain of 12.5% per developer, or roughly one hour per day. At the same time, the calculation includes an initial productivity drop of 15% for three months because of the J-Curve.

Then the cost of instability comes into the equation. The example increases deployments from 50 to 56 per year, but it also raises the change failure rate from 5% to 6%. With downtime estimated at $100,000 per hour and four hours of recovery time, that instability creates a negative impact.

Even so, in the example scenario, the report arrives at $11.6 million in annual value, $8.4 million in first-year investment, $3.3 million in benefits, a 39% ROI, and a payback period of roughly eight months.

The final number gets attention, but I would focus more on how the calculation is composed. ROI depends on the time recovered, but it also depends on how much of that gain is consumed by instability, heavier review, and rework. That is where many AI initiatives look promising at first and disappoint later.

How to apply this to the PR workflow

For a team that already uses AI to write code, I would start with a simple question: where in the flow is that speed gain being lost?

I would begin by looking at the PRs. If they became larger after AI adoption, there is a good chance the cost of review increased as well. Large changes require more context, create more reviewer fatigue, and make risks harder to spot.

It is no coincidence that the report repeatedly emphasizes the importance of working in smaller batches. Smaller PRs make reviews easier and help the team find problems before they reach users.

Next, I would look at the types of comments appearing in reviews. If many of them are still focused on conventions, style, uncovered scenarios, simple validations, or known risks, that first filtering layer can be automated.

I think reviewers should spend that time on the decisions that genuinely require their attention: architecture, business logic, security, user impact, and maintainability.

I would also look at how long PRs sit waiting for review. This is one of the places where the speed created by AI tends to disappear. The code was written faster, but the change is still waiting for someone to look at it. From the business perspective, it has not happened yet.

AI-powered code review needs context

The report also highlights the importance of making internal data accessible to AI.

Without that context, an automated review tends to point out the obvious or create noise. To identify meaningful risks, AI needs to understand repository patterns, architecture, dependencies, team rules, and the history behind technical decisions. Otherwise, it may increase the volume of comments without improving review quality.

The data from our AI code review research reinforces this idea.

We analyzed nearly 10,000 rules created by engineering teams and found that suggestions based on those patterns were implemented at a rate close to bug-related suggestions.

This shows that team-specific rules are not just an add-on to the review process. When AI understands those patterns, it can identify the issues that actually matter in that context.

The research also showed that simply switching the model used in the review had little impact on the outcome.

In other words, choosing a newer or more powerful LLM is not enough. Review quality depends heavily on the context the team is able to provide.

That is why I would not start with model selection. I would first try to understand what the team actually needs to catch in reviews, where the process is losing time, and which decisions still require more context from the reviewer:

• Which problems do we want to detect before the PR reaches a person?
• Which comments appear repeatedly in reviews?
• Which team rules need to be explicit?
• Where does the review process get stuck because of missing context?
• Which types of changes should receive more attention?

Once those answers are clear, AI stops being just another layer of comments in the PR and starts genuinely helping the process. It filters out some of the noise, identifies risks earlier, and brings more context to the person making the final decision.

What to measure after adopting AI

If I were reviewing this report with an engineering team, I would not start with direct financial ROI. I would begin with the signals that show up before it.

A few questions can reveal quite a lot:

• Did time in review go down or up?
• Did the average PR size increase?
• Did the change failure rate change?
• Did incident recovery become slower?
• Is the team deploying more often while maintaining the same level of stability?
• Are reviewers spending less time on repetitive comments?
• Is AI reducing rework, or just pushing it further down the process?

These questions help show whether the team is simply moving through the J-Curve or whether AI has created a new bottleneck in the process. And honestly, that is what separates a real change in how the team works from simply buying another tool.

What this means for engineering teams

The DORA 2026 report translates ROI into language that is more familiar to leadership, but for people in engineering, the message is simple: AI only generates returns when the rest of the flow can keep up.

Code review is one of the most sensitive parts of that process. If it remains too slow and manual, it becomes a bottleneck for all the code produced with AI. But when it has the right context, clear rules, and strong risk signals, it helps reduce noise, catch problems earlier, and leave the most important decisions to the people doing the review.

That is why I would focus less on the tool in isolation and more on the surrounding system: smaller PRs, reliable tests, accessible technical context, explicit rules, and metrics that track speed and stability at the same time.

To me, that is the main message of the report: writing code faster is not enough. The return on AI needs to show up across the entire software development lifecycle, from the moment a change is opened to the moment it reaches production.