Most engineering leaders run a version of the same experiment. License an AI coding assistant, roll it out to the team, and wait for velocity to show up in the numbers. Token spend climbs every quarter. Whether that spend is producing anything is a different question, and most organizations cannot answer it.
I have watched this pattern repeat from early-stage startups to Fortune 500 engineering orgs. You keep hearing Copilot this, Claude that, every day, but gross margin on the projects has not shifted one percent.
The reason is structural. The AI assistant produces a faster first draft, but the product manager still writes the story the old way, the developer still submits it into the same review process, and the same number of people do the same checking work. MIT NANDA's 2025 study on enterprise AI adoption found that 95 percent of generative AI pilots failed to produce measurable financial impact, and traced it back to workflows that were never redesigned around the tool. The pattern traces back to the same root cause every time: nobody set up a way to measure what the AI usage was actually returning before scaling it across the org. Access to the tool was never the constraint. Visibility into what the tool was doing was.
There are three groups in this market, and only one of them has a problem.
An organization that has not adopted AI coding tools at all is fine. There is no wasted spend, and whatever the delivery process's limits are, they are at least a known quantity. An organization running AI at true scale, with usage measured, benchmarked, and controlled, is also fine. That organization did the harder work and the numbers reflect it.
The group stuck in Token Hell is everyone in between. Licenses are issued. Token spend climbs. Nobody can say with precision which engineers are getting real output from AI and which are generating drafts that get rewritten anyway, what proportion of spend is going to a model that costs four times more than necessary for the task, or whether AI-assisted work is actually landing faster once review time is counted.
That inability to answer those questions, not the token spend itself, is the actual disease. An organization that cannot build an ROI story for its AI spend is negotiating every renewal on faith instead of evidence.
Here are the reasons of what actually causes token hell.
Most orgs can tell you how many seats are licensed. Almost none can tell you which of those seats are producing work that ships clean versus work that comes back for two rounds of rework.
The AI-generated draft still has to be checked. That checking time is real cost, and it's the cost most productivity claims quietly leave out.
Without a shared standard, one engineer's AI-assisted output holds up in review and another's doesn't, and a usage percentage alone can't tell you which is which. Two engineers can show up identically in an adoption report and land in completely different places on actual delivered output.
No measurement means no ROI story. No ROI story means every renewal conversation about AI tooling spend happens on faith instead of evidence.
Individual developer productivity and organizational delivery velocity are different problems. Moving the second requires three things together, not any one alone.
Shared coding patterns, tools, and libraries, plus telemetry on what AI usage is actually producing engineer by engineer and dollar by dollar. Without it, every AI agent writes against a different convention and nobody can say what the spend is buying.
Structured work, specs, test cases, risk flags, goes to AI agents directly, with humans at defined checkpoints. Without it, the story still passes through a human before it reaches an engineer, and the old bottleneck stays with a tool bolted on top.
How to split work for an AI agent, and what belongs in config files versus a skill versus a manually invoked tool. Without it, every developer runs a different workflow, and output stays inconsistent even when platform and process are right.
Platform + Process + Training. None works independently. Platform without process still routes every draft through the old review queue. Process without training produces agents set up badly. Training without platform has no governed environment to run in.
Skip any one and the other two can't compensate. Platform without process still routes every draft through the old review queue. Process without training produces agents set up badly. Training without platform has no governed environment to run in.
Getting out of Token Hell is not one capability. It is five separate questions an engineering org needs answered, and most tools on the market only answer one of them.
Engineering intelligence: This is the baseline question: where is your SDLC actually getting stuck, from the first prompt to production? Answering it means combining AI-specific telemetry, commits, pull requests, reviews, deploys, with established frameworks like DORA and SPACE into a single view, rather than reading AI adoption off of anecdote or a survey your team fills out once a quarter. Without this layer, "we're using AI" and "we know where AI is helping" remain two completely different claims.
Token intelligence: This is the direct answer to Token Hell. It means knowing where every token goes: which models are consuming the spend, what proportion is going to a frontier model for tasks a cheaper model would have handled just as well, and how your return on that spend compares to benchmarks across other engineering organizations. Most teams can tell you what they're spending on licenses. Almost none can tell you what they're getting per dollar of token spend, or whether that ratio is improving or quietly getting worse.
Prompt routing: Once you can see where tokens go, the next question is whether they're going to the right place. A structural edit does not need a frontier model. A prompt router classifies each request and sends it to the model with the best quality-per-token for that specific task, learning from feedback at the individual and organizational level over time. This is one of the few token-cost levers that reduces spend without asking a single engineer to change how they work, since the routing happens transparently underneath whatever client they're already using.
Code intelligence: Faster output that is worse code is not a win, and an org that only measures speed will not catch that trade-off until it shows up in production. Code intelligence closes the loop by scoring the output itself, not just the volume of it, tracking code quality and review outcomes alongside code output so that an increase in AI-assisted merges is a real signal and not just a warning sign in disguise.
Model observability: This is the layer that makes the other four trustworthy at an enterprise level: security, compliance, and audit-readiness designed in rather than bolted on. Without SOC 2, HIPAA, and GDPR compliance, SSO, and role-based access built into how the measurement itself works, none of the numbers above can be handed to a board or an auditor with confidence.
Token intelligence without code intelligence tells you spend is dropping without telling you whether quality dropped with it. Engineering intelligence without a prompt router tells you where the bottleneck is without giving you a lever to pull on it. All five have to operate on the same underlying data for the picture to be one a CFO or a board can act on.
One AI agent writes the artifact, a spec, a test suite, a first code pass. A second agent verifies it. Only then does it reach a human product manager or tech lead, who still owns intent, prioritization, and the final go or no-go. What changes is the volume of first-draft work that arrives already checked once.
This is the same maker-checker logic banks have used for decades in financial controls. It doesn't remove human judgment, it relocates it, out of the checkpoints where a human was just re-doing work an AI could draft correctly, and into the checkpoints where judgment actually matters: plan review, edge cases, production readiness.
Here's the actual process:
Every AI coding tool vendor has a headline productivity number. The number that actually predicts margin movement looks different, and it has to be measured at the individual level before it means anything in aggregate.
Practical lift = the productivity gain from AI − the review and correction overhead it creates.
A team can look substantially faster on raw output. Once the hours spent correcting, re-prompting, and validating are subtracted, the net gain that reaches a sprint is smaller, sometimes dramatically. That gap is exactly where token costs stop translating into anything a CFO can see: the org pays for the draft, then pays again in engineering hours to make it production-ready.
None of this is calculable without measuring first. Most orgs in Token Hell skip straight to optimizing, a new tool, a tighter prompt library, without ever establishing what current usage returns. That sequence runs backward.
An engineer using AI on 72 percent of their work and producing output 31 percent above baseline, at a quality score in the low 90s, is in a completely different position than an engineer using AI on 31 percent of their work with an output gain of 9 percent. Both engineers show up in an org-wide "AI adoption" number as adopters. Only one of them is actually moving the team's delivery numbers. Averaging those two together into a single company-wide productivity claim is exactly how organizations end up unable to explain, a year later, why the AI spend never showed up in the P&L.
This is also why token consumption on its own is a misleading metric. Tokens show consumption, not value. Two engineers can burn the same number of tokens in a month and produce completely different amounts of usable, review-ready work. Scoring cost, efficiency, and quality together, rather than reporting spend as a single number, is what turns "we're using a lot of AI" into a claim you can actually defend.
A team can look substantially faster on raw output. Once the hours spent correcting, re-prompting, and validating are subtracted, the net gain that reaches a sprint is smaller, sometimes dramatically. That gap is exactly where token costs stop translating into anything a CFO can see.
An org-wide adoption number hides more than it reveals. Usage has to be measured per engineer and per model before it means anything in aggregate.
Output speed without a quality and review-time check is a trap. None of this is calculable without measuring first, and most orgs in Token Hell skip straight to optimizing, a new tool, a tighter prompt library, without ever establishing what current usage returns. That sequence runs backward.
Signs you're in Token Hell:
Most orgs already have some measurement, a DORA dashboard, a SPACE survey, a quarterly AI adoption pulse check. None of it separates what a human wrote from what an AI generated. A thousand AI-generated lines in ten seconds and a thousand lines a senior engineer wrote over two days look identical in a lines-shipped count, so the volume spike that should raise a flag reads as a productivity win instead.
Building this internally is possible in theory. In practice it means standing up human-versus-AI attribution at the pull-request level and maintaining it as new models ship every few months, on top of the engineering work it's supposed to measure. That's the project that stays half-built while the token bill keeps climbing. It's why I build this in as phase one of an engagement, not something a client stands up before we start.
This runs through our Forward-Deployed Engineering model: our engineers embedded inside the client's delivery process, working alongside their team on real sprint work, not a training environment disconnected from production.
A measurement layer asking to see every commit, pull request, and prompt across an org is asking for real access. That access has to be governed the same way any other sensitive system is. Role-based access and audit trails on the measurement layer itself, not just on the codebase it's reporting on.
A measurement layer asking to see every commit, pull request, and prompt across an org is asking for real access. An evaluation that skips the compliance question stalls the moment it reaches security review.
Here's how to proceed from tool adoption.
The engagement starts by establishing your practical lift baseline, engineer by engineer and model by model, before anything else changes.
Agile gets rebuilt around the maker-checker model, with a decision register that reflects your actual risk posture, not a generic policy.
Your team goes through the same platform, prompt, and review discipline training built from our internal rollout across more than 700 engineers.
What's validated in one or two pilot squads becomes the roadmap for the rest of the org, with a trained cohort that can run it without us.
The measurement layer goes in first, before process redesign or training begins. It answers five questions most orgs have never had answered together.
Here's how the assessment engagement actually looks like.
The entry point is a token cost-of-ownership assessment: what you're actually paying for AI coding tools, seat by seat and model by model, against what you're getting back once review time is counted.
Most orgs in Token Hell find the same thing once the numbers are in: spend climbing with no matching lift, and the gap sitting in review and correction overhead rather than in the tools themselves.
If the assessment confirms that gap, the engagement moves into the full redesign: maker-checker process, decision register, training that gets your team running it without us in the room.
If your organization is paying for AI coding tools and cannot say which engineers are getting real value from them, where the token spend is actually going, or whether AI-assisted work is landing faster once review is counted, that visibility gap is Token Hell.
Book a demo to see engineering intelligence, token intelligence, and code quality scored together for your own team.
