Inside Uber's Agentic SDLC: The Six Building Blocks Behind 70% Agent-Written PRs

Step-by-Step Breakdown

1. Block 1 — Put every model call behind one gateway

   All internal and external use cases, including the coding harnesses, go through a single OpenAI- and Anthropic-compatible endpoint. Requests pass a middleware chain: identity and authentication using Spire, a data anonymiser that redacts 20+ PII types, then an "AI guard" built from five specialised models handling safety and policy. The whole chain is held under 100 milliseconds. Every request is attributed to a project ID, so spend can be tracked per caller, per user and per team in real time and in the data lake. From an engineer's side the whole setup is: take the vanilla client, set the project ID, and the platform handles the rest. Uber reports 800+ internal projects and 100M+ model requests per day through it, across both frontier and open-source models.

2. Block 2 — Put every tool behind an MCP gateway, then optimise the token cost four times over

   Uber had thousands of internal APIs, none agent-accessible, plus a pile of SaaS tools each with its own auth. An automated crawler now projects internal APIs into MCPs with one config change, and SaaS MCPs (Google, Slack, Jira) are hosted behind the same gateway with token exchange handled centrally — one entry point, one install path. The interesting part is the four generations of token optimisation: (1) direct MCP, the naive pattern; (2) Omni MCP — a single MCP you install that can discover and invoke any MCP in the gateway, so the tool list stops eating context; (3) projecting MCPs into a CLI pattern, so the tool response doesn't land in context either; (4) an auto-installed "code mode" skill that writes Python scripts on the fly to hyper-optimise the top MCP token consumers. 1,000+ MCP tools now sit behind it.

3. Block 3 — Give agents somewhere to run that starts in seconds

   Uber "agentified" its existing remote dev environments. Agents get pre-provisioned Kubernetes balloon pods — claimed from a warm pool rather than built on demand, with repositories already snapshotted and the search index already built, so an agent starts working in seconds rather than minutes. Because agent and engineer roles now blur across repos, they replaced the old per-language dev pod (one for Go, one for Java, one for Android) with a single "mega dev pod" holding all repositories, which is what the autonomous coding agents run in.

4. Block 4 — Treat skills as a managed marketplace, not a free-for-all

   They hit three problems as engineers started writing skills independently: duplication (the same skill rebuilt in different repos), discovery and configuration friction, and a lot of sub-par quality. The fix was a lifecycle: core skills plus domain-specific skills, all published to a managed marketplace, all passing lint checks and automated review to enforce a quality baseline. One command discovers and installs any plugin; some skills are auto-installed based on engineer persona, so agents pick up the right skill without anyone installing it. Traces, comments and continuous evals are collected and fed back to skill authors. Current scale: 2,500 skills, 20,000+ cumulative invocations.

5. Block 5 — Collapse 20–30 context systems into one graph

   Execution traces showed agents burning time and tokens just locating basic context in a large monorepo — where a service lives, its dependencies, its owner, the patterns to follow — data scattered across 20 to 30 systems, each needing its own skill or MCP. They built a single context graph: 150 unique node and edge types, 40 million entries, spanning mobile apps, backend, data lake, design docs, Jira and incident history. Skills and use cases (on-call RCAs, planning, data analysis, security scans) are being plugged into it. Their example — "how many mobility trips in India are cash" — requires resolving concepts to tables and cities before SQL can be written; with the graph versus without, they report large reductions in tokens, turns and latency.

6. Block 6 — Surface all of it through one assistant, on every surface

   "Cortana" is the internal assistant with the skills, MCPs and context graph all plugged in, reachable from Slack, CLI and web. Employees can personalise it — hook up custom skills and a custom prompt, then attach it to a team Slack channel so it behaves like a member of that team. 300 unique personas were created in the first month, with 20,000+ sessions per day.

7. Now run a feature through it: idea → research → design

   The worked example is a World Cup pickup-location feature. The idea is jammed on in Slack, Cortana is tagged in, and the context graph backs a business-opportunity assessment (what large-venue events happened before, which stadiums are relevant). That opens into a web interface for the product requirements, then initial Figma mockups — deliberately two variants with different button strings, because the plan is to A/B them. Cortana then reasons about which code changes are needed and what already exists in the app and backend to reuse. The claim is compressing weeks of alignment into a short session.

