What Dijkstra had to say about token spend

Key takeaways

• Lines of code was never a productivity measure. It was invented in the 1960s to estimate effort and cost, so every use of it since has been a stand-in for a bill.
• AI removed the last thing holding it up. Once an agent produces the volume, volume stops tracking effort, and a dashboard can show a 10x team that is moving slower.
• Token spend is the honest version of what lines of code was reaching for, because it is the real cost, itemized on an invoice, instead of a number guessed at through an equation.
• Never make token spend a target. Manage the ratio instead, meaning cost per merged change, cost per closed ticket, cost per feature that survives contact with real users.

‍

Tokens and lines of code measure the same thing: the cost of building software. Neither tells you whether it was worth building. AI made the cost side easy to read and left the value side exactly as hard as it always was, and engineering leaders are being asked to report on both.

Dijkstra put the count on the other side of the ledger

Edsger Dijkstra saw this in 1988.

“If we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.”

He was making an accounting argument. Every line you write is a liability the business takes on, because somebody has to maintain it, debug it, secure it, and eventually delete it. Counting those lines and calling the number productivity works the same way as celebrating how much debt you took on this quarter. He also named the consequence, which is that counting lines of code “encourages the writing of insipid code.” Pay for volume, and you get volume.

That is all the metric ever did. “Lines of code” were invented in the 1960s to measure size, because size was the only property of software anyone could count, and size stood in for effort and cost. Barry Boehm’s COCOMO made that explicit in 1981, taking thousands of lines into one side of an equation and returning person-months out the other. Nobody was measuring achievement. They were estimating a bill.

What AI actually broke

When an agent generates hundreds of lines in seconds, every volume signal goes haywire. Commit counts spike, pull requests multiply, and on a naive dashboard, every developer looks like a 10x engineer.

METR ran a randomized controlled trial in early 2025 on experienced open-source developers using AI tools on codebases they knew well. They were about 19% slower with the tools than without them, but they believed they were about 20% faster. Handle that carefully, since the sample was 16 developers working close to the worst case for AI assistance. The narrower finding is the more useful one. Felt productivity and real productivity drifted apart, and the volume metric sided with the feeling. 

Lines of code was broken long before any of this, and what AI removed was the last bit of cover. When humans typed every line, lines typed correlated loosely with effort spent, and that noisy correlation kept the illusion alive.

The work was never in the code you keep

Lines of code only ever counted the code that survived. Dijkstra’s point was that the surviving code should be as small as possible, so if your best work makes the final code smaller, then counting the final code measures the opposite of skill.

The effort went into everything you wrote and threw away. The three approaches you tried before the fourth one worked. The exploratory pass that taught you what the real problem was. That is where the thinking and the failing happen, and lines of code were blind to all of it.

Token spend sees that discarded work, because every draft you throw out burns tokens whether or not one line of it reaches the final diff. An agent might generate and discard thousands of lines to land a forty-line difference. Count lines, and you measure the forty. Count tokens, and you see the thousands. Tokens also carry a metered dollar cost, which no line of code ever did. COCOMO estimated its number through a regression equation, and token spend is the cost itself, itemized on your bill.

Do not put token spend on a dashboard

If your takeaway is to rank engineers by token spend, that repeats the original mistake one level up.

Goodhart’s Law, in the phrasing we owe to Marilyn Strathern, says that when a measure becomes a target, it ceases to be a good measure. Reward token consumption and engineers will consume tokens, padding prompts and running agents in loops to hit a number. Gergely Orosz documented the early cases of “tokenmaxxing” in 2026, including companies setting per-engineer token minimums. The developer who solves a hard problem in one shot burns fewer tokens than the one who thrashes through twenty agent iterations, so the thrasher looks like the hero.

The original sin was never measuring effort. A direct meter on effort is the most honest instrument this field has ever had. The sin is taking the number in the cost column and cheering for it as though it lived in the accomplishment column. Measure effort so you can reason about it, and do not reward it as though it were the outcome.

What to measure, and what we still cannot

If tokens are the honest denominator, the number worth managing is the ratio: cost per merged change, cost per closed ticket, cost per feature that survives contact with real users. That treats token spend as a return-on-investment input, and it points to where the constraint now sits: specification, review, and validation rather than writing code.

Be honest about what that does not solve. For sixty years, this industry poured its ingenuity into measuring software inputs, and token spend is the best entry in that lineage because it reads cost directly instead of guessing. The input side was never the hard part. Measuring the value delivered per unit of input has never had a clean answer, and AI has not cracked it either. It only sharpened the cost side until the value side had nowhere left to hide.

Measuring what we spend was never the mountain. Measuring what it was worth still is. If you have connected a unit of input to the value it delivered, that is the answer I would most like to hear.

Jeremy Freeman is the CTO of Allstacks. He spends a lot of time thinking about what engineering teams should actually measure when the easy things to count stop meaning anything.

‍

Frequently asked questions

Are tokens the new lines of code? Both measure what software cost to produce, and tokens do it far more honestly. Lines of code was a stand-in for effort and cost, invented because size was the only measurable property of software. Token spend is the effort itself, metered and billed, so it does not stand in for anything.

Is token usage a good developer productivity metric? No. It measures effort and cost, while productivity is about value delivered per unit of that effort. Rewarding token consumption produces more token consumption. Use token spend as the cost input to a ratio, never as a score on its own.

What should engineering leaders measure when AI writes the code? Measure cost per merged change, cost per closed ticket, and cost per feature that survives contact with real users, because each pairs a dollar-denominated input with a delivered outcome. Keep DORA's four keys for flow and stability, since they measure outcomes and are unaffected by how much code got generated.