Uber 的智能体 SDLC：从编码智能体到可治理的软件工厂

Brief Description

Uber engineers Uday Kiran Medisetty and Adam Huda describe the infrastructure and workflows behind the company’s emerging agentic software factory. They first explain six shared building blocks—model and MCP gateways, cloud development environments, managed skills, a context graph, and the Cortana assistant—then walk through a World Cup pickup feature from idea and design to autonomous coding, inner-loop validation, CI, review, and ongoing maintenance. The talk shows that scaling agentic development is less about adding a coding assistant and more about creating secure, observable, context-rich systems that can support the entire software lifecycle.

Table of Contents

• The Scale of Agentic Engineering at Uber
• A Secure and Observable Model Gateway
• Making Internal Tools Accessible Through an MCP Gateway
• Cloud Environments Built for Long-Running Agents
• A Managed Lifecycle for Agent Skills
• Unifying Company Knowledge in a Context Graph
• Cortana as a Company-Wide AI Interface
• Taking a World Cup Feature from Idea to Prototype
• Building the Feature with Minion
• Moving Validation and Review into the Inner Loop
• Managed Maintenance and Continuous Improvement
• The New Bottlenecks in an Agentic SDLC

The Scale of Agentic Engineering at Uber

Uday Kiran Medisetty: Good morning. I’m Uday, and I’m here with my colleague Adam. I’ll begin by explaining the key building blocks we are investing in as we move toward a managed software factory. Adam will then show how those blocks come together as an end-to-end solution for engineers.

Uber has a few thousand engineers across twelve global technology sites. Over the last year, our investments in agentic AI have led to more than 70 percent of pull requests being created with either local or cloud agents. We have also seen twice as many lines of code per engineer year over year. The effect extends far beyond coding and is visible in every part of the engineering lifecycle.

We are also accelerating toil reduction at a massive pace. We have handled more than 250 automated migrations, covering nine million lines of code for our engineers. This progress rests on foundations built over the previous six years, including our move to monorepos and Bazel. Those earlier investments made it possible to accelerate agentic development now.

The software factory has six building blocks. They are in different stages of maturity and rollout inside Uber, but together they show the direction we are taking.

A Secure and Observable Model Gateway

The first building block is the model gateway, one of our earliest investments. We established three important requirements. By default, personally identifiable information must never leave our perimeter for a vendor. The latency introduced by any guardrail must be strictly bounded. Every request must also be attributable to a user, project, and team.

All internal use cases, coding harnesses, and external use cases go through one OpenAI- and Anthropic-compatible endpoint. Behind it is a series of middleware layers. Identity and authentication use SPIRE. A data anonymizer redacts more than twenty types of PII. An AI guard uses five specialized models to enforce the safety and policy requirements we care about. All of these controls run in under 100 milliseconds. We are also investing in caching and token-optimization strategies at this layer.

Every request can be attributed to a specific project in our catalog and traced to its caller, user, and team, both in real time and in our data lake. That lets us create spend views and guardrails holistically across our portfolio. The same layer captures audit logs and session traces, which feed benchmarking and self-improvement loops.

For an Uber engineer, the experience is simple: take a standard client, set the project ID, and the platform handles everything else. More than 800 internal projects now use the gateway, collectively making over 100 million model requests per day. This includes frontier and open-source models, whether they are hosted in Uber infrastructure or by vendors.

Making Internal Tools Accessible Through an MCP Gateway

Once models are available, they need access to tools. When we began this journey last year, Uber had thousands of internal APIs, but none were agent-accessible out of the box. We also used many SaaS products, each with different authentication and setup requirements. That created friction for users, while installing enough independent MCP servers imposed a substantial token tax.

We built an MCP gateway that, like the model gateway, handles common middleware for engineers. An automated crawler examines internal APIs and projects them into MCP servers with a single configuration change. SaaS integrations such as Google, Slack, and Jira also pass through the gateway. Uber hosts them and performs token exchange, so engineers and other employees use one entry point and one installation method for any MCP integration.