8. Hand off to the coding agent — and stop it before CI

   The build is handed to Minion, Uber's cloud coding agent, running on a dev pod so it has a full build environment and can work across repos (backend and frontend changes in the same run). Minion runs interactive or fully autonomous. The important design decision: it stops at a draft PR and does not push to CI. They found the naive flow was fine for toil but that end-to-end features need validating before CI, both for quality and to avoid dumping load on CI infrastructure.

9. Shift validation left into the inner loop

   Checks that traditionally live in the outer loop move into the agent's inner loop, where the agent can fix what it finds before a human or CI ever sees it. Static analysis runs there and failures get auto-fixed. Beyond that they add visual validation: a skill launches a simulator, grabs a screenshot, and compares it against the Figma specs. They also bring the service up in the backend staging environment and check the frontend/backend integration together.

10. Split code review across two loops with two model sizes

    Code review is deliberately run twice at different cost points. The outer loop uses a powerful reasoning model with a review skill for a deep pass. The inner loop uses a smaller, faster medium model so the agent gets review feedback continuously without paying frontier prices on every iteration. CI itself is self-healing — a large share of CI failures get fixed automatically rather than bounced back.

11. Show the human reviewer what already happened

    When an autonomous diff arrives from Minion, the PR carries a table listing every check that ran. The point is trust calibration: the reviewer can see the diff didn't come straight out of a single generation, but survived a chain of self-improvement steps.

12. Enroll the service into maintenance skills on a managed loop

    After shipping, a service is enrolled into maintenance skills — feature-flag cleanup being the example, retiring the losing A/B variant. Crucially the loop is managed from one surface rather than set up ad hoc. It's scheduled for Sunday, chosen for two reasons: CI capacity is free, and engineers aren't flooded with extra diffs on Monday morning. Whether each generated diff gets comments and lands or not becomes label data that improves the skill. On a monthly cadence they review incidents to decide which ones should become new maintenance skills.

Gotchas & Caveats

• Don't let agents push straight to CI. Uber explicitly changed this after finding that autonomous diffs were fine for toil but not for end-to-end features, and that unvalidated pushes put avoidable load on CI infrastructure.
• Unbounded maintenance loops are the failure mode to design against. Their stated reason for a single managed loop surface is that they don't want thousands of loops set up across the company with no bounds — a constraint worth copying at any scale.
• The naive MCP install pattern doesn't survive contact with scale. Once you have enough MCPs, the tool definitions alone become what they call a "massive token tax" — which is why they went through three further generations of the pattern.
• Skills rot without a quality gate. Duplication and sub-par quality showed up as soon as engineers started writing skills independently; lint checks plus automated review were the response, not an afterthought.
• The foundations predate the agents. They credit six years of prior investment in monorepos and Bazel as what made this possible — the agent layer sits on top of that, it didn't replace it.
• The new bottlenecks are infrastructure and decisions, not typing. They name CI capacity, the number of experiments that can feasibly run, and — pointedly — that the question shifts from "can we build it" to "should we build it".

Key Takeaways

• Both gateways exist for the same reason: one policy chokepoint. The model gateway enforces PII redaction and safety in under 100ms; the MCP gateway centralises auth and token exchange so engineers install tools one way.
• Per-project attribution on every model request is what makes spend guardrails possible at all — set the project ID and the platform handles cost tracking per user and per team.
• MCP token cost is an architecture problem with known escalation steps: direct → a discovery MCP (Omni MCP) → CLI projection → generated scripts for the worst offenders.
• Warm, pre-provisioned environments with repos snapshotted and search indexed are what let an agent start in seconds; cold-starting a workspace per agent run is the thing to avoid.
• Cheap-model review in the inner loop plus expensive-model review in the outer loop is a cost pattern any team can copy, not just one with a platform team.
• A checks-table on the PR is a low-effort way to make autonomous diffs reviewable — it tells the human what has already been verified.
• Scheduling recurring agent maintenance for Sunday is a genuinely practical detail: it uses idle CI and keeps Monday's review queue human-sized.