What the research actually says about AI coding ROI

Here is the whole picture, before the evidence that earns it.

Almost every developer now uses AI tools, and a large minority do not trust what comes out. Where gains have been counted across many companies, the middle result is a few percent, with a spread wide enough to include teams that got slower. Those personal gains have not been shown to make the company better off, and the effect seems to fade within a few quarters. What the speed cost in quality can be counted. And the industry's ability to count any of this is worse than its confidence suggests.

What follows is sorted by what each finding can support. Every claim carries its method, because the method decides whether the number belongs in a board deck.

Almost everyone uses it. Almost nobody trusts it.

DORA's 2025 report landed in September 2025 with roughly 5,000 replies. It found 90% of technology professionals using AI at work and more than 80% believing it made them more productive. It also found 30% reporting little or no trust in AI-written code. DORA found AI linked to more work getting shipped and, in the same breath, to less stable delivery. Both directions, one dataset.

The Stack Overflow Developer Survey 2025 asked about 49,000 people and points the same way with sharper edges. It found 84% use or plan to use AI tools, and 51% of professionals use them daily. Only 3.1% highly trust the accuracy of the output. The top complaint, from 66%, is code that is "almost right, but not quite." And 45.2% say debugging AI-written code takes *more* time than debugging their own.

So use is settled, and belief in the gains runs far ahead of trust in the output. None of that supports a dollar figure. These are self-reports, and the METR work below should make you wary of those.

The gain is real, small, and hugely uneven

The best count across many companies is DX's "AI Efficiency Plateau" from May 2026, drawn from 400+ companies between November 2024 and February 2026. The median gain in pull requests shipped: 7.76%.

The spread matters more than the middle. Line every company up from worst to best. The one a tenth of the way up — the 10th percentile — came in at −3%. A quarter of the way up: 2%. Three quarters up: 17%. Nine tenths up: 44%.

That spread is the real finding. A well-run rollout can plausibly deliver 40% or more. A badly run one can go backwards. Quoting the median as your expected result is a coin flip dressed up as a forecast.

What this supports: a range, with your own place in the spread unknown until you count it. What it does not support: "AI makes developers 8% faster." The spread is bigger than the effect.

One person's gains don't add up to company gains

This is the most important and least quoted finding in the field. Faros AI's analysis from July 2025 covered 10,000+ developers across 1,255 teams. Developers using AI finished 21% more tasks and merged 98% more pull requests. The same work found no real link between AI use and company-level improvement.

The same data explains why: 9% more bugs per developer, pull requests 154% larger, and 91% more time spent in review. Work moved faster into review and then sat there. Personal speed turned into a longer queue.

Gains per developer and gains for the company are two different things to count, and the first does not imply the second. Any ROI model that multiplies a time saving per seat — one paid license for one person — by headcount assumes exactly the adding-up this study failed to find.

The gain appears to level off

The same DX data found 69.7% of developers hit their peak time saving within two quarters. Then 66.1% watched that saving shrink.

The budgeting consequence is direct. A 12-month payback model built on a first-quarter count is stretching from the peak. Whatever curve you assume, it is probably not a straight line.

What the speed cost you can be counted

What the speed cost you is everything sitting beside a gain in output: more work redone, more review, more defects. A speed number leaves all of it out by design.

GitClear's "Maintainability Gap" came out in January 2026 and looked at 623 million changes to code. Refactoring — tidying up code that already works — is down 70% since 2022. Moved code fell from 21% of changes to 3.8% so far in 2026. Duplicated blocks are up 81% over 2023. Developers are roughly five times more likely to copy and paste than to tidy up. This reads real code rather than asking people questions, but it is not a controlled comparison either.

Veracode's GenAI Code Security Report from July 2025 tested 100+ models. It found 45% of AI-written code failed OWASP Top 10 security tests. Java was worst at 72%. Newer and bigger models were no better.

Opsera's 2026 benchmark from January 2026 covers 250,000+ developers. It reports AI-written pull requests taking 4.6× longer to review, and 15–18% more security flaws. Opsera published it and has not made the full method public, so treat it as backup, not as an independent count.

The counting itself is broken

Harness surveyed 700 practitioners in May 2026 and produced the most damning pair of numbers in this whole field. Fully 89% of leaders say their metrics accurately reflect AI's impact. Yet 94% admit those same metrics leave out tech debt, checking time and burnout.

