AI Code Review Prompts That Actually Work (With Examples)

TL;DR: A good code-review prompt does three things: it narrows scope (tell the model what to ignore), it gives an escape hatch (permission to say "nothing to add"), and it asks for structured output (severity + location + fix). Vague prompts produce vague, noisy reviews. The patterns and copy-paste examples below fix that.

Most disappointing AI code reviews aren't a model problem — they're a prompt problem. Ask an LLM to "review this code" and you'll get a wall of generic observations, half of which restate the obvious and none of which you'd act on. The same model, given a sharp prompt, will hand you a short list of real issues with locations and fixes. This post is a field guide to writing that sharper prompt.

This is the practical companion to the AI code review complete guide. If you want these prompts running automatically on every PR, wire them into CI with the GitHub Actions setup.

The three rules of a good review prompt

Every effective review prompt I've used comes back to the same three principles. Miss any one of them and quality drops off a cliff.

Rule 1: Narrow the scope — say what to ignore

An unfocused model reviews everything: style, naming, formatting, and the actual bugs, all mixed together at equal weight. You end up scrolling past "consider a more descriptive variable name" to find the one comment that matters. Fix this by explicitly excluding what a linter already handles:

Review this code for correctness and security only.
Do NOT comment on formatting, naming, or style — those are handled
by our linter and formatter. If you catch yourself writing a style
note, delete it.

That single instruction removes the majority of the noise, because style nitpicks are exactly what LLMs over-produce.

Rule 2: Give it permission to say nothing

LLMs are trained to be helpful, which means when you ask for feedback they will produce feedback — even on flawless code. This is the root of the "noisy bot" problem. The cure is an explicit escape hatch:

If the code is correct and you have no substantive concerns,
respond with exactly: "No blocking issues found."
Do not invent minor suggestions to appear thorough.

Without this, a clean PR still gets three paragraphs of manufactured concern. With it, clean PRs get a one-line all-clear and everyone trusts the bot more.

Rule 3: Demand structured output

"Some issues" is useless. You want severity, location, and a concrete fix so the output is actionable at a glance:

For each issue, output:
- Severity: [blocking | warning | nit]
- Location: file and line or function name
- Problem: one sentence
- Fix: the concrete change to make

Structured output also makes the review skimmable and easy to post as PR comments — you can even parse it programmatically to only surface blocking items in CI.

Copy-paste prompt: general PR review

Combine all three rules and you get a reusable review prompt:

You are an experienced engineer reviewing a pull request diff.

Focus ONLY on:
- Correctness and logic bugs
- Error handling and resource leaks
- Security issues (injection, secrets, auth, unsafe input)

Ignore formatting, naming, and style — a linter handles those.

For each real issue, output:
- Severity: [blocking | warning | nit]
- Location: file + line or function
- Problem: one sentence
- Fix: the concrete change

If there are no substantive issues, respond with exactly:
"No blocking issues found."

Diff:
<paste the diff here>

Copy-paste prompt: security-focused pass

For sensitive code — auth, payments, anything touching user input — run a second, narrower pass. Specialisation beats generalisation here:

You are a security reviewer. Examine this diff ONLY for:
- Injection (SQL, command, template, XSS)
- Hardcoded secrets or credentials
- Broken authentication or authorization
- Unsafe deserialization or unvalidated input
- Sensitive data in logs or error messages

For each finding: severity (critical/high/medium), the exact line,
the exploit scenario in one sentence, and the fix.
If you find nothing, say "No security issues found." Do not speculate
about theoretical risks that aren't present in this diff.

The final line matters: without it, security prompts tend to produce paranoid, hypothetical findings that bury the real ones.

Copy-paste prompt: explain-and-review for learning

If a junior developer is using AI review to learn, not just to catch bugs, tilt the prompt toward teaching:

Review this code for correctness and security. For each issue,
explain WHY it's a problem and what could go wrong in production,
as if mentoring a mid-level engineer. Keep it concrete — reference
the actual code, not general principles.

This produces longer output, so it's a bad fit for CI (too noisy) but a great fit for a developer pasting their own code into a chat window before opening the PR.

Anti-patterns to avoid

• "Review this code." Too vague. You'll get generic output every time.
• "Find all bugs." Invites the model to hallucinate bugs to satisfy the "all." Ask it to find real issues and allow zero.
• Dumping the whole repo. Review the diff. Context dilutes focus and wastes tokens — the same lesson from the GitHub Actions setup.
• No output format. Unstructured reviews are hard to act on and impossible to parse.

Iterate on your prompt like it's code

Treat the review prompt as a living artifact. When the bot produces a bad review, don't shrug — figure out which of the three rules it violated and tighten the prompt. Over a few weeks you'll converge on something tuned to your codebase's actual failure modes. The general principles of that tuning process are covered in prompt engineering for developers; this post is just those principles pointed squarely at code review.

Get the prompt right and AI review stops being a novelty and starts being a genuine part of your workflow — the complete guide shows where it fits alongside human review and tests.