In summary (5-minute read)

• Per-token prices for a fixed level of capability have collapsed since 2022, yet enterprise AI bills have risen.

• Token spend is an input metric. Managed in isolation it optimises for the wrong outcome, because the cheapest engineering organisation is the one that ships nothing. 

• Google Cloud’s DORA programme, in its 2025 State of AI-assisted Software Development report, found that AI adoption now correlates with both higher delivery throughput and higher delivery instability. Acceleration does not remove your downstream constraint, it loads it. 

• Vendor consoles report spend at seat or workspace level. They cannot answer the question finance is asking, which is what the spend produced. 

• The largest uncontrolled variable is capability, not price. Two organisations with identical tooling and similar token consumption can see materially different returns. 

• Four things are worth instrumenting: cost per merged change, the quality tail, review load, and capability distribution. Baseline before you scale, because a result you cannot attribute is indistinguishable from a story.
  

---

The pricing paradox

Per-token prices have collapsed. Enterprise AI bills have not. The gap between those two facts is where many engineering leaders are currently losing the ROI argument, and it is not a pricing problem.

Two years ago, boards approved AI budgets on the strength of a demonstration. Today, the conversation has moved to the CFO, who is asking a harder question: what did we get?

It is a fair question, and most engineering organisations cannot answer it well. Not because the tools are not working, because for the most part they are, but because the number everyone has to hand is a cost, while the number everyone needs is a return.

The fall in the cost of intelligence is real, but it is worth being precise about what has actually fallen. Stanford HAI’s 2025 AI Index found that querying a model scoring at GPT-3.5 level on MMLU dropped from around $20 per million tokens in November 2022 to around $0.07 by October 2024, a reduction of more than 280 times in roughly eighteen months. That is the price of holding capability constant while the technology improves underneath it.

It is not the price of staying at the frontier. Frontier per-token prices have fallen more modestly, and reasoning models consume substantially more tokens to complete the same task. So the cost of a fixed capability has collapsed, while the cost of a frontier-quality answer has not fallen nearly as far, and in some workloads has risen. Both things are true, and conflating them is how the ROI argument gets lost.

Enterprise bills have gone the other way.

The mechanism is straightforward once you see it. Agentic tools bill by consumption, and consumption scales with usefulness. A more capable agent does more work, and doing more work means reading more context, running more iterations and generating more output. A tool that developers love produces a larger invoice than one they ignore. Unless a team sets a ceiling deliberately, there is not one.

Why token spend is not a measure of AI ROI

Here is the trap. When cost becomes visible and volatile, it becomes the thing everyone manages. Dashboards get built. Spend gets attributed to teams. Somebody is asked to bring the number down. 

But token spend is an input metric. Managed on its own it optimises for the wrong thing, because the cheapest engineering organisation is the one that ships nothing. 

The harder problem is attribution. Vendor consoles report at workspace or seat level. They will tell you what a team consumed last month. They will not tell you which change consumed it, whether that change solved a novel problem or re-solved one already in the codebase, or whether the code it produced is still standing thirty days later. Without that, every ROI conversation reduces to a spend figure on one side and a developer sentiment survey on the other, and finance does not fund sentiment. 

What the evidence shows

The most useful research here comes from Google Cloud’s DORA programme (DevOps Research and Assessment) and its 2025 State of AI-assisted Software Development report, because it measures outcomes rather than adoption. The report draws on a survey of nearly 5,000 technology professionals conducted between June and July 2025, alongside qualitative interviews. 

Its findings are worth sitting with, and worth separating carefully into what is measured and what is perceived: 

• Around 90% of respondents now use AI as part of their work, up 14 percentage points on the previous year’s 76%, with a median of about two hours of daily use.

• AI adoption is associated with higher software delivery throughput, reversing the previous year’s finding, alongside improvements in individual effectiveness and organisational performance. 

• AI adoption is also associated with higher software delivery instability, which the report describes as a continuation of the prior year’s finding rather than a new one. 

• It has no measurable effect on friction or burnout. 

One point deserves care, because it is where this argument is most easily attacked. DORA reports that a majority of respondents, around 59%, perceive a positive influence of AI on code quality. That is a self-reported perception, not an objective measurement, and it sits in obvious tension with the instability finding. Jellyfish, an engineering management vendor and a sponsor of the DORA report, analysing its own delivery data alongside the DORA results, reported that AI adoption showed no strong influence on bug counts per pull request. The honest reading is that developers believe their code is better while system-level delivery outcomes are getting less stable, and those two things can coexist because they measure different layers. Anyone citing the code-quality figure as evidence of improved quality is overstating what the research supports. 

The instability finding is the one that gets skipped in vendor decks, and it is the one that explains the ROI gap. Acceleration exposes whatever is downstream of it. If your review capacity, automated testing, release plumbing and feedback loops were already the constraint, generating code faster does not remove the constraint. It loads it. Time saved in creation reappears as time spent in verification. 

The research team’s own framing is that AI acts as an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones. Their AI Capabilities Model makes the corollary explicit. The value of AI is unlocked not by the tools but by the technical and cultural environment around them. Successful adoption is a systems problem, not a tools problem. 

Telemetry from delivery pipelines points the same way. Faros AI’s 2026 AI Engineering Report, drawing on two years of telemetry from around 22,000 developers across more than 4,000 teams, found that under high AI adoption, task throughput per developer rose by roughly 34% and epics completed per developer by 66%, while average pull request size increased by around 51%, median review time rose sharply, and 31.3% more pull requests merged with no review at all, human or automated. Faros attributes the last of these not to a change in policy but to reviewers being unable to keep pace with volume. 