We have steadily optimized how these tools consume context. At first, clients connected directly to individual MCP servers. Earlier this year, we created Omni MCP, a single installed MCP that can discover and invoke any MCP available through the gateway. A few months later, we projected the MCPs into a CLI pattern so that large responses would not consume the agent’s context directly. More recently, we added an automatically installed code-mode skill that creates Python scripts on the fly to optimize some of the highest-token MCP use cases.

The gateway now exposes more than a thousand MCP tools. These optimization efforts have delivered fleet-wide savings of more than 40 percent.

Cloud Environments Built for Long-Running Agents

Models and tools need somewhere to run. For years, Uber has used Devpod cloud development environments because our engineers work in large monorepos containing millions of lines of code. We have now made that environment agent-ready. Agents need to run for long periods, start quickly, remain isolated, scale to many concurrent instances, and be available across all global sites.

To provide that capacity, we maintain pre-provisioned Kubernetes balloon pods. When an agent needs a fresh environment, it claims a pod that already has repository snapshots and a built search index. The agent can begin working in seconds instead of waiting for a complete environment to be assembled.

We also saw engineering roles becoming less sharply separated. Previously, Uber offered a Devpod flavor for each language or platform, such as Go, Java, or Android. Agents now need to work across repositories, and engineers increasingly do as well. We therefore created a mega Devpod that brings all repositories into one common environment. It supports our autonomous coding agents and gives non-engineering employees a simple way to start using an agent harness within seconds.

A Managed Lifecycle for Agent Skills

The next building block is knowledge packaged as skills. Earlier this year, we saw engineers creating many skills across many repositories. Three problems emerged: different engineers duplicated the same skills, discovery and configuration were difficult, and many skills did not meet an acceptable quality bar.

We responded by building an entire lifecycle around skills. Core and domain-specific skills are published to a managed marketplace that currently contains 2,500 skills. Every submission passes lint checks and automated reviews that enforce a baseline level of quality. Installation and discovery are available through a single command, and default skills can be installed automatically according to an engineer’s persona, allowing an agent to select the right capability without requiring manual setup.

More recently, we began collecting execution traces and comments and running continuous evaluations. These signals can be returned to skill authors to guide improvements, making this an important area of current investment. Across the fleet, the 2,500 managed skills are executed more than 20,000 times per day.

Unifying Company Knowledge in a Context Graph

Skills alone do not solve the context problem. Execution traces showed that agents spent substantial time finding even basic information in Uber’s large monorepos: where a service lives, what depends on it, who owns it, and which established patterns should be followed. The required context was scattered across twenty to thirty systems, each of which needed its own skill or MCP integration. Gathering it burned tokens, added latency, and made outcomes less predictable.

We built one context graph that captures information about how Uber operates. It has 150 distinct node and edge types and currently contains forty million entries. It spans mobile applications, backend systems, and the data lake, connecting design documents, Jira items, incidents, bugs, and other internal knowledge. Agents can use those connections to find the right context quickly.

We are connecting skills and use cases throughout the company to this graph, including on-call root-cause analysis, planning, data analysis, and security scanning. Across those evaluations, graph-backed context substantially improves the skills.

Consider a seemingly simple question: how many mobility trips in India are paid in cash? Answering it requires understanding the relevant business concepts, identifying the right tables, selecting the cities involved, and constructing the SQL. In our evaluations, using the context graph produced major improvements in token usage, agent turns, and latency compared with gathering the same information without the graph.

Cortana as a Company-Wide AI Interface

The final building block packages these capabilities for everyone in the company. Uber’s AI assistant, Cortana, brings together skills, MCP tools, and the context graph across Slack, the CLI, and the web. An employee can ask a question from any of those surfaces, and Cortana can consult the context graph, invoke a skill, inspect code in any codebase, and return an answer.

Employees can also personalize the assistant with custom skills and prompts, then connect that persona to a team Slack channel. It can learn the relevant context for the team and behave more like a teammate. Multiple people can collaborate with the same persona in a shared channel. In the last month, employees created 300 unique personas, and Cortana has grown to more than 20,000 sessions per day.

