Uber burned its whole year of AI budget by April

The pitch for AI features used to be about capability. Can the model do the thing? These days the answer is almost always yes. So the interesting questions moved. Not "can we build it" but "should we, what does it cost, and what happens when it breaks." Let me catch you up on the operational reality your team is walking into.

The deep cut

• Feasibility is not a reason to build. Almost any workflow can be made agentic, which is exactly why the "should we" question keeps getting skipped.
• A credit balance is infrastructure, not a subscription. Elena's Lovable app went dark on a Saturday because a number in a dashboard hit zero.
• Judge models by cost per finished task, not per token. Uber burned its whole annual AI budget by April after rolling Claude Code out to 5,000 engineers.

The bottleneck just moved, and you can't see where

Individual productivity gains are real and large. Craig Unsworth, who gets dropped into private-equity businesses to fix them, saw work that took weeks now take days. But he flags the trap: the engineer got faster, and the org around the engineer did not. Discovery, pricing, QA, security, stakeholder alignment all still take the same time.

So the bottleneck moves. Speeding up one part of a broken system just exposes where it was already broken. His sharper point for you: the goal is not to make the same team ship twice as much code. It is to redesign the workflow around what your people can now do. That is a roadmap decision, not a tooling one.

Not every workflow needs an agent

The most useful pushback in this cluster comes from an enterprise architect who says the quiet part out loud: not every workflow needs an agent. A rules engine, a fine-tuned model, or a plain API call is often cheaper, faster, and easier to audit. His first question before building anything: could an if-else tree handle this? If yes, write the if-else tree.

When you skip that question, you pay what he calls the agentic tax. An agent that makes twelve tool calls to answer what a rule resolves in one is paying twelve times the inference cost, plus latency, plus a new class of failures your ops team has to learn.

An agent earns its place only when the input is ambiguous, the path forks on evidence, or the edge cases can't be written as rules. Before that point, autonomy is waste with extra steps.

Cost per finished task, not per token

Here is the number that should reset how your team evaluates models. In browser-automation benchmarks, GPT-5.5 ran at $1.42 per task with a 66% pass rate, while Claude Fable 5 cost $10.22 but passed 92%. The "cheap" model looks cheap until a 34% failure rate sends expensive engineers to debug broken paths by hand.

That is why the metric to bring to your next review is cost per successful task, not cost per token. Multi-step agent loops consume 5 to 30 times more tokens than a single query, and error-recovery loops alone eat roughly 60% of agentic spend. Uber learned this the hard way, exhausting its annual AI budget by April after rolling Claude Code out to 84% of its 5,000 engineers. Raw leaderboard pricing told them nothing about that bill.

The number that can turn your product off

The failure mode nobody plans for is the platform switching your product off. Elena, an AI product lead, logged in to a dead Lovable build on a Saturday and found no bug, just an empty credit balance. Lovable had merged its build and run credits into one pool, so the same number that used to be an inconvenience now took her live app offline with no warning.

She checked four other platforms. Netlify pauses your projects until the next cycle. Vercel won't unpause on its own; you resume each project by hand. Replit suspends published apps after payment failures. The gap between "down" and "back up" is however long it takes a human to notice.

Her rule is the one to steal: if your product's uptime depends on a number in a dashboard, that number is infrastructure. Monitor it like a server, with alerts, not like a subscription you glance at monthly.

Context is the new prompt

The upside case worth building toward: your power users are already curating context, not perfecting prompts. In an NN/g study, every Claude power user had built a context library of files, databases, and live feeds. One dictated a lazy prompt like "read the MD file and implement it," and it worked, because the file carried the context.

The frame is three roles: global (rules and brand that rarely change), local (the current task and its data), and ambient (raw email, transcripts, analytics the agent sifts through). Knowing which role a piece of information plays tells you where it should live.

That library is also what keeps AI output on-spec. Applitools now lets teams use a Figma frame as the visual baseline and flag drift automatically, which makes the design file more important, not less. "It generated successfully" and "it matches the design" are two different claims, and something has to check the second one.

Three questions for your team

• When Engineering gets twice as fast, where does our next bottleneck move, and are we redesigning the workflow or just expecting more code?
• For each AI feature on the roadmap, could a rules engine or an API call do this, and if so why are we building an agent?
• Which of our live tools would go dark on a weekend before a customer told us, and who gets the alert when a balance hits zero?