How is Uber getting 70% of PRs from AI agents?

Is Uber really getting more than 70% of its pull requests from AI agents?

Yes. Uber now says more than 70% of its pull requests are attributed to local or cloud AI agents, although that does not mean 70% are autonomously written from start to finish.

The distinction is easy to miss. In Uber’s latest engineering update, the company used the broad wording “attributed to local or cloud agents.” That includes engineers working interactively with tools such as Claude Code as well as background agents operating more independently.

Uber gave a much narrower number at AI Engineer World’s Fair: 15% of PRs were being done entirely by autonomous agents. Those are the cases closest to the popular idea of “AI wrote the PR.” The engineer can review and approve the result without personally writing the code.

So the headline is real, but it describes agent involvement across Uber’s development process. Full autonomy has already become meaningful at Uber, yet it remains much smaller than overall agent participation.

Uber metric	What it tells us
More than 70% of PRs attributed to agents	AI agents are involved in most code changes
15% of PRs entirely autonomous	A significant minority require no human code authoring
99% of engineers using AI monthly	Agentic development has reached almost the whole engineering organization
2x lines of code per engineer YoY	Uber is producing much more code per engineer

How quickly did autonomous coding take off inside Uber?

Uber’s autonomous coding adoption moved from tiny to material within a few months. That is probably the most surprising part of the story.

Earlier this year, Uber CTO Praveen Neppalli Naga said the company’s internal background coding agent had grown from less than 1% of code changes to around 8%. At that point it was already producing roughly 1,800 changes every week with zero human code authoring.

The later AI Engineer World’s Fair disclosure put fully autonomous agents at 15% of PRs. We should be careful about drawing a perfect growth curve between those numbers because “code changes” and “PRs” are different measures. Still, both disclosures point in the same direction: autonomous work moved from an edge case to a normal part of Uber engineering remarkably quickly.

Interactive coding changed even faster. Naga said 84% of Uber’s AI users were already using agent-style workflows rather than relying mainly on autocomplete, while Claude Code adoption rose from 32% to 63% in roughly two months.

This helps explain how Uber reached such a high overall PR figure. Engineers increasingly stopped asking AI to complete individual lines and started handing over chunks of work.

Is Uber mostly getting these AI-generated PRs from Claude Code?

No. Claude Code has grown very quickly inside Uber, but Uber’s current setup is deliberately built around multiple models, coding tools and internal agents.

The common layer underneath them is more interesting than any individual coding product. Uber sends model traffic through its own Model Gateway, which gives internal applications one shared interface for frontier models, open-weight models and different providers.

At AI Engineer World’s Fair, Uber said more than 800 internal projects were already using this gateway and generating over 100 million model requests per day. Every request can be attributed to a project, user and team. The gateway also handles authentication, removes more than 20 types of personally identifiable information and runs five specialized safety checks.

This lets Uber change models without rebuilding the whole engineering workflow. Its latest engineering update says the company continuously benchmarks models on real internal tasks and moves workloads toward whichever option gives the best mix of quality, reliability and cost.

Simple subagent jobs can therefore run on cheaper models while a stronger model handles decomposition or difficult reasoning. Uber is treating models as interchangeable compute for specific jobs rather than committing the whole company to one AI coding vendor.

What does Uber’s Minion coding agent actually do?

Minion is Uber’s cloud coding agent, and it can take an engineering task far enough to create a working pull request with little or no human coding.

Minion runs inside Uber’s remote development infrastructure rather than starting from an empty generic sandbox. It gets the repositories, build environment and search indexes required to work on real Uber software.

Engineers can use Minion interactively or let it operate autonomously. Uber showed an example where the agent worked across frontend and backend repositories for the same feature, produced the changes and created a draft PR.

For more complicated work, Minion deliberately stops before sending the change straight into CI. Uber learned that blindly generating code and immediately pushing everything through shared CI works poorly once agents begin producing large volumes of complex changes.

The agent first gets a chance to inspect and improve its work locally. That small workflow choice tells us quite a lot about Uber’s approach: higher autonomy came from surrounding the model with better execution and verification, rather than simply telling the model to try harder.

