AI coding tools ROI: a business case that holds up

Stefan-Iulian Tesoi · 21 October 2026 · 7 min read

Count the costs that are not on the invoice, and write down in advance which result would end the spend. Seat licences and token usage are the small lines. Review time, specification time and rework are the large ones, and they land on senior people. A case that prices those hours and names the constraint it expects to move survives its first review.

Most attempts at AI coding tools ROI run the other way: a vendor's productivity figure, multiplied by headcount and salary. The arithmetic yields a large number that nothing the team later does can confirm or refute, so the spend drifts instead of being judged.

What does AI coding tools ROI actually include?

Return on investment here is the capacity a team gets back, minus everything it spends to get it, over a period long enough for rework to show. The spend has three parts: what the vendors charge, what the people around the tool spend, and what the change costs while it beds in. The return has one honest form: more accepted work from the same team, or the same work using fewer hours of the people who were the constraint.

The vendor part is the easiest to find and the smallest. An assistant's seat licence is tens of dollars a month. Agents billed on token usage cost more and vary more. Anthropic's own Claude Code cost documentation gives an average across enterprise deployments of around $13 per developer per active day, or $150-250 per developer per month, with 90% of users below $30 per active day. For a team of eight, that is roughly $1,200 to $2,000 a month, which in most markets is less than one senior engineer's week.

Which costs never appear on the invoice?

The people's time. Coding agents move effort from typing to specifying the work beforehand and judging it afterwards, and both are done by the people who were already the bottleneck.

On a team of three to eight, keeping a backlog executable takes four to six hours a week, and that is what product ownership costs a small engineering team whether or not anyone holds the title. Review grows with volume: an agent that returns twice as many diffs doubles the reading, and reading is slower than writing.

Token spend has a failure mode a seat licence lacks. A provider account has one spending limit, and everything on the account draws from it. We hit this in October 2026: an evaluation run on a developer's machine used a key in the same provider account as production, the account reached its monthly limit, and production's model calls began failing with the same payment error. The money was small. The cost was an outage. A sound cost of coding agents line names who owns the cap, and keeps experiments on an account of their own.

Which benefits can you measure in a quarter?

Three, and none of them is lines of code. Lines and merged pull requests rise on the first day whatever else is true, which is why they are the ones that get quoted.

1. Accepted items per week, counting only work that came back right without the item being rewritten.
2. Ready-to-accepted time per item, including the wait for review, because review is where the gain is usually absorbed.
3. Senior hours per accepted item, the hours of the people who were the constraint before any tool arrived.

All three need a baseline taken before the tools arrive: two sprints of the current numbers, recorded the same way. Without one, every figure afterwards is an anecdote. The full set, and how to read rework as a specification signal, is in coding agent metrics that are worth tracking.

DORA metrics belong in the case as a guard rather than a goal. Deployment frequency and lead time move slowly and for many reasons; change failure rate is the one to watch, because it is where extra volume shows up first.

Why do vendor productivity figures not transfer?

They measure a task, and a business case is about a team. GitHub's controlled experiment with Copilot found the group with the assistant finished 55.8% faster. The task was to implement an HTTP server in JavaScript as quickly as possible: greenfield, self-contained, and reviewed by nobody.

METR's July 2025 study took the opposite setting. Sixteen experienced developers working 246 real issues in repositories they knew well took 19% longer with AI tools, and afterwards believed they had been 20% faster. METR now treats that result as a snapshot of early-2025 tools, and its 2026 follow-up gives what it calls an unreliable signal, partly because many developers declined to work without AI at all.

The two studies do not contradict each other. One measured a task and the other measured a working codebase, and a business case is written for the second.

The team-level evidence points the same way. The 2024 DORA report estimated that each 25% increase in AI adoption came with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability, even as documentation quality, code quality and review speed improved. Its 2025 report describes AI as an amplifier of an organisation's existing strengths and weaknesses. The multiplier in any borrowed figure is the borrower's own process.

A one-page business case for AI coding tools

One page is enough, and the lines that matter are the ones a finance team cannot fill in for you. Here is a business case for AI coding agents on a team of six, with two senior engineers who specify and review most of the work:

• The constraint. Delivery is capped by the two seniors' hours, not by typing speed.
• The baseline. Two sprints measured before the start: accepted items per week, ready-to-accepted days, senior hours per item.
• Vendor spend. Token usage at $150-250 per developer per month, so $900 to $1,500 for six, capped at the provider account.
• People spend. Four to six hours a week of specification, named to one person, and review time budgeted rather than absorbed.
• The expected return. A range in accepted items per week, and a fall in senior hours per item.
• The stopping rule. If neither number has moved after two full sprints, the spend stops. When to stop an AI rollout, and what to keep covers the rest.
• The review date. Fixed on the day the case is approved.

To justify AI tool spend to someone outside engineering, the stopping rule does more work than the projected return. It shows the case can lose, which is what makes its numbers credible. The rollout that produces the baseline is laid out in a coding agent rollout plan for one team.

Laimonade belongs on the people line, not the vendor line: it drafts items with acceptance criteria an agent can execute and checks returned work against them, which is the specification and review time in the table. It is priced per project rather than per seat, so its cost does not grow with headcount.

Frequently asked questions

Should the case be judged per developer or per team?

Per team. A per-developer figure rewards whoever produces the most diffs, while the cost of that output is paid by someone else, usually a reviewer. Accepted items per week and senior hours per accepted item capture both the speed and the review it created. Look at individual usage only to find who needs help, never to rank people.

How long before the return can be measured?

About two months on two-week sprints: two sprints of baseline, then two full sprints with the tools. The first sprint spends a stock of old, half-specified items, and its result says more about that stock than about the tool. Token spend is readable within a week. The return is not.

What result should end the spend?

The one written down before the spend began. Typically that is accepted items per week flat after two full sprints, or senior hours per accepted item rising rather than falling. When neither moves, the constraint was elsewhere, usually in specification, and more seats will not move it.