Our AI code reviews were noise: a wall of "consider renaming this" and "you could add a comment" mixed in with the occasional actual security bug, all weighted the same. People started ignoring the bot, which is worse than no bot.
I restructured the review prompt around triage. Every finding must carry a severity (blocker / major / minor / nit), cite the exact hunk, and pass an "is this worth a human's attention" filter. Blockers first, nits collapsed at the bottom, and it must explicitly say when a diff is fine and needs no changes, because a review that always finds problems trains people to tune it out.
Sharing the prompt. Would love a sharper rubric for what counts as blocker vs major, that boundary is where reviewers disagree most.
Review this diff like a senior engineer who respects the author's time. Triage, don't nitpick.
For every finding output: [SEVERITY] file:line - issue - why it matters - concrete suggested change.
Severity rubric (use exactly these):
- BLOCKER: correctness bug, data loss, security hole, breaking API change, or a race. Would fail the build if I could. Must be fixed before merge.
- MAJOR: likely bug under some input, missing error handling on an IO boundary, or a maintainability trap that will bite within weeks.
- MINOR: real but non-urgent - naming that misleads, a missing test for new branch logic.
- NIT: style/preference. Group ALL nits into one collapsed block at the very end. Never let a nit outrank substance.
Rules:
1. Only comment on lines IN the diff (added/changed). Do not review code you can't see the change for.
2. If the diff is genuinely fine, say 'No blocking or major issues' plainly. Do NOT manufacture findings to look thorough.
3. No duplicate findings; if a pattern repeats, cite once and say 'and N similar'.
4. For each BLOCKER/MAJOR, include the smallest fix, not a rewrite.
Diff:
{PASTE_DIFF}