Years ago, a reviewer left a single comment on a pull request I was fairly proud of: 'what happens when this list is empty?' No suggested fix, no code sample, just the question. It turned out the answer was 'the page crashes,' which I hadn't checked, because I'd been testing with the same three-item list the whole time. That one sentence caught more than any of the twelve nitpicks left on the same diff about spacing and variable names.
Most review culture optimizes for the wrong kind of attention. Formatting, naming, import order — all real, all worth getting right, and all things a linter should be catching before a human ever looks at the diff. When review time gets spent there, the reviewer's actual judgment, the thing a linter can't replace, goes unused on the question that would have caught the real bug.
John Ousterhout's 'A Philosophy of Software Design' names the thing worth protecting that attention for: complexity is the real enemy of a maintainable codebase, and complexity mostly hides in the assumptions a piece of code makes about its own inputs — the empty list, the null value, the request that arrives twice. A good review interrogates those assumptions. A review consumed by style nits usually never gets there.
The shift we made internally was procedural before it was cultural: automate every style rule that can be automated, so it never occupies a human comment thread, and treat the reviewer's actual job as asking 'what happens when' questions — empty inputs, concurrent access, the request that times out halfway through. It's a smaller list of comments per review and a much higher hit rate on the ones that matter.
The single-sentence review stuck with me not because it was clever, but because it was aimed at the one thing worth aiming at. Most bugs aren't hiding in how the code is formatted. They're hiding in the case nobody thought to ask about.