Ask HN: Why does it still make sense to review stupid bugs at PR time?
3 comments
Hey where can we look at it i really wanted to have this so badly !!
pre-commit hooks catch the easy stuff. code review is still useful for architecture and logic though.
Code review is not and never has been the right place to uncover bugs. Correct tests are.
Code reviews are essential, but I keep seeing the same pattern: PR reviews are full of comments about trivial bugs, lint issues, and convention mismatches that could have been caught before the code ever left the developer’s machine.
With AI-assisted coding becoming the norm, this seems worse, not better. AI is fast, but it happily produces subtle bugs, inconsistent patterns, and sloppy edge cases. By the time a PR is up, reviewers are debugging noise instead of reviewing architecture, correctness, or intent.
Why isn’t pre-commit review (automated or otherwise) the default place to catch these issues? Is there a real downside, or is this just inertia?
I built a small pre-commit review tool to experiment with this idea and genuinely can’t imagine going back, but I’m curious why this isn’t already standard practice.
Would love to hear how others think about this.