A Code Review Prompt That Finds Bugs (Not Nitpicks)

Source: Dev.to

Most “AI code review” prompts produce… vibes.

You paste a diff and you get:

• “Nice work!”
• “Consider naming this better”
• “Add comments”

Meanwhile the actual bug is a missing null check or an off‑by‑one in pagination.

Here’s a code review prompt that’s biased toward finding real defects, with a workflow you can reuse.

Mindset: reviewers don’t read, they hunt

Good reviewers scan for:

• incorrect assumptions at boundaries (nulls, empty arrays, timezones, encoding)
• security footguns (authZ, injection, SSRF, secrets)
• concurrency issues (double writes, retries, idempotency)
• performance cliffs (N+1, unbounded loops, missing indexes)
• test gaps (no failing test for the bug you think you fixed)

So we’re going to tell the model to do exactly that.

Prompt (copy/paste)

Use this as‑is, then tweak the repo‑specific checklist.

You are doing a production PR review as a senior engineer.
Goal: find defects and risky assumptions, not style nitpicks.

Context:
- Language/runtime: 
- Frameworks: 
- Critical paths: 

Input:
1) PR description:

2) Diff (unified):

Review rules:
- Prioritize correctness, security, reliability, and performance.
- If you’re unsure, ask a targeted question instead of guessing.
- Do NOT suggest renames unless it prevents a bug.

Output format:
A) Top 5 risks (most severe first)
B) Concrete review comments (bullet list). Each comment must include:
   - what could break
   - why
   - a minimal fix suggestion
C) Test plan: 6‑10 tests I should add or run
D) One “red team” scenario: how a malicious/chaotic user could break this

That output format matters. It forces the model to commit to why something is risky.

Make it even better: add a repo‑specific checklist

Most bugs in a codebase are repetitive. Add this after “Review rules”:

Repo-specific checks:
- Dates are always UTC internally; never parse locale strings.
- All external requests must have timeouts.
- Any write endpoint must be idempotent under retries.
- Avoid N+1 DB queries.
- Logs must not include PII.

You can build this list over time from your post‑mortems.

A practical example: review a pagination change

Let’s say a PR modifies a GET /users endpoint.

A “nice” review might say: “Looks good, add docs.”
A useful review hunts for:

• what happens when limit is 0 or 5000?
• does cursor decode safely?
• can users enumerate other tenants?
• is ordering stable across pages?
• are we leaking PII fields?

If your prompt doesn’t steer the model toward these questions, it won’t reliably find them.

The two‑pass trick (this is where it gets spicy)

Pass 1: defect hunter – use the prompt above.

Pass 2: minimal patch author

Given your review comments, propose a minimal follow‑up diff.
Rules:
- Focus only on the top 1‑2 risks.
- Keep the diff under ~120 lines.
- Include tests.
Output a unified diff.

This prevents the “let’s refactor the whole module” problem.

Tooling tip: make it easy to paste the right context

If you’re doing this often, create a tiny script that:

• grabs the PR diff
• grabs the PR description
• injects them into your template

Even a manual copy/paste workflow gets 80 % of the benefit, but the consistency is what makes it a habit.

What to watch out for

• If you don’t give critical context (“this touches auth”), the model won’t prioritize it.
• If you paste too much, you’ll get shallow output. Prefer the diff + a 5‑line description.
• If the model is uncertain, that’s a feature. Treat “unclear” as a cue to add a test or a guard.

If you want more prompts like this (debugging, spec‑writing, refactors, test generation), I’m building a Prompt Engineering Cheatsheet at Nova Press.

Free sample: