Building uReview, Uber’s Multi-Agent Code Review Engine — Will Bond & Ameya Ketkar, Uber

Three hours to review in 2024, nine in 2026

00:12All right. Hello everyone. My name is Will and uh I'm here to talk to you about automated code review. Uh my teammate Amea and I work at Uber and we're going to be walking through Ureview a system that Uber has built uh to help increase the velocity of our software engineering teams.

00:33Um for a little bit of context about what software engineering or 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 monor repos.

00:50As 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 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 three hours.

01:11Now in 2026, that has grown to nine 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 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

01:43provide support for fabricator um in addition if you were at the previous talk you saw U and Adam talking about the agentic SDLC See, a big part of what we want to do is bring a consistent code review experience to the inner loop so

Why Uber built this instead of buying it

01:58that 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.

02:14We need to distribute that. So we have a need for uh plugging into an 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.

02:39Not 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.

02:47We need reliability there. With all that said, I wanted to give you an overview of the architecture of what Ureview 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.

03:07GitHub fabricator and the agent loop. These all feed into Ureview 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 uh avenues.

03:31There are we also have the ability to plug into third-party uh code review systems so that we can compare ourselves to uh what's available more broadly. Finally, with all these different generators, we might be might be duplicating comments and we can

The architecture, and deduplicating comment volume

03:48actually 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 dduplicate comments so that our engineers get only the highest confidence comments that are actionable for them to work on.

04:06You'll also notice along the bottom we talk a little bit about feedback and our evaluation. But with this context of the overall system, I'm now going to hand it off to Amea to dive into our first focus area. Hello. Hello everyone. So I will be talking about how we evolved Ureview uh with observability and evaluation.

04:33So Ureview had a very humble beginning. Uh basically it was a single prompt that used to 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.

Humble beginnings, and cost as the only metric

04:47Uh 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.

04:56Like 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. Um then what we did is that we started collecting more uh data. So we started collecting the sentiments of the replies that were made to the Ureview uh that the Ureview uh you know the Ureview agent got from the developers.

05:20So we categorized them into positive, negative. We classified them into uh various categories and we found a bunch a lot of classes of bugs and issues that

Sentiment, addressal rate, agent trajectory

05:37we could actually solve and uh 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. Uh we need to know more of how the review is done.

05:54So we started tracking things like addressal rate. So basically when a Ureview comment is made does the developer go and actually address the comment. Uh we started tracking that and then we also started doing more like a runtime profile which is like the agent trajectory.

06:10Uh which told us why the agent is doing what it what it did. Uh we get to know what tool 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 uh very quickly give us uh high quality results at a low cost.

06:28Uh one of

The model never knows that it is wrong

06:35the 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 uh patterns or like antiatterns that they want to look for.

06:51So that all should be like baked into the agent and we also realize that we need to have guard rails 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 uh quality code review.

07:13Uh second focus area for U review has beenations.

Letting hundreds of teams customize reviews

07:26We uh we went very deep on team customizations because as will presented that we have hundreds of teams and everyone has like their own way or their own thing for code review. Uh so our review stack is pretty straightforward. We have single file reviewers and multi-file reviewers.

07:39Uh 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 monor repos. So all these mono repos have their own antiattern style guides and all baked into this agent review which does a nice multifile review.

07:54But then we extended it further uh basically to AI linters. These are basically few short uh AI prompt or like a few short 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.

08:22And 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 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.

08:53uh we had to basically do a uh what do you say colllocate 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.

09:14And 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 uh all the people who are contributing to the platform.

09:37Uh, 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.

10:02And that required a lot of iterations not only from the Ureview team side but also like for each team who was trying to

Results: 25,000 comments a week

10:10write these rules. uh in results we basically uh see that you know a 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 around 67% and almost three quarters of the high severity issues uh were usually addressed by the developers which shows that you review actually add some value to the entire development life cycle and then uh with all the observability and

10:49uh evals that I show 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 around 70%. Um, for our last focus area, I'll give the mic back to Will and he will go over the inner versus outer loop.

Inner loop versus outer loop

11:11Awesome. 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 agentic SDLC or moving software into a model where engineers are interacting with the code less.

11:34They're oftentimes not as involved in authoring the code. Uh currently we still have 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 there.

11:52Various 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?

12:10Um, 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.

12:32Um the one of the other interesting things is agents are more than happy to go through and fix a 100 knits on a poll request where your engineers really get frustrated in situations like that. Um, but probably the most interesting aspect of this transition is the feedback.

12:47As 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?

13:23Is 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 coales 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

Expanding the outer loop rather than killing it

14:03rather 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.

14:14It'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.

14:27So 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.