Uber’s AI infra, from the inside

Summary

The episode examines how Uber’s long-running investment in developer infrastructure prepared it to adopt AI agents. Its central argument is that models and coding tools are the easy part; reliable production use depends on the systems around them—standardized development environments, service APIs, testing, security, code review, and engineering knowledge.

Foundations built before generative AI

Uber developed many internal platforms to support rapid growth and the needs of a large, global, service-based business:

• M3DB supported high-volume metrics; Michelangelo provided a machine-learning platform; and Cadence handled long-running workflows. These systems were later open-sourced or influenced tools used elsewhere.
• Morpheus supported feature configuration and experimentation, including complex tests across cities and marketplace conditions.
• DevPods, introduced as repositories and build systems grew more complex, provide preconfigured cloud development environments with cached builds and tests. Uber later adapted this foundation for agents, including a “mega-DevPod” with access to multiple repositories.
• Edge Gateway provides a common entry point for APIs and supports multiple endpoint types. Uber also relies on distributed tracing and service-routing infrastructure to diagnose and test behavior across services.

The speakers emphasize that this infrastructure was not built specifically for AI. Its standardization and accumulated operational knowledge made it easier to give agents access to code, tools, and test environments later.

AI infrastructure and access to tools

• Model Gateway gives teams a common, OpenAI- or Anthropic-compatible interface to models from different providers. Built on Michelangelo, it centralizes model access, security policies, audit logs, usage attribution, cost tracking, and other operational controls.
• AI Guard applies checks to model requests and responses, including safeguards against sending confidential information. Centralizing model access lets Uber apply common policies across projects.
• AI FX wraps different coding-agent tools and synchronizes settings, personas, plugins, and skills across local machines and DevPods. It also provides usage and cost feedback. Engineers have spending tiers, with a route to request higher limits rather than being uniformly blocked.
• MCP Gateway, begun in 2025, is a shared gateway for internal and external tools. Because Uber already maintained an API/IDL registry for Thrift and Protobuf services, it could automatically generate MCP tools from service definitions, including descriptions optimized for model use. Teams can also publish custom MCPs. Uber later made these tools available through a CLI as well as MCP.
• A centralized skills repository distributes reusable, portable agent instructions and plugins. Uber evaluates and improves skills rather than treating them as simple folders of prompts; the speakers cite roughly 30,000 skill launches per day.

Shared engineering context and background agents

Uber’s context graph links information that had historically been scattered across systems. It contains more than 100 node types and 130 relationship types, connecting people, services, code changes, documents, incidents, ownership, and other engineering records. An assistant called Cortana can use the graph to orient itself before searching deeper, helping answer questions about code, data, service health, ownership, or incident history. The guest says this can reduce the number of agent steps and improve answer quality, latency, and cost.

Minion is Uber’s background coding agent. At the time described, about 15% of PRs went through it. Engineers can delegate a task through the web or Slack, provide a plan or specification, and have Minion work across repositories using the mega-DevPod. It is also used in support workflows to investigate reported bugs and, in some cases, propose a fix without waiting for the issue to move through a backlog.

Testing, code review, and maintenance

• Slate creates isolated test environments for branches and routes selected test accounts’ requests through the relevant services. It lets engineers—or agents—test changes across several services without changing the rest of the system. This depends on years of work standardizing services and using distributed tracing to direct test traffic.
• Capture/replay tooling records real service traffic, including downstream requests and responses, so teams can replay scenarios and compare behavior before and after a change. A related match guard checks broad combinations of captured inputs in CI, helping expose regressions that would be difficult to cover with manual tests.
• Code Inbox gathers PRs awaiting review and provides signals such as test results, screenshots, videos, risk, and likely impact. Uber is adding automation to CI and letting agents run more checks before a PR reaches a reviewer. Human review remains required for now; automated approval of low-risk changes is described as a possible future step once risk assessment is sufficiently reliable.
• Shepherd manages large code migrations by generating PRs across modules, using either deterministic rewrite rules or AI-assisted changes. Fox extends this idea to recurring maintenance: registered services can receive regular agent-generated PRs for tasks such as cleanup, performance improvements, and noisy-log reduction.
• Wisdom collects employee reports of problems in Uber’s apps along with logs, telemetry, and reproduction details. Debugger Assist analyzes this information with the codebase to identify a likely root cause; engineers can then pass the context to Minion to create a PR. The resulting feedback can also help improve the debugging and coding agents.

How the work of engineers is changing

The guest describes a shift from primarily writing code to creating the context and conditions that let agents produce and verify useful changes. Important skills include writing clear specifications, supplying the right context and constraints, working across multiple agent tasks, and quickly checking results for errors or “code smells.”

Uber is also reconsidering how it measures productivity. Rather than relying mainly on code volume or PR counts, it is tracking feature delivery and cycle time, categorizing PRs, and using AI to connect project documents to implementation work. One useful signal, according to the guest, is that the share of PRs for new features is rising while the share for maintenance is falling.

The interviewer’s closing analysis is that Uber’s AI adoption benefited from more than a decade of developer-platform investment. He notes that the company still has roughly 4,500–5,000 services, though they are larger and more consolidated than in the past, and highlights capture/replay and the integration of existing infrastructure with agents as particularly notable examples.

Guides, reviews, and demonstrations

• The episode is a walkthrough of Uber’s internal developer and AI-agent systems, not a step-by-step tutorial.
• It demonstrates or explains Minion, DevPods, MCP Gateway, the context graph, Code Inbox, Slate, capture/replay, Shepherd, Fox, and Wisdom/Debugger Assist.
• It includes analysis of AI-era code review, production safety, engineering productivity, and how existing platform investments support agent adoption.

Main speakers and sources

• Uday Kiran Medisetty, Uber Distinguished Engineer and guest, explains Uber’s systems and AI-agent workflows.
• Gergely Orosz, host of The Pragmatic Engineer, asks questions and provides closing commentary based on his earlier experience at Uber.
• Brief sponsor segments for WorkOS, turbopuffer, and Linear are included in the subtitles but are separate from the main technical discussion.