There is a number going around engineering org charts that should not be there. It tracks how many tokens a developer burns in a week. Some teams have turned it into a leaderboard. Others quietly use it for performance reviews. The pitch is intuitive: more tokens means more AI usage means more leverage. The data does not agree.

TechCrunch's reporting on tokenmaxxing makes the autopsy easy. Developers feel faster. They are not. The extra throughput is showing up downstream as rework, scrapped pull requests, deploys that get rolled back, and tickets reopened a week later. The opening line of the piece is the only management theory you need: you get more of whatever you measure. Measure tokens, and you will get tokens. You will not necessarily get software.

This is not a hype crash. Frontier coding agents are genuinely good, and getting better. The error is at the layer above the model, in the KPI that organizations are pasting on top of it. My read is that tokenmaxxing is not a productivity strategy. It is a mis-specified objective function being executed at frontier speed, which is the worst possible combination.

The KPI is the bug

Lines of code was a bad metric in 1985 because it rewarded volume over judgment. Tokens are lines of code with a faster compiler and a larger blast radius. Both metrics share the same defect: they measure input proxies in a domain where the only thing that matters is whether the output survives contact with reality.

The surface-level failure is rework. The deeper failure is the incentive: when a team is graded on tokens spent, the cheapest path to a good review is to keep the agent running. Refactor again. Regenerate the test suite. Ask for one more pass. Each loop looks like progress on the dashboard. Each loop also pushes the actual decision, which is "is this code correct enough to ship," further into the future and into someone else's queue.

This is also where the budget conversations have started to land. The token bill is coming due across the industry, with companies burning through annual AI coding budgets in a quarter and pulling licenses they enabled with fanfare months earlier. Costs are the visible symptom. The underlying disease is that the organization never defined what it was buying. It bought "more AI," priced in tokens, and got exactly that.

Durable output is a different number

The useful instruments already exist. Engineering analytics platforms have been quietly converging on the same small set of durable output metrics for AI-assisted work:

  • Acceptance ratio: of the code an agent produces, what percentage gets merged without substantive rewrite.
  • Code churn: of the code that merges, how much survives the next two weeks without being deleted, rewritten, or reverted.
  • Deploy conversion: of the work that started as an agent-generated change, how much actually reached production and stayed there.

None of these are exotic. They are the same questions a good engineering manager has always asked, with the verbs updated. What is different now is that they have to be measured against agent output specifically, because the volume coming out of the agent has decoupled from the volume of decisions humans actually want to make.

If you instrument those three numbers honestly, tokenmaxxing dies on contact. A developer who runs the agent ten times and ships one clean change beats a developer who runs it a hundred times and merges noise. The leaderboard inverts. That is the point.

This is upstream of where I went in The Agent Productivity Gap Is a Measurement Problem. That piece argued for better instrumentation: trace fields, step-conditioned evaluation, weekly outcome review. All still true. But instrumentation only answers the question you asked. If the question is "how many tokens did we burn," no amount of telemetry rescues you. You have to change the question first.

Problem selection is the actual leverage

Here is the part I keep coming back to. The reason tokenmaxxing breaks reality is not that tokens are the wrong unit. It is that the team never decided, before the agent ran, what would count as correct.

In pre-agent workflows, this was implicit. A human engineer holding the problem in their head was also holding the acceptance criteria. The two could not separate, because they lived in the same skull. Agentic workflows split them apart. The agent holds the generation. Someone, somewhere, has to hold the definition of done. If no one does, the agent will fill the silence with output, and the team will mistake that output for work.

Problem selection is the discipline of doing the upstream work that agents cannot do for you: deciding which problem is worth solving this week, what the acceptance criteria are, what a rejected output looks like, and when to stop. It is unglamorous. It does not show up on a token dashboard. It is also the only step that converts frontier capability into compounding value.

This is what platforms like Gemini Enterprise and the AWS Agent stack are implicitly demanding, even when their marketing does not say so. When you package a multi-step agent workflow, you have to declare what success means at each handoff. The platform forces you to specify intent because the agent cannot infer it. Teams that have been living on ad hoc prompting are about to discover that the new packaging layer is mostly a forcing function for problem definition. The prompt was never the bottleneck. The unstated acceptance contract was.

Why selection feels slower and is faster

The pushback I hear most often is that adding selection gates upstream slows experimentation. It does not. It moves the slowness to a place where slowness compounds the right way.

A team that spends thirty minutes defining what a good output looks like, then runs the agent once, ships in an hour. A team that skips the thirty minutes runs the agent fifteen times, generates a wall of plausible code, spends two days reviewing it, ships something half-broken, and pays for the rest in production. The token leaderboard rewards the second team. The acceptance ratio destroys them.

This is also what links the tokenmaxxing problem to the unit economics question I wrote about in Token Cost Is the Real Infrastructure. Tokens per outcome only becomes a usable number when you have defined the outcome. Without that, you are just measuring noise and calling it infrastructure.

The rewire

If you operate a team using coding agents right now, the practical move is small and unambiguous:

Kill the token leaderboard. Replace it with acceptance ratio, churn, and deploy conversion, measured weekly and reviewed openly. Make problem selection a named step in the workflow, with a written acceptance contract before the agent runs. Treat the contract as the artifact under review, not the generated output. When a change misses, do the post-mortem on the contract, not the model.

That is the entire rewire. It is not a governance program. It is not a procurement exercise. It is a one-page change to how a team decides what it is doing before the agent starts doing it.

The organizations that make this move quietly are going to look, six months from now, like they have a better model than everyone else. They will not. They will have a better question.

The closing turn

Frontier agents have made generation cheap. They have not made judgment cheap. Tokenmaxxing is what happens when a team tries to substitute the first for the second and hopes no one notices the difference in the deploy logs.

The question on the wall should not be how much your team produced this week. It should be the one your dashboards are not asking yet: what are you willing to treat as correct, long enough and clearly enough for the agent's output to become real?

Everything else, including the token bill, sorts itself out from there.

Sources and further reading