What should an AI coding tool budget actually include?

Four lines rather than one: seat licences, variable usage costs, the review capacity needed to handle the extra output, and the engineering time to build verification that can actually fail. Most budgets contain only the first, which is the smallest of the four and the only one with a published price.

Why is review capacity the real constraint rather than tool cost?

Because AI made writing code cheap, and review costs as much as it always did. A team that produces twice the code has doubled what someone must read, understand, and take responsibility for, and that work is paid in salaried engineering hours that no pricing page shows.

How do you estimate variable usage costs before you have data?

Run a limited pilot for a few weeks with usage reporting on, then budget the spread rather than the average. Consumption varies widely between engineers depending on codebase size and whether they run agents, so an average hides the individuals who cost several times the median.

Should the business case promise cost reduction?

No, and promising it is how these programmes lose credibility in the second quarter. The honest case is that spend moves from writing code to verifying it, and the total may stay the same in year one while throughput and traceability improve.

What is the most common budgeting mistake with AI coding tools?

Treating the seat licence as the whole cost and assuming output translates directly into delivered value. The 2025 DORA report found AI adoption correlating with higher throughput and with worse delivery stability, which means the unbudgeted cost usually appears later as incidents and rework.

How many seats should you buy in the first year?

Fewer than the headcount, allocated to the people who will actually use them daily, then expanded on evidence. Buying a seat for everyone on day one produces a large invoice and a low activation rate, and it removes the natural pilot that a smaller rollout gives you.

How do you know whether the tools are worth what they cost?

Measure delivery outcomes rather than tool activity: how long a change takes to reach production, how often it fails there, and how quickly you recover. Counting accepted suggestions or lines generated tells you the tool is being used and nothing about whether the business got anything.

What is the verification layer and why does it belong in the budget?

It is the set of automated checks that encode what the software must guarantee and that fail when those guarantees break. It belongs in the budget because it is the thing that lets a reviewer accept generated work without reading every line, and without it the review queue becomes the slowest step, which cancels out the speed.

Does an AI coding budget change how you hire?

An AI coding budget moves hiring toward people who can describe and check the work as well as produce it. The scarce skill becomes deciding what correct means and building the checks that prove it, which is senior work, so the budget often needs more senior time.

How should a small team approach this differently from an enterprise?

A small team can skip the procurement overhead and run a real pilot in two weeks, which is a genuine advantage. What it cannot skip is the verification layer, because a small team has less review capacity to handle a mistake and fewer people who would notice a silent failure.

What happens if you fund the tools but not the review capacity?

The extra work waits in the queue, which stays invisible until it is weeks long, at which point the fastest-moving work is also the least reviewed. This is the specific failure that turns a productivity programme into a backlog of code nobody has read and nobody will own.

How to budget for AI coding tools without guessing: Reveneau

Every few weeks someone asks us to check a budget line for AI coding tools. The number is usually seat count multiplied by list price, plus a round figure for "usage". It is a clean spreadsheet and it is almost always wrong, not because the arithmetic fails but because the largest cost in the programme has no row.

Here is what the seat price hides. AI made writing code cheap, and review costs as much as it always did.

A team that doubles the code it produces has also doubled the code someone has to read, understand, and be accountable for when it misbehaves at two in the morning. That second quantity is paid for in salaried engineering hours, it does not appear on any vendor's pricing page, and it is the line that decides whether the whole programme is worth doing.

So budget four things, in this order.

If the tool in question is Claude Code, the guide to Claude Code costs for a team gives Anthropic's own per-developer figures, where to see spend on each setup, and a printable budget worksheet.

1. Seats, which is the easy part

Take the list price and assume you pay it. Volume discounts exist and they are worth asking for, but do not build the case on a discount you have not been offered yet.

The more useful discipline is buying fewer seats than you have engineers. Give them to the people who will use the tools daily, then expand on evidence. Buying a seat for everyone in month one produces a large invoice and a low activation rate, and it throws away the pilot you would otherwise have got for free.

You will hear the objection that partial rollout is unfair. It is a reasonable objection and it is worth answering directly: this is a trial, the criteria for expanding are written down, and the second group gets seats a quarter later. That explanation is usually accepted.

2. Usage variance, not the usage average

Most of these tools bill something beyond the seat: tokens, requests, agent runs, compute minutes. The mistake is to model that as a flat per-head number.

Consumption between two engineers on the same team routinely differs by several times. Someone running an agent repeatedly against a large repository consumes far more than someone using inline completion in a small service. The average across the team hides exactly the people who make the bill high.

Run a limited pilot with usage reporting switched on, then budget the spread rather than the mean. Set a per-seat alert while you are at it. The first surprise invoice in a programme like this is usually one engineer, one loop, and one weekend.

