AI is already part of the daily workflow for many engineering teams.
And to me, the most interesting question 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 was the biggest takeaway for me from the DORA 2026 report, “The ROI of AI-assisted Software Development.”
Instead of looking only at individual productivity, the report tries to understand when AI adoption actually turns into value for the team and the business.
Because writing more code and opening pull requests faster does not automatically mean the company is delivering more value.
When the rest of the process cannot keep up, the gain starts showing up somewhere else as a cost:
- more changes waiting for review;
- more rework;
- more broken tests;
- more risk reaching production.
That is why I do not see AI as something that eliminates bottlenecks.
In many cases, it simply moves the bottleneck to the next stage.
And code review is one of the stages that feels this impact the most.
When a 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 implementation is lost during validation.
The change reaches the pull request faster, but it may sit in review, testing, or approval.
In some cases, it gets through all of those stages and the problem only shows up in production.
AI amplifies what the team already has
One of the most important ideas in the report is to think of AI as an amplifier.
In a team with reliable tests, small pull requests, accessible technical context, and a healthy delivery process, AI tends to increase 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.
Code can also become a liability.
More code means more code to maintain, review, secure, and operate.
When AI increases code volume without a proportional increase in verification capacity, the team pays the difference later.
It pays through rework, incidents, technical debt, and engineering time spent fixing problems.
That is why measuring the return on AI requires looking beyond license costs or hours saved per developer.
It also requires accounting for the time spent understanding, validating, and correcting AI-assisted code.
An initial drop in productivity can be normal
The report uses the idea of a J-curve to explain AI adoption in software development.
At the beginning, it is normal for a team to experience a temporary drop in productivity before it starts capturing value.
That drop usually comes from very practical things:
- time spent learning how to use the tools effectively;
- changes to the existing workflow;
- additional effort required to review generated code;
- more pressure on tests, pipelines, and approval steps.
DORA describes part of this as a “verification tax”: the effort required to make sure AI-generated code is reliable, secure, and consistent with the system’s architecture.
This matters because it prevents teams from drawing the wrong conclusion too early.
When leadership expects immediate returns, it may interpret the initial decline as a failed adoption.
But in many cases, that decline is part of the cost of learning how to operate AI within the engineering system.
The real problem begins when that cost was never planned for and no one knows where it is showing up.
Code review has become an ROI lever
Code review has always been an important quality layer.
It helps catch issues related to logic, architecture, security, readability, and production impact.
But as AI increases code output, review also starts protecting the return on that investment.
When a change sits for days waiting for review, the speed gained during implementation never turns into delivery.
When large pull requests are approved without enough context or clear risk signals, that speed may come back later as rework, incidents, and instability.
In both cases, the value created by AI is lost either before or after the change reaches production.
The report connects this to two dimensions of software delivery:
- Throughput: the volume and speed of changes moving through the system.
- Instability: the cost created when those changes fail, cause incidents, or require recovery.
The goal should not be to make the team open more pull requests just to appear more productive.
The goal should be to increase throughput without increasing instability.
That distinction sounds simple, but it changes how AI adoption should be measured.
Saving time is not enough
One thing I have seen often is teams measuring AI adoption mainly by the amount of time saved per developer.
That number is useful, but it does not tell the whole story.
A developer may save an hour a day with AI.
But if that speed produces larger pull requests, slower reviews, and more rework, the gain does not turn into business value.
It gets lost in the process.
That is why I would look at metrics across the entire delivery flow:
- lead time for changes;
- deployment frequency;
- change failure rate;
- failed deployment recovery time;
- average review time;
- pull request size;
- rework after review;
- volume of repetitive review comments.
These signals help separate real improvement from a simple feeling of speed.
AI makes the process feel faster very early.
You write code faster and move more changes into review.
But that still does not mean the team is delivering better.
The gain only becomes real when the change reaches production without increasing rework, instability, or operational cost.
Where is the speed being lost?
For a team that already uses AI to write code, I would start with one question:
Where in the delivery flow is that speed being lost?
I would begin with pull requests.
Did they get larger after the team adopted AI?
If they did, the cost of review probably 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 pull requests are easier to review and help teams catch problems before they reach users.
Then I would look at the types of comments appearing in reviews.
If a large portion of them still focuses on conventions, style, missing test scenarios, simple validations, or known risks, that first layer can be automated.
Reviewers should spend more time on decisions that truly require human judgment:
- architecture;
- business logic;
- security;
- user impact;
- long-term maintainability.
It is also worth looking at how long a pull request sits waiting for review.
That is one of the places where the speed created by AI often disappears.
The code was written faster, but the change is still waiting for someone to look at it.
From the business perspective, that change has not happened yet.
AI code review needs context
Automating code review does not solve the problem by itself.
Without context, an AI review tool tends to point out the obvious or create noise.
To identify meaningful risks, it needs to understand:
- repository patterns;
- architecture;
- dependencies;
- team rules;
- decision history;
- which types of changes deserve more attention.
Otherwise, it may increase the number of comments without improving review quality.
In our research on AI code review, we analyzed nearly 10,000 rules created by engineering teams.
Suggestions based on those rules were implemented at a rate close to suggestions related to bugs.
That shows that team-specific rules are not just a nice addition to the review process.
When AI understands those patterns, it can identify issues that actually matter in that context.
The research also showed that simply changing the model used for 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 can provide.
That is why I would not start with model selection.
I would start by trying to answer:
- Which problems do we want to catch before a pull request reaches a person?
- Which comments keep appearing repeatedly in reviews?
- Which team rules need to be made explicit?
- Where does review slow down because context is missing?
- Which types of changes should receive more attention?
Once those answers are clear, AI stops being just another layer of comments in the pull request.
It starts filtering noise, identifying risks earlier, and bringing more context to the people making the final decision.
What to measure after adopting AI
I would not start by trying to calculate the direct financial ROI of AI.
I would start with the signals that appear before it:
- did review time go down or up?
- did the average pull request size increase?
- did the change failure rate change?
- did incident recovery become slower?
- is the team deploying more often with the same level of stability?
- are reviewers spending less time on repetitive comments?
- is AI reducing rework, or simply pushing it further down the process?
These questions help determine whether the team is simply moving through the J-curve or whether AI has created a new bottleneck.
To me, that is what separates a real change in how the team works from simply buying another tool.
The main takeaway
The DORA 2026 report translates AI ROI into language that is closer to engineering leadership.
But for people working in engineering, the message is simple:
AI only generates returns when the rest of the delivery flow can keep up.
Code review is one of the most sensitive parts of that process.
When it remains too slow and too manual, it becomes a bottleneck for all the code produced with AI.
When it has the right context, clear rules, and useful risk signals, it can reduce noise, catch issues earlier, and leave the most important decisions to reviewers.
That is why I would look less at the tool in isolation and more at the system around it:
Smaller pull requests, reliable tests, accessible technical context, explicit rules, and metrics that track speed and stability at the same time.
Writing code faster is only the beginning.
The return on AI needs to show up across the entire development lifecycle, from opening a change to delivering it in production.
Top comments (0)