How to Prompt AI to Review Your Code Before You Ship It

Before you merge, paste your diff into this prompt. Not the whole repository, not a vague "can you check this," but the diff plus a fixed structure that tells the model exactly what to look for: security, edge cases, naming, and missing tests.

A generic review request gets you a paragraph of praise and a couple of formatting nitpicks. A structured one gets you a list of specific problems, each with a line reference and a fix. This post gives you that structure: a copy-pasteable prompt that shows you how to prompt AI to review your code before you ship it, plus a small worked example so you can see exactly what it catches before you trust it.

Why "review this code" doesn't work

Ask a chat model to review code with no other instruction and you'll usually get something like: "This looks reasonable. You might want to add some error handling and a few more tests." That's true of almost any function ever written, which is exactly the problem. It's not a finding, it's a hedge.

Left open-ended, a model optimizes for sounding helpful rather than for being right. It agrees more than it disagrees, and it rarely tells you a function is fine when it actually is, because "looks good" is the safest thing to say. Giving it a fixed checklist and a required output format closes most of that gap. That's the same idea behind prompt engineering generally: the model does its best work when the job is concrete, not open-ended.

The review prompt

Copy this as-is. Fill in the three context lines, paste your diff at the bottom, and send it before you open the PR or hit merge.

You are reviewing a code diff before it ships. Review only the changes below, not the whole file.

Context:
- Language/framework: <e.g. Node.js + Express>
- What this change is supposed to do: <one sentence>
- Who will run this code: <e.g. internal tool, public API, side project>

Review the diff for exactly these four things, in this order. Skip a category only if there is genuinely nothing to say about it.

1. SECURITY: injection (SQL, command, template), unvalidated input, secrets or credentials in code, missing auth/authorization checks, unsafe deserialization.
2. EDGE CASES: empty, null, or undefined input; zero and negative numbers; very large input; concurrent calls; network or dependency failures; off-by-one errors.
3. NAMING AND READABILITY: names that don't describe what a variable holds or a function does, magic numbers, functions doing more than one job, anything a new teammate would have to ask about.
4. MISSING TESTS: which specific behaviors from the categories above aren't covered by a test yet, and the one or two test cases that would matter most.

For each issue: quote the line or snippet, explain why it matters in one plain-language sentence, and give a concrete fix as a code suggestion, not "consider improving this."

Do not comment on formatting a linter would already catch. Do not praise the code. If a category is genuinely clean, say so in one line and move on.

Diff:
<paste your diff here>

What each part of the prompt is actually doing

Every line in that template is there to close a specific failure mode of an unstructured ai code review prompt:

• "Review only the changes below, not the whole file" stops the model from re-explaining code you didn't touch, which pads the answer and buries the parts that matter.

• The four fixed categories force coverage of things people skip under deadline pressure. Security and missing tests are the two that get dropped first when a reviewer is rushing; naming them explicitly means the model can't skip them either.

• "Quote the line, explain why, give a fix" turns vague notes into something you can act on without a follow-up question.

• "Do not praise the code" matters more than it sounds like it should. Without it, a chunk of the response is filler agreement, which trains you to skim past the parts that aren't filler.

Adjust the four categories to your stack. A frontend change might swap "security" for accessibility and state management bugs. The structure is the point, not this exact list.

A worked example: before and after

Here's a small function with real, easy-to-miss problems, then what running it through the prompt above actually surfaces.

The original diff

function getUserOrders(email, page) {
  const offset = page * 10;
  const query = `SELECT * FROM orders WHERE email = '${email}' LIMIT 10 OFFSET ${offset}`;
  return db.query(query);
}

It works in a demo. Call it with a real email and page 1, and you get orders back. Nothing about it looks obviously broken.

What the review catches

• Security: the email is interpolated directly into the SQL string. Any value containing a quote breaks the query, and a crafted email string is a classic injection path. Fix: use a parameterized query, never string interpolation, for any value that comes from a request.

• Edge cases: page=0 produces an offset of 0 (fine, but probably not intended if pages are meant to start at 1), page=1 also produces offset 0, and a missing or non-numeric page value produces NaN, which most SQL drivers will either reject or silently coerce in a way nobody tested for.

• Naming and readability: the bare 10 appears twice with no name, so a future change to page size has to be made in two places by memory, not by search.

• Missing tests: there's no test for a page boundary, no test for a missing or malformed page argument, and no test that an email containing a quote character doesn't break the query.

