08.10.2026
Reading time: 5 minutes

Why AI coding can cost more than it saves

In this article​

Summary

  • AI-generated code costs more than it saves when it is hard to maintain, because rework, review, and refactoring burn more tokens.
  • AI token spend behaves like cloud spend: variable, usage-based, and capable of spiking without warning.
  • Agentic workflows are usually the reason for the spikes, because agentic coding tasks can consume up to 1,000 times more tokens than code chat.
  • Capping the bill mostly relocates the cost into missed deadlines. Raising the yield per token works better.
  • The teams keeping this under control measure what their tokens produce, not just how many they burn.

The urgent need for AI coding cost management

Tokenomics. Token spend. Token consumption efficiency. Odd to think these were unfamiliar terms just a few months ago. Now they sit on leadership agendas, because the cost of AI coding has become a variable line item. In the State of Software 2026 report we cite research finding that AI cost management is now the top skill teams say they need to develop.

Easier said than done.

How does AI charge costs?

While consumer subscriptions often include token usage in their flat monthly fee, developer and enterprise subscriptions typically bill for token consumption separately, on top of the base subscription.

So, in many enterprise organizations AI-assisted coding now shows up as its own line on the budget sheet. AI tokenomics is the economics of that line: what AI-assisted coding consumes, what it costs, and what it returns.

Most organizations have no number for the last part. While the metrics for AI token cost in software engineering are still taking shape, leaders are already expected to budget for a line item the industry has not yet learned to measure. It’s almost unfair.
A good place to start is with the unit AI models charge for: tokens.

In June 2026 I recorded a SIGNAL episode on this with Luc Brandts, CEO of Software Improvement Group (SIG). You can watch the full conversation below, but if you would rather read than watch, here are my main takeaways from our conversation.

What are tokens, and how do they work?

Tokens are the units AI models process when running, a stage called inference.
Providers charge separately for input tokens (what you send), output tokens (what the model generates), and cached tokens (context the model reuses), measured per million tokens and varying widely by provider and model.

How much does AI coding cost per developer?

The honest answer is that it depends, but the published estimates give you a center of gravity. For everyday (non-agentic) assistant use, Anthropic puts Claude Code at around $13 per developer per active day and $150 to $250 per developer per month across enterprise deployments, with 90% of users staying below $30 on any active day. In the State of Software 2026 report we took that estimate and calculated that non-agentic token spend for a team of 50 developers costs the equivalent of nearly one additional full-time developer per year (about 120K per year).

That figure is billed on API tokens. Prices are quoted per million tokens, differ enormously by model, and the meter runs on volume you do not directly choose. At the end of the day, it is the model that decides how much thinking, re-reading, and rewriting your prompt requires.

It also covers old-fashioned chatting with an AI and pasting the answers into your IDE. It does not describe agentic work at all.

“It’s also not helped by the pricing models not being particularly clear. So you need to really understand how it’s going, and it can very quickly go wrong. Everybody knows the examples of Uber spending their entire budget in four months.” – Luc Brandts, Signal podcast episode: The real cost of AI coding explained.

For many, the bill that showed up painted a different picture. For example, in April, Uber’s CTO Praveen Neppalli Naga said the company had spent its entire 2026 Claude Code budget four months into the year. Average monthly cost per engineer landed in that same 150 to 250 dollar band, while power users ran between 500 and 2,000 dollars, and Naga reported spending $1,200 in a single two-hour session himself. By June, Uber had put a $1,500 monthly cap on each employee, per coding tool.

Uber is not the only example. In May, Microsoft reportedly began canceling most of the direct Claude Code licenses in its Experiences and Devices division, with a cutover to GitHub Copilot CLI by June 30, 2026. And Nvidia’s vice president of applied deep learning told Axios that for his team, the cost of compute now runs far beyond the cost of the employees.

Why do AI coding agents cost so much more than a coding assistant?

An AI chat assistant takes a task and returns an answer. An agent reads the task, generates a response, takes an action, then re-reads everything before its next step. It often pulls in other agents that re-read the same context again. It also picks up the work around the task, writing and running tests, then iterating on whatever those tests surface. A single task can run that loop many times, and most of the spend sits in input and cache tokens rather than in the output you eventually get.

“If agents collaborate and they need to talk to each other, what they do is they give all context. A lot of text, a lot of information around the problem that they’re currently addressing, is just pumped through them continuously. So the token count is much, much higher, essentially for the increased collaboration between agents.” –Werner Heijstek, Signal podcast episode: The real cost of AI coding explained.