3. Review capacity, which is the line nobody writes

This is the one that matters, and it is the one that gets left out because it does not arrive as an invoice.

If output goes up and the number of people who can competently review that output stays the same, the difference goes into the queue. Queues are invisible for a while. Then they are three weeks long, and the work being merged fastest is the work nobody has read carefully.

The 2025 DORA report, drawn from nearly 5,000 technology professionals, is direct about this pattern. AI adoption now shows a positive relationship with software delivery throughput and a continuing negative relationship with delivery stability, and the report's blunt summary is that "AI doesn't fix a team; it amplifies what's already there". More code arriving faster into a team whose review process was already the constraint makes that slowest step slower.

There is a second cost in the same place. Stack Overflow's 2025 survey of developers found the single biggest frustration with AI tools was output that is "almost right, but not quite", reported by 66 percent, with 45.2 percent saying that debugging AI-generated code takes more time than writing it themselves. Almost-right is the expensive category. Obviously wrong code is discarded in seconds. Nearly correct code gets read three times, argued about, merged, and then explains an incident a month later.

So put a real number here. If you expect meaningfully more change volume, either some people move into review, or you accept a longer queue, or you build the thing in step four. Pretending the capacity appears by itself is how the programme quietly fails.

4. The verification layer, which is what makes the rest worth the cost

The only lasting way to fix the slow review step is to stop having humans check the things a machine can check.

That means automated checks written from the specification, covering what the software must guarantee: authentication and permissions, anything that moves money, anything that writes or deletes customer data. Then a reviewer's job narrows to judgment, which is the part a person is actually good at, instead of scanning four hundred lines for a mistake that a test could have caught in eight seconds.

This is engineering time, it is spent before the benefit arrives, and it is the line most likely to get cut in a first-year budget. Cutting it is a false saving, because it is the only line that makes the other three worth funding. Our fuller treatment is in how to write your first eval suite, and the money argument specifically is in the business case for evals.

One caution worth budgeting around: checks that cannot fail are worse than no checks, because they show every check passing and give false confidence. Break something deliberately and confirm the suite notices. The catalogue of ways this goes wrong is in when evals give false confidence.

What the security picture does to the number

If your product touches regulated data, payments, or anything where one failure would harm many people or systems, there is a further cost you should price rather than discover.

Veracode's Spring 2026 research across more than 150 models found generated code compiling and running correctly over 95 percent of the time while passing security checks in roughly 55 percent of generations. The breakdown matters more than the overall number: SQL injection passed at 82 percent while cross-site scripting passed at 15 percent and log injection at 13 percent. The failures cluster in classes that are hard to notice in review and do not break any test you were likely to have written.

Budget the security tooling and the security review time explicitly. This is the cost of accepting code at a rate no human reading process was designed for.

How to tell whether any of it worked

Measure delivery, not tool activity.

Accepted suggestions and lines generated tell you the tool is being used. They tell you nothing about whether the business received anything. The four delivery measures in the DORA research are the ones worth tracking: how long a change takes to reach production, how often you deploy, how often a change fails there, and how quickly you recover. If throughput rises while change failure rate rises to match, you have paid for activity with no gain in results. Related reading on this trap is in how to measure engineering productivity.

Give it two quarters before judging. The first quarter is mostly learning where the tools are bad, which is genuinely useful and looks like nothing on a chart.

The version of the business case that a CFO will accept

Do not promise the programme reduces cost. That claim gets tested at the next budget review and it usually fails.

Promise this instead: spend moves from writing code to specifying and verifying it, throughput improves, traceability improves, and the total may stay the same in year one. That is a defensible statement, it matches what the research actually shows, and it does not require anyone to pretend that review capacity is free.

Thanks to the engineering leaders who showed us the budgets that went wrong and let us look at why. In every case the seat line was accurate to the dollar, and the line that ruined the plan was the one that had never been written down at all.

The cheapest part of AI-assisted development is producing the code. Everything after that is the budget.

Related guide: Moving a team to AI-native development.

Sources

2025 DORA report announcement, Google Cloud: nearly 5,000 respondents; AI adoption relates positively to throughput and negatively to delivery stability, and amplifies a team's existing strengths and dysfunctions.
Stack Overflow 2025 Developer Survey, AI section: 66 percent cite "almost right, but not quite" as the biggest frustration; 45.2 percent say debugging AI-generated code is more time-consuming.
Veracode, Spring 2026 GenAI Code Security update: across more than 150 models, over 95 percent syntactic correctness against roughly 55 percent security pass rate, with cross-site scripting at 15 percent and log injection at 13 percent.
DORA research programme: the four software delivery measures.

How to budget for AI coding tools without guessing