After

const PAGE_SIZE = 10;

function getUserOrders(email, page = 1) {
  if (!email || typeof email !== 'string') {
    throw new TypeError('email is required and must be a string');
  }
  const pageNumber = Math.max(1, Number(page) || 1);
  const offset = (pageNumber - 1) * PAGE_SIZE;
  const query = 'SELECT * FROM orders WHERE email = $1 LIMIT $2 OFFSET $3';
  return db.query(query, [email, PAGE_SIZE, offset]);
}

Four lines of original code produced four separate, fixable findings. That ratio is normal for code that hasn't had a second pair of eyes on it yet, AI or human.

Using it in a real pull request workflow

Run this per diff, not per repository. If you prompt AI for a code review on a 2,000-line PR in one shot, the response gets shallow and starts missing things in the middle of the diff, the same way a tired human reviewer does. GitHub's own guidance on working with Copilot makes the same point about breaking large reviews into logical chunks rather than reviewing everything at once.

A few habits make this stick as a real ai pull request review prompt instead of a one-off you run when you remember to:

1. Run it before you open the PR, not after a reviewer has commented. Fixing findings first saves a review round trip.

2. Keep the context lines honest. Calling a public endpoint an "internal tool" makes the security review under-weight exactly what matters most.

3. Treat a clean report as a starting point, not a signoff. "Nothing to flag" from a model that never ran the code is a different claim than "a human ran this and it works."

If the finding touches something that handles user data, pair the fix with a record of who changed it and why; that's a separate concern from the review itself, covered in how to add an audit log to an AI-built app.

The same discipline extends past code. Once you're comfortable writing a review prompt like this one, the natural next step is applying the same structured-checklist approach to prompting AI to check its own work on non-code output, like drafts or generated reports.

And if you run this prompt for a few weeks and the findings quietly get vaguer, that's usually not the model drifting, it's the prompt losing its edge as your codebase and context change. How to debug a prompt that stopped working covers how to diagnose that.

Where a single prompt stops being enough

This prompt assumes a human is still in the loop: you paste the diff, you read the findings, you decide what to fix. That's a different setup from autonomous coding agents that open their own pull requests, where the agent writes the code, reviews it, and proposes the merge with less of a human checkpoint in between. If you're evaluating that kind of tooling, treat this prompt as the manual technique underneath it, not a competing option.

It's also solving a different problem than reviewing code an AI already wrote for you. This prompt reviews your diff, regardless of who or what wrote it. How to review AI-generated code before you ship it is about the failure patterns specific to AI-authored code and a five-minute human process for catching them. Use that one when the code came out of a coding assistant; use this prompt whenever you want a second pass on any diff before it ships.

Anthropic's Claude Code docs describe a similar structured approach: a code review setup that runs focused checks against a diff instead of one open-ended pass, with a confidence threshold to filter low-value nitpicks. GitHub's Copilot best-practices guide recommends the same targeted approach: ask for one category at a time, not a blanket "review this." For the security line specifically, the OWASP Top 10:2025 is the current reference for which vulnerability classes actually show up most, including broken access control and software supply chain failures.

FAQ

Does an AI code review prompt replace a human reviewer?

No. It catches a useful slice of problems fast and cheaply before a human looks at the diff, so the human review that follows is shorter and focused on judgment calls, not typos and missed null checks. It doesn't know your team's unwritten conventions or the reason a workaround exists.

What if I don't have a diff, just a file?

Paste the whole file and change the first line to "Review the code below" instead of "Review only the changes below." The four-category structure still applies; you just lose the "only what changed" scoping, so expect a longer response on a large file.

Which AI model should I use for this?

Any current model with a context window large enough to hold your diff comfortably. The structure of the prompt matters more than the specific model. If your coding assistant already has a built-in review command, this template still works as a manual fallback or for reviewing code outside that tool.

How big can the diff be before this stops working well?

Once a diff crosses a few hundred lines, split it. Review one logical change at a time, such as one function or one endpoint, rather than a whole feature branch in one pass. Findings get noticeably shallower on long diffs, the same failure mode a rushed human reviewer has.

Can I use this for a security-only review?

Yes. Drop categories 2 through 4 and keep the security section, or add specific concerns from the OWASP list relevant to your app. A narrower prompt with one job tends to catch more in that one category than a four-category prompt does.