Overview of Uber’s AI infra, from the inside
This episode explores how Uber’s massive pre-AI developer platform laid the groundwork for its current AI-native engineering workflow. Uday Mendicetti, a long-tenured Uber engineer now focused on agentic AI, walks through the internal systems that help Uber’s thousands of engineers build, test, review, debug, and maintain software with AI assistants and coding agents. The central theme is that the “agent harness” is the easy part — the hard part is the surrounding infrastructure: permissions, routing, observability, testing, evaluations, and workflow integration.
Key Themes and Takeaways
- Uber’s AI stack is built on years of investment in internal platforms, not just recent LLM adoption.
- Most AI systems are designed to be model-agnostic and harness-agnostic so Uber can switch vendors and tools without re-architecting everything.
- The company is extending AI across the full software lifecycle:
- planning
- implementation
- validation
- code review
- debugging
- maintenance
- Uber treats agentic AI as a way to reduce toil and improve feature velocity, while still keeping strong safety and review guardrails.
Uber’s Internal Foundations Before AI
Early engineering platforms
The conversation revisits Uber’s earlier infrastructure, which was built to support rapid scale:
- RTAPI / Edge Gateway: Uber’s internal API layer for mobile traffic and service abstraction.
- UOwn: asset ownership and on-call ownership lookup.
- M3DB: Uber’s metrics backend, built to handle extreme metrics volume.
- Michelangelo: Uber’s machine learning platform for the full ML lifecycle.
- Cadence: durable workflow orchestration for long-running jobs and business processes.
- Morpheus: experimentation / feature flagging / configuration tooling with deep integration into Uber’s platform.
- DevPods: cloud developer environments for standardized builds and faster local development.
Why these mattered
These systems made Uber unusually ready for AI because they already solved hard problems like:
- identity and ownership
- access control
- deployment and routing
- observability and tracing
- experiment management
- distributed testing
- cloud development environments
- cross-service orchestration
Uber’s AI Foundations
Model Gateway
Uber built a central gateway for LLM usage so teams can:
- access multiple model providers through a single interface
- use OpenAI-compatible or Anthropic-compatible APIs
- keep security, policy, logging, and routing centralized
- switch models/vendors without rewriting downstream apps
This gateway sits on top of Uber’s existing Michelangelo platform, which now includes GenAI/agentic components.
AI Guard
A middleware layer that checks every request and response for:
- safety
- policy compliance
- sensitive data leakage
- other compliance-related constraints
It acts as a consistent enforcement layer across all AI use cases.
AIFX
Uber’s wrapper around coding harnesses and agent tools:
- standardizes settings across environments
- works across local machines and DevPods
- supports personas, plugins, and skills
- lets engineers switch between harnesses without reconfiguring everything
MCP Gateway
Uber’s gateway for exposing internal tools to agents via MCP:
- auto-generates MCP specs from service APIs
- supports both internal and vendor tools
- works across APIs already defined in thrift or protobuf
- can also expose tools as CLI commands
This is a major enabler for allowing agents to do more than code generation — including operational and workflow tasks.
Skills repository
Uber has a centralized skills system for agents:
- shared skills in a monorepo
- team-specific skills when needed
- quality gates and evaluations
- portable across harnesses
- increasingly executed through CLI-style tooling for token efficiency
The transcript emphasizes that skills are easy to prototype, but hard to make robust at scale.
AI in the Software Development Lifecycle
Planning and documentation
Uber uses AI across docs and planning artifacts such as:
- PRDs
- engineering design docs
- launch reviews
- production-readiness reviews
- approval workflows
The goal is to create a more structured source of truth that both humans and agents can use to understand project history, ownership, and status.
Minion: Uber’s coding agent
Minion is Uber’s background coding agent, now responsible for a meaningful share of PRs.
What it does
- takes a spec or task and executes it with minimal steering
- works from Slack, web, or other surfaces
- can create PRs across multiple repos
- uses Uber’s DevPod/mega-dev environment
- can self-validate work in web, mobile, and backend contexts
Current usage
- about 15% of production PRs go through Minion
- it started with maintenance tasks, but Uber is expanding the scope over time
- it can operate from Slack threads and turn conversations directly into code changes
DevPods
Uber’s cloud developer environments were an early win that now benefit AI agents too.
Why they matter
- standardized build environments
- cached dependencies and build systems
- faster setup and test cycles
- a “mega DevPod” for multi-repo work
- preinstalled AI tools like Claude Code and Codex
This makes it easy for both engineers and agents to start working immediately.
Testing, Validation, and Safe Execution
Slate
A service for creating branch-isolated environments for end-to-end testing.
What it enables
- deploy a branch into its own environment
- route a test account to that branch
- test across mobile, web, backend, and multi-service flows
- let agents validate their own changes
Slate is especially important at Uber’s scale because it allows realistic end-to-end testing across many services without risking production.
Capri
Uber’s capture-and-replay system for real production traffic.
What it does
- captures request/response pairs
- records downstream calls too
- replays traffic against candidate fixes
- helps reproduce bugs and validate bug fixes
- supports dimensional testing across many product combinations
This is especially useful for complex services and locale-specific behavior.
Match guard
A testing layer that uses captured traffic to verify PRs against the full combinatorial space a product/platform supports.
Benefit
This helps catch regressions that would be nearly impossible to reproduce manually, especially in a company with many products, countries, and service combinations.
Code Review and CI in the AI Era
CodeInbox
A centralized place to manage PRs and review signals.
It surfaces:
- PRs waiting for review
- CI results
- AI review output
- screenshots and videos from validation
- blast radius and risk scores
Self-healing CI
Uber moved many checks earlier into the developer inner loop and added automation like:
- auto-fix
- auto-request review
- auto-merge for safe cases
- validation commands for linting, coverage, build, and more
Main idea
Human review is still required, but AI and automation reduce the amount of manual work and help reviewers focus on high-risk changes.
Debugging and Bug Reproduction
Wisdom
An internal bug-reporting and reproduction system used by employees dogfooding Uber apps.
Capabilities
- route bug reports automatically to the right team
- collect rich telemetry, logs, and analytics
- reconstruct reproduction steps
- compare observed vs expected behavior
- feed issues into debugging and coding agents
Debug Assist
A managed agent that:
- analyzes logs and code
- suggests root cause
- produces RCA-style output
- hands off to Minion for a fix
This creates a closed loop from bug report to root cause to PR.
Large-Scale Maintenance and Continuous Improvement
Shepherd
Used for large-scale library and codebase migrations.
- can apply deterministic transformations
- can also use AI-driven fixes
- creates campaign-style PR rollouts across many modules
Fox
A more continuous code-maintenance system.
What it does
- enroll a service into ongoing improvement skills
- regularly generate PRs for:
- dead code cleanup
- noisy logs
- performance improvements
- other maintenance tasks
This turns code maintenance into an ongoing managed loop instead of a one-off effort.
Context Graph: Uber’s Knowledge Graph for Agents
One of the most interesting systems discussed is Uber’s Context Graph.
What it connects
- people
- services
- design docs
- PRs
- incidents
- configs
- queries
- data tables
- on-call events
- Jira/Linear tasks
- ownership relationships
Why it matters
It gives agents and humans a shared mental model of the organization and its software. Instead of jumping between siloed tools, agents can use the graph to ground answers and navigate dependencies faster.
Benefits
- fewer agent steps/turns
- better answer quality
- lower latency
- lower cost
- better cross-org discoverability
Productivity: How Uber Thinks About It Now
The episode argues that AI is changing not just how engineers code, but how engineering productivity is measured.
Old metrics
- diffs per engineer
- code reviews
- raw throughput
Newer emphasis
- feature velocity
- end-to-end cycle time
- percentage of work that is feature work vs maintenance
- quality and risk of output
- PR categorization by complexity and type
Uber is trying to measure not just “how much code” gets shipped, but how much customer value gets shipped.
How the Engineer Role Is Changing
According to Uday, software engineers at Uber are increasingly becoming:
- context builders for agents
- spec writers and constraint setters
- workflow designers
- reviewers and verifiers of agent output
- operators of multiple parallel agent sessions
He frames this as a shift from “writing code” to “designing systems that help agents reliably write and verify code.”
Notable Insights
- “The harness is the easy part. What’s hard is all the things around them.”
- Uber’s AI advantage comes from years of developer-platform investment.
- Production software at Uber is too complex to rely on a coding model alone; testing, routing, observability, and permissions are essential.
- The best AI outcomes come from combining strong infra with strong guardrails.
- Companies with mature developer platforms before AI seem positioned to get the most value from agents.
Bottom Line
Uber’s AI story is not “we added LLMs to coding.” It is “we turned a decade of engineering infrastructure into an AI-native development platform.” The result is a tightly integrated system where agents can plan, code, test, debug, review, and maintain software inside a highly governed environment.
The episode is a strong case study in how modern AI adoption depends on old-school platform engineering.