AI coding tools have become one of the fastest-growing and least understood line items in engineering budgets. That's not a knock on the leaders buying them. It's the honest state of the market. Adoption came first. Measurement hasn't caught up. That can't last.
I understand why the gap exists. Companies overhired during the boom years preceding the pandemic, then doubled down when digital usage went through the roof during the pandemic itself. They've spent the years since working that headcount back down. The economy went wobbly, inflation set in, and right alongside both came a new promise of automation: AI. This automation story was something the industry hadn't seen before, and public markets rewarded companies that laid off workers while talking up AI. Venture capital followed the same signal: AI startups captured roughly 80 percent of all global venture funding in the first quarter of 2026, up from 55 percent a year earlier, and Crunchbase described the quarter as an all-time high not approached by any other quarter on record.
Inside that environment, part of the pressure to adopt is a real bet: that these tools let a smaller team do more, which is a genuine economic case even before anyone has measured whether it's paying off. But another part of the pressure has nothing to do with that bet. It's about not looking like the person who missed the biggest shift in how software gets built in a generation, and AI tools are the visible proof that leadership is taking it seriously. Under that pressure, keeping the subscription running is the easy call. Canceling it looks like falling behind. Justifying the spend with numbers isn't required yet, because almost nobody is asking.
Budgets get reviewed the way they always have. Someone leaves. A quarter comes in soft. A CFO does a sweep. And the person holding that line item gets a question they haven't had to answer before: What did we get for this? Not "is AI valuable in general?" Specifically: this spend, this team, this quarter.
Right now, almost nobody can answer that question with anything more than a feeling. I talked to one engineering leader recently who was honest about it. He wasn't sure whether his team's AI spend was solving a real problem or merely generating activity that might feel like progress.
That uncertainty is starting to show up on the buying side too. Engineering leaders at several large companies have told us they are reluctant to keep expanding AI products whose costs rise unpredictably with usage. They aren't rejecting the potential of AI. They're questioning whether the cost can be tied to a measurable return, and right now it can't.
That scrutiny starts with the numbers companies already have: token spend per engineer, cost per pull request, some version of a coding-agent expense report.
Coding agents have introduced a new variable cost into engineering. Previously, you paid an engineer and tried to assess the value of the work. Now you pay the engineer and also pay for the model usage behind that work. Every parallel session, abandoned approach, generated test and attempted refactor has a price attached to it.
But that accounting answers only one side of the ROI question. Token use tells you what the work cost, not what the output was worth. An engineer spending thousands of dollars a month could be running 10 Claude Code sessions in parallel and producing five times as much as before. Another engineer could generate the same bill without producing much durable work at all. Low usage is just as ambiguous. It could indicate someone using the tools precisely and efficiently, or someone barely using them.
Put engineering output on one axis and agent spend on the other, we get the following table:
It gets more complicated when you look at impact per developer, not just per team or company. Two recent studies show that the same tool made some developers faster and others measurably slower, depending on who was using it and what they already knew.
In a randomized controlled trial, researchers at METR followed 16 experienced open-source developers completing 246 tasks in mature repositories they had worked in for an average of five years. With Cursor and Claude available, the developers took 19 percent longer, even though they believed afterward that AI had made them 20 percent faster.
A separate working paper analyzing open-source projects after the introduction of GitHub Copilot found that the productivity gains accrued primarily to less-experienced, peripheral contributors. Experienced core developers saw the opposite: they reviewed 6.5 percent more code while their own original output fell 19 percent, a pattern the researchers behind the study attribute to a rising rework and maintenance burden landing on the people most qualified to catch it. The productivity gain didn't disappear. It just shifted the extra review and maintenance work onto the people who could least afford the time.
Counting the volume of code generated doesn't work any better. Lines of code were already a bad proxy for engineering productivity; coding agents simply make it possible to produce much more of the thing we already knew not to count.
Even a perfect accounting of cost would solve only half the problem. AI-assisted coding is widening an old gap between engineering activity and the outcomes it is supposed to produce. Code can now be generated faster than many teams can review it, test it, observe it in production and determine whether it did anything worthwhile. The bottleneck has moved downstream.
DORA's research describes AI as an amplifier of the engineering system already in place. A team with strong review practices, testing, observability and product feedback can turn that acceleration into useful software. A weak system turns the same acceleration into more rework, more fragile code and more risk. Either way, the tool is not producing the return by itself. The system around it is.
That downstream burden has a cost too, one that rarely shows up next to the token bill. Incident response, rollback time and the hours spent tracing a production issue back to a change nobody reviewed carefully: none of that appears on the line item labeled "AI spend." The ROI conversation VPEs are struggling to have is missing not just a clear picture of the value. It's missing a full accounting of the cost.
When leaders cannot establish the return, cost is the part of the equation they can act on. That's not cynical. It's how budget discipline works, and it means an unpredictable line item is vulnerable when the financial picture becomes uncertain.
Two examples make the point from different angles.
Uber spent its entire annual Claude Code budget in about four months. Its president and COO, Andrew Macdonald, later said the company still couldn't draw a clean line from that spend to anything customers noticed. The underlying metrics might be moving in an impressive direction, he said, but the connection to customer value wasn't there yet. Uber didn't stop believing in the tools. Everyone just went on an allowance.
Microsoft gave thousands of employees access to Claude Code. Usage grew, and so did the bill. Microsoft decided to cut most of those licenses in its Experiences and Devices division and move employees to its own GitHub Copilot CLI instead. The company said it wanted one common internal tool built around its own repositories and workflows. Reporters found a second reason: the cutoff lined up with the end of Microsoft's fiscal year. Claude Code worked fine. Microsoft canceled it anyway.
No one has a clean framework for measuring all of this yet. But the minimum standard is becoming clear: usage is not output, output is not outcome, and an open-ended cost with no credible line connecting the three will eventually get cut.
Winter is coming for the AI engineering budget the same way it comes for any hype cycle once the price finally has to match the value. The only real question is who spent the summer building something that survives it.