I’ll now pass to Adam, who will show how these building blocks support the full journey of shipping a feature.

Taking a World Cup Feature from Idea to Prototype

Adam Huda: We are going to use those building blocks to power the software factory and follow one feature from beginning to end. First, we need an idea. With the World Cup approaching, imagine a rider leaving a crowded stadium. It would be useful to recommend a better pickup location away from the crowd.

The team starts discussing the idea in Slack and brings Cortana into the conversation. With access to the context graph, Cortana can help determine whether the idea represents a worthwhile business opportunity. The Slack discussion can then be opened in Cortana’s web interface for deeper business research, such as examining other large-scale venue events and identifying stadiums where the feature might be useful.

From there, the team develops product requirements. Because the relevant stadiums are in North America, the initial rollout should likely focus there. Cortana can also help with Figma designs and produce initial mockups. In this example, the team creates two variants with different button text so they can run an A/B experiment and measure which performs better.

Cortana then helps identify the code changes needed to implement the design. It can determine what existing app screens can be reused and which backend capabilities already exist. A process that once might have taken weeks to align all the participants can be compressed into a short period, allowing the team to reach a prototype quickly.

Building the Feature with Minion

After planning and prototyping, work is handed from Cortana to Minion, Uber’s cloud coding agent. Minion can run interactively or autonomously. It is powered by the Devpod building block, giving it a complete build environment and the ability to modify multiple repositories. In this example, it makes both backend and frontend changes.

Minion progresses until it has created a draft pull request, but it does not immediately send the change to CI. Autonomous agents worked well for toil-oriented tasks, but more advanced end-to-end features require meaningful validation before CI. Validating earlier avoids putting unnecessary load on shared CI infrastructure.

Moving Validation and Review into the Inner Loop

The software development lifecycle has an inner loop and an outer loop, and both can become agentic. We are moving more checks into the inner loop. Static analysis already runs there, and detected problems can be fixed immediately. We can now bring in richer checks as well, including visual validation. A skill can launch a simulator, take a screenshot, and compare it with the Figma specification. It can also start a service in the backend staging environment and validate the frontend and backend integration together.

After inner-loop validation, the change moves to the outer loop, where CI normally runs. Errors can still occur, so Uber has implemented self-healing CI that can resolve many of the issues encountered there.

Code review also spans both loops. Some review work has shifted into the inner loop, where a smaller, faster model can provide rapid feedback. The outer loop can use a more powerful reasoning model and a specialized skill for deeper review.

For an autonomous diff produced by Minion, the human reviewer needs confidence that the code has already undergone multiple rounds of validation and self-improvement. The pull request therefore includes a table listing the checks that were performed, including screenshots. The reviewer is not seeing only the agent’s initial generation; they can inspect evidence that the subsequent validation steps have happened.

Managed Maintenance and Continuous Improvement

As the software factory produces more code, maintenance becomes even more important. A feature or service can be enrolled in maintenance skills. One example is feature-flag cleanup. After the World Cup modal experiment chooses a winner, the unused variant no longer needs to remain in the codebase, so a maintenance skill can remove it on a schedule.

These schedules run as managed loops. Uber does not want thousands of unbounded loops independently created across the company. Teams use a managed surface to configure them. A cleanup can run on Sunday, when more CI capacity is available, while the platform also controls how many automated diffs engineers will see on Monday morning.

When a maintenance skill creates a diff, the change receives comments and is either landed or rejected. Both outcomes provide labeled data that can improve the skill. On a roughly monthly cadence, teams can also examine incident reviews, identify recurring work that could become a new maintenance skill, and apply that skill across services.

The New Bottlenecks in an Agentic SDLC

The same building blocks can support other parts of the lifecycle, including monitoring, but higher agent throughput creates new constraints. More code puts more strain on infrastructure, so Uber must anticipate future CI capacity and make the corresponding foundational investments. Experiment capacity is another bottleneck because only a finite number of experiments can be run meaningfully.

The final constraint is decision-making. As agents make implementation dramatically easier, the central question changes. It is no longer simply whether the organization can build something—we increasingly know that it probably can—but whether it should build it.