The AI Budget Reckoning
Why the way we budget for AI is broken, and how to fix it.
Uber burned through its entire 2026 AI coding budget in four months. Microsoft began canceling direct Claude Code licenses and redirecting engineers toward cheaper alternatives. Nvidia’s Bryan Catanzaro put the arithmetic plainly: for his team, the cost of compute now exceeds the cost of the employees.
This is a story about engineering leaders applying the wrong financial model to a new category of tool, and the bill arriving faster than anyone expected.
The hype cycle is over, the budget cycle has begun.
The Wrong Mental Model
For most of the last decade, software tooling worked on a simple financial model: a fixed cost per seat, renewed annually, with predictable budget impact. A GitHub license costs X. A Datadog license costs Y. You multiply by headcount, add a growth buffer, and move on.
AI coding tools broke this model quietly, then loudly.
The problem isn’t the per-seat price, most AI coding tools are priced competitively against traditional developer tooling. The problem is that “per seat” is the wrong unit entirely. AI tools don’t consume a flat resource. They consume compute, and compute scales with usage. When an engineer runs a single autocomplete suggestion, the cost is negligible. When an engineer runs an autonomous coding agent across a large codebase for several hours, the cost is an order of magnitude higher. When twenty engineers do that simultaneously, the numbers stop being theoretical.
The teams that exploded their budgets weren’t being reckless. They were using a mental model built for the previous generation of tooling and applying it to something that behaves fundamentally differently. A seat license is a fixed cost. Token consumption is a variable cost that scales non-linearly with the ambition of what you’re building.
This distinction matters more than it sounds. Variable costs require different controls, different forecasting, and different conversations with finance than fixed costs do. Most engineering organizations hadn’t had those conversations before the invoices arrived.
What ROI Actually Includes
The case for AI coding tools was built on a simple productivity story: engineers write code faster, therefore engineers deliver more, therefore the business moves faster. This story is true as far as it goes, which is not very far.
Individual throughput is easy to measure. Pull requests per engineer, cycle time per ticket, time-to-first-commit: these numbers moved in the right direction for most teams that adopted AI tooling seriously. The dashboard looked good. Then someone looked at the full picture.
A 59% increase in average engineering throughput was recorded last year according to CircleCI’s 2026 State of Software Delivery report, the largest analysis of CI/CD performance ever published, drawn from more than 28 million workflows. What the same data also shows is that most organizations are not capturing the majority of those gains, because the systems built to validate and deliver software haven’t kept pace with what AI makes possible.
The costs that rarely appear in the ROI calculation:
Review overhead. More code generated means more code reviewed. Review is not free, it consumes senior engineer time, which is the most expensive and most constrained resource in most engineering organizations. A 59% increase in throughput that generates a 40% increase in review burden is not a 59% productivity gain. The math is more complicated.
Rework cost. AI-generated codebases tend to accumulate redundancy, inconsistent patterns, and technical debt faster than human-written code. The teams discovering this in 2026 are hiring senior engineers specifically to remediate AI-generated output, an expense that was never in the original ROI model.
Context engineering time. Getting consistent, high-quality output from AI agents requires investment in documentation, prompt design, and codebase structure that isn’t free. The teams with the best results from AI tooling are the ones that invested heavily in this work before expecting returns. That investment is rarely counted against the productivity gains.
Compute cost per feature. Gartner expects per-token prices to fall sharply by 2030, while total bills keep climbing, because agents consume far more tokens per task and usage grows faster than unit prices drop. Cheaper tokens do not save you if the volume grows faster than the price falls. The unit economics look favorable until you account for consumption patterns.
True ROI is net value delivered divided by total cost, including the costs that don’t appear on the AI vendor invoice.
A Framework for Engineering Leaders
Before renewing or expanding any AI tooling contract, there are three questions every engineering leader should be able to answer with data, not intuition.
1. What are we spending per feature delivered?
This requires connecting your AI tooling costs — licenses, compute, API usage — to your delivery metrics. Not throughput metrics, delivery metrics: features shipped, incidents caused by AI-generated code, rollback rate on AI-assisted PRs. If you can’t answer this question, you don’t have enough visibility to make a sound renewal decision. The vendor’s productivity dashboard is not a substitute for your own measurement.
2. Is the time saved in implementation being absorbed in review?
This is the question most engineering leaders are not asking systematically, even when they suspect the answer. Map where senior engineer time is actually going. If a meaningful portion of your most experienced people’s weeks is now spent reviewing AI output rather than making architectural decisions or developing junior talent, you have a structural problem that tooling alone will not solve, and that the productivity gains from AI tooling are partially subsidizing.
3. Does our licensing model reflect how the team actually uses the tool?
Most AI tooling contracts were signed when usage patterns were unknown. A year later, you have data. Are your power users on the same plan as engineers who use autocomplete occasionally? If so, you are almost certainly either overpaying for light users or underpaying for heavy ones, and your budget forecasting is built on averages that don’t reflect reality. Segment usage, then negotiate accordingly.
How to Structure AI Tooling Budgets for 2027
The teams that will manage AI tooling costs well next year are the ones making three structural changes now.
Separate licenses from compute. Treat them as different budget lines with different forecasting models. License costs are relatively predictable. Compute costs are not, they need usage-based forecasting, not headcount-based forecasting. Finance teams that have never budgeted for variable developer tooling costs need this distinction explained clearly and early.
Define accountability metrics before expanding access. Expansion decisions should be tied to evidence: delivery outcomes, not usage volume. High usage is not evidence of value. Shipping more, faster, with acceptable quality is. If you can’t connect expanded AI tooling access to delivery outcomes, you don’t yet have the measurement infrastructure to justify the expansion.
Have the honest conversation with stakeholders. The original productivity projections for AI tooling were built on throughput numbers and license costs. They did not include review overhead, rework cost, or compute scaling. Most stakeholders are still working from the original model. Engineering leaders who proactively update that conversation with data, maintain credibility. The ones who don’t will find themselves explaining a budget overrun with no prior warning, which is a much harder conversation.
The Real Argument
None of this is an argument against AI tooling. The productivity gains are real. The acceleration is real. The competitive pressure to adopt is real.
The argument is for financial clarity. AI tooling is not a fixed-cost line item with a predictable return. It is a variable-cost investment with a return that depends heavily on how it is deployed, measured, and managed. The organizations treating it like the former are the ones burning through annual budgets in four months.
The engineering leaders who will get this right in 2027 are not the ones with the most aggressive adoption plans, but the ones who built the measurement infrastructure to know what they are actually getting, and the financial models to pay for it without surprises.
Faster delivery is worth paying for. Paying for it without knowing what you’re getting is just a hope.
If you’re navigating the AI tooling budget conversation with your CFO or VP of Finance right now, I’d be curious what’s working and what isn’t. Find me on LinkedIn.