The review comment that engages with nothing
A nit about a variable name used to be harmless. On a generated pull request it is often the only recorded evidence anyone looked, and it certifies a review that did not happen. The unreviewed merge is not the worst category.
Nine hundred lines. Four files, one of them a migration. The only comment on the pull request reads: nit: maybe customerId rather than custId for consistency? Author fixes it, reviewer approves, merged.
Every part of that is normal. The reviewer was not lazy and was not pretending. They opened the change, scrolled, found something they could evaluate quickly and correctly, said it, and moved on. That is what a busy person does under load, and it used to be fine.
My position: it is not fine any more, and the reason is not about effort or standards. A comment like that is now the mechanism by which an unread change acquires a review record. The industry is worried about pull requests merged with no review at all. The larger and better-hidden category is the change that was nominally reviewed by someone who engaged with nothing.
Why the nit was harmless before
Under human authorship, a pull request came with a person attached. That person had held the whole change in their head for hours or days, had already asked themselves most of the obvious questions, and was available to answer the rest.
The reviewer’s job in that setting was genuinely partly social. Being present, signalling that the work was seen, catching surface problems. The deep verification was distributed: the author had done a version of it, the tests encoded another version, and the reviewer’s marginal contribution was often small by design.
So a comment about naming was not a failure of review. It was a low-cost contribution on top of a system that had other checks in it, and the most important of those checks was that somebody understood the change and would still understand it in three months.
That check is what disappeared. The author of a generated change did not build a mental model of it. They read some of it, decided it looked right, and opened the pull request. When the reviewer also does not build a model, the change enters your codebase with nobody holding it, which is a state the old process never produced.
What a nit costs to write
- Ninety seconds
- No model of the change required
- Findable by scrolling
- Always correct, therefore always safe to say
What it now certifies
- A review event in the record
- An approval that satisfies branch protection
- A merge that looks identical to a scrutinised one
- An audit trail that says a human examined this change
The number everyone quotes misses this entirely
LinearB’s 2026 benchmarks put pull requests merged with zero review up about 31 percent, alongside pickup time roughly 5.3 times longer on agentic pull requests and median review duration up over 400 percent. Those are the figures being passed around, and they are worth taking seriously.
But zero-review merges are the visible failure. They are countable, they trigger alarms, and a policy can address them directly.
The nominally-reviewed merge is invisible by construction. It has a reviewer, a comment, an approval and a timestamp. Every dashboard in your organisation counts it as a reviewed change. There is no query that distinguishes it from a change where someone spent forty minutes tracing a data path, because the artefacts are identical.
Put that next to the Stack Overflow finding that developer trust in AI output fell from around 40 percent to 29 percent, and the shape of the situation gets clearer. People trust the output less and are engaging with it no more deeply, because the constraint was never willingness. It was time.
What engagement looks like in a comment
The useful test is whether a comment could have been written without understanding what the change does. Run it across your last fifty review threads and the results are usually uncomfortable.
Naming, formatting, a missing docstring, “could this be extracted”, “should we add a test here”: all writable from the diff alone. None of them require knowing what the code is for.
Now the other kind. What happens to in-flight requests during this migration. This adds a second retry on top of the one in the client, is that intended. The cache key does not include the tenant. If this fails halfway, what state is the account in. Every one of those requires a model of the system and the change together, which is exactly the thing that is now missing.
That second list is also much shorter, which is the practical point. Deep engagement does not mean reading every line. It means asking a small number of questions that cannot be answered from the diff.
What to change on Monday
Stop counting reviews and start counting engagement, imperfectly.
The crude version works better than it should: for changes above a size threshold or touching a listed sensitive path, require at least one comment or approval note that references behaviour rather than form. Not a policy about tone. A prompt in the template with the four questions, and an expectation that the approval says something about at least one of them.
Reduce what needs reviewing at all, because none of this survives volume. Line-level consistency comments should be a linter’s job, permanently. Every nit that a tool could have made is a reviewer’s attention spent on the wrong thing, and under generated volume that trade is no longer close.
And separate the two review types explicitly. Surface review, done fast, for low-risk changes in well-tested areas. Deep review, slower and rarer, for anything touching money, identity, data migration or an external contract. Trying to give every change the same review is how you end up giving every change the cheapest one.
Where this breaks down
Nits catch real bugs, and I have been glib about that. An off-by-one spotted while scanning for style is still an off-by-one caught. Reviewers who scroll looking for surface problems do find substantive ones, and a policy that discourages low-cost comments will lose those catches. I do not think the trade is close, but it is a trade.
I cannot distinguish theatre from a genuine short review. Sometimes a change really is simple, one comment really is the appropriate output, and the reviewer really did understand it. My test flags that case identically to the worst case. Any metric built on comment content will punish people who reviewed well and quickly, which is a serious flaw in the recommendation.
Making review feel policed reduces review. The strongest objection. If people believe their comments are being assessed for depth, the rational response is to comment less, or to write performative depth, which is worse than a nit because it is longer and equally empty. Review culture is fragile and I am proposing to put weight on it.
The real constraint is capacity, and none of this adds any. Asking for deeper engagement without removing anything is asking people to do more work in the same hours. That request fails. If you adopt the four questions and do not simultaneously cut review volume, you will get the questions answered shallowly, and you will have added a ritual rather than a check.
And some teams genuinely do not need this. A small team with high context, working in a codebase they all know, gets deep engagement for free because there is no other kind available to them. This argument is about scale and about people reviewing code in areas they do not own.
The takeaway
A comment that engages with nothing is not a bad comment. It is a cheap one, and it used to be free because other parts of the system were carrying the verification load. Those parts are gone: the author no longer holds a model of the change, and the reviewer’s comment is now the only evidence that anyone did.
The zero-review merge is a countable failure. The nominally reviewed one is not, and it is more common.
If you take one thing into next week: read the last twenty approved pull requests in your busiest repository and ask, for each comment, whether it could have been written without knowing what the change was for. The ratio is your real review coverage, and it is not the number on your dashboard.