Microsoft Told Its Engineers to Stop Using AI. Uber Burned Through Its Entire Annual AI Budget in Four Months. Here Is What Nobody Is Saying About This.

The companies that bet everything on AI replacing engineers just got a very expensive lesson in what engineers actually do.

Photo by Waddas Magalhães on Unsplash

Two stories landed within days of each other recently and together they say something the industry has been avoiding saying clearly.

Microsoft, the company that invested thirteen billion dollars into OpenAI and writes roughly thirty percent of its own code using generative AI, quietly told engineers in a major division to stop using an AI coding tool. Not because the tool did not work. Because the bills were too large.

Uber deployed Claude Code to around five thousand engineers in December 2025. By April 2026 its CTO was telling reporters that the company had burned through its entire annual AI coding budget in four months. Individual engineers were spending between five hundred and two thousand dollars per month on API costs alone. Ninety five percent of engineers were using AI tools monthly. Seventy percent of code commits were AI driven.

And yet the CTO admitted something that rarely makes it into the press releases. The link between those impressive usage numbers and actual consumer value is elusive. More code, more commits, more AI activity. But whether any of it translated into things users actually wanted remained genuinely unclear.

The story that started before these two

To understand what Microsoft and Uber ran into, it helps to look at what happened at Klarna first.

Klarna became the loudest voice in corporate America for AI replacing human workers. Between 2022 and 2024 the Swedish fintech eliminated approximately seven hundred positions and replaced them with an AI powered chatbot. The CEO publicly stated that AI could already do every human job. At its peak the system was handling two thirds to three quarters of all customer interactions.

Then customer satisfaction dropped twenty two percent. The responses were generic. Complex queries went unresolved. The cases that required actual judgment, the ones that were not covered by the patterns the AI had learned, piled up with nobody equipped to handle them.

By mid 2025 Klarna was rehiring human agents.

The headline version of this story is that AI failed. The more accurate version is that AI handled the work it was designed to handle and then discovered that the work it was designed to handle was not actually most of the work.

What the numbers at Uber reveal

The Uber situation is worth looking at carefully because the numbers are unusually honest.

Ninety five percent engineer adoption. Seventy percent of commits AI driven. Agentic AI feature usage jumping from thirty two percent to eighty four percent in a single month. By most visible metrics this looks like a successful rollout.

But the CTO’s own words undercut the celebration. He could not draw a line between those statistics and whether users were actually getting more of what they wanted. The activity was real. The value was unmeasured.

This is the gap that the productivity promises around AI coding tools have been quietly stepping over. Commits are countable. Whether those commits produced something worth having is harder to measure and nobody wanted to do the harder measurement while the easier one looked so impressive.

Engineers who have been doing this work for years recognized this gap immediately. The number of lines of code produced has never been a reliable proxy for the value of engineering work. Generating more of them faster does not automatically make the proxy more reliable.

What this means for the engineers who were told to stop

There is a specific irony in the Microsoft situation worth naming.

Microsoft engineers preferred Claude Code over the company’s own in-house AI tools. The tool worked well enough that engineers chose it consistently over what their employer had built. Then the employer told them to stop using it because the cost at enterprise scale was unsustainable.

So the engineers go back to the previous workflow. Which means the previous workflow is what actually gets used. Which means the things that the previous workflow required, judgment about what to build, understanding of the existing system, ability to debug what the AI generated and produced, context about why the system is the way it is, are the things that the engineering team is now leaning on again.

None of those things were made obsolete by four months of high AI adoption. They were just temporarily deprioritized while everyone was excited about the usage statistics.

The structural problem nobody wants to say out loud

The pattern across Microsoft, Uber, Klarna, and every similar story from the past two years is the same underneath the different surface details.

AI tools are genuinely useful for specific, well-defined tasks where the requirements are clear and the output can be verified quickly. They are expensive and unreliable for the work that requires understanding the full context of a system, making judgment calls in ambiguous situations, and ensuring that what gets built is what actually needed to be built.

The second category is not a small edge case. It is most of the real work.

Companies got very excited about the first category because it produces visible, countable output. They underinvested in measuring whether the second category was still being handled well. And then they discovered, through Klarna’s customer satisfaction numbers and Uber’s budget hole and Microsoft’s cost crisis, that the second category had not gone away just because nobody was measuring it.

The engineers who understand both categories, who can use AI tools effectively for the first while maintaining the judgment and context that the second requires, are more valuable now than they were before the AI wave began. Not because AI failed. Because the AI wave revealed exactly which parts of engineering work cannot be automated away and which parts can.

What backend engineers specifically need to understand right now

The implications for backend engineering are more specific than the general AI conversation acknowledges.

Backend systems have a property that makes the second category of work particularly important. They accumulate history. The decisions made two years ago shaped what is possible and what is dangerous today. A new AI tool can read the code but it cannot read the meeting where someone decided not to use a particular approach because of a failure that happened three years earlier and never got documented.

That institutional knowledge, the kind that comes from having been present for the system’s evolution, is what got leveraged when Klarna’s chatbot hit its limits and needed human agents who understood the edge cases. It is what Uber’s engineers are using now that the AI budget is gone and the work still needs to happen. It is what Microsoft’s engineers are drawing on now that the Claude Code experiment in that division is paused.

The engineers who spent the last two years building genuine depth of understanding in their systems, rather than replacing their own thinking with AI output, are the ones the teams are depending on right now. That is not an argument against AI tools. It is an argument for maintaining the understanding that makes AI tools valuable in the first place.

The honest version of where this is going

Neither AI replacing engineers nor AI being a failed experiment is the right frame for what is happening.

The right frame is that AI tools are genuinely useful at a cost that companies have not yet figured out how to manage predictably, for tasks that turn out to be a subset of what engineering actually requires, in a way that amplifies the work of engineers who have deep understanding and exposes the fragility of workflows that substituted AI output for that understanding.

The companies that will use AI most effectively going forward are not the ones that eliminated their engineering judgment in favor of AI generation. They are the ones that maintained their engineering judgment and used AI to make it faster.

Microsoft and Uber did not fail because their engineers used AI tools. They hit walls because the costs and the value were both harder to predict than the demos suggested. The lesson is not to stop using the tools. It is to be honest about what the tools can and cannot do and to stop pretending that the parts they cannot do are less important than the parts they can.

The engineers who understood this before the expensive experiments confirmed it are not surprised by any of these headlines. They were just waiting for the rest of the industry to catch up.

What is the part of your current engineering work that you believe no AI tool currently available could handle reliably, and how much time are you actually spending on it versus the parts that could be automated?