Every engineering team likes to believe it takes code review seriously. The reality is messier. Open any pull request with twenty comments on it and you'll usually find two different things tangled together: a few observations that genuinely made the code better, and a pile of remarks that just slowed things down. Both look like engagement. Only one of them is review.

Comment count is a poor proxy for review quality, but teams treat it as one anyway. A PR with lots of comments feels rigorous. One approved in two minutes feels lax. That's how teams end up with reviewers nitpicking variable names for an hour while a broken auth check sails through untouched.

What noise looks like

Noise is feedback that costs a contributor's time without changing whether the code works, stays maintainable, or fails safely in production. It shows up as formatting preferences a linter should already enforce, renaming something that was already clear, or relitigating a decision that was genuinely a coin flip. Most of it comes from reviewers trying to be helpful. The cost is real anyway: every comment is a context switch, a delay in shipping, and a small tax on the reviewer's credibility, since a real issue can get lost among ten trivial ones. Over time, noise also trains authors to skim review feedback instead of reading it closely, which is exactly when a real bug slips through.

What thoroughness looks like

Thoroughness is feedback that changes an outcome. It catches the missing null check on an untested edge case, questions a query that will do a full table scan once data grows, flags a race condition that only appears when two requests land at once, or asks whether a new endpoint has the same authorization check as the similar one three files over. It also asks slower questions: does this match the ticket's intent, does the error handling actually handle the error or just swallow it.

The real test isn't tone or comment count, it's whether a comment would have mattered had the code shipped exactly as written. If skipping it wouldn't have changed correctness, security, performance, or maintainability, it was noise, however reasonable it sounded.

Why teams drift toward noise

Noise is easier to produce. Spotting a style inconsistency takes seconds and no context. Spotting a race condition takes real effort and real understanding of the system. Under time pressure, which is most of the time, reviewers gravitate toward comments that are fast to write and easy to defend, even when they don't move the needle. There's also a status dynamic: nitpicks are a low risk way to prove you read the diff. A wrong nitpick costs nothing; a missed bug caught later in an incident costs a lot more, so it's tempting to hedge with lots of small, safe comments instead of committing to the harder call of "I looked closely and I think it's sound."

Shifting the balance

Let tooling own anything mechanically checkable, so human attention isn't spent on what a linter already catches. Before leaving a comment, ask whether the code would actually behave differently if the author ignored it; if not, drop it or clearly mark it optional. Spend the saved time tracing logic against the code it touches and thinking through edges: empty input, concurrent access, the retry path, the second time this function runs instead of the first. And separate preference from correctness explicitly, so an author can tell at a glance which comments are blocking and which are just worth a skim.

None of this means style doesn't matter, it does, but that's a job for linters and style guides applied consistently, not a reviewer's judgment spent one PR at a time. A good review doesn't feel exhaustive. It feels precise: a few comments that clearly mattered, and an approval that means something.