Your AI Agent Is Not Expensive. Your Rework Loop Is.

Tokenmaxxing taught companies the wrong lesson. The real metric is not how much AI you use, but how much stable product value survives review, testing, and production.

I used to think the biggest AI coding problem was accuracy.

Then I started seeing a different problem.

The agent writes code. The code looks reasonable. The task seems done. Then the real work starts: fixing edge cases, rewriting half the change, reviewing a giant diff, asking why three unrelated files changed, running tests again, and discovering that the feature technically works but is not safe enough to ship.

The expensive part is not always the first generation.

The expensive part is the loop after generation.

That is why the recent “tokenmaxxing” discussion caught my attention. One chart, shared widely on X, claimed that across 2,444 companies, only $0.18 of every $1.00 of AI coding spend becomes shipped product value.

The rest was broken down like this:

• $0.44 on bug fixing
• $0.27 on rework
• $0.11 on review friction
• $0.18 on shipped product

In other words, the claim is that 82% of AI coding spend never reaches the product.

That number should be treated carefully. It appears to come from a platform-reported dataset, not an independently audited industry benchmark. But even if the exact number changes, the pattern is hard to ignore.

Companies are discovering that AI coding productivity cannot be measured by how much AI is used.

More tokens do not automatically mean more progress.

More generated code does not automatically mean more shipped value.

More pull requests do not automatically mean customers got something useful.

The real question is much simpler:

How much of the AI work survived review, testing, production, and time?

That is the question tokenmaxxing avoids.

What tokenmaxxing actually means

A token is a small unit of text processed by an AI model. When you send a prompt, read files, include context, run tools, ask for a rewrite, or let an agent work through a codebase, tokens are being consumed.

Tokenmaxxing is the habit of treating high token usage as a signal of serious AI adoption.

It sounds productive on the surface.

Your engineers are using Claude Code more. Your teams are spending more on AI tools. Your internal dashboard shows more prompts, more agent runs, more generated code, more pull requests, and more automation.

But that is like judging a car by how much petrol it burns.

If one car burns 10 litres and travels 20 km, while another burns 2 litres and travels 18 km, the first car is not more productive. It is less efficient.

AI tokens are fuel.

Stable shipped product is distance travelled.

Burning more fuel is only good if the vehicle is actually moving in the right direction.

Token usage is an input metric. The useful question is how much reliable product value came out at the other end.

Uber made this a boardroom problem

The tokenmaxxing conversation became more concrete when Uber’s COO Andrew Macdonald questioned whether rising AI token spend was translating into useful customer-facing output.

According to reporting from Business Insider, Fortune, and Indian Express, Uber had been pushing AI coding tools heavily. Fortune reported that Uber burned through its 2026 AI coding tools budget in four months. The company also reportedly had internal usage leaderboards, which is exactly the kind of thing that can turn a tool into a status game.

The most important line from Macdonald was not anti-AI. It was an anti-bad measurement.

He basically asked: if you cannot draw a direct line from token consumption to useful features and functionality shipped to users, how do you justify the trade?

That is the right question.

Because once AI spending becomes large enough, it stops being a developer productivity experiment. It becomes a finance, operations, and strategy problem.

A small team can say, “We are experimenting.”

A large company spending millions needs to answer, “What changed for the customer?”

That is where tokenmaxxing breaks down.

It measures the fire, not the cooking.

The old mistake is back with a new bill

This is not the first time software teams have measured the wrong thing.

We already had the lines-of-code trap.

If a developer writes 2,000 lines and another writes 200 lines, who was more productive?

You cannot answer that from the line count.

Maybe the 2,000-line change added unnecessary complexity. Maybe the 200-line change removed a fragile abstraction and made the system easier to maintain. Maybe the best work was deleting code.

Tokenmaxxing is the AI-era version of the same mistake.

Instead of counting lines written by humans, we count tokens consumed by agents.

The problem is the same: we are measuring activity instead of value.

AI makes this worse because it can create activity very quickly.

A coding agent can generate code, tests, comments, documentation, migration plans, changelogs, and refactors at a speed that feels magical. But if the surrounding engineering system cannot absorb that output, the cost simply moves downstream.

