To measure the ROI of AI coding tools, count everything the tools cost, measure the return as the significant work your teams shipped rather than the number of pull requests, and report break-even: how much more significant work the tools have to produce to pay for themselves. Get the cost side from invoices (seats, metered usage, overage) and add salaries for the all-in view. Get the return side by having tech leads tag a sample of merged changes by size and kind of work, with the big ones weighted more. Break-even is the extra AI cost divided by the baseline all-in cost. When AI spend is small next to salaries, it comes out at a few percent, and the question becomes whether the return cleared that line.
As of November 2026. The company in the worked example is fictional; every public figure is linked.
Report break-even, not an ROI percentage
The textbook formula is (value of the return − cost) ÷ cost. The cost is knowable; the value of the return, in dollars, isn't. The usual workaround prices the extra output at the old average cost of producing it. That gives a headcount equivalent, not business value, and a percentage built on it rests on two guesses: how much output grew, and how much of that the tools caused.
Break-even asks a question you can answer. If the AI line adds 4% to what a team costs, the team's significant shipped work has to rise by at least 4% for the tools to pay for themselves. The inputs check against invoices and payroll, and you argue about attribution with a threshold in hand: if work rose 15%, the tools need to account for only about a quarter of it.
The cost side: count all of it
Pull every AI line from invoices: per-seat plans, metered API usage, overage, and anything billed through a cloud account. Allocate it to teams and add loaded salaries. Engineer time spent supervising agents is already inside the salary line, so don't estimate it separately.
Cost per merged PR is useful here as a measure of spend intensity, what you paid in AI per unit of shipped change; the cost per merged PR post covers it. Just keep it on the cost side of the ledger.
The hard part of the cost side is what the invoice can't show: how much of the spend went to rework. Some agent sessions guess, fail a test, rewrite and fail again. That spend can come down without touching output, and you only find it by reading sessions, not bills. The sessions are also where you see whether a team is using the tools well, which neither an invoice nor a PR count shows.
The return side: what shipped and how much it mattered
The tempting return measure is merged pull requests, which went up after rollout. But AI makes pull requests cheap to produce, so more of them isn't more value. We made the longer case in the output was never the work. PR counts are the crude fallback when you have nothing else.
What you want is shipped work weighted by significance. Weighted work asks how much mattered, not how much was produced. By hand:
- Each quarter, have each team's tech lead tag a random sample of 30 merged PRs as small, medium or large, weighted 1, 3 and 8. Reverted changes count zero. Write the rubric down, with an example of each size from your own codebase, and keep it fixed across quarters, or the trend means nothing.
- Multiply the team's merged PR count by the sample's average weight. That's the team's estimated weighted work for the quarter.
- Tag the same sample by kind of work: feature, bug, maintenance. That shows where any extra capacity went.
- Have each lead write a paragraph on what the team's most significant work that quarter did for the business. The weighted number shows whether work grew; the paragraph shows whether it mattered.
Skip acceptance rates, lines of code and self-reported time saved, and treat token volume and adoption as inputs. Measure teams, not individuals; a ranking by person mostly shows who drew the big project.
The tagging is where this breaks down at scale. Thirty PRs is an afternoon per lead, a few percent of what a busy team merges, and the first thing dropped in a busy quarter. The rework share has the same problem on the cost side. Both are what VibeCheck and Maestro read automatically, from agent sessions and from merged code.
What the research says
There's no typical figure to borrow, and the studies disagree on direction. In METR's randomized trial (July 10, 2025), 16 experienced open-source developers worked 246 issues on their own repos and took 19% longer with AI allowed, while believing afterward that AI had sped them up by 20%. METR has since marked those results out of date: the post now says they "no longer reflect the current impact of AI models," and its February 2026 update calls the newer data "only very weak evidence" for the size of the change.
Cui and colleagues ran field experiments at Microsoft, Accenture and an anonymous Fortune 100 company with 4,867 developers and found "a 26.08% increase (SE: 10.3%) in completed tasks" among developers given an AI coding assistant. The 2025 DORA report (September 23, 2025) found AI adoption now goes with higher delivery throughput, but it "does continue to have a negative relationship with software delivery stability." And Jellyfish (October 2026) found that "increasing the tokens used in a week tenfold, from the median developer-week's level, buys about 2.2x the merged PRs," while noting "the relationship is correlational rather than causal."
METR's gap between belief and stopwatch is why self-reports can't be the return. DORA's stability finding is why reverted changes count zero.
The basics, for one team
If you manage one team and need an answer for the renewal, allocate last quarter's AI invoices to your team and add loaded salaries. Divide the AI cost added since rollout by the all-in cost before it; that's your break-even lift. Take the quarter before rollout and the latest quarter, tag 30 merged PRs from each with the rubric above, and compute weighted work for both. If weighted work rose by more than the break-even lift, with room to spare for whatever else changed, the tools are paying for themselves. Note which kinds of work the gain went to and the two or three changes you'd point to.
A worked example: Halvard Analytics
Halvard Analytics is a fictional mid-sized company: 60 engineers in four teams, two-week sprints, a loaded cost of $200,000 per engineer and no change in headcount. Salaries come to $12,000,000 a year (60 × $200,000). Before agents, Halvard paid only for autocomplete seats at $600 per engineer a year, $36,000 in total, so the baseline all-in cost was $12,036,000. After rollout, metered agent usage added $480,000 a year.
Break-even for the company is $480,000 ÷ $12,036,000 = 3.99%, call it 4%. The CFO asked for ROI by team, annual license cost against features per sprint. Weighted work is quarterly merged PRs × the average weight of a 30-PR sample, for the quarter before rollout and the most recent one.
| Team | Engineers | Added AI cost / year | Break-even lift | Features per sprint | Merged PRs / quarter | Weighted work / quarter |
|---|---|---|---|---|---|---|
| Payments | 18 | $160,000 | 4.4% | 6 → 7 | 600 → 760 (+27%) | 1,380 → 1,520 (+10%) |
| Platform | 12 | $110,000 | 4.6% | 2 → 2 | 400 → 520 (+30%) | 1,200 → 1,560 (+30%) |
| Growth | 16 | $120,000 | 3.7% | 10 → 16 | 520 → 680 (+31%) | 1,144 → 1,179 (+3%) |
| Data | 14 | $90,000 | 3.2% | 4 → 5 | 460 → 540 (+17%) | 1,058 → 1,242 (+17%) |
| Total | 60 | $480,000 | 4.0% | 22 → 30 | 1,980 → 2,500 (+26%) | 4,782 → 5,501 (+15%) |
Each team's break-even is its added AI cost over its own baseline: for Payments, $160,000 ÷ ($3,600,000 + $10,800) = 4.4%. For weighted work, Growth's latest sample had 24 small, 4 medium and 2 large PRs, an average of (24 + 12 + 16) ÷ 30 = 1.73, and 680 × 52 ÷ 30 = 1,179.
Features per sprint is the column that misleads. Growth's rose 60%, the best on the page, and its sample shows why: after rollout, Growth split features into smaller tickets, and its average PR weight fell from 2.2 to 1.73. Weighted work rose 3% against a 3.7% break-even, a gap too small for a 30-PR sample to resolve. Call it on the line. Platform shipped no extra features and gained the most, on a database migration its sample tagged as large. Ranked by features, Growth won and Platform got nothing.
Across Halvard, weighted work rose 15% against a 4% break-even. Halvard also sped up CI that quarter, so not all of the 15% belongs to the tools. They need to account for about a quarter of it (4 ÷ 15) to pay for themselves. By team, Platform and Data clear their own break-even with plenty of room, Payments clears it with less (10% against 4.4%), and Growth is on the line. Growth is where to look first.
On the cost side, 22% of Halvard's agent spend, $105,600 a year, sat in sessions with heavy rework. Halving it would cut the added cost to $427,200 and break-even to 3.5%.
What to do with the number
Well above break-even with room for attribution: renew, then work on rework. Near the line: check rework and model mix, and read the team's sample, before cutting seats. PR counts climbing while weighted work stays flat: the tools are producing more pieces, not more work. Reverts rising: fix review before buying more usage.
Recompute every quarter with the same rubric. The board reporting post shows how to present the split by kind of work, the 2027 budget post carries the numbers into next year's plan, and if you bought a spend-visibility tool, see measuring ROI after deploying an AI coding cost tool.
Where VibeCheck and Maestro fit
VibeCheck gives you the cost side from inside agent sessions. It captures Claude Code, Codex and Cursor sessions, estimates each one's cost, and tags its kind of work and whether it needed heavy rework, so the rework share takes one filter to find. Costs are estimates, so use invoices for totals; its cost per PR counts PRs authored, not merged. Get started for free.
Maestro gives you the return side. It scores every merged PR 0–5 for scope, complexity and effect, sorts the work into features, bugs and maintenance, and writes up what shipped and why it mattered. Neither product gives you an ROI percentage; break-even and what shipped are what you can defend. Book a walkthrough, or for a larger rollout, talk to us. Comparing tools? See what software measures AI coding ROI.