AI spend per engineer is not ROI

Tomasz Tunguz published the comparison that will anchor every AI-budget meeting this quarter: by his estimates, Anthropic spends about 2.3 times its engineering payroll on model compute — roughly $515k per engineer against a $224k fully-loaded salary — while the top tier of software firms spends around 0.4 times payroll, and the median company elsewhere spends a nearly comical $137 per engineer per year. Estimates, stacked on assumptions and external forecasts; none of it independently verifiable, as he'd be the first to note. But the spread is so wide that the error bars barely matter. Somewhere between $137 and $515,000 per engineer, your company has a number.

The mistake coming for that number: reading it as a verdict. The bull version — "spend more, the frontier labs do" — and the bear version — "look at the waste" — share the same fallacy. Spend per engineer is a measure of workload intensity. It says nothing about value until you divide it by work.

The same ratio, four different companies

Take a high ratio — an engineer burning thousands a month in tokens. That is consistent with at least four realities. An engineer running productive autonomous loops overnight, shipping accepted changes while asleep — the dream. An agent stuck in retry loops, burning premium tokens on failures nobody audits — the nightmare wearing the dream's invoice. A team defaulting everything to the priciest model because nobody built a router — pure inefficiency. Or genuine research workloads where expensive exploration is the job — legitimate, but a different budget line than delivery. Identical bills. Wildly different businesses.

Now the low ratio. $137 a year is either a company whose engineers barely touch the tools — adoption failure disguised as thrift — or, occasionally, a disciplined shop routing everything through cheap models with sharp evals. The bill alone cannot distinguish frugality from stagnation, any more than the high bill distinguishes leverage from waste.

rendering diagram…

A ratio with four interpretations is not a KPI. It is a conversation starter that arrives dressed as a conclusion.

The denominator that makes it mean something

What turns spend into ROI is the same thing that turns any input into a unit economic: dividing by output you actually accept. Four denominators do the work.

Accepted changes. Not tasks attempted, not PRs opened — changes merged and retained. Cost per accepted change is the closest thing to a unit price for AI-assisted engineering, and it is computable from data you already have: the token bill and the git log.

Review time consumed. Every AI-generated change bills twice — once in tokens, once in senior-engineer review minutes. A tool that halves token cost while doubling review load raised your real cost; the spend line just hid it in payroll, where it always hides.

Escaped defects. Failure cost is part of the price. If accepted changes regress in production at a higher rate than the human baseline, the cheap tokens were expensive. This is the column that most spend dashboards omit and most CFOs never think to request.

Displaced work. The honest credit side: what did the spend make unnecessary? Contractor hours not bought, backlog retired, the migration that happened this quarter instead of never. Hard to measure, worth estimating badly rather than ignoring.

At work, I sat in precisely the meeting this piece is warning about: a CFO looking at a rising token bill, asking whether it was "worth it", and a platform team answering with adoption stats — seats, sessions, tokens. Nobody in the room could say what an accepted change cost, whether review load had moved, or what the defect trend looked like. The bill was declared "probably fine" — a decision made by vibes at five figures a month, renewable monthly. We spent a week wiring the token spend to the git log and the incident tracker. Cost per accepted change turned out to be falling — adoption was working — but one team's agent was generating a third of the spend and a tenth of the acceptances. The ratio said nothing; the denominator found the leak in an afternoon.

What to build before the budget meeting

The instrumentation is deliberately boring: tag AI spend by team and workflow, count accepted changes from the version-control system, sample review time from PR timestamps, and pull escaped defects from the incident tracker. Four joins, one dashboard, no new tools. Then let the ratios argue: cost per accepted change trending down is a program working; spend rising while acceptances flatline is a leak with a growth curve — whatever the per-engineer headline says, in either direction.

Steal the one-line version for the meeting itself. When the spend-per-engineer slide appears, ask: per what? If the answer is "per engineer", the metric is intensity. If the answer is "per accepted change, and here is the trend" — fund that team. They are the ones actually measuring.

A token bill divided by headcount is a feeling; divided by accepted work, it is a business — bring the denominator.