When you’re a team of five, code review is simple. Everyone knows the codebase, everyone knows each other, and the PR queue never gets that long. You review each other’s work, leave a few comments, approve, and merge. It works.

Then you grow. And somewhere around 10-15 engineers, the whole thing starts to buckle. PRs pile up. Review cycles stretch from hours to days. People start approving without really reading. New joiners don’t know who to ask for review, and senior engineers are drowning in review requests.

I’ve been through this transition at three different companies. Here’s what I’ve learned about making code review work at scale.

What Breaks First: Reviewer Assignment

The first thing that falls apart is figuring out who should review what. In a small team, it’s obvious — you review whatever comes up. In a larger team, you get a few failure modes:

The expert bottleneck. One or two people understand a particular subsystem deeply. Every PR touching that subsystem goes to them. They become permanent review bottlenecks, and nothing in their area moves quickly.

The rubber stamp. Someone who doesn’t really understand the code approves it because they were assigned and don’t want to hold things up. The review technically happened but provided no value.

The orphan PR. Nobody picks it up because it’s in an area between teams, or the assignee is busy, or it’s a large diff that nobody wants to deal with. It sits for days, the author gets frustrated, and eventually it’s either merged without proper review or abandoned.

The fix is a combination of CODEOWNERS files and rotation. GitHub’s CODEOWNERS feature lets you automatically assign reviewers based on which files are changed. This handles the “who should review this” question mechanically. But you also need a review rotation within teams, so the same person isn’t doing all the reviews. We’ve used round-robin assignment with good results.

What Breaks Second: PR Size

Large PRs are the enemy of good code review. Study after study shows that review quality drops dramatically as PR size increases. After about 400 lines of changed code, reviewers start skimming. After 1,000 lines, they’re mostly looking at the test results and hoping for the best.

This isn’t a discipline problem — it’s a cognitive load problem. Nobody can meaningfully review 2,000 lines of code in a single sitting. Pretending otherwise is a fiction that teams maintain because splitting PRs is annoying.

But you have to do it. My rule of thumb: if a PR is over 400 lines (excluding generated files and test fixtures), it should be split. Yes, this means more PRs. Yes, this means more review cycles. But each individual review is faster, higher quality, and more likely to catch issues.

Some practical approaches to splitting:

• Separate refactoring from feature work. If you need to restructure code before adding a feature, that’s two PRs.
• Separate data model changes from application logic. Migration + model changes in one PR, business logic in another.
• Use feature flags. Ship incomplete features behind flags in small increments rather than one massive PR.

What Breaks Third: Review Quality

At scale, you need to be explicit about what code review is for. Different teams have different expectations, and if you don’t align on this, reviews become a source of friction rather than value.

In my experience, effective code review focuses on:

1. Correctness. Does this code do what it’s supposed to do? Are there edge cases that aren’t handled?
2. Maintainability. Will someone be able to understand and modify this code in six months?
3. Architecture. Does this fit into the system’s design, or is it introducing patterns that will cause problems later?
4. Security. Are there obvious vulnerabilities? Input validation? Auth checks?

What code review is NOT for (at scale):

• Style. This should be handled by automated formatters and linters. If you’re arguing about semicolons in code review, something has gone wrong.
• Trivial naming. Unless a name is genuinely misleading, save it. Bikeshedding over variable names is the biggest waste of review time I’ve seen.

What Helps: Review SLAs

Set expectations for review turnaround time. We use 4 business hours for standard PRs and 1 hour for hotfixes. This isn’t a target — it’s a commitment. If you’re assigned a review, you respond within that window, even if the response is “I need more time to look at this, will review by EOD.”

The SLA does two things: it prevents the orphan PR problem, and it creates accountability. If reviews are consistently late, you can see it in the metrics and address it.

What Also Helps: Automated Checks

Every minute a human spends checking something a machine could check is wasted. Before a PR reaches a human reviewer, it should have passed:

• Tests (unit, integration, e2e as appropriate)
• Linting and formatting
• Type checking (if you’re using a typed language)
• Security scanning (dependency vulnerabilities, secret detection)
• Build verification

If any of these fail, the PR goes back to the author before a human sees it. This saves reviewers from spending time on PRs that aren’t ready.

The Culture Piece

The hardest part isn’t the process — it’s the culture. Code review works when people see it as a collaborative act, not an adversarial one. Reviewers should assume good intent. Authors should welcome feedback. Both sides should communicate clearly.

I’ve found that writing “why” in PR descriptions makes the biggest single difference. Not just “what changed” — why it changed, what alternatives were considered, what trade-offs were made. When a reviewer understands the author’s reasoning, the conversation is immediately more productive.

Good code review is a skill, and like any skill, it takes practice and intentional effort. But get it right, and it’s one of the highest-leverage activities an engineering team can invest in.