@@ · review culture @@

Nitpicks are killing your code review

Othman Shareef · June 30, 2026 · 6 min read

Ask developers what they dread about code review and the answer usually isn’t the hard feedback; it’s the twelve comments about naming conventions on a PR that fixes a race condition. A 300-comment Hacker News thread on review tone and another on making an AI review bot stop nitpicking say the quiet part: nits are the most common review comment and the least valuable one.

Why nits win by default

It’s an attention-economics problem, not a character flaw. Evaluating logic requires reconstructing the author’s mental model (expensive). Spotting a naming inconsistency requires a glance (free). Under time pressure, reviewers produce what’s producible, and on teams where “thorough review” is measured by comment count, nits become how diligence is performed. (That performance problem is its own disease; see our piece on review theatre.)

Automate the automatable, ruthlessly

Every style rule a human enforces in review is a tooling failure. Formatters (Prettier, gofmt, Black) end whitespace and layout debates; linters encode naming and idiom rules; CI enforces both before a reviewer ever looks. The rule of thumb: if two reasonable people could be told the answer by a config file, the config file should do the telling. What’s left for humans is the stuff that genuinely needs judgment.

Label what remains

For judgment-call nits, severity must travel with the comment. Conventional Comments does this with prefixes: nit: (take it or leave it), question: (I might be missing context), issue: (this blocks). The author triages at a glance instead of treating every comment as a demand. Two norms make it stick: a nit: can be declined without justification, and approval is given with nits outstanding (“approve, two optional nits”) rather than holding the merge hostage to preferences.

Watch the bot, too

AI reviewers inherit the nit bias: style observations are the easiest tokens to generate. The team behind one popular bot wrote up the fix: they had to deliberately engineer nitpicking out, because noisy comments trained developers to ignore the bot entirely, including its real catches. The same applies to humans: a reviewer known for nits gets skimmed.

What to do with the attention you save

The point of killing nits isn’t kinder reviews; it’s reallocated reviews. The attention that was going to naming goes to the questions that prevent incidents: is this correct at the edges, is this the right shape, what happens under failure. That’s the review your authors actually want, and the one worth structuring your passes around. Style should be table stakes settled by machines; judgment is the part worth a human’s signature.

Frequently asked questions

Are nitpicks ever worth leaving?

Yes, when they’re about clarity a future reader will pay for (a misleading name, a confusing structure), not personal preference. The discipline is labeling them non-blocking (nit:) and accepting the author may decline. If a “nit” must be fixed before merge, it isn’t a nit: say why it blocks.

What tone should review comments use?

Comment on the code, not the person; prefer questions over verdicts when intent is unclear (“was X considered here?”); give the reason, not just the instruction. Prefixes like nit:, question:, issue: (Conventional Comments) carry severity so the author doesn’t have to guess what blocks.

Our AI review bot is the biggest nitpicker. What now?

Tune or replace it. Teams that shipped AI reviewers found nitpicky output erodes trust in all the bot’s comments, including the good ones; one team wrote up how they specifically engineered their bot to stop nitpicking. A bot that comments rarely and correctly beats one that comments always.

← All posts