Uber torches 2026 AI budget on Claude Code in four months

Speaking as someone who's bootstrapping here, I'm often envious of engineers at these larger companies, but I also worry that the incentives are screwed up.

If I were an engineer at Uber, why wouldn't I select gpt 5.5 pro @ very high thinking + fast mode for a prompt? There's no incentive not to use the most powerful (and thus most expensive) model for even the smallest of changes.

I tried one of these prompts for some tests I'm doing for image->html conversion, and a single prompt cost me $40. For someone that's paying that themselves, I'd pretty much never use this configuration. For someone at a large company where someone else is footing the bill, I'd spin these up regularly (the output was significantly better, fwiw). For engineers they're being rated on what they deliver, not the expenditure to get there.

There are ways to do this cheaply, but there are no incentives for engineers to do so.

> First: There's the obvious "If the company is letting me do it, I'll be wasteful." This includes not clearing/compacting the context often. Opus now has a 1M context window, and quality is good to at least 200K. So each query is burning a lot of tokens until you clear/compact.

What is wasteful? If you are costing the organization $x/hr, and spend an hour saving the company $(x*0.5), you didn't save money, you wasted it.

To the company, are you spending more time being token efficient to save less money than they're paying you for the time? That's not even getting into opportunity costs.

There is some extreme wasteful spending of AI tokens out there. But trying to get below $3k/month in token costs is often of questionable value.

Advanced agentic prompting.

> When developer productivity tools become so valuable that engineers blow the entire budget in four months, the issue isn't the tool but that the budget was invented too early to forecast this adoption curve.

Where oh where can I find clients like these??

Oh it does... but what happens after 6 months is an entirely different story.

A codebase that has exploded in size 2-3 times in just a few months,... internal architecture that is not layers of simple parts anymore, but, layers of complex architectures corresponding to individual agentic runs,... a codebase that now has 10 times more if-else and individual codepaths because you were not clear enough in your requirements, and used the phrase "handle all cases",... a codebase that neither you, nor anyone else now understands properly, thus, can't comment on what's possible anymore, and and at what costs when your manager or PM asks,...and finally, due to combined effect of these, a need for an ever increasing token budget, and constantly increasing fragilty of new AI-generated code due to repeated context compactions.

And we haven't even touched on the security and performance elements yet.

The right way to use these tools is to use them as, what I like to call, "code-monkeys". You tell them exactly what you want, where you want, how to do it, and how to architecture it, and more.. and then make them code.