You Stopped Tokenmaxxing. The Bill Went Up Anyway.
Tokenmaxxing was never the cost driver. Delivery debt is.
I was halfway through a coffee when the message came in.
“Mike, we should talk. I have something to say about some AI work we could do together.”
He is someone who moves between companies for a living, the kind of person who knows who is buying before the buying starts. Within a minute we were past the pleasantries and into it: there were contacts in his network asking about the nWave Software Factory, the enterprise version, the one with centralised governance over how a team works with agentic AI.
I asked the questions I always ask. What kind of companies. How are they using AI. Which models. What does their workflow actually look like.
Then I asked the commercial one. How much are they spending now, so we can put a sensible price against it.
He laughed.
Not a small laugh. The kind you make when a number has passed the point where a straight answer is possible.
And in the second before he answered, two things went through me. The first was that there is no longer a price attached to this expense. A price implies you know what you are getting in return. These organisations are spending as much as they can, hoping the return shows up. That is not a price. That is a wager.
The second thought was heavier. To fund a line item that size, somebody was probably let go.
Then he told me the number. Capped at five thousand a month. Per developer.
Then he added something else. Last month, for the first time, he had watched a three million dollar AI bill land on a single company. And he had been told it was not the largest one out there.
I went quiet for a few seconds.
There is a particular silence that arrives when you take a left hook from Tyson in his prime. Your legs are still under you. Your head has not caught up.
The two curves that stopped moving together
Every year, tokens get about ten times cheaper for the same work. Some measures put it nearer fifty.
Every year, the bills get bigger.
Read those two lines again. They should not both be true. The raw material is in freefall and the cost of using it is climbing. Nothing else in business behaves like that.
And it is not a phase. Gartner expects inference on the best models to cost ninety percent less by 2030, and says in the same breath that enterprise AI will not get cheaper, because agentic systems consume far more tokens per task than anyone budgeted for.
The obvious explanation had a name.
The explanation that stopped working
Tokenmaxxing. Maximising token consumption and treating the volume as proof of productivity.
It went mainstream in April, when Meta’s internal leaderboard surfaced. Roughly eighty-five thousand employees ranked by token usage. The top contender reportedly burned two hundred and eighty-one billion tokens in a month. Meta pulled the leaderboard after the backlash.
Uber is the cleanest case study, because the numbers are public and the sequence is documented. Claude Code went out to around five thousand engineers in December 2025. Agentic adoption climbed from thirty-two percent in February to eighty-four percent by March. Roughly seventy percent of committed code came from AI. The entire 2026 AI budget was gone by April, four months in, and the CTO confirmed the company was back to the drawing board. Power users were running five hundred to two thousand dollars a month. One two-hour session cost twelve hundred. By June, Uber had imposed a fifteen hundred dollar monthly cap per employee per tool, and its COO was saying the spending had become harder to justify.
Note the detail that usually gets skipped: Uber’s overrun followed an internal leaderboard designed to drive adoption.
The industry corrected quickly. IBM published the obituary in July, arguing that tokenmaxxing is dead and the future belongs to measuring value rather than volume.
Here is the problem with that being the whole story.
The correction happened, and the bills kept climbing.
Companies that never ran a leaderboard, never gamified usage, never encouraged a single wasted call, are watching the same curve. Volume was never the driver. Volume was the visible part.
IBM comes close to the real answer without naming it. They point out that stripping context to reduce tokens produces ambiguous instructions, which produce extra reasoning, retries, tool calls, validation cycles and human rework. The cost does not disappear. It moves.
They have found the rework loop. They have not said where it comes from.
Where it comes from
AI accelerated one half of software delivery and left the other half exactly where it was.
Building now runs at machine speed. Deciding what to build does not, and cannot. That decision depends on understanding a customer’s situation: what happened, what changed, and what they therefore need. It is a causal chain, and it is held by someone who has spent time in the room. A model holds a domain as associations, not as causation. When the chain is missing, the model does not stop and ask. It interpolates between the things it does know, produces something plausible, and ships it as a feature. At machine speed, that guess is often already in the codebase before a human has had time to ask whether it solves a problem any customer actually has.
So the two halves come apart. Engineering outruns product. Product outruns the feedback loop from the user, which is slower than both. And the organisation starts producing more software per week than it can decide well about.
Nobody chose this. There is no bad call to point at, no team that dropped the ball. A speed differential is not a decision. It is what happens when you accelerate one part of a system and leave the rest at its original pace.
Which means every line of code written before the user’s feedback arrives is a bet, not an asset.
And it means the bottleneck has moved. Development is not the constraint any more.
The loop nobody can see
Watch what happens next, because this is where the money goes.
A team ships Feature A. The codebase already carries some mess, so the agents burn more tokens than they should have. Nobody notices, because the feature shipped.
Then the feedback arrives. Bugs, first. Then improvement requests, because the thing works but does not quite fit. Sometimes the feature was simply not what the market wanted, and a product manager proposes a replacement in complete good faith, because that is exactly their job.
So the developers open the codebase again. It is worse than it was last quarter, because Feature A left its own residue. The agents run against it, with full AI-driven discovery, and they burn more this time than last time.
Then it repeats.
CodeScene benchmarked what this costs. Across C++, Java and Python, agents working on unhealthy code consumed almost fifty percent more tokens for the same task. For Java specifically, the language most enterprise legacy runs on, iterative agentic refactoring used around one hundred and twenty percent more output tokens once code health dropped below eight. Even code sitting in the eight to nine band drove considerable waste.
The threshold their research puts on AI-safe code is nine and a half. The industry average is five point one five.
Now put the two together. The per-turn penalty applies, and then the loop runs that penalty three or four times over, on ground that degrades with each pass. In the best case we see in the field, a user story only becomes real five-star value to a user after the first delivery plus several cycles of fixes and improvements. Three times the original estimate, at minimum.
And the board shows one delivery.
You are not paying for tokens. You are paying to rebuild, repeatedly, on ground that becomes more expensive to stand on every time you return to it.
Tech debt has a sibling you never budgeted for
Everyone in your organisation can name tech debt. Almost nobody can name the other one.
Tech debt is the accidental mess in how software is built. Ward Cunningham named it in 1992, and it now has thirty years of research behind it: taxonomies, detection tools, live metrics. It is visible, measurable and refactorable. A machine can be pointed at it, and increasingly is.
Product debt is the sibling, and it is the one sitting behind the mess. Not how the software was built, but what was built. The features that shipped before anyone knew whether they were the right ones. It has a practitioner lineage running seventeen years. Andrew Chen coined product design debt in 2009. Ben Yoskovitz used the bare term in 2015. Paul Jackson split it into types in 2016. Dan Duett gave the modern definition in 2023: anything that compromises the learning loop or impedes progress toward market fit. No standard instrument. No live score.
Chen wrote in 2009 that design debt compounds technical debt. He was right, and he was early. What he could not see was what happens when one half of that pair suddenly starts running at machine speed and the other does not.
Delivery debt is the name for the two of them compounding together. One half a machine can drain. The other half it cannot, because draining it requires understanding what another person actually needs.
And that is harder than any of us admit. I have a wife and a daughter. Same flesh, same house, years of practice, and I still get them wrong. Understanding another human being is not a retrieval problem. We are asking a model to do the one thing we are not reliably good at ourselves, and then we act surprised when it guesses.
Three horizons
Right now, this shows up as friction. Engineering delivers, product cannot keep pace, and the feedback loop trails both. Your teams are already describing it. They are not complaining. They are reading an instrument nobody installed.
In the mid term, it shows up on the invoice, climbing while the price of tokens falls. That is the point at which finance starts asking questions, roughly two quarters after engineering already told you.
In the long term, the cost curve and the value curve diverge, and the gap does not close on its own. Some organisations are already swapping headcount for AI spend to hold the line, which buys a quarter and removes the people who understood the customer. And the invoice is not the only thing arriving on a schedule: the European AI Act has dates attached to it too.
What actually closes the gap
Two halves, two different answers, and conflating them is why most of this spending is not working.
The nWave Software Factory exists to drive the drainable half toward zero, continuously, because continuous refactoring is the only mechanism that keeps delivery predictable and keeps the surface your agents work on cheap to work on.
The Helm is the other half, and it does two things. It builds the practice of modern product management with AI, so the people closest to the customer can keep pace with what the machine now produces. And it gives your teams the competence to run nWave at its full potential, the way a marque prepares drivers for its own machine.
My friend and I never finished that coffee. Five minutes became a long conversation about how you help an organisation that cannot see the loop it is inside.
Because that is the thing about a whirlpool. From the deck, nobody sees the kraken. They see the water turning and take it for weather. The pull is gentle at first, the ship is still under way, and every instrument on board reads normal. By the time the spiral is obvious, the ship is already in it.
That is why the three million silenced me. Not the size of the number. The fact that nobody on that deck could see what had hold of them.
The five thousand a month was never a token problem.
Next week is Episode 100. 🍾
I am marking it the only way that makes sense: the full anatomy of delivery debt. What the research measures, what I am arguing, and the line between the two drawn where you can see it.