AI AI Tools Guidebook
Prompt Library

Code Review Prompts: Beyond "Looks Good to Me"

13 prompts for AI code review that surfaces real issues — bugs, security, performance, readability, tests.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

Generic “review this code” gives generic feedback. These prompts target specific failure modes a senior reviewer would catch.

Who this is for

Engineers doing self-review before a PR, tech leads who triage 10+ PRs a week, indie devs without a peer reviewer, anyone onboarding to an unfamiliar codebase.

When not to use these prompts

Skip these for tiny one-line diffs or generated code (lockfiles, migrations) — the overhead outweighs the signal. Don’t use on AI-generated patches you haven’t read yet; review your own draft first.

Prompt anatomy / structure formula

A code-review prompt should always carry six elements:

  • Reviewer role: who AI plays (senior backend reviewer / SRE / staff frontend).
  • Scope filter: one review lens only — bugs OR security OR perf — never all at once.
  • Evidence requirement: every finding needs file:line so you can verify.
  • Severity scale: Critical / High / Med / Low to force ranking, not just a list.
  • Confidence threshold: tell AI to only flag when it is confident; cuts false positives.
  • Output shape: numbered list or markdown table — not prose paragraphs.

Best for

  • Pre-PR self-review
  • AI-pair code review
  • Onboarding code reading
  • Security-sensitive reviews

13 copy-ready prompt templates

1. Bug-focused review

Below is a diff. Review for likely bugs only. For each: file:line, severity (high/med/low), what’s wrong, suggested fix. Ignore style. Be conservative — only flag if you’re confident.

{paste diff}

2. Security-focused review

Review this code for security issues: injection, auth, secrets, input validation, unsafe deserialization, race conditions. For each: file:line, attacker scenario, fix.

{paste}

3. Performance review

Review for performance issues only: N+1 queries, sync calls in hot paths, redundant work, missing memoization, unbounded growth. Show before/after for the top 3 issues.

{paste}

4. Readability + naming

Review readability only: unclear names, overlong functions, deep nesting, mixed levels of abstraction. Suggest specific renames. Don’t propose rewrites.

{paste}

5. Test-coverage review

Below is a change with its tests. Identify: cases not covered, brittle test patterns, tests that test implementation rather than behavior. Suggest 3 missing test cases.

{paste}

6. API design review

Review this public API surface for: parameter clarity, error handling consistency, breaking-change risk, idiomatic style for {language}. Suggest one alternative shape if applicable.

{paste}

7. Diff context check

For this diff, list any change where the author may not have read enough surrounding context (e.g., touched a function but didn’t update callers). For each: what’s likely missing.

{paste}

8. “PR description” sanity check

I’m writing a PR description. Here’s my draft + the diff. Does the description accurately cover the change? List discrepancies.

Description: {paste}
Diff: {paste}

9. Migration / schema-change review

This diff includes a DB migration (paste). Review for: missing backfill, irreversible ALTERs, lock duration on large tables, missing index for new FKs, downstream code still referencing old shape. For each: file:line, risk, suggested mitigation.

{paste}

Variables to swap: the migration file + any model/ORM changes

Optimization: Add: “Assume the table has ~10M rows in production.” Forces realistic lock-duration thinking.

10. Concurrency-aware review

Review this diff for concurrency issues only: shared mutable state, missing locks/mutexes, async race windows, awaits inside transactions, double-fires from React effects/handlers. For each: file:line, the interleaving that fails, suggested fix. Skip everything else.

{paste}

11. Reviewer-junior translator

I will paste a senior reviewer comment. Rewrite it for a junior engineer who just joined: explain the underlying principle in 2 sentences, then quote one before/after code snippet showing the fix. Keep the original sharpness but remove jargon.

Reviewer comment: {paste}
Original code: {paste}

12. “Should this be split?” review

Below is a PR diff with N files changed. Decide whether it should be split into smaller PRs. Output: (1) verdict (ship / split into 2 / split into 3+), (2) the split lines I should cut along, (3) any change that should be its own commit even within one PR.

{paste}

13. Reviewer behavior audit (self-check)

Run on your own past review comments to spot patterns.

Below are 20 review comments I left this month. Cluster them: (1) what kind of issues I catch best, (2) what I systematically miss (security? perf? test design?), (3) tone patterns that may feel harsh, (4) 3 specific changes I should make to my review style.

{paste comments}

Common mistakes

  • “Review this code” with no focus
  • Skipping AI’s flagged “low confidence” items without checking
  • Letting AI propose rewrites in review mode
  • No severity scale — every finding looks equally urgent
  • Missing file:line in findings — you cannot verify and the bar drops

How to push results further

  • Always pin one lens per prompt — bugs OR security OR perf. Mixing dilutes signal.
  • Demand file:line on every finding. If the model cannot give it, the finding is likely hallucinated.
  • Add severity (Critical / High / Med / Low) to the prompt so AI ranks, not just enumerates.
  • For Claude Code / Cursor, let the agent Read the diff via git rather than pasting — full context, fewer truncations.
  • Run a second pass with the opposite reviewer persona (“now critique your own findings — which are weakest?”) to filter false positives.
  • For PRs > 500 lines, ask AI to first list the riskiest files, then review only those. Cuts noise.
  • Save the prompt + response in the PR thread — future reviewers see what AI already checked and don’t duplicate work.

FAQ

  • Does AI review replace human review?: No. Treat it as 80% — AI catches mechanical issues, humans catch product / intent / context drift. Pair both.
  • Can I run this on PRs from teammates?: Yes, but disclose: drop a note like “Ran AI pass for bugs + security — flagged X, Y.” Avoids stealth automation distrust.
  • Why does AI keep flagging style issues even when I say “skip style”?: Constraint drift. Add a closing line: “If your finding is about style/formatting, drop it from the output entirely.”
  • How long should review prompts be?: Prompt itself: 60-150 words. Pasted diff: under 1,500 lines per pass. Larger diffs go in chunks by directory.
  • What if AI suggests a fix I disagree with?: Don’t apply it. Reply in the same thread asking AI to defend the suggestion; if the defense is weak, you’ve confirmed the original code was fine.
  • Should I ever let AI auto-apply review fixes?: Only on lint-class issues (naming, unused imports). Never on logic/security fixes — auto-apply hides bugs you didn’t consciously accept.

Tags: #Prompt #AI coding #Code review

Related Articles