Agentic SDLC at Uber - Building Blocks for Uber’s Software Factory

With a few thousand engineers across twelve global tech sites, Uber is already dealing with the consequences of widespread agent use. Uday Kiran Medisetty reports that more than 70% of PRs now involve local or cloud agents, and lines of code per engineer doubled year over year. Uber also reports more than 250 automated migrations, cumulatively covering nine million lines of code. These measure adoption, output, and toil reduction; they do not by themselves establish software quality.

The infrastructure foundation predates the agents. Six years of investment in monorepos and Bazel gave Uber a common base on which to automate engineering work. Medisetty introduces six building blocks, before Adam Huda combines them into an end-to-end feature example. The components are at different stages of maturity and rollout: the walkthrough describes a developing software factory, not a uniformly deployed system.

The Model Gateway begins with three requirements: keep PII from leaving Uber’s perimeter for vendors by default, strictly bound the latency added by guardrails, and attribute every request to its user, project, and team. Internal applications, coding harnesses, and external use cases all go through one OpenAI/Anthropic-compatible endpoint. This makes the gateway the common place to enforce those requirements.

Requests pass through identity and authentication middleware using SPIRE, followed by a data anonymizer and an AI guard. SPIRE supplies workload identity; that should not be confused with the full identity and delegation history of an agent. Medisetty reports redaction of more than twenty PII types, five specialized safety and policy models, and execution of the described middleware in under 100 milliseconds. The talk does not specify a latency percentile.

Caching and token optimization sit at the same boundary. Each request maps to a project in Uber’s catalog, with caller, user, and team attribution available both in real time and in the data lake. That accounting supports portfolio-wide spend tiers and guardrails. Audit logs and session traces also feed benchmarking and self-improvement work, so the gateway is both an enforcement point and a source of evaluation data.

For an engineer, the intended interface is a vanilla client configured with a project ID; the platform handles the surrounding controls. Medisetty reports more than 800 internal projects and more than 100 million model requests per day through the gateway. It routes to frontier and open-source models, hosted either inside Uber or by vendors.

Model access did not automatically make Uber’s systems usable by agents. Thousands of internal APIs initially lacked agent-accessible interfaces, while SaaS tools each brought their own authentication and setup. Exposing enough MCP tools also imposed a token tax. The MCP Gateway consolidates access: an automated crawler projects internal APIs into MCPs with a configuration change, while the gateway hosts SaaS MCPs for services such as Google, Slack, and Jira and handles token exchange. Engineers get one entry point and a common installation path.

Uber then changed how agents consume that tool surface, in successive steps:

Discovery reduces the need to expose everything up front. CLI and code-mode approaches also address the response side: intermediate data can be processed outside the model’s context, with only the useful result returned.

A small Python filter illustrates that last operation. Given a JSON array of tool-result records on standard input, it retains only identifiers and names before returning the result to the agent:

import json
import sys

records = json.load(sys.stdin)
selected = [
    {"id": record["id"], "name": record["name"]}
    for record in records
]
json.dump(selected, sys.stdout, ensure_ascii=False)
sys.stdout.write("\n")

The important boundary is where the reduction happens: Python sees the full payload; the model receives the selected fields. Uber’s code-mode skill generates scripts for its highest-token tool use cases.

Medisetty reports more than 1,000 MCP tools and over 40% fleetwide savings from the optimization efforts. He does not specify the savings denominator, baseline, or measurement window, so this is not a general token- or cost-reduction benchmark.

Once agents have models and tools, they need somewhere to work. Uber already used DevPods, remote development environments built for monorepos containing millions of lines of code. Adapting them for agents adds requirements for long runtimes, isolation, rapid startup, many concurrent environments, and availability across global sites.

Uber keeps pre-provisioned Kubernetes balloon pods ready for allocation. Repository snapshots and search indexes are already present, so an agent does not have to prepare its workspace from scratch. Medisetty says agents can begin working within seconds.

The workspace boundary also changes. Earlier DevPods came in language flavors such as Go, Java, and Android. Agents and engineers increasingly need to cross those boundaries, so a mega DevPod brings all repositories into one environment for autonomous coding. Simplified startup also lets non-engineer employees begin using agent harnesses without assembling a development environment themselves.

As engineers began writing skills across repositories, three problems appeared: duplicated work, difficult discovery and configuration, and uneven quality. Uber responded with a managed skills marketplace containing both core and domain-specific skills. Lint checks and automated reviews establish a baseline before those skills reach agents.

A single command supports plugin discovery and installation. Persona-based defaults go further by installing relevant skills automatically, allowing an agent to select them without requiring each engineer to configure them first. The next layer is feedback: traces, comments, and continuous evaluations return evidence to skill authors so they can improve behavior. Medisetty describes this as an active investment and reports 2,500 skills with more than 20,000 skill executions per day across the fleet.