Review queues get longer.

CI gets noisier.

Pull requests get bigger.

Reviewers lose trust.

Bugs appear later.

Code churn increases.

The team feels busy, but the product does not necessarily improve.

That is the hidden cost of unstructured AI adoption.

More code can create more work

This is the uncomfortable part.

AI coding tools can absolutely increase output. That part is real.

But output is not the same as throughput.

Output is “how much code appeared.”

Throughput is “how much useful work moved through the system and reached users.”

Those are different.

TechCrunch reported a useful pattern from engineering analytics companies: AI-generated code may look highly accepted at first, but much of it can be revised or churned later. Some reports suggest that initial acceptance can look like 80% to 90%, while retained acceptance after later churn may fall much lower.

Faros AI reported a similar split in its platform data. In high-AI environments, task completion and epics completed per developer increased. That is the good news.

But the same analysis also reported:

• Bugs per developer up 54%
• Median review time up 5x
• Code churn up 861%
• Incident-to-PR ratio more than tripled
• More PRs merging without review

Again, this is vendor/platform data, so I would not treat every number as a universal law. But the shape matches what many engineering teams are starting to feel.

AI speeds up code production first.

Then the rest of the software delivery system has to catch up.

That includes:

• Product clarity
• Task scoping
• Architecture review
• Code review
• Test coverage
• CI speed
• Release safety
• Observability
• Rollback paths
• Ownership

If those systems are weak, AI does not remove the bottleneck.

It floods the bottleneck.

AI can speed up implementation, but weak review, testing, and release systems turn that speed into rework.

The real bottleneck is the SDLC

Dropbox wrote one of the more balanced pieces on this topic. Their point was simple: AI coding tools increase code throughput, but the bottleneck shifts downstream.

That means the problem is no longer just “Can developers write code faster?”

The better question is:

Can the whole software delivery lifecycle safely absorb more code?

This is where many AI productivity discussions become too shallow.

They focus on the model.

Which model writes better code? Which model has better reasoning? Which agent edits files faster? Which tool has the best terminal integration?

Those things matter.

But production software is not created by code generation alone.

It moves through a system:

1. Someone defines the problem.
2. Someone scopes the change.
3. Someone writes or generates code.
4. Someone reviews the code.
5. Tests and checks validate it.
6. The system is released.
7. Users interact with it.
8. Logs, incidents, and metrics tell you whether it worked.

AI can speed up step 3 dramatically.

But if steps 1, 2, 4, 5, 6, 7, and 8 remain weak, the team has not improved the system. It has only increased pressure inside it.

That is why some teams feel like AI made them faster, while others feel like AI made everything noisier.

The difference is not always the model.

Often, it is the workflow around the model.

This is why I keep coming back to harnesses

In my previous article, “The Missing Piece in AI Agents: The Harness Around the Model,” I wrote about this exact problem from a different angle.

The core idea was:

A model thinks.

An assistant replies.

An agent acts.

A harness controls how that action happens.

A model is the engine.

The harness is the car around it: steering, brakes, dashboard, mirrors, memory, permissions, tests, logs, evaluators, and recovery paths.

Tokenmaxxing shows what happens when companies install a bigger engine but forget the rest of the car.

The agent can move faster, but can it steer?

Can it stop?

Can it tell when it is wrong?

Can it recover from mistakes?

Can it prove that the change is safe?

Can the company trace cost to value?

Without that harness, AI coding becomes a very expensive autocomplete loop.

With a strong harness, AI coding can become a real production workflow.

That is the difference.

Related article: If you want the deeper version of this idea, I wrote about it here: The Missing Piece in AI Agents: The Harness Around the Model.

What a weak AI coding harness looks like

A weak harness usually has the same symptoms.

The team gives agents broad tasks like:

Refactor this module.

or:

Improve this service.

or:

Fix all bugs in this flow.

Then the agent starts editing.

It reads some files, misses others, makes reasonable assumptions, touches more code than expected, runs a small test, and returns with a confident summary.

The summary sounds good.

But the reviewer sees the real cost:

• The PR is too large.
• The change includes unrelated cleanup.
• The tests are shallow.
• The agent missed an edge case.
• The implementation works for the happy path only.
• The generated code is harder to maintain.
• The task needs another round.

Now the team spends more tokens fixing the previous tokens.

That is the rework loop.

This is not always because the model is bad.

Sometimes the task was too vague. Sometimes the repo had poor tests. Sometimes the agent had too much freedom. Sometimes there was no cost boundary. Sometimes, nobody defined what “done” meant.

In human teams, we do not solve this by telling developers, “Please be smarter.”

We create better systems.

We write clearer tickets. We add tests. We require reviews. We create CI checks. We use staging. We monitor production. We create rollback paths.

AI agents need the same treatment.

The ratchet pattern: every failure should improve the system

The best idea from harness engineering is what I call the ratchet pattern.

A ratchet moves in one direction. Every mistake should move the system one click forward.

Suppose an agent keeps creating oversized pull requests.

A weak response is:

Please make smaller PRs next time.

A stronger response is:

Before coding, create a file-level change plan.

Reject the task if more than 8 files need to change.

Split large tasks into phases.

Show touched files before editing.

Suppose an agent keeps missing tests.

A weak response is:

Remember to add tests.

A stronger response is:

The task is not done until unit tests, integration tests, and type checks pass.

If no test is added, explain why.

If tests fail, do not hide or skip them.

Suppose an agent keeps wasting tokens exploring irrelevant files.

A weak response is:

Be efficient.

A stronger response is:

Start with repo map.

Search only relevant folders.

Summarize findings before editing.

Set a max-turn budget.

Stop and ask if scope expands.

The point is simple:

Do not just fix the current AI mistake. Change the workflow so the same mistake becomes less likely next time.

That is how token waste becomes learning.

Without the ratchet pattern, every bug creates another expensive loop.

With the ratchet pattern, every bug improves the harness.

The metrics I would track instead

If a company wants to use AI coding agents seriously, I would not start with token usage leaderboards.

That encourages the wrong behavior.

I would track the journey from AI activity to shipped value.

Here are the metrics that matter more:

1. Tokens per verified task

Not tokens per engineer.

Not tokens per team.

Not tokens per day.

Track how many tokens it takes to complete a task that passes the agreed verification criteria.

That means tests, review, and acceptance matter.

2. Dollars per shipped feature

This is closer to what leadership actually cares about.

If AI spending went up, did more useful functionality reach users?

No more demos. Not more drafts. Not more branches.

Shipped functionality.

3. Rework rate after 7, 14, and 30 days

A generated change can look good on day one and become expensive on day seven.

Track how often AI-assisted changes are rewritten, reverted, patched, or heavily modified after merge.

This is where the hidden cost appears.

4. AI-authored bug rate

Do AI-assisted changes introduce more bugs, fewer bugs, or different types of bugs?

This should not be used to shame developers. It should be used to improve task design, prompts, tests, and review gates.

5. Review time and review quality

If AI creates more code than humans can review, the system is not healthier.

Track review time, PR size, number of review comments, skipped reviews, and post-merge fixes.

Review friction is a real cost.

6. Code churn

If AI writes code that gets rewritten soon after, the first version was not free. It was a debt with a nicer interface.

Code churn is one of the clearest signs that generated output is not sticking.

7. Rollbacks and incidents

This is the production reality check.

If AI-assisted development increases deployment speed but also increases rollbacks and incidents, the team needs stronger gates.

8. Tokens per retained change

This is my favorite metric.

Do not only ask how much code AI generated.

Ask how much of that code remained useful after review, testing, and time.

That is much closer to real productivity.

The useful dashboard follows AI work all the way to retained, reviewed, shipped product value.

The answer is not “use less AI”

I do not think the lesson is that AI coding tools are bad.

That is too easy.

The better lesson is that AI coding tools expose the quality of your engineering system.

If your tickets are vague, AI will amplify vagueness.

If your tests are weak, AI will generate code that looks done before it is done.

If your reviews are overloaded, AI will make the queue worse.

If your architecture is messy, AI will find more ways to patch around the mess.

If nobody knows what metric matters, token usage will become the metric.

But if your harness is strong, AI becomes much more useful.