Why can Uber’s AI agents work inside such a huge codebase?

Uber’s agents have an unusually clean foundation because the company spent roughly six years standardizing its development infrastructure before today’s coding agents arrived.

Uber specifically credits its move toward large monorepos and Bazel as part of the reason it could adopt agents so quickly. A huge codebase is difficult for an agent, but thousands of disconnected repositories with different build systems, ownership conventions and tooling would be considerably worse.

Uber also had DevPod, its cloud development environment. The company adapted it for agents by pre-provisioning Kubernetes capacity, snapshotting repositories and preparing search indexes before an agent starts working.

Uber says an agent can now obtain one of these environments and begin working within seconds. It has also built a “mega DevPod” containing multiple repositories because both engineers and agents increasingly need to cross the old boundaries between Go, Java, Android and other codebases.

This is one of the less obvious reasons Uber is ahead. Years of boring infrastructure work suddenly became extremely valuable once software agents needed predictable environments.

How does Uber stop AI agents from getting lost in company knowledge?

Uber built a Context Graph because its agents were spending too much time searching for information instead of solving the actual task.

The scale of the problem is enormous. Uber describes hundreds of millions of lines of code, thousands of data tables and information spread across dozens of internal systems. An agent might need to find the right service, team, dataset, incident history, architecture document or previous pull request before touching any code.

Uber’s current Context Graph contains 24 million nodes and 80 million edges built from more than 30 internal systems. Agents can query it directly instead of independently searching every source.

Uber tested the same question with the same model both ways. With graph grounding, the agent found the correct dataset and answered in 38 seconds. Without it, the model searched for more than 20 minutes, launched two subagents, hit three errors and eventually gave the wrong answer.

The time difference was roughly 32x. More importantly, one path succeeded while the other failed.

That experiment gets surprisingly close to the core of Uber’s advantage. Better models help, but giving an existing model the right internal context can change the result much more dramatically than another small jump in benchmark performance.

Same Uber task	With Context Graph	Without Context Graph
Time	38 seconds	More than 20 minutes
Extra subagents	None reported	2
Errors	None reported	3
Result	Correct	Incorrect

How can Uber give AI agents access to more than 1,000 internal tools?

Uber gives agents access to more than 1,000 tools through a common gateway, then avoids loading all those tool definitions into every AI session.

The second part turned out to be crucial. Uber found that installing more than 100 MCP tools could add roughly 50,000 to 70,000 tokens of tool definitions to the context before useful work had even started.

Its solution is closer to how a developer uses a terminal. Internal MCP tools can be exposed as command-line commands, and an agent can search for the tool it actually needs instead of carrying the full catalog around throughout the session.

Uber also lets agents write small scripts for repetitive tool interactions. Consider a database query that requires several status checks before returning its result. A normal agent could send each request through the model one at a time, repeatedly filling its context with intermediate responses. Uber can move that loop into code and return only the useful result to the model.

On simple SQL tests, Uber measured token reductions above 50%. On bulk workflows, savings could exceed 90%. The company also reported more than 40% fleet-wide savings from its broader tool-access optimizations during its AI Engineer presentation.

At Uber’s scale, those seemingly small pieces of plumbing become essential. An agent architecture that wastes tens of thousands of tokens before doing any work becomes very expensive once millions of requests are flowing through it.

Why has Uber built more than 3,600 AI agent skills?

Uber’s 3,600-plus agent skills let engineers package a good workflow once and reuse it instead of repeatedly explaining the same process to an AI model.

It has grown quickly. In its latest engineering update, Uber said employees had created more than 3,600 skills across the software-development lifecycle and were running them more than 30,000 times per day.

A skill can encode how Uber expects an agent to handle a specific recurring job: validate a user interface, clean up a feature flag, query an internal service, review a particular type of code or perform maintenance on a system.

Uber originally saw engineers creating large numbers of overlapping skills across different repositories. It responded by managing them more like internal software, with discovery, quality controls and reusable shared versions.

