AI Code Review Prompts: Make the Reviewer Show Its Evidence

Ask a model to review a diff and it will almost always find something - and that is exactly the problem. AI code review prompts fail in two opposite directions: the reviewer invents issues that are not there, or it rubber-stamps the bug in front of it. A written contract fixes both.

AI Code Review Prompts Fail in Two Opposite Directions

Most teams write one sentence ("review this code") and then judge the result by gut feeling. One calibration line first: the model does not understand your code, it produces a list of plausible findings. The value is in whether each item carries evidence and whether the verdict is explicit. A reviewer with no contract has two ways to disappoint you, and they pull in opposite directions.

Failure One: The Invented Issue

Models are trained to be helpful, and a helpful answer to "review this" contains findings. When there is nothing real to report, the report gets filled anyway: naming opinions, "consider adding error handling", a suggestion to extract a helper that already exists three files away.

The symptom is easy to spot: no file, no line, no concrete fix. If it cannot be anchored to the code, it was not a finding, it was filler.

Failure Two: The Rubber Stamp

The worse failure is quiet. Research on sycophancy in large language models describes the tendency to prioritize agreement with the person writing the prompt over independent judgment (arXiv 2411.15287). That study covers sycophancy in general, not code review, so it should not be stretched into a rate of bad approvals. But the mechanism transfers to a diff.

Frame the request as "here is my refactor, looks good, right?" and you have told the model which answer makes you happy. Ask the model that wrote the code to review its own output and author and reviewer become the same voice, with the same blind spots. The result is an approval that carries no information, which reads like success and behaves like a skipped review.

The Review Contract: Four Clauses to Write Into the Prompt

A review contract is text your prompt demands from the output, not a hope that the model will be rigorous. Four clauses cover both failure modes and the gap in between.

Clause 1: Every Finding Carries a Line and a Fix

No location, no finding. The unit of the report is file:line, what breaks, and the concrete fix - not "consider a different approach". This clause kills half the invented issues by itself: filler cannot be anchored to a location.

Clause 2: Rank by Severity, Not by Category

A list grouped by category tells you what kinds of problems exist but not what to do first. Severity orders the work instead: P0 is critical and gets fixed before the merge, P1 is real and gets fixed in this pass, P2 is a nit that blocks nothing. Human review draws the same line when it prefixes a minor comment with "Nit:" so it does not hold up an otherwise good change (Google Engineering Practices: The Standard of Code Review).

One prompt in the store already ships that scale: Claude Code Review Partner asks for six blocks - summary, bugs and correctness with P0/P1 severity and a line reference, security, performance, readability, and missing tests for the riskiest path - and reports only issues justified by the code.

Clause 3: Say "No Issues" When There Are None

This is the clause almost nobody writes, and the one that fixes failure mode one. The permitted output must include "no issues found", and the prompt must forbid inventing findings to fill the report. Without it, a format that asks for N problems obliges the model to produce N.

A short reviewer is often the honest one. Senior Code Review Assistant does five passes - bugs and edge cases, security, performance, readability and naming, missing tests - requires the exact line plus a proposed fix, stays under 400 words, and ends by stating that if the code is correct the model should say so instead of inventing problems. That is clause 3 written as a product decision.

Clause 4: Ask Instead of Assuming

When the diff does not reveal the intent, the correct output is a question, not a finding. A false positive about a deliberate decision is the model deciding for you: it assumed the behavior was accidental because nothing in the snippet said otherwise. A question clause turns that guess into a conversation you settle in one reply.

Review the Diff in Fresh Context

The author is not the reviewer. Open a session with no history - no earlier message where you asked for the change, no "looks good so far" - and paste the diff plus the intent in one line. That breaks the symmetry feeding the rubber stamp, because the model is no longer grading its own homework with your approval already in the room.

The hunk is not always enough. Google's guidance on what to look for in a review notes that review tools usually show only a few lines around the change, and that sometimes you have to read the whole file to be sure the change makes sense (What to look for in a code review). In prompt terms: include the full file when the diff touches shared state or exported types. A reviewer that cannot see the caller cannot judge the call.

Three Prompts From the Store That Already Write the Contract

The Full Contract, Severity Included

Claude Code Review Partner is the long version: six blocks, P0/P1 severity, line references, and the two rules that matter here - only report what you can justify with the code, and never rewrite for the sake of it. Use it when the diff is big enough that skipping the security and performance blocks would be irresponsible.

The Fast Version, Under 400 Words

Senior Code Review Assistant is the same discipline compressed: five passes, exact line plus proposed fix, under 400 words, and an explicit instruction to say the code is correct rather than manufacture problems. Run it on a small file, or as a first pass before a human reads anything.

After the Verdict - the Missing States

React Component Generator is normally used to generate a component, but its lists double as a review checklist for UI work: states (loading, empty, error, disabled), accessibility (roles and aria attributes, keyboard handling, focus management), edge cases (zero items, very long content, fast repeated clicks, unmount during an async call) and interaction tests. Use it here in reverse - not to write the component, but to see what a review should have demanded. The generating side is a different job, covered in the refactoring workflow post.

What the Model Cannot Judge

The human gate stays, because the diff does not contain every answer. Whether this code should exist at all, whether the business rule is right, whether there is time to fix it properly - those are judgment calls, not pattern matches.

Google puts the standard where it belongs: the purpose of review is to keep the code health of the system improving over time, and reviewers should favor approving a change that clearly improves it even when it is not perfect. On tests the same documentation is blunt: tests do not test themselves, and a human must be satisfied that they are valid. The report is input; the merge decision stays human.

The Review Habit That Outlives the Tool

The quality of an AI review has little to do with which model you picked this month and a lot to do with the contract you wrote for it: evidence anchored to a line, severity instead of category, permission to report nothing, and a context where the reviewer was not also the author.

Start with the three prompts that already encode it - Claude Code Review Partner for the full pass, Senior Code Review Assistant for the quick one, and React Component Generator as the UI checklist - and make that contract part of every AI code review prompt you write from now on.