Most code review time goes to things a linter should catch and nobody says the thing that actually matters: “I don’t understand why this approach was chosen.” Fix the ratio, not the process.

Automate the stuff that isn’t a judgment call

Formatting, import order, unused variables, line length — none of that belongs in a human review. If a reviewer is typing “missing semicolon” as a PR comment, that’s a CI failure you haven’t configured yet.

# runs on every push, blocks merge on failure
npx eslint . --max-warnings 0
npx prettier --check .

Same for type errors, basic security lint (npm audit, gosec, whatever your language has), and test coverage thresholds if you use them. None of it needs a person. Every minute a reviewer spends on it is a minute not spent on the one thing a linter can’t do: judging whether the change is right.

What to actually comment on

• Correctness. Does this do what it claims? Walk the logic, not just the diff coloring.
• Blast radius. Does this touch something shared — an auth check, a migration, a rate limiter — where a mistake affects more than this one feature?
• The approach, before the implementation. If the whole approach is wrong, “add a null check here” is a waste of everyone’s time. Say “I think this should be a queue, not a cron job” as early as possible, ideally before the PR even exists.
• Missing tests for the actual risk. Not “add a test” as a reflex — “this branch where the payment fails halfway through has no test, and that’s the exact case that’ll happen in production.”

What to let go

• Naming preferences that aren’t actually confusing. userData vs userInfo is not worth a comment.
• Style the linter didn’t catch because it’s a genuine style choice, not a bug.
• Anything you’d change but that doesn’t change behavior or readability for the next person. Approve it. Nitpick in a follow-up if it really bugs you.

If you comment on everything, the important comment drowns in the pile, and the author starts treating every comment as equally optional.

The timing problem

A review that sits for two days kills momentum harder than a bad review. The author context-switches, forgets the decisions they made, and the eventual fix takes longer than the original PR. Set an actual team norm: reviews get a first pass within a few hours, not “whenever I get to it.” If your team is small, a Slack ping when a PR is ready beats waiting for someone to check the queue.

Size matters more than most review checklists

A 40-line PR gets a real review. A 900-line PR gets a rubber stamp, because nobody has the attention span to actually trace 900 lines of logic changes in one sitting, and everyone knows it. If PRs are consistently huge, that’s not a review problem, it’s a “the work wasn’t broken down” problem — and no review checklist fixes a PR that should have been three PRs.

The one-line test for whether review is working

Ask: in the last month, did a review catch a real bug before it shipped? If the honest answer is “no, it just catches style stuff,” your review process is theater. Redirect the automated checks to catch the style stuff, and free the humans to actually read the logic.