No One Knows the Ideal Code Review Process

Most engineering teams live by a familiar loop: code, PR, review, merge, repeat. But what if the review process itself needs a review? One question keeps popping up: should you have two reviewers per PR?

For some teams, it’s standard practice. For others, it’s overkill. The reality is that no one really knows the universally “correct” number of reviewers per PR. But there are a few perspectives worth considering:

The Good Stuff (Pros):

• Better Code Quality: Two reviewers = double the chances of catching bugs, weird logic, or sketchy architecture choices.
• Knowledge Sharing: More reviewers means more eyeballs on code changes. Everyone learns a bit more, especially junior devs.
• Balanced Feedback: Two reviewers help balance out biases. One person might miss something, but the other can catch it.

The Not-So-Good Stuff (Cons):

• Slower Merges: Waiting on that extra thumbs-up? Yeah, it can feel like forever when you just want your PR merged.
• Review Overload: Redundant comments. Endless back-and-forths. It’s like herding cats.
• Burnout: Constantly reviewing PRs with multiple people gets old fast. Especially for smaller teams.

Each of these points has merit, but the answer isn’t universal.

Research indicates that involving two reviewers per pull request (PR) is a common practice across various organizations. For instance, studies have found that at AMD, the median number of reviewers is two, and similar patterns are observed at Google Chrome and Android projects.

However, the optimal number of reviewers can vary depending on the size and complexity of the codebase, as well as the team’s workflow.

At Google, fewer than 25% of changes have more than one reviewer, with over 90% having at most five reviewers and a median reviewer count of one. Larger changes tend to have more reviewers on average, but even very large changes typically require fewer than two reviewers.

Other factors, like review frequency, review speed, and team size, also play a role in shaping this decision. Here’s a quick look at how these impact PR review practices:

• Review Frequency: Some teams opt for daily PR reviews, while others do them weekly. More frequent reviews could mean involving multiple reviewers, but it also ensures consistency in code quality.
• Review Speed: In fast-paced teams, PRs need to be reviewed quickly. This often leads to a single reviewer keeping things moving. Larger teams with more resources can afford to slow down and involve two reviewers.
• Team Size: Smaller teams may lean towards a single reviewer due to limited personnel, whereas larger teams with more developers can afford the luxury of multiple reviewers.

In certain situations, having two reviewers per PR works really well. For high-impact changes, like modifying core libraries or addressing security issues, the benefits of extra scrutiny are clear. More eyes mean fewer chances of bugs slipping into production.

But for routine changes or small bug fixes, having two reviewers often feels like overkill. The process slows down without adding much value.

You can think of this like content moderation on social media. In the early days, it was a simpler process with one layer of review. As platforms scaled, they added multiple layers to maintain quality, but that came at the cost of speed and efficiency.

The same goes for code reviews. As your codebase grows, the complexity of the changes increases, justifying the need for a layered review system. However, this comes with its own trade-offs in speed and efficiency.

The Right Context Matters

Ultimately, the decision depends on the team size, the type of product, and the level of risk involved.

At smaller startups, where speed is crucial, a single reviewer might make more sense. In larger companies, especially those handling sensitive data or massive codebases, multiple reviewers could be the right call.

The ideal solution might be a hybrid approach:

• Critical PRs: Two reviewers.
• Minor changes: One reviewer.

With AI tools improving code review processes, the definition of a "critical" PR might evolve over time. Tools like greptile are already helping teams spot issues before a human reviewer even looks at the code. As AI gets better, what’s considered “critical” could change. Routine changes might be flagged for review just as easily as high-priority ones, making the process smoother and faster.

Final thoughts

Every team is different. What works for one company might not work for another. It’s important to experiment, iterate, and adapt based on your team’s needs and pain points.