A Hacker News post arguing that code review's primary purpose is identifying hard-to-maintain code — not catching bugs — struck a nerve this week, climbing to 143 points and 91 comments. The thesis is simple: functional correctness is table stakes; the real review signal is whether a change will still make sense six months from now.
This reframes the reviewer's role from gatekeeper to archaeologist. Instead of asking "does this work?" teams should ask "will someone understand why this exists?" The distinction matters because bugs get fixed; architectural confusion compounds. Every opaque abstraction, implicit dependency, or clever one-liner becomes technical debt that slows future velocity.
Engineering leads and senior developers bear the brunt of this shift. They're the ones who inherit the confusion when original authors move on. Organizations that treat review as a rubber stamp for correctness accumulate invisible friction — onboarding drags, refactors stall, and simple changes require days of spelunking.
The long-term impact compounds across hiring cycles. Codebases optimized for readability attract contributors; those optimized for cleverness repel them. The review culture you build today determines the team you can hire tomorrow.
What signals do your reviewers actually reward — clarity or cleverness?