# Building uReview, Uber's Multi-Agent Code Review Engine Will Bond & Ameya Ketkar, Uber | AI Engineer World's Fair 2026 | 15:07 Source: https://www.youtube.com/watch?v=EL123UNokkI Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/building-ureview-ubers-multi-agent-code-review-engine Published: 2026-08-28 Tags: agents, coding-agents, evals, multi-agent, observability ## TL;DR - Uber's first-review wait grew from three hours in 2024 to nine hours in 2026, making code review a bottleneck for its engineering organization. - uReview combines multiple review generators with routing, post-processing, feedback, and team-owned customizations to produce actionable comments at scale. - Tracking reply sentiment, addressal rate, and agent trajectories helped Uber reduce cost by 60% against a naive implementation while posting about 25,000 comments each week. ## Summary Will Bond and Ameya Ketkar explain why Uber built uReview instead of buying an automated code review product. Uber needed support for Phabricator, the same review rules in human and agent workflows, team-owned customizations, and routing based on change risk and complexity. The system accepts reviews from GitHub, Phabricator, and the agent loop, then rates, filters, categorizes, and deduplicates comments. Ketkar describes how evaluation moved beyond cost and surveys to include reply sentiment, whether developers addressed comments, and the agent's runtime trajectory. Teams can add style guides, AI linters, knowledge bases, past pull requests, and custom agents, though running these skills cheaply and consistently is harder than writing them. uReview now produces about 25,000 comments per week, with a 67% overall addressal rate. Bond closes by arguing that automation will expand the human outer loop toward architecture, domain expertise, and product decisions rather than remove it. ## Key ideas ### Review delays made automation a capacity problem [00:35](https://www.youtube.com/watch?v=EL123UNokkI&t=35s) Uber has thousands of software engineers across hundreds of teams, 12 sites, and six language-specific monorepos. Will Bond says both pull request volume and pull request size grew over the previous 24 months. The first-review wait rose from three hours in 2024 to nine hours in 2026. He calls code review the bottleneck Uber was running into. The problem was therefore tied to the scale and shape of the engineering organization, rather than only to the quality of a particular review tool. ### Uber built uReview around its existing systems and ownership model [01:19](https://www.youtube.com/watch?v=EL123UNokkI&t=79s) Uber was using Phabricator and was migrating to GitHub, while most available products did not support Phabricator. The team also wanted agents in the inner loop to receive the same rules and review experience as human engineers. Hundreds of teams have their own rules, knowledge, and ownership, so centralized management would not fit. uReview plugs into Uber's existing team ownership system. It can also consider the risk profile and complexity of a change, since not every code change needs the same review. Security and compliance checks still need to run reliably across all code. ### uReview uses several generators and removes duplicate comments before delivery [02:58](https://www.youtube.com/watch?v=EL123UNokkI&t=178s) The review surfaces are GitHub, Phabricator, and the agent loop. They send requests to the uReview service, which brings in user feedback and routes work to generators tuned for different cost and performance needs. Uber can connect third-party review systems for comparison. Multiple generators can produce overlapping comments, so post-processing rates, categorizes, filters, and deduplicates them. Engineers receive comments that the system considers high-confidence and actionable instead of the full raw output. ### Evaluation had to move beyond cost and surveys [04:37](https://www.youtube.com/watch?v=EL123UNokkI&t=277s) uReview began with a prompt for per-file logic checks, a simple thorough-review agent, and a dispatcher. Its early observability consisted of cost, an NPS survey, Google Forms, and Slack support. The resulting quality-to-cost ratio was spread across the chart rather than concentrated in the desired high-quality, low-cost area. Uber then analyzed the sentiment of developer replies and classified the issues that appeared in that feedback. This exposed bug and review problems that the team could fix, moving more pull requests into the desired quality-to-cost range. ### Addressal rate and agent trajectories exposed problems that output quality alone missed [05:33](https://www.youtube.com/watch?v=EL123UNokkI&t=333s) Uber began measuring whether developers actually addressed a uReview comment. It also captured the agent trajectory, including the tool calls made and the reasoning path that led to the result. Those signals helped the team tune runtime behavior so the agent could return useful reviews quickly and cheaply. Ketkar says the model does not know when it is wrong and can confidently assert a bad review. Teams therefore need to provide style guides, patterns, anti-patterns, and guardrails that stop the agent from spending turns on work outside the review's time and quality requirements. ### Team customizations range from fixed rules to custom agents [07:31](https://www.youtube.com/watch?v=EL123UNokkI&t=451s) uReview has single-file and multi-file reviewers. General-purpose reviews look for logic bugs per file, while deeper reviews include anti-patterns and style guides from Uber's six monorepos. AI linters give developers a more deterministic way to apply contextual rules to files and find systematic issues. Teams can also define custom agents linked to a knowledge base, past pull requests, and a review skill. These customizations live beside the code and follow Uber's ownership model. Deterministic routing decides which team's review, model, and generators apply. ### Writing a review skill is easier than operating it at company scale [09:37](https://www.youtube.com/watch?v=EL123UNokkI&t=577s) Teams could quickly ask Claude to inspect previous pull request reviews and write a skill. The harder problem was running those skills with consistent quality and low cost. That work required repeated changes from both the uReview team and the teams authoring their rules. Uber also had to expose agent trajectories, addressal rates, and sentiment analysis back to the teams. A team can then see that developers dislike or ignore a rule and revise it instead of treating the skill as finished once it has been written. ### The reported results combine usage, developer response, and cost changes [10:10](https://www.youtube.com/watch?v=EL123UNokkI&t=610s) uReview produces about 25,000 comments per week. About 10% receive some feedback, and 4% of pull requests receive negative feedback. The overall addressal rate is about 67%, while almost three quarters of high-severity issues are addressed by developers. Against a naive implementation, Uber reports a 60% cost reduction and about a 70% increase in quality and accuracy. These measurements came after the team added broader observability and evaluation to the original cost-focused approach. ### Automation moves human review toward architecture and product decisions [11:08](https://www.youtube.com/watch?v=EL123UNokkI&t=668s) Will Bond says engineers are becoming less involved in authoring code while humans still approve it. The inner loop needs higher accuracy because a low-quality comment can make an agent fix one issue, return for another review, and then work backward. Agents are also willing to fix large numbers of minor issues that frustrate engineers. Bond argues that humans should not disappear from the outer loop. Their responsibility moves upward, toward architecture, domain expertise, product thinking, performance decisions, and API compatibility, while agents handle more implementation detail and routine review. ## Notable quotes - "Back in 2024, we were seeing that engineers would get their first review within 3 hours. Now in 2026, that has grown to 9 hours." (00:58) - "One of the biggest learnings in this process was like the model doesn't know that it's wrong." (06:27) - "The hard part was how to run these skills at scale with consistent quality and low cost." (09:57) - "Rather than killing the outer loop, I think that we believe and the industry has just started to really kind of coalesce on this idea that we're really expanding the outer loop." (13:41) ## Tools & references mentioned - uReview - Uber - Phabricator - GitHub - Claude ## Who should watch - You are building automated code review and need to decide what to measure beyond model output and inference cost. - Your organization has many teams with different style guides, ownership boundaries, or review rules that need to run through one platform. - You are moving coding agents into production and need to think about how human feedback and approval will change.