AI is not new to Uber. Our fairs platform, our matching platform has been using AI methodology for years and years. It's one of the things that sets us apart from the competitors. But over the past few years, using AI as part of the engineering productivity and engineering life cycle, that's fairly new. DAR has stated that AI is one of our six strategic shifts. We move from a early AI powered company into a generative AI powered company. Nowadays it's more fashionable to be an agentic powered company but the concept still holds where AI is enabling people to become superhumans in terms of their productivity.

We want to focus on enabling our engineers to focus on creative work rather than toil. When we push some of the boring stuff to it, upgrades, migrations, bug fixes, not only does it result in much higher satisfaction from our engineers, they're able to push our product and create features in ways that we didn't even thought was possible.

We are going from pair programming to peer programming. Back in the good old days of 2022 and 2023 when GitHub copilot first came out, it was a novel way of augmenting development. You had synchronous tab completion, an ID chat window. We saw about a 10 to 15% bump in overall diff velocity. But over the past year, the paradigm has shifted to peer programming where you could hand off workloads that are running asynchronously. The models are so good, they're so accurate that all you need to do with the AI agent is to redirect it in certain ways. We imagine developers acting as their own tech leads, directing AI agents to execute asynchronously. This concept of vibe coding, which was just a joke a couple years ago, is becoming much more prominent.

We are building on the shoulders of giants. We have our historic Michelangelo platform which provides a model gateway so that we can proxy and talk to the main frontier models or host internal models. On top of that, we have context at Uber: source code, engineering documentation, Jira tickets, Slack information. To have an effective agent have organizational memory, it needs to get access to these.

One of the key ones is our deployment of MCPs throughout Uber. We moved very quickly to design a strategy and built a central MCP gateway. This allows us to both to proxy external and internal MCPs and expose those in a consistent way to engineers that handles authorization, telemetry, logging. We also provide a registry and a sandbox so that developers can play with these MCPs.

We built this tool called AIFX. It's a CLI and it is the forefront of what developers are using to access our agent infrastructure. It provides the central ability to provision, configure and update the agent clients themselves, install and discover MCPs from the registry, and deploy standard configuration management so that people have more effective prompts and configurations right away.

We wanted these background agents to be running autonomously. External vendors were running their background agents in other people's infrastructure. We built a product called Minion, our formal background agent platform. It leverages all of Uber's existing infrastructure, runs in our CI platform. This has our monorepos checked out, ready to work in quickly. It's integrated through the web interface, Slack, GitHub PRs, and CLI.

One other powerful thing is this offers good defaults. We have these existing templates that users can choose from that are well-written prompts. We built into this a prompt improver. The ability to analyze the prompt and make suggestions that the user can accept on how to have a higher chance of success.

A few minutes later, the Slack notification pings them: "the minion task is done. You can go look at the PR here." Our minion bot co-authors this with the person that kicked it off. We have a link to Jira, the test plan of how it verified. It's much easier for the developer to just dump in a prompt and get a PR out of that as opposed to all of the context switching. What we saw is 70% of the workloads that developers are pushing into the system were toil tasks. The accuracy was higher compared to more ambiguous workloads.

Developers are spending more and more time in planning and code review because there's so much more code being generated. We built a tool called Code Inbox, a unified inbox for PRs. It's designed to remove noise. We put a lot of work into the smart assignments, trying to find the most relevant person based on ownership, history, time zone, and calendar availability.

U Review is designed for review help itself. We have a pre-processor and a set of plugins. We have a review grader to filter low-value comments. We only want to put the high confidence changes that the developer really needs to focus on, not little nits.

We built a system called AutoCover to generate unit tests. We're seeing about 5,000 tests generated and merged per month. It has a critic engine and an independent test validator to uplevel the test quality. For code maintenance, we created a scalable version of how we handle large scale change called AutoMigrate. The key platform is Shepherd. It's a web UI where migration authors can track all of the PRs associated with a migration. Shepherd handles generating those PRs, refreshing them, and notifying the people that need to review it.

The leaders when it comes to AI tech are changing pretty frequently. We need to commit dozens of people on projects that might be running for months. So we can't just change our mind after a quarter. Making sure that we have the right abstraction layers in place. We should not be married to the tech that we're building. delivering impact for Uber is what matters.

Our adoption for this technology has been relatively slow. Part of it is because we're telling them to take a risk by operating in a very different way. The more successful technique is actually just sharing wins. Promoters pushing techniques to their peers. Engineers trust other engineers as opposed to directors like me.

The cost of AI is too damn high. Since 2024 our costs have gone up at least 6x. The GPU costs are high and memory costs are really high. So we've had to be more responsible about how we use tokens. We help developers think about the right model to form the plan and then lower cost but still effective models to do the execution. We want to have the infrastructure decide for them so that we reduce the friction but also optimize our costs.