Why Uber's AI Spend Isn't Moving the Needle
Uber's AI spending problem isn't about AI, it's about building faster, and building more, when there's nothing left to build
Last week, Uber’s COO Andrew Macdonald said something unusually honest. In an interview on the Rapid Response podcast, he admitted the company can’t draw a clear line between its AI spending and useful consumer features. “That link is not there yet,” he said. 95% of Uber’s engineers use AI coding tools every month. 70% of committed code is now AI-generated. The company burned through its entire 2026 Claude Code budget in 4 months. By every adoption metric, the rollout was a resounding success. By every product metric, it didn’t matter.
The crowd was quick to read this as “AI coding doesn’t deliver.” I think that’s the wrong takeaway entirely. AI did its job exactly as expected: more code, faster. It's just that the given job didn't need doing.
The real issue is something most people in the industry aren’t ready to say out loud: Uber’s product was already completed years ago.
The app is just the window
There’s a class of tech companies that most of us interact with daily, such as marketplaces, where the software is essentially a bridge. It connects users to something real on the other side of the screen. A ride, a room, a person, or a payment. Users look through the app to evaluate that real-world thing. They rarely evaluate the app itself once it works well enough. After that, it disappears, and becomes just glass between you and what you actually came for.
When you open Uber, you don’t think “what a nice interface.” You look at two factors: the ETA and the price. When you open Airbnb, you don’t admire the search UI, you scroll through listing photos, check the price, read a few reviews, and glance at the map. The aspects that determine whether you book: location, price, cleanliness, how nice the place looks, the host’s rating are all qualities of the listing, not qualities of the software. Every single one is a property of the supply side, and a redesigned discovery page doesn’t make the apartments nicer, or cheaper.
This distinction matters enormously for the AI spending conversation. If the things your users care about don’t live in your codebase, burning a ton of tokens to create more code, no matter how efficiently, doesn’t move the metrics that count. You’re optimizing the wrong layer.
Why More Code Won't Help
A company hits the AI-velocity ceiling, for product development, when three things are true at the same time.
Value lives outside the code. The factors users evaluate: price, speed, location, reliability, the quality of the listing, are supply-side, network-side, or physical-world qualities. They’re not app features. They’re not UI elements. They’re not what engineers ship.
The plumbing is mature. The hard problems that once required heavy engineering such as handling millions of concurrent rides, real-time matching, optimized pooling algorithms, payment processing at scale, syncing across devices, were all solved years ago. The infrastructure works. Incremental improvements yield diminishing returns.
Feature additions create friction, not value. Users of these products don’t want more. They want the app to get out of the way and connect them to what matters on the other side as fast as possible. Every new screen, modal, or toggle is an obstacle between them and what they actually came for.
When all three are true, agentic coding tools won’t move the needle, no matter how fast they ship.
A Pattern Hiding in Plain Sight
Uber, AirBnb and Booking.com are the obvious cases. But there are many others that will hit the same reality.
WhatsApp might be the purest illustration. What do users evaluate? Did my message get there, and did it get there fast. The app’s real breakthrough was a structural decision: use the phone number as identity, skip the username and password entirely, and pull the social graph straight from the mobile phonebook. The network built itself. From there, the app famously served 900 million users with less than 50 engineers because the product surface is vanishingly small. Features like Status, Communities, and Channels have found varying degrees of adoption, but none of them are why people open WhatsApp.
Venmo, Zelle, and Cash App are the same pattern applied to money. Did the payment go through? How fast? Was there a fee? These are transaction outcome questions, not feature questions. Venmo’s social feed is the only feature anyone engages with, and even that’s polarizing.
Dropbox tells the same story in slow motion. The product is: are my files there when I need them? Sync reliability was solved years ago. Everything since: Dropbox Paper, Dropbox Dash, AI search has been an attempt to expand a product surface that users don’t want expanded. They just want the folder to sync.
When the delivery layer is mature, users want simplicity, not sophistication.
The uncomfortable part is most of these companies are in denial, or at least in a comfortable fog, about the fact that their core product is essentially done. Internally, the roadmap is full. There are always more features to spec, more redesigns to pitch, more “strategic initiatives” to greenlight. The machinery of product development keeps running because that’s what it’s built to do. Admitting that your product is finished feels like admitting your engineering org doesn’t have a purpose. So nobody says it. Instead, they pour AI-accelerated velocity into a product that didn’t need more velocity, and then wonder why the output metrics don’t move.
When the Product Is Done, the Opportunity Moves
This doesn’t mean those companies should stop investing in AI agentic engineering. It means they should redirect it.
For Uber, the ultimate prize is autonomous vehicles, the one lever that would genuinely move the supply-side metrics riders care about. No driver wage means, in theory, lower prices. An always-on fleet means lower ETAs.
And then there’s the less glamorous but potentially higher return play: turning AI inward by automating internal workflows in finance, logistics, operations, compliance, and marketing. The kind of enterprise machinery that every company at Uber’s scale runs on and that is full of inefficiencies. None of this is as visible as a consumer feature launch, but it’s where AI agentic coding velocity might actually translate into measurable returns.
Final Thoughts
Before measuring AI coding ROI, before tracking tokens consumed or lines of code generated, ask one question: do the things my users care about live in my codebase?
If yes, and your product is a tool, a workspace, a creative surface, a platform people build on, then invest in coding velocity. Every feature you ship faster is value delivered sooner.
If no, and your product is really the ride, the room, the message, the payment, the file, then coding speed won’t save you. Your users are evaluating something your engineers can’t touch. The plumbing is built. The water already runs clean.
Uber isn’t discovering that AI doesn’t work. They’re discovering that their product was already done, and a lot of companies are about to have the same realization, not because AI failed them, but because it forced them to confront a question they’d been avoiding: was there anything left to build?