A good AI coding workflow has:

• Clear task scope
• Small PRs
• File-level plans before edits
• Cost budgets
• Permission boundaries
• Strong tests
• Separate builder and reviewer passes
• CI checks
• Human quality gates
• Logs and traceability
• Post-merge monitoring
• A way to turn repeated failures into new rules

That is not anti-AI.

That is how you make AI useful in real engineering work.

A practical workflow for teams

If I were introducing AI coding agents into a backend team, I would keep the first version boring.

Boring is good.

I would not start with giant autonomous migrations.

I would start with scoped tasks where success is easy to verify.

For example:

Add validation to this endpoint.

Touch only these files.

Before editing, explain the current flow.

After editing, run these tests.

If the change requires more files, stop and ask.

Final answer must include files changed, tests run, and remaining risks.

Then I would measure what happens.

Did the task pass review?

Did tests catch issues?

Was the PR small?

Did the agent over-edit?

Did a bug appear later?

How many tokens did it take from the prompt to the verified task?

Then I would improve the harness.

If the agent misses ownership checks, add an authorization checklist.

If it creates giant PRs, add scope limits.

If it forgets tests, make tests part of the definition of done.

If it burns tokens reading irrelevant files, improve repo maps and task templates.

If reviewers struggle to understand the change, improve the final report format.

This is the boring work that creates real productivity.

Not leaderboards.

Not token contests.

Not “who used the most AI this week?”

The teams that win will probably be the teams that make AI work boring, measurable, and safe.

Where memory and context fit in

There is another reason token spend gets messy: agentic coding is not like a short chat.

A normal chat might answer one question.

A coding agent may read files, inspect logs, search the repo, run tests, process errors, rewrite code, review itself, and try again.

Every one of those steps adds context.

Context costs tokens.

Long-running agent work is expensive because the agent keeps carrying information forward. Sometimes that context is useful. Sometimes it is noise. Sometimes it is the same mistake being repeated in a slightly different way.

This connects to another article I wrote, “AI’s Biggest Problem Isn’t Intelligence. It’s Memory.” The short version is that AI systems do not get useful memory for free. Context, retrieval, cache, summaries, files, and logs all affect cost and quality.

In tokenmaxxing, poor context management becomes a hidden tax.

If the agent reads too much, it spends more.

If it reads too little, it misses important details.

If it keeps bad assumptions in context, it repeats mistakes.

If it loses an important state, it restarts work.

So the answer is not simply “shorter prompts.”

The answer is better context engineering:

• Give the agent the right files, not every file.
• Summarize long histories into useful checkpoints.
• Store durable project knowledge outside the active prompt.
• Use repo maps and task-specific context bundles.
• Keep verification results separate and easy to inspect.
• Stop failed loops early instead of letting them burn tokens.

A strong harness controls not only what the agent can do, but also what the agent needs to know.

Review friction is also a product problem

One part of the 82% chart is easy to underestimate: review friction.

People usually focus on bugs and rework because those sound expensive.

But review friction is where many teams quietly lose trust.

If AI produces a huge markdown explanation, a giant diff, and a vague “all tests pass” summary, the human reviewer now has to reconstruct what happened.

That is not productivity.

That is work transferred from the agent to the reviewer.

This is why output format matters.

In another article, “The One-Word Change That Makes AI Agents 10x More Useful,” I wrote about asking agents to produce HTML artifacts instead of plain markdown when the output needs to be reviewed visually. The deeper point is not just HTML. The deeper point is that AI output should reduce human review load, not increase it.

For coding agents, that might mean:

• A clean change summary
• A before/after behavior explanation
• A list of touched files
• A test evidence section
• A risk section
• Screenshots for frontend changes
• API examples for backend changes
• A reviewer checklist

If reviewers cannot quickly understand what changed and why, the agent has not finished the job.

It has only generated the next review burden.

The simple rule I would use

Here is the rule I keep coming back to:

Do not measure AI by how much it produces. Measure AI by how much useful work survives.

Survives review.

Survives tests.

Survives production.

Survives maintenance.

Survives the next developer reading it.

That is the difference between generated code and engineering output.