The scale is already substantial. Thirty thousand executions per day works out to more than eight daily runs for every skill if usage were evenly distributed, although in practice popular skills will account for much more activity.

There is also a compounding effect. Uber now wants failed runs, reviewer comments and other “papercuts” to feed back into the skills themselves. A workflow that initially works 80% of the time can gradually become more reliable without waiting for the underlying foundation model to improve.

What work are Uber’s AI agents actually doing today?

Uber’s AI agents are already doing large amounts of maintenance, migration, review, testing, CI repair and coding work where success can be checked relatively clearly.

The migration numbers are especially useful because they measure completed engineering work rather than prompts. Uber says it has handled more than 250 automated migrations covering nine million lines of code in total.

That works out to about 36,000 lines touched per migration on average, although the actual projects will vary widely in size. More importantly, this is exactly the kind of work agents can attack aggressively: repetitive changes spread across a huge codebase, with compilation, tests and static analysis providing strong feedback.

Uber’s newer managed agents also cover code review, self-healing CI failures, debugging incoming bugs, on-call triage and code maintenance. Some of these sessions now start automatically rather than waiting for an engineer to type a prompt.

The pattern is fairly clear. Uber keeps pushing agents toward tasks where the desired outcome is explicit and the result can be tested. That creates a much safer path to high autonomy than giving an open-ended product problem to an agent and hoping it makes good decisions.

Can Uber’s AI agents build an entire product feature?

Uber can already run an AI-assisted feature workflow from product research through code and validation, although the company has not shown that this is how most new Uber features are built today.

At AI Engineer World’s Fair, Uber demonstrated the process using a feature designed to improve pickups around crowded stadiums. An internal assistant could help research the problem, turn the discussion into requirements and generate design variants before passing the implementation to Minion.

Minion then worked on both frontend and backend changes. Before consuming shared CI capacity, the workflow could launch the app in a simulator, take screenshots, compare them with the Figma design and start backend services in a staging environment to check whether the full interaction worked.

Once those checks passed, the change could continue through CI and deeper review.

This example shows how far Uber is trying to stretch agent autonomy. It does not tell us that agents are independently deciding which Uber products should exist, or that most major features currently travel through this full workflow. Some of the building blocks are still at different stages of rollout.

For now, Uber has demonstrated automated implementation and verification much more convincingly than automated product judgment.

How does Uber stop AI-generated PRs from overwhelming CI and human reviewers?

Uber is moving more checks before CI and using AI review because faster code generation simply creates a new bottleneck downstream.

The pressure is straightforward. If engineers and background agents can produce code much faster, Uber’s CI infrastructure receives more work, and human reviewers receive more PRs. Generating another change becomes cheap while deciding whether that change deserves to land remains expensive.

Uber therefore separates validation into an inner loop and an outer loop. Faster checks can run inside the agent’s own environment. Visual validation can launch a simulator and compare screenshots with Figma. Backend services can be started in staging. Static-analysis problems can be detected and repaired before shared CI receives the PR.

CI itself can now repair many failures through self-healing agents. Code review also uses multiple AI layers, with faster models checking changes earlier and stronger models performing deeper review later.

Uber’s uReview system gives us a sense of how mature that layer already was before the latest wave of coding agents. Uber reported that uReview analyzed more than 90% of roughly 65,000 weekly diffs, returned reviews within a median of four minutes, and maintained a usefulness score above 75% among engineers who rated its comments. More than 65% of the comments it posted were addressed in the same changeset.

Humans still make the final call on autonomous Minion changes. To make that review easier, Uber attaches evidence to the PR showing which checks ran, including screenshots when relevant.

The bottleneck has therefore started moving from typing code toward reviewing, testing and deciding which generated work deserves attention.

Stage	What Uber does before code lands
Agent workspace	Build, test and improve the first implementation
Visual validation	Compare running UI against designs
AI review	Catch problems before and during the main review loop
Self-healing CI	Repair many CI failures automatically
Human review	Decide whether the change should actually land

Has AI actually made Uber engineers twice as productive?

