Uber's Agentic Shift: What Happens When 6,000 Engineers Restructure Around AI Agents

Uber's Pragmatic Summit presentation is one of the most honest public accounts of what enterprise AI agent adoption actually looks like: 95% of engineers using AI monthly, 1,800 autonomous code changes per week, and a sixfold increase in AI-related costs. Here's what engineering leaders can take from it — and what Shipwright provides for teams that can't build Uber-scale infrastructure themselves.

Datum

March 24, 2026

Uber's Agentic Shift: What Happens When 6,000 Engineers Restructure Around AI Agents

There are moments when a company shows you something you've only ever read about in conference papers. Uber's appearance at the Pragmatic Summit was one of those moments. Ty Smith, Principal Engineer, and Anshu Chada, Director of Engineering, talked openly about how Uber has reorganised its entire software development practice around AI agents. No marketing slides, no vague promises — just concrete numbers, honest admissions, and a rare look inside what this actually means at scale.

I follow these case studies closely because they show what happens in practice. And what's happening at Uber is instructive for any engineering leader thinking about where this is all heading.

The Numbers That Caught My Attention

Uber's CTO Praveen Neppalli Naga put a number out publicly: 95% of Uber's engineers use AI tools every month. Not as an experiment — as a normal part of the job. And 84% of those are already working in agentic workflows, meaning they're no longer just typing prompts and getting code suggestions. They're coordinating agents that independently pick up tasks, execute them, and report back.

Here's what that looks like in production: Uber's internal background agent now writes 1,800 code changes per week — fully autonomously. Engineers review and approve them, but the writing itself has moved to the machine. AI-generated changes have gone from under 1% to roughly 8% of all code changes. Eleven percent of all pull requests are now opened by agents.

That's not a pilot. That's production reality at one of the world's largest tech companies.

What Actually Changed for Engineers

The CTO calls it "a real reset moment for engineering." Not a threat — a description. Engineers at Uber write less code. They review more. They think about architecture, agent output quality, system reliability. The tasks that used to eat hours — writing migration scripts, adding unit tests, hunting bugs in legacy code — are increasingly handled by agents.

Uber built four internal tools to make this work:

  • Autocover generates over 5,000 unit tests automatically per month
  • Shepherd manages large-scale migrations across the monorepo
  • Minion is a background agent with full codebase access, built for autonomous routine work
  • uReview filters AI-generated code review comments so engineers only see what's actually relevant

This isn't tooling for the sake of tooling. It's deliberate infrastructure for a new way of working.

The Architecture: Four Layers

What interests me most about this case study is the underlying architecture. Uber didn't introduce a single AI solution. They built four layers:

  1. An internal AI platform as the foundation
  2. Context sources that give agents access to internal knowledge, code, and data
  3. External industry tools, integrated selectively
  4. Specialised agents for specific tasks like testing and code review

Their MCP Gateway — built on the Model Context Protocol — centralises access to internal endpoints and data sources. The Uber Agent Builder is a no-code platform that lets teams create their own agents without worrying about infrastructure. AIFX CLI handles provisioning and discovery.

What's emerged is an internal marketplace for AI agents. By mid-2025, Uber had over 200 curated skills in their main catalogue and 300 more experimental tools in team repositories, with 20 new skills added every week. They run a two-tier model: a tightly governed core of 100-200 essential skills — think App Store — and an open edge where teams experiment freely.

The governance question — what runs autonomously, what needs human approval, what gets centrally managed — is one of the most important organisational decisions any company building agentic systems has to make.

The Cost Side Nobody Talks About Enough

Honest case studies show both sides. At the Pragmatic Summit, Uber's engineers didn't just present the wins. AI-related costs have increased sixfold since 2024. Token cost optimisation has become its own discipline. Engineers naturally tend to run multiple agents in parallel — which burns resources that weren't on anyone's radar before.

This isn't an argument against the direction. It's an argument for going in with your eyes open. The economics look different from classic SaaS tools, and if you're building agentic workflows at any scale, the infrastructure cost conversation needs to happen early.

How Adoption Actually Happened

What I find most interesting about Uber's story is the adoption pattern — or rather, the absence of a classic top-down rollout.

Uber didn't mandate AI tool usage. The strongest adoption came where engineers quietly experimented on their own, built experience, and shared it peer-to-peer. Not management decree — organic spread. Top-down mandates proved less effective than this kind of grassroots wave.

That's worth sitting with if you're planning an AI agent rollout. Building the technical infrastructure is one thing. Creating a culture where people actually want to work this way is another — and often the harder part.

What This Means If You're Not Uber

Gartner predicts that by end of 2026, around 40% of enterprise applications will include task-specific AI agents — up from less than 5% in 2025. That's a fast shift. And yet reality shows that most companies haven't moved beyond pilots: 57% of enterprises have AI agents in production, but fewer than 40% have genuinely scaled them.

What Uber demonstrates is one way scaling can look. But it's Uber's way — built for Uber's codebase, Uber's engineering culture, Uber's resources. A company with 50 engineers and no dedicated platform team can't replicate this directly.

The transferable parts are the principles: the four-layer architecture as a thinking model, the separation between a curated core and an experimental edge, the understanding that adoption grows through peer learning rather than mandates, and the honesty to name the uncomfortable numbers.

The challenge for smaller organisations is that Uber could build all of this infrastructure themselves. Most companies can't. They need a structured approach that gives them the same foundations without requiring a hundred-person platform engineering team to stand it up.

That's exactly what I built Shipwright for — a structured SDLC that gives engineering teams the governance model, the agent integration patterns, and the workflow foundations they need to move from ad-hoc AI experiments to production-grade agentic development. Without Uber-scale resources.

→ Explore Shipwright

 

Sources: