Waydev: the race for tokens reduces returns from AI coding and inflates rework volume

A new cult in teams actively using AI-coding: not the quality of releases, but the volume of burnt tokens. The problem is that more code and more PRs don't necessarily mean more useful work: a significant portion of this volume then goes into rewriting.

How tokenmaxxing works

The term tokenmaxxing describes simple logic: if a developer spends many tokens in Claude Code, Cursor, or Codex, supposedly they work more productively. Inside companies, large AI-compute budgets have already become an element of status, almost like the number of code lines or commits once did. But it's the same old mistake in new packaging.

Tokens are an input to the process, not a result. They show how many resources were burned, but don't answer whether the team has more reliable, useful, and maintainable code. According to Waydev, which works with approximately 50 companies and more than 10 thousand engineers, managers often see a very nice high-level picture: 80–90% of AI-generated code is initially accepted and enters the repository.

But then less visible work begins—fixes, rollbacks, and rewrites in the coming weeks. If you account for this tail, the real share of code that actually "stuck" drops to 10–30%. This is where the illusion of instant productivity breaks down.

Metrics against illusions

Several companies working on engineering analytics are now trying to measure this picture. Demand has grown so much that large players have also started investing in such tools: Atlassian bought DX startup for $1 billion in 2025 to better measure the return on AI-agents in development. The general conclusion across different platforms is similar: the volume of code produced is growing, but the share of sustainable results is not.

• GitClear reports that regular users of AI tools show code churn 9.4 times higher than developers without AI, although cleaned year-over-year growth looks much more modest—about 25%.
• Faros AI in its March 2026 report recorded a 51% increase in PR size with high AI share in development, a 28% increase in bugs per PR, a fivefold increase in median review time, and a spike in code churn of 861%.
• Jellyfish on a sample of 7,548 engineers found that the most "token-budget" developers make more PRs, but the dependency quickly becomes unprofitable in price.
• In Jellyfish data, the top 20% in token spending on average released 23 merged PRs per quarter against 11 for the bottom 20%, but spent about $1,822 on this versus roughly $3.

The cost of extra code

The main problem is not that AI writes a lot, but that the extra volume shifts the cost of work further down the pipeline. The team generates drafts faster, but then pays for reading, review, integration, and maintenance of this code. If PRs become larger, bugs more numerous, and reviews longer, then part of the "acceleration" is simply moved into the future as technical debt.

This is especially noticeable in junior developers: they more often accept AI suggestions without much filtering and then more often return to these changes. With senior engineers, the situation is better because they set context more precisely and cut garbage at the entrance more ruthlessly. But even in this case, marginal returns decline.

Jellyfish writes almost linearly: at the upper end of the curve, developers spend almost 10 times more tokens to get roughly twice the throughput. This is no longer a story about efficiency, but about very expensive acceleration.

"This is a new era of software development, and companies will have to adapt anyway," says

Waydev CEO Alex Chirchey.

What this means

AI-coding won't go away, but a cult of maximum token spending looks like a bad management metric. If companies want real productivity, they will have to look not at the amount of generated code, but at how many changes pass review without breaking production, don't return for rewriting, and pay for their token cost.