Uber has strong evidence that engineers are producing more software with AI, but “2x productivity” would be a stronger claim than the public data currently supports.

At AI Engineer World’s Fair, Uber said lines of code per engineer had doubled year over year. Combine that with millions of lines handled through automated migrations and a meaningful share of autonomous PRs, and it is difficult to argue that these tools are merely generating demos.

Lines of code still tell us much less than product output. An engineer who deletes 10,000 unnecessary lines may create more value than someone who generates 50,000 new ones. More code can also increase review, maintenance and infrastructure costs.

Uber’s own measurement is becoming more sophisticated for exactly this reason. The company now tracks managed agents using outcomes such as cost per merged PR, cost per review and cost per resolved alert, alongside quality measures including revert rates, F1 scores and mean time to resolution.

We therefore have good evidence that AI has sharply increased Uber’s engineering throughput. We do not yet have enough public evidence to claim that customer value or economic output per engineer has doubled at the same rate.

How can Uber afford this much AI coding?

Uber has managed to keep total AI spending roughly stable while agent usage exploded, which makes its current level of adoption much more sustainable than it looked earlier this year.

Cost was initially a genuine problem. Uber’s CTO said earlier this year that AI usage had already blown through the budget he expected to need. The company then attacked the cost structurally instead of simply restricting engineers.

The latest numbers show how much changed. Weekly active users across Uber’s agentic products grew about 7x from February into the middle of the year, while weekly agent requests grew 9.4x. Requests therefore increased roughly 34% faster than the user base, suggesting that existing users were also becoming heavier users.

Despite that surge, Uber says total AI spending has stayed relatively stable since spring.

Holding the model constant to isolate its own optimizations, Uber measured cost per 1,000 model requests falling almost 34% from its peak. Cost per session fell 52% from its earlier peak.

Several changes produced those savings. Uber routes tasks toward models that perform well enough at lower cost, gives simpler subagent jobs to cheaper models, limits interactive context even when a provider allows much larger windows, makes better use of prompt caching and strips unnecessary tool traffic out of model context.

Engineers can also see their running AI cost directly in the terminal. Uber sends alerts as usage approaches expected spending levels and has built a session analyzer that detects 16 types of waste, from oversized context to unnecessarily expensive model choices.

That is the key cost result: Uber increased both the number of users and the amount each user does with agents while pushing unit economics in the opposite direction.

So how is Uber getting more than 70% of PRs from AI agents?

Uber is getting agent involvement in most pull requests because it has turned AI coding into engineering infrastructure rather than treating it as an optional chatbot sitting beside the IDE.

As we saw above, the 70% figure covers a spectrum. Some engineers delegate work interactively to tools such as Claude Code. Minion can take larger tasks in the cloud. A smaller but already substantial group of PRs can be produced autonomously. Other agents review code, repair CI failures, debug problems and perform recurring maintenance.

What makes the whole system work is everything surrounding those agents. Uber already had standardized monorepos and build infrastructure. DevPods give agents prepared environments. The Model Gateway gives them access to different models. More than 1,000 tools connect them with internal systems. The Context Graph gives them company knowledge. Thousands of reusable skills encode recurring workflows. Validation happens before expensive shared CI. Automated review absorbs part of the extra code volume. Humans remain involved where judgment is harder to automate.

Uber has also proved that this architecture can operate at serious scale. The latest company numbers show more than 30,000 skill executions per day and weekly agent traffic up 9.4x, while unit costs have fallen sharply.

The clearest lesson from Uber is that better coding models alone do not explain its 70% figure. The bigger advantage comes from reducing everything that makes delegation painful: missing context, slow environments, inaccessible tools, repeated instructions, weak validation and uncontrolled costs.

Once those problems are removed, engineers can hand over much larger pieces of work. Uber is already far enough along that its next constraints are starting to look different. CI capacity is finite. Human review capacity is finite. The number of product experiments a company can meaningfully evaluate is finite.

Code generation is becoming abundant inside Uber. Deciding what deserves to be built, checked and shipped is increasingly where the scarce human time goes.