The Nit Was Never Optional

“This is a minor thing. Technically you should do it, but it won’t hugely impact things.” — Google, Engineering Practices, defining the “Nit:” label

Read that definition again. It’s one of the most widely-cited code-review standards telling reviewers how to flag a small issue: say the author should fix it — then, in the same breath, that they needn’t bother. “Technically you should do it, but…”

Every reviewer has written that comment. I’ve written it hundreds of times: nit, feel free to ignore. It’s a strange little contradiction — you spent the attention to notice the thing and the keystrokes to describe it, then apologised for asking. We’ve all made peace with it. The peace was economic, and the economics just changed.

BLUF

• The hedged nit is an accommodation, not a truth. We hedged small should-fix items because making the change was expensive — the author’s time, the review round-trip, the risk of stalling a good change over polish. The apology was never about whether the code should be better. It was about whether it was worth your effort to make it so.
• AI reprices that. When generating the fix is cheap and instant, the effort the hedge protected all but disappears — a nit you’d have waved through is just a fix you haven’t made yet. You still pay to check the fix is right; that cost stays, and the bottom tier gets rebuilt on it.
• So drop the hedge. Stop writing “nit, up to you.” If it’s worth noticing, it’s worth fixing — because fixing no longer costs what it cost when the rule was written.
• But don’t delete the severity levels — re-point them. The tiers conflate two questions, and AI only answers one. “Is it worth the cost to fix?” is now dead (everything is). “How much does this matter, and how hard must I check the fix is right?” is alive — because judging correctness never got cheap. And this only touches the Nit — the should-fix-but-small. Optional/Consider (“not strictly required”) hedges on merit, not cost, so cheap fixes leave it exactly where it was.

The optional nit is a contradiction we priced

Severity labels present as a quality signal. They’re really a triage signal. Google’s own guidance says the labels exist to “help authors prioritise the importance of various comments” — and its tiers spell out the triage: Nit (“technically you should… but won’t hugely impact things”), Optional/Consider (“may be a good idea, but it’s not strictly required”), FYI (“not in this CL”). My own review engine does the same thing — it tiers findings 🔴🟡🟢🔵, and the bottom tier is labelled, in as many words, “suggestions, not demands.” I built the hedge in on purpose.

Two of those tiers look alike and aren’t. A Nit is a should-fix — Google’s own “technically you should do it” — carrying an apology for the size of the request. Optional/Consider is a needn’t-fix: “may be a good idea, but it’s not strictly required.” The nit hedges on cost — worth doing, sorry to make you spend the effort. Optional/Consider hedges on merit — I’m not certain this is the right change, or it’s a matter of taste. That difference is the whole argument. Cheap fixes reprice the nit’s apology; they do nothing to what Optional/Consider is asking, because that was never a question about effort.

I taught this, too. My own book has a section titled “Severity is a communication tool”, and elsewhere: “That is triage. Not because the cold code is fine. Because attention is finite.” That’s the honest account of what severity is for — rationing a human’s finite effort so it lands on what matters. The “optional” tier is the part of the budget you’re telling the author they can skip.

Which means the optional nit was never a statement about the code. It was a statement about the author’s time.

The premise was expensive change

The standard says so, out loud. The reason to favour approval over polish, in Google’s words, is that a good change “shouldn’t be delayed for days or weeks because it isn’t ‘perfect,’” and that “if a reviewer makes it very difficult for any change to go in, then developers are disincentivized to make improvements in the future.” The whole doctrine is a defence against the friction of iteration — the round-trip, the re-review, the human on the other end who has to stop, context-switch, and redo.

That friction is what made “optional” rational. When asking for a rename means a day of latency and a bit of social cost, you learn to spend those asks carefully — you let the small stuff go so the important stuff gets through. “Nit: feel free to ignore” is a reviewer being economical with someone else’s expensive time. It was good practice. It was good practice because the fix was dear.

AI reprices the fix

Increasingly the author is a machine, and the round-trip that cost days costs a sentence. “Rename this, pull that constant out, alphabetise the props” — applied in seconds, no context-switch, no bruised ego, no waiting on a human to circle back. The two costs the hedge was built against — the author’s effort and the iteration latency — both fall toward zero. What doesn’t fall is the reading afterwards: someone still has to confirm the change is right and hasn’t moved something three files over. Generating the fix got cheap; validating it didn’t.

Take the cost out of “technically you should do it, but it won’t hugely impact things” and you’re left with “technically you should do it.” The but was the price tag.

Recently I reviewed a designer’s AI-produced front-end PR and flagged a heading element sitting where a <label> belonged — so clicking the text didn’t focus the input beneath it. Two years ago that is a textbook nit — a should-fix small enough you’d wave it through rather than spend a round-trip on one tag. The fix was a one-element swap: cheap to make, and — the part that matters — cheap to verify, because you can watch the click land on the field. When the price drops that far, the nit is just a fix you’re declining to make for almost no reason. So I stopped declining. I fix them, or the agent does, and the “up to you” comes off — because the “you” it was sparing barely spends anything now.

So keep the levels — but point them somewhere real

Here’s where it would be easy to overshoot. “Fixes are free, so abolish severity” is wrong, because the tiers were doing two jobs at once and only one of them just disappeared.

The dead job is cost-triage: is this worth the effort to fix? Almost nothing is un-worth a fix this cheap, so that meaning is gone, and the nit’s apology goes with it. The live job is everything else the label smuggled in: how load-bearing is this, and how hard do I have to work to be sure the fix is correct? A bug and a rename are both one click to apply — but verifying that the bug-fix is actually right, and doesn’t break something three files over, still costs judgment. And judgment didn’t get cheap. That’s the same split as everywhere else the machine touches this work: applying got cheap, deciding stayed scarce.

So re-point the tiers. Severity stops meaning “how much of your time is this worth” and starts meaning “how much scrutiny does this need before I trust the fix.” A nit gets fixed and barely checked. A logic change gets fixed and read hard. Different care, same expectation: it gets done. (Two labels survive untouched, because neither was ever a cost hedge. Optional/Consider asks whether the change is even the right one — taste, or a judgment call a cheap fix doesn’t settle. FYI — “not in this CL, but worth thinking about” — is scope. Cost was the nit’s problem alone.)

The loudest advice in 2026 runs the other way: nits are noise, so suppress them — mute the bottom tier, stop the bot raising them at all. That is the right instinct aimed at the wrong target. What it’s protecting is human attention spent triaging trivia; when applying-and-checking a nit is cheap, you don’t hide the finding to spare the human, you act on it and move on. Suppressing the nit throws away a fix you could simply have made. It’s the call I made building my own reviewer: surface the nit rather than drop it to look restrained, because its job is to educate and lift the code first — not to protect its own precision score.

The apology comes off

The “Nit:” prefix was always a small apology — sorry to make you spend real effort on something this minor. It was the right thing to say when effort was real. It isn’t anymore. You can keep the label as a marker of how much to check, but not as permission to skip. The nit was never optional. It was expensive, and we called that the same thing for so long we forgot they were different. They’re different now.

---

How sure I am: The norm and its cost-justification are cited — Google’s engineering-practices standard states the “delayed for days or weeks” / “difficult for any change to go in” reasoning explicitly, and its “Nit:” label is quoted verbatim; my own book’s “severity is a communication tool” framing is the prior treatment I’m updating. That AI reprices iteration cost is from building and running the reviewer, not a controlled measurement; the honest lived detail is the reviewer side — I’ve almost always fixed a nit once I saw one, and what I changed is making the reviewer surface nits rather than drop them to avoid looking like it over-fires, a deliberate call that its job is to educate and lift the code. The move — drop the hedge, re-point severity from cost to scrutiny — is my argued extension, not a measured result. The honest bound: I’m claiming the cost-triage meaning of severity is dead, not that impact or verification stopped mattering; those are exactly what the levels should track instead. And the claim is scoped to the Nit — the should-fix-but-small — not to Optional/Consider, which hedges on merit rather than cost and survives untouched.

Sources

• Google, Engineering Practices — The Standard of Code Review and How to write code review comments — the “favor approving… even if the CL isn’t perfect” standard, the “shouldn’t be delayed for days or weeks” / “disincentivized to make improvements” reasoning, and the “Nit:” / “Optional:” / “FYI:” labels. The canonical statement of the norm this post updates.
• How to Think About Code (my own) — “Severity is a communication tool”; “That is triage… because attention is finite.”
• The prevailing move runs the other way — toward eliminating nitpicking and de-noising review (e.g. kluster.ai, “how to eliminate nit comments”). This argues the opposite for machine-authored code, on the economics.

---

Related: Noticing Is Cheap, Judgment Is Scarce (applying got cheap, judging stayed scarce — the split that re-points the levels), Your Codebase Is the Prompt (why the small stuff compounds into what the model imitates next), Teaching the Reviewer (severity as communication — the thing being re-pointed here).