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

0:01 [music] >> 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

0:24 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

0:35 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

0:47 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.

0:58 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

1:09 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

1:20 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

1:31 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

1:40 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

1:52 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.

2:04 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

2:14 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.

2:25 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

2:38 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

2:48 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

2:58 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.

3:07 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

3:20 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

3:33 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.

3:43 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

3:53 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

4:04 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

4:14 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.

4:25 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

4:37 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.

4:48 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

4:58 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

5:08 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

5:22 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

5:32 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

5:45 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

5:55 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

6:07 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

6:15 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

6:27 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

6:39 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

6:50 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

7:03 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

7:14 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

7:25 nations. We We went very deep on team customizations because as we'll presented that we have hundreds of teams and everyone has like

7:33 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.

7:43 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

7:54 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

8:04 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

8:16 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

8:29 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.

8:41 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.

8:54 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

9:04 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.

9:16 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

9:27 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

9:37 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

9:46 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

9:57 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

10:09 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:21 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

10:33 67% and almost three quarters of the high severity issues uh were usually addressed by the developers, which shows that U-Review

10:42 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

10:53 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

11:05 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

11:19 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

11:31 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,

11:43 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.

11:56 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

12:07 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,

12:20 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

12:29 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

12:39 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

12:53 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

13:06 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,

13:19 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.

13:29 Some people are already here. Now, with the feedback taken into consideration, you start wondering, all right,

13:37 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

13:48 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

14:01 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

14:11 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

14:20 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

14:31 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

14:43 guiding it. And that's it. Thank you so much for coming. Thanks.