Should AI Code Review Block Your Merges? Gating vs. Advisory

The question every rollout eventually hits

Sooner or later, every team that adopts AI code review has the same meeting. The reviewer has been running for a few weeks, the comments are mostly good, and someone asks: should we make it a required check? From there the room splits. One camp wants the bot in the merge gate — if the AI found a real problem, why would we ever merge past it? The other camp has seen a required check go red on a Friday afternoon for a nitpick and wants the bot kept firmly advisory, forever.

Both camps are right about something. This post lays out what gating and advisory modes actually trade against each other, why the common failure of each looks the way it does, and a staged middle path that most teams land on once the arguing stops.

What advisory mode buys you

In advisory mode the AI reviewer comments like a colleague: it can warn, suggest, and object, but it cannot stop a merge. Humans remain the only gate. This is the right default for a new rollout, and not just for political reasons.

• Trust has to be earned on your codebase. Review quality varies with language, framework, and repo conventions. Advisory mode is the evaluation period where you learn your reviewer’s real precision — on your diffs, not a vendor benchmark.
• Noise is survivable. A false positive in advisory mode costs a few seconds of eye-roll. The same comment as a failed required check costs a re-run, an override request, or a workaround habit.
• Engineers stay the authority. The reviewer is a second opinion, and authors decide what to act on — which keeps the team reading the comments instead of gaming the gate.

Advisory mode has a failure mode of its own, though, and every team discovers it: comments that block nothing get skipped when people are busy — and the deadline weeks when everyone is busy are exactly the weeks risky code ships. An advisory reviewer is only as strong as the team’s worst afternoon.

What gating buys you — and what it costs

Making the AI a required status check turns its findings into policy. The obvious gain is consistency: a security finding can no longer be scrolled past, whoever the author is, whatever the deadline. For certain classes of finding — hardcoded credentials, obvious injection patterns, license violations — a hard stop is exactly the behavior you want, for the same reason nobody argues about a failing build.

The costs arrive just as predictably:

• Every false positive becomes an incident. A wrong blocking comment does not just waste time; it teaches the team that the gate is unreliable, and resentment of a gate compounds far faster than annoyance at a comment.
• Latency joins the critical path. An advisory reviewer that takes five minutes is invisible. A gating one adds those minutes to every merge, and to every re-run after every push.
• People optimize against gates. Splitting changes to dodge the reviewer, batching risky edits into PRs the bot handles poorly, pressuring whoever holds override rights — gate-gaming is a tax you pay in exactly the currency AI review was meant to save: reviewer attention.

The severity split: gate findings, not the reviewer

The framing mistake in the Friday-afternoon argument is treating gating as a single switch. The teams that get this right do not gate the reviewer — they gate specific classes of finding, and leave everything else advisory.

A workable split looks like this: block on high-confidence, high-severity findings where a false positive is rare and the cost of shipping the bug is an incident — leaked secrets, clear injection sinks, broken auth checks. Comment, but never block, on maintainability, style, performance suggestions, and anything the model itself is less than certain about. The dividing line is not “is this a real issue” but “is this class of finding reliable enough that a red X will be respected.”

This is also the honest answer to “should AI approve PRs?” — approval and blocking are different powers. A reviewer that can block a credential leak but cannot approve a merge keeps humans accountable for what ships while making the worst mistakes unshippable.

A staged path that avoids both failure modes

1. Weeks 1–4: fully advisory. Let the reviewer comment on everything. Track precision by severity class — which findings does the team act on, which get dismissed, and why. Our guide to measuring AI review covers what to count.
2. Weeks 4–8: gate one severity class. Pick the class with the cleanest record — usually secrets and credential findings — and make only that a required check, with a documented override path (a human can dismiss with a reason, and dismissals get reviewed weekly).
3. After week 8: expand by evidence. Add a class to the gate only when its advisory-period precision says a red X will be trusted. Some classes — style, architecture opinions — should stay advisory forever.

The override path deserves emphasis. A gate without an escape hatch fails closed at the worst moment — the hotfix at 2 a.m. — and gets globally disabled the next morning. A gate with a logged, reviewable override fails gracefully and leaves an audit trail instead of a disabled check.

Where PURA sits

PURA is built for exactly this staged model. It posts review comments with explicit severity levels, so you can wire your merge requirements to the classes you trust — block on critical findings via required checks while everything else stays conversational. Because PURA is self-hosted, the thresholds, the override policy, and the logs live in your infrastructure, not a vendor dashboard — which tends to matter to the same teams that care about gating in the first place. And per-team review budgets keep an expanded gate from quietly expanding your inference bill.

The short version

Advisory-only review leaks exactly the findings you most wanted caught; gate-everything review gets gamed or disabled. Gate narrow classes of finding that have earned it with measured precision, keep a logged override, and leave the rest as commentary. The goal is not an AI that can stop your team — it is a merge process where the red X, when it appears, is believed.