Execution traces exposed another source of wasted work: agents spent substantial time finding basic context. Before changing a service, they needed its location, dependencies, owner, and implementation conventions. That information was scattered across twenty to thirty systems, each requiring its own skills or MCPs. Repeated discovery consumed tokens, added latency, and made outcomes less predictable.

Uber consolidates those relationships in a context graph. Medisetty reports 150 unique node and edge types and forty million entries. The graph connects mobile applications, backend systems, the data lake, design documents, Jira, and incidents. Skills for on-call root-cause analysis, planning, data analysis, and security scans are being connected to this shared source of context.

Consider the example question: how many mobility trips in India are cash trips? Answering it requires more than generating plausible SQL. The agent must resolve the business concepts, identify the relevant tables, and determine which common table expressions to construct. In early internal comparisons with and without the graph, Medisetty reports improvements in token use, turns, and latency, but supplies no numerical effect sizes. The graph’s role is to make those dependencies easier to resolve before the agent builds the query.

Cortana, Uber’s internal AI assistant, packages skills, MCPs, and graph context into Slack, CLI, and web interfaces. An employee can ask a question, and the assistant can retrieve context, invoke a skill, and inspect code across codebases. The surface changes; the underlying capabilities remain available.

Employees can personalize Cortana with custom prompts and skills, then connect the resulting persona to a team’s Slack channel. Multiple people can collaborate in that channel, including on the earlier India cash-trip question. Medisetty reports 300 unique personas created in the preceding month and more than 20,000 sessions per day.

Huda’s feature walkthrough starts with a rider leaving a busy World Cup stadium. Could the app suggest a better pickup location away from the crowd? The team discusses the idea in Slack and tags Cortana. With access to the context graph, the assistant helps investigate the business opportunity, then carries the work into its web interface. Research considers previous large venue events and candidate stadiums.

The example then moves through requirements and design:

1. Propose a North America rollout for the stadium feature.
2. Create initial Figma mockups with two variants whose button strings differ.
3. Plan an A/B experiment to compare those variants.
4. Identify existing app screens and backend capabilities that can be reused, along with the code changes needed.

This is a proposed feature workflow, not evidence of a completed rollout or an experiment result. Huda contrasts the potentially weeks-long alignment process with reaching a prototype quickly, without giving a measured new duration.

Cortana hands the design to Minion, Uber’s cloud coding agent. Minion supports both interactive and autonomous operation. Its DevPod provides a full build environment and access across repositories, allowing the stadium feature’s frontend and backend changes to be developed together.

The demonstrated workflow stops at a draft PR, without immediately sending it to CI. The boundary is deliberate. Generating changes works well for many toil tasks, but an end-to-end feature needs behavioral validation before it consumes shared CI resources. Earlier validation is part of capacity management, as well as a way to catch mistakes closer to generation.

Uber separates the agent’s inner loop from the outer loop where CI normally runs, then moves more checks inward. The validation sequence extends beyond static analysis:

1. Detect and repair static-analysis issues.
2. Use a skill to launch the app in a simulator and capture a screenshot.
3. Compare the screenshot with the Figma specification.
4. Start the backend service in staging and validate frontend/backend integration.

For the stadium feature, this lets the workflow examine both the visible interface and the connection to its service before advancing to CI. Staging validation remains distinct from production deployment.

Inner-loop validation does not eliminate CI failures. Once a change enters the outer loop, Uber’s self-healing CI can repair many issues encountered there. Code review is also split across the two loops: a smaller, faster model reviews earlier, while a more powerful model uses reasoning and a review skill for deeper outer-loop review.

For an autonomous Minion diff, the human reviewer needs to see what happened after the first generation. The PR carries a table of the checks performed, including screenshots. That evidence makes the agent’s validation and improvement work inspectable; it does not guarantee correctness or remove the need for human judgment.

More generated code increases the importance of maintenance. Features and services can enroll in maintenance skills. Returning to the stadium example, once variant B is no longer needed, a feature-flag cleanup skill can remove the obsolete variant and its associated branching logic. The example assumes that cleanup decision has been made; it does not establish which variant won an experiment.

These jobs run through a managed loop, rather than thousands of independent, unbounded schedules. A shared configuration surface can place work on Sunday, when CI has more available capacity, and limit how many resulting diffs engineers face on Monday. Scheduling execution and controlling review volume are separate requirements: spare compute does not imply unlimited reviewer attention.

The maintenance loop also produces learning signals. Review comments and whether a generated diff lands become labeled data for improving the skill that proposed it. At roughly a monthly cadence, Uber looks through incident reviews for lessons that can become new maintenance skills and be applied across services. Maintenance therefore feeds both individual code changes and the next version of the automation.

The workflow extends beyond the stages shown—Huda also mentions monitoring—but increased implementation throughput creates new constraints. More code places more strain on infrastructure, making CI capacity and foundational investment increasingly consequential.

Experiment capacity is finite too: the organization cannot feasibly test every feature it can generate. Decision-making becomes another bottleneck. Once building a feature is relatively easy, implementation feasibility no longer settles the product question. The factory still needs people to decide whether that feature should be built.