I went back through three months of our team's pull request comments once, out of curiosity, and counted them by type. Over 60% were about formatting, naming conventions, or style preferences that a linter could have caught automatically. Fewer than 15% touched actual logic, edge cases, or architecture. That ratio told us our code review process was mostly theater — a lot of activity, not much protection against the bugs that actually cost us time later.

Step one: get style arguments out of the review entirely

This sounds almost too simple to mention, but it was the single highest-leverage change we made. We adopted Prettier and a strict ESLint config with pre-commit hooks, which meant a PR literally could not be opened with inconsistent formatting or common style violations — the tooling rejected it before a human ever had to comment on it. Every "can you add a space here" or "we use camelCase for this" comment disappeared from our review threads within a month, not because reviewers got more disciplined, but because the argument became structurally impossible to have. If your team is still debating tabs versus spaces in PR comments, that's not a code review culture problem, it's a missing pre-commit hook.

What we started asking reviewers to actually look for

Once style was off the table, we had to be explicit about what a review was actually supposed to catch, because "review the code" as an instruction is vague enough that everyone defaults to whatever's easiest to spot, which is usually surface-level stuff. We settled on four questions we ask reviewers to hold in mind, not as a rigid checklist to fill out, but as the actual point of the exercise:

What happens when this fails? Not the happy path — the network timeout, the null value, the empty array, the concurrent request
Does this change match how the rest of the codebase does similar things, or is it introducing a new pattern that should be a separate conversation first
Could I have written a simpler version of this that does the same thing
Is there a test that would have caught this if the logic were wrong, and if not, should there be

That first question alone changed the character of our reviews the most. "What happens when this fails" surfaced a real bug in a payment reconciliation script three weeks after we started asking it explicitly — a loop that assumed an API response would always include a `transactions` array, which worked in every test case and every demo, and would have thrown an unhandled exception the first time that endpoint returned an empty result during a genuinely quiet processing window.

The size of the PR matters more than reviewers admit

We used to let PRs grow organically until a feature felt "done," which meant reviewers regularly faced 800-line diffs touching a dozen files. Nobody reviews an 800-line diff carefully. You skim it, you approve it, and you tell yourself you'll catch anything important, and you mostly don't, because human attention doesn't scale linearly with diff size the way people pretend it does. We started actively pushing back on large PRs and asking authors to split work into smaller, independently reviewable chunks wherever the change genuinely allowed it. A PR under roughly 200 lines gets a meaningfully more careful review than a PR at 800 lines, not because reviewers are lazy, but because that's roughly the point where careful line-by-line reading stops being realistic for most people.

Approving with comments versus blocking: we got this wrong for a while

Early on, any reviewer comment, however minor, tended to block a merge until it was addressed, which trained people to either not comment on small things at all, or to hold PRs hostage over genuinely minor preferences. We now explicitly distinguish blocking issues — this will break in production, this has a real bug, this needs a test — from non-blocking suggestions, which get left as comments but don't prevent merging. That distinction had to be said out loud and modeled by senior engineers before it actually stuck; just changing the tooling's button labels didn't change the culture on its own.

What actually changed after all this

Our post-release bug rate, tracked as incidents traced back to a specific merged PR within 30 days, dropped by roughly a third over two quarters after we made these changes, and PR turnaround time got faster despite reviews being more substantive, because smaller PRs and automated style enforcement removed most of the friction that used to slow reviews down. Code review isn't inherently valuable just because it happens. It's valuable when reviewers are actually looking for the things that cost you later, and everything else is stripped away so that's what they have attention left to look for.