AI can help a lot. I use it every day. But the useful version of AI coding is not “let the agent run forever and celebrate the token graph.”

The useful version is:

1. Give it a clear task.
2. Give it the right context.
3. Limit the blast radius.
4. Make it prove the result.
5. Review the risky parts.
6. Measure what survived.
7. Turn mistakes into better guardrails.

That is how AI becomes part of engineering instead of another source of engineering debt.

Tokenmaxxing is dead. AI engineering is not.

I think this is where the conversation should land.

AI coding is not dead.

Autonomous agents are not useless.

Claude Code, Cursor, OpenCode, Codex-style tools, and internal company agents are all going to keep getting better.

But tokenmaxxing as a productivity strategy should die.

It is the wrong scoreboard.

The future is not going to belong to the team that burns the most tokens.

It will belong to the team that can convert AI work into reliable shipped value with the least rework, the clearest review path, and the strongest feedback loop.

That means the winning teams will not just buy better models.

They will build better harnesses.

They will know when to let agents work, when to stop them, when to verify them, when to split tasks, when to ask humans, and how to measure the cost from prompt to production.

The model is the engine.

Tokens are the fuel.

The harness is the car.

The distance travelled is the shipped product.

If we measure the fuel and ignore the distance, we should not be surprised when the bill looks ridiculous.

Thanks for reading.

This topic matters to me because I use AI coding agents every day. I do not think the answer is to avoid them. The answer is to become more disciplined about how we use them.

The best AI workflows I have seen are not the ones where the agent runs wildly and produces the most code. They are the workflows where the agent has clear context, a tight scope, good tests, useful review output, and a way to learn from mistakes.

That is the kind of AI engineering I want to keep exploring: not hype, not fear, but practical systems that make developers better without quietly creating more debt.

If you are experimenting with Claude Code, Cursor, OpenCode, Codex-style tools, or your own internal agents, I would love to hear what you are measuring. Are you tracking token usage, shipped features, rework, review time, or something else entirely?

You can connect with me here:

• LinkedIn
• Twitter / X

I write about AI agents, backend engineering, system design, and the practical workflows around modern software development.

No hype. No affiliate links. Just what I am learning while building and using these tools.

References

Primary discussion

• Brandon Carl tweet on 82% token spend: https://x.com/brandonjcarl/status/2059407045690859584
• Aiswarya Sankar / Entelligence chart: https://x.com/Aiswarya_Sankar/status/2059298259949232484

Reporting and analysis

• Business Insider: Uber COO says AI token spend is getting harder to justify: https://www.businessinsider.com/uber-coo-andrew-macdonald-ai-token-spending-harder-justify-2026-5
• Indian Express: Uber COO on tokenmaxxing and AI spend: https://indianexpress.com/article/technology/artificial-intelligence/uber-coo-ai-spending-hard-to-justify-tokenmaxxing-layoffs-10710504/
• Fortune: Uber burned through its AI coding tools budget: https://fortune.com/2026/05/26/uber-coo-ai-spending-tokens-claude-code/
• Fortune follow-up on tokenmaxxing ROI: https://fortune.com/2026/05/28/tokenmaxxing-is-dead-companies-didnt-get-the-roi-from-ai-they-wanted-to-see/
• TechCrunch on tokenmaxxing and developer productivity: https://techcrunch.com/2026/04/17/tokenmaxxing-is-making-developers-less-productive-than-they-think/
• Faros AI analysis of tokenmaxxing: https://www.faros.ai/blog/tokenmaxxing
• Dropbox engineering on AI agents and SDLC bottlenecks: https://dropbox.tech/culture/beyond-code-generation-rethinking-engineering-productivity-in-the-age-of-ai-agents
• Deloitte on AI token spend dynamics: https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-tokens-how-to-navigate-spend-dynamics.html

Research papers

• How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks: https://arxiv.org/abs/2604.22750
• Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review: https://arxiv.org/abs/2605.17548

My related articles

• The Missing Piece in AI Agents: The Harness Around the Model
• AI’s Biggest Problem Isn’t Intelligence. It’s Memory.
• The One-Word Change That Makes AI Agents 10x More Useful