According to Gartner, agentic models require between five and 30 times more tokens per task than a standard GenAI chatbot. A recent research paper put the gap far wider for coding specifically, finding that agentic coding tasks consume roughly 1,000 times more tokens than code reasoning or code chat.

Token use is also close to unpredictable. The same paper found that identical tasks, run again, can differ by up to 30 times in total tokens.

Gartner reports the commercial consequence in blunter terms, describing bills with “cost increases of up to 100x over coding assistants.”

So, especially with agentic adoption, the meter runs faster. The next question is what it buys.

Can AI coding agents build software on their own?

Up to a point, yes. Give agents the right context and rules, and add deterministic checks, and they produce code that holds up.

Earlier this year, we wanted to see what happens when nobody does that.

Cursor’s FastRender experiment is the clearest illustration available. A swarm of coding agents produced a working browser engine, more than 3 million lines of Rust, in a single week. That is roughly 110 person-years of development effort. That is huge.

We ran the output through our Sigrid® Core platform to check two things:

  • Maintainability: how easy will it be to change this system over time?
  • Architecture: how well can you understand the structure and the connections inside the system?

It scored 1.1 out of 5 for maintainability and 2.2 out of 5 for architecture, after we recalibrated our first pass at those numbers.

For comparison, the industry average sits around 3 stars, and 4 is what we advise our customers to aim for when a new system starts its life. Anything below 2 behaves like legacy software: you can change it, but it tends to be slow, risky, and expensive.

FastRender’s codebase is large and ambitious for its time-to-build, but the maintainability and architecture profiles are weak. Tightly interwoven components, uneven abstractions, and limited test isolation make change risky.

Lots of hidden connections, features woven through several places, and very little room to move without bumping into something else. In practice, a team picking up FastRender would spend a lot of time just working out where it is safe to touch.

Now, I hear what you are thinking. You can always regenerate a better version, right?

You can.

Generating code is not free, though.

The FastRender experiment is estimated to have consumed 10 to 20 trillion tokens, which at then-current list prices for frontier models would have cost several million dollars.

From that angle, does it sound wise to spend three to five years of developer salary, compressed into one week of token spend, for a system that looks like legacy?

“That means that your time to market is a lot faster, but your time to bankruptcy also.” – Luc Brandts, Signal podcast episode: The real cost of AI coding explained.

Nor will the next run necessarily be better. AI has real limits worth naming. It hallucinates, has a limited context window, relies on probability rather than understanding, and is overconfident. 

Why does AI speed up delivery but slow down the codebase?

The throughput case is real, and it is now measured properly for the first time. Microsoft ran a field study across tens of thousands of its own engineers, published as a preprint in July 2026, using developer-level telemetry rather than survey answers. Engineers who adopted agentic command line tools merged roughly 24% more pull requests than they otherwise would have, and the lift held across the full four-month window instead of fading. It scaled with use, from roughly 15% in weeks with three days of tool use to more than 50% in weeks with five or more.

At scale that is a serious gain, and when working in familiar parts of a high-quality codebase on well-understood problems, AI assistance works well.

The issue is what happens underneath the faster output.

Researchers at Carnegie Mellon compared 806 GitHub projects that adopted Cursor against 1,380 matched control projects that did not. Adopting projects added three to five times more lines of code in their first month, and the gain dissipated after two.

Static analysis warnings rose 30% and code complexity 41%, and both persisted. Their follow-up estimation found that the extra warnings and complexity were themselves major drivers of the later slowdown, and the paper names quality assurance as the bottleneck for early adopters.
The two studies measure different things: pull requests per engineer inside one enterprise, against velocity and quality per project across open source. Read together, they suggest individual throughput can hold up while the codebase underneath it degrades. The Microsoft authors are careful about this. They treat merged pull requests as a proxy for output, say plainly that whether the output justifies its cost is a question of value rather than throughput alone, and call quality the pressing open question, with the field still lacking agreed measures to answer it.

What we see is that the technical debt which builds up is often architectural rather than code-level, and the reason is context. Writing a function is a bounded task. Deciding how a new component should connect to the rest of a system is not. That decision depends on boundaries, dependencies, downstream effects, team ownership, and existing design intent.

Agents cannot hold a large codebase in view at once, so past a certain size, extra tokens buy more code that ignores the architecture. That is the kind of debt that surfaces in technical debt management two years later rather than in this quarter’s bill.