That is not a counting problem. It is a confidence problem. The same report found 81% saying developers spend more time in code review since AI.

The spend side matches. KPMG's Q2 2026 Global AI Pulse asked 2,145 C-suite leaders and found just 7% reporting established ROI on AI: 15% of those with strong cost visibility, 3% of those without.

The two famous numbers

Both sides of this argument over-quote studies that do not support their conclusions. This is the most useful section to carry into your next debate.

GitHub's 55% faster

The number comes from a 2022 GitHub study of 95 developers. Three things fall out of the paper.

First, the 95% confidence interval — the range the true answer most likely sits in — runs from 21% to 89%. That is an enormous spread, and the headline quotes the midpoint.

Second, the task was writing an HTTP server from scratch. Brand new code, no existing architecture, no review cycle.

Third, GitHub ran the study itself, on a model that is now roughly four years old.

That does not make it fraudulent. It makes it a count of one narrow task, under conditions unlike your codebase. Use it as a foil, not as evidence.

METR's 19% slowdown

The skeptics' number has a bigger problem. METR's July 2025 controlled trial found 16 experienced open-source developers were 19% *slower* with AI tools while believing they were 20% faster. It became the go-to citation for anyone arguing AI does not work.

Then METR published a February 2026 update that clearly walks it back. The late-2025 follow-up does not repeat the result. Returning developers came in at −18%, with a range of −38% to +9%. New developers came in at −4%, with a range of −15% to +9%. Both ranges cross zero. METR's own read is that developers are more sped up by AI tools now, in early 2026.

So the 19% is not a settled fact, and quoting it as one is exactly the mistake the study itself warns about. But the finding underneath it survived, and that is the one that matters. Developers were about 39 percentage points wrong about their own speed, in the flattering direction. That gap is why the self-reports above cannot be turned into dollars, and why "the team says it is faster" is not a count.

The lasting finding from METR is not the 19%. It is the 39-point gap between how fast developers were and how fast they believed they were.

What a claim you can defend looks like

Three properties. Nothing else in this post is more useful.

A range with its assumptions on show. Not "AI saved us $1.4M" but "between $600K and $1.6M, assuming a 7–17% lift in work shipped on 40% of engineering time, at a loaded rate of $X." Every input editable by the reader. Honest AI ROI modeling walks through building one.

A number that shows the cost of going faster, beside every speed number. That is a number which moves the wrong way when you buy speed with quality: work redone within 21 days, bugs per pull request, merges that skipped review, incidents per pull request. Faros and GitClear are why this is required rather than nice to have.

A proof level on every figure. Every number we show carries a proof level, so you know how much guessing sits behind it.

Counted — read straight off a bill, a seat list or a usage report. No guessing. Two people pulling the same numbers would get the same answer.

Compared — the difference between two similar teams inside your own company, over the same period. Real signal, but a difference is not proof of a cause.

Estimated — worked out from assumptions you can see and change. Always shown as a range, never a single number.

Most AI ROI figures in circulation are estimated but presented as counted, which is why your AI ROI number is wrong.

Apply that last test to DORA's own 2026 ROI work. The widely quoted 39% first-year return — $11.6M of value on $8.4M invested for a 500-person company — is a model with stated assumptions, not a count. It is an admirably open model. It even builds in the change failure rate rising from 5% to 6%, at a cost of $344,000. But being open does not promote it a level. Present it as an estimate, or do not present it.

The honest caveats

This is a round-up, not a formal pooling of the data. The studies use different people, different windows and different outcomes, and stacking them into one story is a judgment call. Several are published by vendors: DX, Faros, GitClear, Opsera and Harness all sell into this market, and so do we. Sample sizes run from 16 developers to 250,000, and the small ones do more work in public than they can bear. Most of this counts coding, which is roughly 14% of a developer's day, and that caps how much any coding gain can move. If a new count across many companies contradicts the above, update rather than defend.

Find your recoverable AI spend

None of the studies above can tell you what AI is worth at your company. They can only tell you which shapes of answer are credible. Spendassay counts your own output and the cost of going faster against your own spend, and hands back a range with the assumptions visible.

`Start free` → /login?src=blog_what-research-says-ai-coding-roi