Two caveats belong with those numbers. Faros itself states that its 2025 and 2026 reports are independent cross-sections drawn from different datasets rather than a longitudinal study of the same teams, so the comparisons show direction rather than precise year-on-year change. And Faros sells engineering intelligence tooling, which does not invalidate the telemetry but does mean the findings sit close to a commercial interest. Cite the direction with confidence; cite the decimal places with care. 

Set against that, the enterprise-level financial picture is unsurprising. McKinsey’s 2025 State of AI survey, covering close to 2,000 respondents, found that 88% of organisations use AI in at least one business function, but only 39% attribute any level of EBIT impact to it, and among those that do, most report less than 5% of EBIT. Around 6% of respondents qualify as high performers on McKinsey’s definition, attributing 5% or more of EBIT to AI alongside significant reported value. The technology is not the bottleneck. The operating model is. 

How engineering capability affects AI costs and ROI

Two engineering organisations can buy the same licences, run the same models and consume similar volumes of tokens, and get materially different returns. 

The difference is capability, and it is more granular than having been trained on the tool. 

It shows up in prompt and context discipline: knowing what to put in front of a model and what to leave out, because context is the cost driver. It shows up in model selection, since routing everything to the most expensive model available is a common source of avoidable spend. It shows up in review judgement, in knowing which AI-generated changes need scrutiny and which do not, which is a skill rather than a policy. And it shows up in restraint, in recognising the tasks where an agent is the wrong instrument. 

Codebase health plausibly compounds this. CodeScene’s research team has benchmarked agent token consumption on healthy versus unhealthy code across C++, Java and Python, reporting that agents consumed roughly 35% to 45% more tokens to complete comparable tasks on unhealthy codebases, with the marketing framing citing up to 50%. The proposed mechanism is intuitive: poor structure produces more correction loops and larger context windows. 

That said, this is vendor research on two specific task types, single-prompt test generation and agentic refactoring, benchmarked on a single open-weight model in a research agent framework rather than the commercial agents most enterprises actually run, and CodeScene has indicated the token-consumption work is not yet published in peer-reviewed form, unlike its earlier code-health research. Treat it as a directionally useful benchmark from an interested party rather than a settled finding. If it holds at your scale, technical debt now carries a direct, metered, monthly cost, which is a genuinely new argument for addressing it. It is also a claim worth testing on your own codebase before repeating in a board paper. 

None of this capability is bought. It is built, and it is built unevenly across a large engineering organisation, which is why aggregate spend figures hide the interesting variation rather than revealing it. 

A measurement frame that survives a board meeting 

If you want an AI ROI position that holds up under scrutiny, four things need instrumenting. 

1. Cost per merged change, not cost per seat. Seats measure access. Merged changes measure output. The ratio between them is the only number that behaves like a unit economic. 

2. The quality tail. Change failure rate, rework rate and thirty-day survival of AI-assisted changes. Throughput gains that arrive alongside rising instability are not gains; they are deferred costs. 

3. Review load. Review time and review coverage. If time saved in creation is reappearing in review, you have moved the cost rather than removing it, and you should know by how much. 

4. Capability distribution. Where AI proficiency sits across your engineering population, by team and by discipline. This is the input that most strongly predicts the other three, and the one almost nobody baselines. 

The order matters. Baseline before you scale, because without a pre-deployment measurement you can never prove what changed, and a positive result you cannot attribute is indistinguishable from a story. 

Where this leaves engineering leaders 

The ROI question is answerable. It is just not answerable from a billing console. 

Organisations getting a defensible return appear to be doing three things: instrumenting the workflow rather than the tool, treating downstream capacity as part of the AI investment rather than an afterthought, and building capability deliberately instead of assuming it arrives with the licence. 

The last of those is the most neglected and the cheapest to fix. Before the next budget cycle, it is worth knowing precisely where AI capability sits across your engineering teams: not how many people have access, but who can actually use these tools economically and safely. That baseline turns the ROI conversation from an argument into an exercise. 

Are your engineering teams getting real value from AI?

A note on the evidence

The research cited here is correlational, not causal. DORA’s findings describe associations between AI adoption and delivery outcomes among survey respondents, and the report is explicit that these are not causal claims. Telemetry studies observe teams that chose to adopt AI heavily, which is not the same as a controlled comparison. Three of the sources drawn on, Faros AI, Jellyfish and CodeScene, sell products whose value proposition is supported by their own findings. None of that makes the evidence unusable, and the direction of travel is consistent across independent sources. It does mean the argument here rests on convergence between several imperfect measurements rather than on any single decisive study. 

• DORA (DevOps Research and Assessment), State of AI-assisted Software Development, Google Cloud, September 2025. Survey of nearly 5,000 technology professionals, June to July 2025.
• Google Cloud, Announcing the 2025 DORA Report, September 2025.
• DORA AI Capabilities Model, Google Cloud.
• Jellyfish, analysis of the 2025 DORA report with lead author Nathen Harvey, November 2025.
• Stanford HAI, 2025 AI Index Report, Research and Development chapter (inference cost decline).
• McKinsey, The State of AI: Global Survey 2025, QuantumBlack, November 2025 (EBIT impact findings).
• CodeScene, Unhealthy Code is Burning Your Token Usage, 2026 (vendor benchmark research).
• Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash, March 2026 (telemetry from approximately 22,000 developers across 4,000+ teams).