Uber Burned Through Its Entire 2026 AI Budget in Four Months — And Yours Probably Isn’t Built Right Either
In April, Uber’s CTO, Praveen Neppalli Naga, made a statement that should hit hard for anyone leading an engineering team: the company had burned through its entire annual AI tools budget before Q2 even kicked off. Four months. Done.
The culprit wasn’t waste. It wasn’t reckless experimentation. It was Claude Code and Cursor working exactly as they’re supposed to.
95% of Uber’s engineers use AI tools every month. 70% of committed code comes from AI. Monthly API costs per engineer ranged between $500 and $2,000. Total AI-related spending grew roughly 6× since 2024. The CTO’s own words: “back to zero” on AI budget.
I’ve been following how this story circulated — it hit Hacker News today with almost 90 comments in the first hour — and what stands out to me isn’t the headline number. What stands out is that almost every engineering leader I know is going to read this and think “that’s not going to happen to us.” They’re probably wrong.
Why the Budget Model Breaks
Traditional software tools scale predictably. You buy X licenses, you pay Y per license, you can project it. AI coding tools don’t work that way.
Claude Code consumption scales with three variables that traditional procurement models don’t account for: codebase complexity, task type, and adoption depth. Larger repositories require more context per operation. Multi-step agentic tasks burn tokens at a completely different rate than autocomplete. And the difference between a developer using it for quick queries and one running full autonomous sessions is enormous.
Uber rolled out Claude Code in December 2025. Usage doubled in February. By April, the curve had consumed the entire year. That’s not a tool failure — that’s what genuine adoption looks like. The mistake was assuming the old budgeting framework would hold.
The HN thread is illustrative. One developer reports $400–$500 per day during active development phases. Another points out that in large codebases with custom frameworks, token consumption explodes because the model has to orient itself in unfamiliar territory every session. A third does the math that seems obvious in hindsight: a $160k annual engineer spending $1k a month on tokens that strips away mechanical work is still a win — if you account for it correctly. The problem is almost nobody accounts for it upfront.
This Isn’t a Cautionary Tale About AI. It’s a Budget Architecture Problem.
Most coverage frames it as a warning. I read it differently.
Uber didn’t burn its budget because AI tools failed. It burned it because those tools delivered enough value that 95% of its engineering organization adopted them with high intensity in a few months. That’s an extraordinary outcome. The question isn’t whether to use these tools. The question is whether your financial model reflects how they actually behave at scale.
Some things that break traditional procurement logic:
Per-seat licensing intuition doesn’t apply. The variance in usage between engineers is huge — some will spend $200 a month, others $2,000, and both can be completely justified based on the work they do.
“AI budget” as a line item is a category error. If 70% of your committed code comes from AI, that’s not a tool expense. It’s a core production cost. You need to model it as infrastructure, not as a software subscription.
Adoption curves are nonlinear. If you build a budget for month one and don’t construct dynamic caps, you’re going to hit the same wall Uber did.
What I’d Do Differently
If I were building AI coding infrastructure for an engineering team of any meaningful size today, here’s what I’d construct before day one of broad rollout:
Cost observability first. Instrument spending tracking by engineer and by team before giving everyone access. Most API platforms expose it — use it.
Tiered access by use case. Exploratory prompting and critical production agentic sessions should be at different cost levels, with distinct monitoring thresholds.
Rolling budget windows, not annual. Annual AI budgets are fiction. Build quarterly reviews with real consumption data baked in.
Set a cost-per-commit target. If AI generates 70% of your code, know how much it costs to produce that code. This connects AI spending to engineering output in a way CFOs can participate in — and gives you ammunition when you need to expand budget.
The LatAm Variable
For teams operating in Latin America, this problem has an additional dimension. API costs are denominated in dollars. A 20-engineer team at the midpoint of the $500–$2,000 range burns through $15,000 to $30,000 USD monthly. That number looks very different depending on what currency your revenue is denominated in.
This doesn’t mean avoid the tools. It means build the cost governance architecture before broad rollout — not after you’ve hit the wall.
Uber had $3.4 billion in annual R&D spending and it still caught them off guard. For teams operating on tighter margins and with revenue denominated in other currencies, being caught off guard isn’t “back to zero.” It’s a budget crisis.
The Bottom Line
Claude Code broke Uber’s budget because it was genuinely useful at scale. That’s the story.
If you’re planning to roll out AI tools for your team in 2026 and you’re still working with a per-seat licensing mental model, build the cost observability layer first. Not because the tools don’t work — but because they do. Teams that get this right won’t be avoiding AI spending. They’ll be measuring it as infrastructure and budgeting accordingly.
That’s a different conversation than most organizations are still having.