A Code Reviewer That Refuses to Nitpick

Most automated code review is noise. 40 comments about spacing and naming, and buried somewhere in there, maybe, the 1 bug that actually matters, which nobody finds because they stopped reading at comment 8. I wanted the opposite, so I stopped asking a model to generate opinions and started making it defend them.

What it actually is

It reviews a pull request hunting only for the worst mistakes - security, performance, correctness, scalability, the team conventions that actually bite. Then comes the part I care about: it self-verifies. Every candidate finding goes through a tournament where the reviewer tries to refute its own claim. If it can't prove the issue is real, the finding dies. What survives gets ranked - top 10 down to top 5 - and only the best 3 get staged.

Quality over quota. 1 verified, devastating finding beats 3 plausible-but-weak ones, every time. A review that's mostly right is worse than a short review that's entirely right, because the wrong ones burn the author's trust in all of them.

In practice

Instead of spraying a PR with 40 comments, it posted 3. Each one had already survived its own attempt to disprove it. The author didn't have to triage noise to find the real issue - the real issue was the whole message. That's the difference between a reviewer people mute and one they actually read.

What I learned

Finding issues was never the hard part - a model will happily find 40. The hard part is the discipline to throw out the 37 that aren't worth a human's attention. The product isn't the findings. It's everything it decided not to say.

The skill behind this is open source. Clone the 1 folder you need from bunlongheng/audits, point it at your own work, and find out which of your review comments can survive being argued with.