If your review gate blocks a merge on something the author did not cause and cannot fix, your engineers will route around it within a week.
Then you have paid for a reviewer nobody reads.
Picture a PR. The diff is clean. The reviewer flags a bug three files away, written two years ago by someone who left. The check goes red.
The author has three options: fix a stranger's bug in an unrelated PR, argue with a bot, or find an admin with bypass rights. Two of those teach your team the gate is noise.
Anthropic's own tooling sidesteps this on purpose. Claude Code's GitHub review tags such findings as "Pre-existing," a bug "that exists in the codebase but was not introduced by this PR." It surfaces them. It does not block on them. The check "always completes with a neutral conclusion so it never blocks merging through branch protection rules," and "a failed run never blocks your PR" (docs).
Gates go red for reasons that aren't the diff, too. GitHub warns that "Status checks may fail after you merge your branch if there are incompatible changes with the base branch" (GitHub). The base moved. The author did nothing. Flaky tests are the same story, which is why Trunk quarantines them so they "won't break main or fail CI workflows" (Trunk).
Blocking burns trust fast. One practitioner's verdict: an AI that can block merges "will, the first time it's confidently wrong, get switched off." Their rule is "AI proposes, humans dispose" (DEV). Google's human standard agrees: "Don't let a CL sit around because the author and the reviewer can't come to an agreement" (Google).
If a human reviewer blocked your PR over someone else's old bug, you would escalate. Do not let a bot do what you would not tolerate from a person.
One rule, starting tomorrow: the reviewer may only request changes on findings the diff introduced. Everything else, pre-existing bugs, base-branch drift, flaky tests, reviewer outages, becomes a comment and a filed issue. Block what the author broke. Report the rest.