Talk by Will Bond and Ameya Ketkar (Uber) on uReview, the multi-agent code review engine Uber built internally rather than purchased, motivated by long review wait times, monorepo scale, and lack of Phabricator support among vendors. They describe the system's architecture and comment deduplication, the evolution of their measurement approach from cost-only and NPS surveys to tracking reply sentiment, whether comments are addressed, and agent trajectory, noting that models assert incorrect reviews with full confidence. Teams author their own review skills, and authoring proved easier than running skills cheaply at scale. Reported outcomes: about 25,000 comments per week with roughly 67% addressed, and a 60% cost reduction versus the first build. Includes discussion of inner versus outer loop review and future expansion. # Channel Presentation Observations: uReview Talk (Will Bond & Ameya Ketkar, Uber) ## Observable Format & Presentation Style - **Conference-style technical talk** with two alternating speakers; explicit handoffs ("I'm going to hand it off to Ameya", "I'll give the mic back to Will"). - **Structured narrative**: context/motivation → architecture overview → three named "focus areas" (observability & evaluation, customizations, inner vs. outer loop) → closing vision statement. - Speaker introduces himself by first name only: > "My name is Will and uh I'm here to talk to you about automated code review." - References an adjacent talk: > "if you were at the previous talk, you saw Uday and Adam talking about the agentic SDLC" — indicating a multi-session event context. ## Intended Audience - **Professional software engineers and engineering leaders**, presumed familiar with code review workflows: > "As many of you have probably noticed over the past 24 months, the volume of PRs, the size of PRs has been growing." - Audience expected to have **hands-on AI experience**: > "If you've ever used AI to run a code review, you've probably seen that." - Practitioners at **large engineering organizations** (monorepos, hundreds of teams, platform-building concerns). ## Claimed Scope of Content - Presents an **in-house platform case study**: "U Review, a system that Uber has built uh to help increase the velocity of our software engineering teams." - Covers: system architecture, observability/evals, team customization mechanisms, and forward-looking SDLC trends — explicitly framed as an overview plus "a few focus areas." - Includes **quantified results** presented by the speakers: ~25,000 comments/week, 67% addressal rate, "costs were down by 60% and our quality and our accuracy was up by around 70%." (Creator claims; presented as measured outcomes, not independently verifiable from this material.) ## Self-Description Evidence - **Employer affiliation stated directly**: "my teammate Amir and I work at Uber." - **Org-scale framing**: "thousands of software engineers who work across hundreds of teams uh located across 12 different sites... primarily one of six language-specific monorepos." - **Opinion/stance offered on industry direction** (distinguishable from factual claims): > "rather than killing the outer loop, I think that we believe... we're really expanding the outer loop" — framed as belief/prediction, not established fact. ## Demonstrated Presentation Patterns (vs. Claims) - Talks from **lived operational experience**: concrete details such as migrating from Fabricator (likely Phabricator) to GitHub, NPS surveys, Google Forms, Slack support channels, and agent trajectory profiling. - Cites **learning-from-failure narratives**: > "U review had a very humble beginning. Basically, it was a single prompt." - Ends with an **open-ended prompt to the audience** rather than a conclusion: > "I'll let your imagination go there in terms of quality degradation, slop, and so forth." ## Notes for Channel-Level Synthesis - No channel metadata was supplied; identity evidence is limited to what speakers state and demonstrate in this talk. - No explicit channel-level self-description (e.g., "this channel is about...") appears in the transcript; observations above are inferred strictly from presentation behavior and stated affiliations. # Delivery Observations: uReview Talk (Will Bond & Ameya Ketkar) ## Overall Structure & Format - **Two-speaker tag-team format** with explicit handoffs. Will opens and closes: "I'm now going to hand it off to Ameya" and Ameya returns it: "I'll give the mic back to Will and he will go over the inner versus outer loop." - Both speakers **signpost "focus areas"** — an organizing device repeated across the talk: "we're going to dive into a few focus areas," "second focus area for U review has been nations [customizations]," "Uh for a last focus area." ## Verbal Fillers & Hesitation Markers - **Heavy use of "uh" and "um"** by both speakers, a stable pattern across the whole transcript: - Will: "My name is Will and uh I'm here to talk to you about automated code review." - Ameya: "But, uh, all of this was not simple because we had to actually uh, piggyback on our uh, ownership model." - Ameya uses **"like" as a filler/example marker** frequently: "quality to cost ratio was like all over the place," "the model doesn't know that it's wrong," "each team has its own style guide, its own patterns or like a anti-patterns." ## Rhetorical & Teaching Habits - **Problem → constraint → solution framing.** Will lists constraints methodically ("One of those is…", "Um in addition…", "So…", "Uh finally…", "And then finally…") before presenting architecture. Note the near-duplicate "finally" ("And then finally, consistency" after "finally, with the volume of code reviews") — an isolated stumble, not a pattern. - **Concrete numbers anchor claims**: "first review within 3 hours… has grown to 9 hours"; "around 25,000 comments a week"; "costs were down by 60% and our quality… up by around 70%"; "addressal rate was uh around 67%." - **Audience-acknowledging asides** to build relatability: - "As many of you have probably noticed over the past 24 months…" - "If you've ever used AI to to run a code review, you've probably seen that." - "if you were at the previous talk, you saw Uday and Adam talking about the agentic SDLC." - **Learning-as-content pattern** — both explicitly flag lessons: "One of the biggest learnings in this process was like the model doesn't know that it's wrong"; "Uh one thing that we learned is that actually writing the skill was very easy… But the hard part was how to run these skills at scale." ## Vocabulary & Recurring Phrases - **Repeated domain vocabulary**: "code review" (dozens of times), "quality to cost ratio," "observability," "agent trajectory," "address rate / addressal rate," "generators," "inner loop / outer loop." - Ameya repeats **"basically"** as a simplification marker: "Basically, it was a single prompt," "So basically when a U review comment is made," "we basically do a general purpose" review, "teams could basically define their own custom agent." - Will uses **casual metaphors/jargon**: "cavitation of an agent," "fix 100 nits on a pull request," "slop." ## Tone & Register - **Conversational, informal register** despite technical content — contractions, "you know," rhetorical questions ("are we going to kill the outer loop?"), and direct audience address ("I'll let your imagination go there"). - Will's closing uses a **reassuring, forward-looking tone**: "we still are going to have an outer loop. It's just going to look a little different." - Ameya's delivery includes **self-corrections mid-sentence**, e.g., "which generator to choose" phrasing jumbles ("to decide whether to go which generator to choose"), and "what do you say?" as a search-for-words moment — suggesting some improvisation. ## Uncertainty Notes - Only Will's final section and Ameya's section were delivered; evidence of Will's opening style vs. closing style differences (e.g., more structured early, more speculative later) is based on limited segments per speaker. - The transcript omits slides/visuals, so references like "you'll notice that we have our code review surface areas" and "As you can see" indicate visual aids that cannot be evaluated here. # Observation Record: Building uReview, Uber’s Multi-Agent Code Review Engine ## Metadata - **Speakers:** Will (Will Bond) and Ameya (Ameya Ketkar), per title; speaker identification in transcript is explicit ("My name is Will", "I'm going to hand it off to Ameya", "I'll give the mic back to Will"). - **Topic:** uReview, Uber's in-house automated/multi-agent code review system. --- ## Section 1: Context & Motivation — Will ### Org Scale (as stated) - Thousands of engineers, hundreds of teams, 12 sites, six language-specific monorepos. ### Problem: Code review bottleneck - PR volume and size growing over past 24 months. - **First-time-to-review metric:** ~3 hours in 2024 → 9 hours in 2026. - Will's claim: "code review is now the bottleneck." ### Why build in-house (constraints cited) - **Phabricator dependency:** currently on Phabricator, migrating to GitHub; most industry tools lack Phabricator support. - **Consistent inner-loop experience:** agents should get the same code review, rules as humans (referencing a prior talk on agentic SDLC by Uday and Adam). - **Decentralization:** hundreds of teams make centralized rule/customization management infeasible; need to plug into existing team ownership systems. - **Risk/complexity-aware review:** not all code gets the same review; volume requires factoring in risk profile and complexity. - **Reliability:** security and compliance reviews must run across everything; can't rely on teams voluntarily running them. ### Architecture overview (Will) - Surface areas: GitHub, Phabricator, agent loop → **uReview service** (routes requests and user feedback). - **Generators** tuned for different performance/cost tradeoffs; third-party review system plugins for benchmarking. - **Post-processing:** rate, categorize, filter, deduplicate comments — Will notes AI reviews can generate high comment volume/duplication; goal is high-confidence, actionable comments only. - Feedback and evaluation loop included in system. --- ## Section 2: Observability & Evaluation — Ameya ### Humble beginnings - Single prompt for per-file logic checks, one simple thorough-review agent, a dispatcher choosing generators. - Surface-level observability: cost, NPS survey, Google Forms, Slack support. - Result: "quality to cost ratio was all over the place" (goal: top-left quadrant). ### Evolution of data collection - **Reply sentiment classification** (positive/negative, categorized) → surfaced bug/issue classes that could be fixed → moved many PRs to high quality-to-cost ratio. - Still insufficient; added: - **Address rate:** whether developers actually address uReview comments. - **Runtime profile / agent trajectory:** tool calls and reasoning process, used to tune runtime for fast, high-quality, low-cost results. ### Key learnings (Ameya) - "The model doesn't know that it's wrong" — it's confidently certain; needs **team-specific guidance** (style guides, patterns, anti-patterns) baked into the agent. - Need **guardrails**: tell the agent what *not* to waste turns on; review must complete in a time span; wasted effort degrades quality. --- ## Section 3: Customizations — Ameya ### Review stack (increasing sophistication) 1. Single-file and multi-file reviewers. 2. General-purpose per-file logic bug review. 3. Deep multi-file review with monorepo-specific anti-patterns/style guides. 4. **AI linters:** few-shot systems giving developers deterministic context to run mechanical/systematic rule checks. 5. **Custom agents:** teams define their own agent, link knowledge bases and past PRs, attach review skills. ### Implementation challenges (stated) - Piggybacked on Uber's **ownership model** for logical team rollout. - **Co-located customizations** next to code so developers update them easily. - **Deterministic routing** deciding team → review type → model → generators. - **Surfaced observability back to teams** (trajectories, addressal rate, sentiment) so teams see rule reception and update; bubbled up to platform contributors. ### Learning - Writing skills was easy — teams asked Claude to generate a skill from past PR reviews. - Hard part: running skills **at scale with consistent quality and low cost**, requiring iteration from both uReview team and each team. ### Results (as claimed) - ~25,000 comments/week; 10% get feedback; only 4% of PRs get negative feedback. - Overall addressal rate ~67%; ~three-quarters of high-severity issues addressed. - Versus naive implementation: **costs down 60%, quality/accuracy up ~70%**. --- ## Section 4: Inner vs. Outer Loop — Will ### Trajectory stated - Agentic SDLC → engineers less involved in authoring; humans still approve now, but Will predicts "a percentage of our code landing automatically" soon; parts of industry already moving there. - Tuning per audience: interfaces (intuitive); **accuracy must rise for the inner loop** — otherwise "cavitation," where an agent fixes something, gets another review, and churns on low-quality comments. - Agents will fix 100 nits happily; engineers get frustrated doing so. ### Feedback concern - Much of quality came from human feedback tuning prompts/agents. - As humans leave the loop, question arises: "are we going to kill the outer loop?" Will explicitly leaves quality degradation/slop as an open implication ("I'll let your imagination go there"). - **Position:** rather than killing the outer loop, they believe the industry is coalescing on **expanding it** — moving human responsibility up a layer from implementation details to **architecture, domain expertise, and product thinking**. --- ## Qualifications & Open Tensions (preserved) - Ameya qualifies early results: quality-to-cost improvement was achieved but "we still felt this was not enough" at intermediate stages. - Negative feedback figure ("only 4%") is Ameya's characterization; smallness is presented as evidence of value. - Will's future claims (automatic approvals, outer-loop expansion) are explicitly predictive/belief-based ("I think that we believe"), not settled outcomes. - Quality degradation risk from removing human feedback is raised but left unresolved by the speakers. # Speaker Attribution & Provenance Record ## Video **Title:** Building uReview, Uber's Multi-Agent Code Review Engine — Will Bond & Ameya Ketkar, Uber **Video ID:** `01a15ca7-9e8c-75d0-b106-b1ed87a8dbf1` ## Speakers & Roles | Speaker | Role | Identification basis | |---|---|---| | **Will** (Will Bond, per title) | **Co-presenter / Creator-side speaker** — Uber engineer | Self-introduction: "My name is Will and... my teammate Amir and I work at Uber" | | **Ameya** (Ameya Ketkar, per title) | **Co-presenter / Creator-side speaker** — Uber engineer, Will's teammate | Introduced by hand-off: "I'm going to hand it off to Ameya" | > Note: The transcript records Will introducing his teammate as **"Amir,"** while the video title names **Ameya Ketkar**. This discrepancy is preserved as-is; both names appear in the source. ### Speaking segments - **Will:** Opening, context on Uber's engineering org, motivations for in-house build, uReview architecture overview; final section on inner vs. outer loop. - **Ameya (transcribed as "Amir" in intro):** Focus areas on observability/evaluation, customizations, results metrics. ## Referenced Sources & Third-Party Claims - **Prior talk (same event):** "If you were at the previous talk, you saw Uday and Adam talking about the agentic SDLC" — referenced, not otherwise described. - **Third-party tools/systems referenced:** - **Phabricator** (transcribed "Fabricator") — Uber's current review tool, migrating to **GitHub** - **Claude** — cited by teams as a tool to generate review skills ("asking Claude to write one") - **Google Forms, Slack** — used for early feedback collection (NPS survey, support) - Third-party code review systems — uReview "has the ability to plug into" them for comparison - **Internal Uber systems:** uReview, team ownership model, six language-specific monorepos. ## Quotable Claims (attributed) - Will: "code review is now the bottleneck that we are running into" (first-time-to-review grew from 3 hours in 2024 to 9 hours in 2026). - Ameya: "the model doesn't know that it's wrong. It always confidently says 100% sure." - Ameya (results): ~25,000 comments/week; 10% receive feedback; 4% of PRs get negative feedback; ~67% addressal rate; costs down 60%; accuracy up ~70% — all **speaker-reported figures**, unverified. ## Promotional Segments - None identified. No product promotion, sponsorship, or call-to-action present in the transcript. ## Comment Availability - Not indicated in transcript or metadata; **unknown**. ## Uncertainty Notes - Speaker-name discrepancy ("Amir" vs. title's "Ameya Ketkar") noted above. - All metrics are speaker claims without cited measurement sources. \>\> All right, hello everyone. My name is Will and uh I'm here to talk to you about automated code review. Uh my teammate Amir and I work at Uber and we're going to be walking through U Review, a system that Uber has built uh to help increase the velocity of our software engineering teams. Um for a little bit of context about what software engineering org at Uber looks like, we have thousands of software engineers who work across hundreds of teams uh located across 12 different sites and uh they work in primarily one of six language-specific monorepos. As many of you have probably noticed over the past 24 months, the volume of PRs, the size of PRs has been growing. One of the ways that that's been exposed to us has been through uh the metric that we track of the first time to review. 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 uh in addition to all of the volume changes. So, in short, code review is now the bottleneck that we are running into. Um specifically around automated code review, uh there are there are various options available in the industry, uh but Uber spent the time to invest in building an in-house solution due to some of the constraints that we have. One of those is uh we currently use Fabricator and have for a long time and are in the process of migrating to GitHub. Uh most of the solutions do not provide support for Fabricator. Um in addition, if you were at the previous talk, you saw Uday and Adam talking about the agentic SDLC. A big part of what we want to do is bring a consistent code review experience to the inner loop so that our agents are getting the same code review, the same rules, everything applied as our humans do. With hundreds of teams across the company, we can't have centralized management of our code reviews, our customizations, and our rules, and even the knowledge that goes into those code reviews. We need to distribute that. So, we have a need for plugging into existing team ownership system rather than trying to replicate that externally. Uh finally, with the volume of code reviews that we perform, we need the ability to take factors like the risk profile and the complexity of a code change and factor that in when deciding how we're going to run a code review. Not all code gets the exact same review. And then finally, consistency. We need to make sure that we have security and compliance reviews run across everything. We can't rely on teams hoping to run the skill the code review skill that happens. We need reliability there. With all that said, I wanted to give you an overview of the architecture of what you review looks like. We'll talk about a couple of the big pieces, and then we're going to dive into a few focus areas. At the top, you'll notice that we have our code review surface areas, GitHub, Fabricator, and the agent loop. These all feed into you review service. These This takes in requests for reviews. It brings in feedback from users, and it routes it. We have a number of different generators. Now, these generators are tuned for different performance and cost avenues. There are We also have the ability to plug into third-party code review systems so that we can compare ourselves to what's available more broadly. Finally, with all these different generators, we might be might be duplicating comments, and we can actually create quite a high volume of comments. If you've ever used AI to to run a code review, you've probably seen that. So, we run through a number of steps in the post-processing where we both rate, categorize, filter, and deduplicate comments so that our engineers get only the highest confidence comments that are actionable for them to work on. You'll also notice along the bottom we talk a little bit about feedback in our evaluation. But, with this context of the overall system, I'm now going to hand it off to Ameya to dive into our first focus area. \>\> Hello. Hello, everyone. So, I will be talking about how we evolve U review with observability and evaluation. So, U review had a very humble beginning. Basically, it was a single prompt that you should do logic checks per file, a simple agent which used to do thorough review. And we had a dispatcher to decide whether to go which generator to choose. Even what we used to collect as observability was very surface-level. We used to collect cost. We used to run an NPS survey, have Google Forms being filled, Slack support. And with all of this, we saw that our quality to cost ratio was like all over the place. Like, our goal is to be in the second quadrant, that is the top left quadrant, but you can see we were all over the place. Then what we did is that we started collecting more data. So, we started collecting the sentiments of the replies that were made to the U review that the U review uh call you know, the U review agent got from the developers. So, we categorized them into positive, negative. We classified them into various categories, and we found a bunch a lot of classes of bugs and issues that we could actually solve. And with that, we improved the system, and we were able to move a large number of PRs to a high quality to cost ratio. Um but, we still felt that this was not enough. We need to know more of how the review is done. So we started tracking things like address rate. So basically when a U review comment is made, does the developer go and actually address the comment? We started tracking that. And then we also started doing more like a runtime profile, which is like the agent trajectory, which told us why the agent is doing what it what it did. We get to know what tools calls it made. We get to know what thinking process it had. And then with that insight, we were able to actually tune our runtime, tune our performance such that the agent could very quickly give us high-quality results at a low cost. One of the biggest learnings in this process was like the model doesn't know that it's wrong. It always confidently says 100% sure that yeah, this is the review for your code. Go ahead. But we saw that no, it actually needs a lot of guidance from the teams because each team has its own style guide, its own patterns or like anti-patterns that they want to look for. So that all should be like baked into the agent. And we also realized that we need to have guardrails for the agent. So we need to tell the agent what not to waste turns doing. Like code review is something that has to happen in like a specific time span. And then if it starts spending time doing things that it should not be doing, uh leads to a bad quality code review. Uh second focus area for U review has been nations. We We went very deep on team customizations because as we'll presented that we have hundreds of teams and everyone has like their own way or their own thing for code review. So our review stack is pretty straightforward. We have single-file reviewers and multi-file reviewers. Uh, we basically do a general purpose "Hey, find me all logic bugs per file" uh, kind of a review. And uh, then we also do a deep review because we have like six mono repos. So, all these mono repos have their own anti-pattern style guides and all baked into this agent review which does have a nice multi-file review. But, then we extended it further uh, basically to AI linters. These are basically few shot uh, AI problem uh, or like a few shots uh, system where uh, developers can basically kind of deterministically get more context and then run rules with that context and like a file and find some uh, systematic and mechanical issues. And finally uh, the most powerful thing is the custom agent uh, where the teams could basically define their own custom agent, link it to like a knowledge base, uh, link it to their past PRs, have like a skill to do the review, and so on. But, uh, all of this was not simple because we had to actually uh, piggyback on our uh, ownership model which is at Uber uh, so that we can like very logically roll out to all the teams. Uh, we had to basically do a uh, what do you say? Co-locate the customizations next to where the developers write their code so that they can like quickly uh, keep updating these customizations. We had to implement a smart deterministic uh, routing so that we could route which team gets what kind of review with which model, what kind of generators, and so on. And finally uh, the hard thing was like we had to actually surface all of this observability that I talked before, like the agent trajectory, addressal rate, uh, sentiment analysis back to the teams. So, so that the teams could actually understand that "Oh, I wrote this rule, but maybe not a lot of developers are liking it in my team, so let me go and update it." And then we had to give Bubble up that kind of observability to all the people who are contributing to the platform. Uh one thing that we learned is that actually writing the skill was very easy. Like teams just very quickly wrote a skill by asking Claude to write one, go over my previous PR reviews and write me a skill. But the hard part was how to run these skills at scale with consistent quality and low cost. And that required a lot of iterations not only from the U-Review team side, but also like for each team who was trying to write these rules. Uh in results, we basically uh see that, you know, uh U-Review does like around 25,000 comments a week. And uh we get 10% of them actually get some feedback. And only 4% of the PRs actually get some negative feedback. Uh we also saw that um the overall addressal rate was uh around 67% and almost three quarters of the high severity issues uh were usually addressed by the developers, which shows that U-Review actually adds some value to the entire development life cycle. And then uh with all the observability and uh evals that I showed that I went through, we saw that against like a very naive implementation, our costs were down by 60% and our quality and our accuracy was up by uh around 70%. Uh for a last focus area, I'll give the mic back to Will and he will go over the inner versus outer loop. \>\> Awesome. So, now that we've talked about uh some of the details of actually implementing high-quality reviews, it kind of brings us to the last area, which is where we start talking about where things are going, right? With moving to the Agentech SDLC, we're moving software into a model where engineers are interacting with the code less. They're often times not as involved in authoring the code. Uh currently, we still have uh humans approving the code, uh but we see a a short path in the near future to a percentage of our code landing automatically, having automatic approvals, right? The various parts of the industry are already moving there. Um Part of the way along the process was figuring out by having our single code review platform, what did we need to tune for the various audiences that are actually getting these code reviews? Um you know, the interface, that's one area that's sort of intuitive there. Uh one thing that might be less intuitive is around accuracy. Uh with the inner loop, our accuracy needs actually need to go up, or else we can result in uh dealing with cavitation of an agent where it fixes something, goes back, gets another code review, and has to kind of like fix backwards because the quality of the comment was low. Um The one of the other interesting things is agents are more than happy to go through and fix 100 nits on a pull request where your engineers really get frustrated in situations like that. Um but probably the most interesting aspect of this transition is the feedback. As you can see, quite a bit of what went into getting high-quality code reviews at Uber was bringing the human feedback into the system and using that to figure out how to tune our prompts, how to tune our agents. Uh and so as we move to a model where humans are less in the loop, where software engineering is moving to an agentic model, we're effectively going to a place where we're starting to talk about are we going to kill the outer loop? Is the human engineer not going to be involved in the code review. Some people are already here. Now, with the feedback taken into consideration, you start wondering, all right, what could this result in, right? I'll let your imagination go there in terms of quality degradation, slop, and so forth. But, 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. Rather than removing humans from the code review process, we are moving their responsibilities up a layer. Rather than them dealing with the details of the implementation, the agent is great at writing the software. The agent is getting much, much better at reviewing the software as a human would. But now, as software engineers, we still are going to have an outer loop. It's just going to look a little different. Instead of you worrying about the optimization of the performance and the API compatibility, you're going to be thinking more about architecture in your code reviews. You're going to have time to focus on the domain expertise that you have and product thinking. So, we believe that as we adopt this automated uh code review, this is going to be the result of how our engineers are interacting with the system and guiding it. And that's it. Thank you so much for coming. Thanks.