In any case, the shape of the spending has changed, and I do not think most budgeting has caught up.

How do you spend fewer tokens without losing quality?

The reflex when a bill grows is to cap it. Capping token spend on a team that has become dependent on agents mostly relocates the cost into missed deadlines. The more useful move is to raise the yield per token.

Five things do that in practice, and all five are properties of the environment the agent works in. Mitchell Hashimoto’s formula for that environment is Agent = Model + Harness, and I wrote a longer piece on what harness engineering is and how to build one.

A visual representation of the harness engineering hores/rider metaphor from the pov of the rider.

The economic argument belongs alongside the reliability argument: a well-designed harness is also the cheaper one, because most wasted tokens would never have been spent if a clear rule, a check, or the right context had been in place up front. 

1. Match the model to the task 

Reaching for the largest available model to answer a simple question is the most common and most invisible source of waste. During the episode I described it as meeting the biggest and smartest software system in the world and asking it what the capital of France is. You can do that. There is a cheaper route to Paris. The same research paper makes the point empirically: higher token use does not translate into higher accuracy, which tends to peak at intermediate cost and then flatten or decline. 

2. Stop paying for the same context twice 

Most of an agent’s bill is input, not output, and most of that input is context the model has already seen: conversation history, file dumps, failed attempts from thirty turns ago. Providers price cached context at a fraction of fresh input, so identical work costs very different amounts depending on whether the context is reused or resent. Most of that saving is available without changing anything about how your team works, which is why it is usually the first thing worth looking at. 

3. Keep deterministic questions out of the model 

Some answers do not require reasoning. Whether a specific library version carries a known vulnerability is a lookup, not a judgment call. An agent will happily spend thousands of tokens reasoning its way to an answer that a query returns instantly and identically every time. Use the model where its strength is generation and interpretation and use deterministic checks where a repeatable answer already exists. 

4. Do not let AI grade its own homework 

Add more models to a review loop and they converge on agreement, because they are agreeable by design. Something in the loop must be able to say no on the same grounds twice. 

5. Move the quality check inside the loop 

Rework is the largest hidden token cost in agentic development, and rework happens when a problem is found after generation instead of during it. We tested this directly: adding a real-time maintainability and security check to an agent’s loop reduced high-risk security findings by roughly 97% and improved the maintainability score by 24%, while pointing toward more efficient token use rather than more expensive.  

How do you measure what AI coding spend produces? 

Tokens generated, lines of code per day, and pull requests merged per sprint tell you who is busiest and close to nothing about whether the work landed well. 

An employee-built leaderboard at Meta shows what happens when the wrong thing gets measured. It ranked more than 85,000 employees on token consumption and handed out titles like “Token Legend.” Over a 30-day period, usage on that dashboard passed 60 trillion tokens, and the top-ranked individual averaged 281 billion, which on the cheapest frontier model works out at more than $1.4 million for one person. It came down two days after the numbers leaked. 

The metric worth building is cost per unit of working software: the token spend behind a change, divided by the share of that output that survives review and holds up as maintainable code. It is harder to calculate than tokens per developer, and it is the only one that answers the question a board asks. 

Measuring the second half is where standardized quality models earn their keep. FastRender’s 1.1 and 2.2 came from running the output through Sigrid Core against ISO/IEC 25010, benchmarked on more than 600 billion lines of code across 40,000 systems. 

Luc closed our conversation with some clear advice: 

“You need to use it, but you need to use it intelligently” –  Luc Brandts, Signal podcast episode: The real cost of AI coding explained.

I couldn’t have said it better myself. 

Keep your AI coding token spend under control

Control built into the agent's loop: powered by the largest software quality benchmark, highest standards and your full architectural context.

About the author

Picture of Werner Heijstek

Werner Heijstek

Werner Heijstek is the Chief Delivery Officer at Software Improvement Group and host of the SIGNAL podcast, a monthly show where we turn complex IT topics into business clarity.

Read our methodology

This field is for validation purposes and should be left unchanged.
Name*
Privacy*

Watch Core in action

This field is for validation purposes and should be left unchanged.
Name*
Privacy*

Watch Axis in action

This field is for validation purposes and should be left unchanged.
Name*
Privacy*

This field is for validation purposes and should be left unchanged.
Name*
Privacy*

This field is for validation purposes and should be left unchanged.
Name*
What type of partnership are you interested in?*
Privacy*

Register for access to Summer Sessions

This field is for validation purposes and should be left unchanged.
Name*
Privacy*