Code review works well at small scale because everyone knows everyone, everyone knows the codebase, and the review is a conversation between people who share context. At five engineers, code review is a formality — you open a PR, someone reviews it, you merge. At fifty engineers, the model breaks down. Not everyone knows the codebase, so reviews are slower because the reviewer has to learn the context. Not everyone knows each other, so reviews are more formal and less collaborative, which means less knowledge transfer. And the volume of PRs overwhelms the reviewers, who are also trying to write their own code, which means PRs sit waiting for review and feature velocity drops.

The scaling problem is fundamentally a context problem: at small scale, context is shared implicitly; at large scale, context has to be made explicit. The system we built is about making context explicit — in the PR description, in the code comments, in the review process itself — so that a reviewer who doesn't know the author and doesn't know the codebase can still review effectively. That explicit context is overhead, but it's overhead that makes the review faster rather than slower, because the alternative is the reviewer spending hours reconstructing the context that the author already had.

The system has three components: structured PR descriptions, reviewer assignment, and review SLAs. Structured PR descriptions follow a template: what does this change do, why does it need to change, how was it tested, what should the reviewer focus on, and are there any known issues or trade-offs. The template sounds bureaucratic, but it's actually faster than unstructured descriptions because the author doesn't have to decide what to include — the template tells them — and the reviewer doesn't have to hunt for the information — it's in the same place every time. The "what should the reviewer focus on" section is the most valuable, because it tells the reviewer where to spend their attention, which means the review is deeper on the important parts rather than shallow everywhere.

Reviewer assignment is about matching the PR to the right reviewer, which at scale means using CODEOWNERS files that map code paths to teams or individuals. CODEOWNERS ensures that the review goes to someone with context on the area, rather than to whoever is available, and it distributes the review load across the team rather than concentrating it on the people who are too responsive. The trade-off is that CODEOWNERS can create silos — if the same person always reviews the same area, they become a bottleneck and a single point of failure — so we pair CODEOWNERS with a rotation that ensures each area has at least two potential reviewers, and that junior engineers are paired with seniors for knowledge transfer.

Review SLAs — "we review PRs within 24 hours" — are the mechanism that keeps velocity high. Without an SLA, PRs sit in the review queue because reviewing is less urgent than writing, and the queue grows until it becomes a bottleneck. With an SLA, reviewing is a commitment, not a nice-to-have, and the team organizes around it. The SLA doesn't mean every PR is reviewed in 24 hours — some PRs are large and need more time — but it means the first response (a comment, a review, an "I'll get to this tomorrow") happens within 24 hours, which keeps the author unblocked and the queue moving.

The biggest lesson was that review quality is a function of PR size, not reviewer effort. Large PRs get shallow reviews because the reviewer can't hold the entire change in their head, and the review becomes a scan for obvious issues rather than a deep engagement with the design. Small PRs get deep reviews because the reviewer can understand the change completely, and the review becomes a discussion of trade-offs and alternatives. We pushed the team toward smaller PRs — "if your PR is more than 400 lines, can it be split?" — and the review quality improved dramatically, because the reviewers had the cognitive capacity to engage deeply with each change.

The other lesson was that review culture matters as much as review process. A culture where reviews are adversarial — "I'm going to find everything wrong with your code" — produces defensive authors and reluctant reviewers. A culture where reviews are collaborative — "we're working together to make this code better" — produces open authors and engaged reviewers. The shift from adversarial to collaborative is mostly about language: asking questions rather than making demands, suggesting alternatives rather than mandating changes, and acknowledging good work rather than only flagging problems. That cultural shift is harder to implement than a process change, but it's the change that has the largest impact on the quality and speed of reviews.