AI Code Review Should Sit Below Your Human Review, Not Replace It
A developer opens a pull request. The AI code review tool posts its comment first: "looks good overall." Two lines below, a human reviewer adds, "this changes the auth path in a way that breaks the token refresh for expiring sessions." The AI saw the diff. It did not see the bug that matters.
That is the shape of the problem. Not that AI review is useless. Not that it is dangerous. That it is useful in one layer of the loop and dangerous when teams let it stand in for the layer above it.
This piece is for the team that is putting AI code review into its workflow and wants to use it without it quietly degrading the review it was meant to support.
The appeal: why teams want AI in review
Code review is slow. It is also one of the few moments where a second pair of eyes catches something the author did not intend. Teams reach for AI review because they want the second pair of eyes to be cheaper, faster, and always available.
That is a real appeal. A diff-level reviewer that catches typos, unused imports, obvious off-by-one errors, and missing edge cases is worth having. The problem is that teams often optimize for "the tool reviewed the diff" and stop there, which is where the loop starts to rot.
Where AI review actually helps — the diff level
AI review is decent at the diff level. It can read a hunk of code and flag things that are locally wrong: a variable used before it is set, a branch that looks unreachable, a call that is missing an argument, a pattern that is repeated when it should be extracted.
That is useful. It is also shallow.
The diff level is the surface of the change. It is the "what changed" layer. A tool that reads the diff well can tell you that the change is internally consistent. It is not, by itself, good at the question that human review is mostly for: whether the change is the right thing to do in the context of the system around it.
That distinction matters. A diff can be locally perfect and globally wrong.
Where it quietly fails — the structural and intent mistakes
The mistakes that cause outages are rarely the ones a diff-level reviewer can see from the code alone. They are the mistakes about intent, about how this change interacts with the rest of the system, about whether the author understood the contract they are changing.
A reviewer who only reads the diff sees the change. A reviewer who reads the intent sees the bug that the diff hides.
That is what human review is for in well-run teams. The author explains what they meant. The reviewer checks whether what they meant is what the code does, and whether what the code does is safe in the broader system. AI review that stands in for that conversation does not catch the bug that matters. It gives the team the comfort of a checkmark and lowers the standard that the checkmark was supposed to raise.
The rubber-stamp effect and how it degrades the loop
There is a specific failure mode worth naming. When a tool posts "looks good," reviewers read the diff less carefully. Not always. Often enough. The tool's approval becomes a cue to skim rather than to engage.
That is the rubber-stamp effect. It is not that the tool is wrong. It is that the tool's presence changes how the human behaves, and the human behavior is the thing that actually catches the structural bugs.
A team that lets the tool's "looks good" replace the reviewer's judgment has not automated review. It has automated delegation. The review still happens, but now it happens in the production incident instead of the pull request.
The signal-to-noise collapse is the related failure. AI review that surfaces too many trivial suggestions buries the structural issues that matter. Reviewers stop reading the suggestions because most of them are noise, and then the one suggestion that mattered is lost in the pile. A tool that is too loud is not a better reviewer. It is a worse one, because it teaches the team to ignore it.
A placement that holds: AI below human review, with boundaries
The placement that holds is simple. AI review sits below the human review. It runs on the diff before the human reviewer reads it. It surfaces diff-level suggestions and obvious checks. It does not sit in the architectural judgment. It does not stand in for the reviewer's read of intent.
Concretely:
- AI review runs first, on the diff. It catches the surface bugs and the obvious issues.
- The human reviewer reads the diff after, with the AI suggestions available but not authoritative.
- The human reviewer is still responsible for the intent, the design, and the interaction with the rest of the system.
- The AI suggestions are an input to the human review, not a replacement for it.
That placement keeps the tool in the role where it is useful and out of the role where it is dangerous. It also makes the review loop explicit: the tool checks the diff, the human checks the intent, and the team catches the bugs that only make sense in context.
Failure modes to watch for
A team that puts AI review in place should watch for the specific ways it degrades the loop. These are the ones worth naming before they show up as incidents.
Rubber-stamping. The reviewer skim-reads because the tool said "looks good." Watch for review comments that are short, generic, and arrive after the AI comment. If the human review is thinner after the tool arrives, the tool is lowering the standard.
Noise drowning the signal. The tool surfaces too many trivial suggestions and the team stops reading them. Watch for the suggestions that get dismissed without reading. If the team is ignoring most of what the tool says, the tool is too loud, not too smart.
Over-trust in local correctness. The team assumes that because the diff is locally clean, the change is safe. Watch for bugs that show up in production that the diff-level review could not have seen because they were about context, not syntax.
Review becoming a tool-approval step. The review stops being a design conversation and becomes a "did the tool pass?" check. Watch for review threads that are about the tool's output rather than the change's intent.
Silence around the real question. The tool does not ask whether the change is the right thing to do. If the team stops asking that question because the tool answered a different one, the loop has degraded.
What to do first
- Place AI review below human review.** Run it on the diff before the human reviewer reads it. Do not let the AI comment be the last word.
- Name what the tool is for.** Diff-level suggestions and obvious checks. Not architectural judgment. Not intent. Make the boundary explicit in the team's review norms.
- Watch the rubber-stamp effect.** If review comments get shorter after the tool arrives, the tool is lowering the standard. Fix the placement, not the tool.
- Tune the noise.** If the team is ignoring most of the suggestions, turn the tool down until the suggestions it surfaces are worth reading. A quiet tool that is read is better than a loud one that is not.
- Keep the intent conversation alive.** The author still explains what they meant. The reviewer still checks whether that is safe in context. The tool does not replace that conversation.
- Run a failure-mode check each sprint.** Ask whether the tool is rubber-stamping, drowning the signal, or being treated as the last word. Fix whatever is happening.
The goal is not to avoid AI review. The goal is to use it in the layer where it helps and keep the human review doing the work it is actually good at — the intent, the design, and the mistakes that only make sense in context.
A team that gets the placement right uses the tool without it becoming a rubber stamp. A team that gets the placement wrong gets a tool that says "looks good" and an incident report that says "why did nobody catch this?"
The difference is the loop, not the tool.
Sources
- r/webdev — AI code review discussions documenting the rubber-stamp effect and over-trust
- r/programming — AI assistant workflow threads from developers using review tools
- GitHub Copilot — AI pair programming as a diff-level assistant, not an architectural reviewer
- Code review best practices — review as a design and intent check, not just a syntax check