Prompt
You are a meticulous senior code reviewer. Review the diff below the way you would in a pull request — but you are a first pass before a human reviewer, not a replacement for one.

What this change is meant to do: {{intent}}
Language/stack and relevant team conventions: {{stack}}
Diff:
{{diff}}

Organize your review as:
- Correctness — logic errors, off-by-one, null handling, race conditions, wrong error handling.
- Edge cases and inputs — what unusual inputs or states would break this.
- Security — injection, unsafe deserialization, secrets in code, missing authorization or validation.
- Tests — what is untested that should be, with a concrete case for each gap.
- Readability and maintainability — naming, dead code, unclear intent.

For each finding give: severity (blocker / should-fix / nit), the file and line, and a specific suggested fix.

Rules:
- Only comment on lines present in the diff. Do not assume the behavior of code not shown; if a finding depends on unseen code, mark it "needs context" and phrase it as a question.
- Do not fabricate line numbers, function names, or standards citations. If you are unsure a finding is real, say so and lower its severity.
- Skip anything a linter or formatter would catch; focus on what a human reviewer would care about.

Fill in your details and the prompt updates live — then copy.

What you get back (excerpt)

Correctness — should-fix — services/auth.js line 20: verifyToken returns undefined on an expired token instead of throwing, so the caller treats expired as valid. Suggest throwing an AuthError. Edge cases — blocker — the email regex rejects addresses with a plus tag (user+tag@example.com); add a test for tagged addresses. Tests — should-fix — no test covers the empty-result branch added on line 42; add one asserting an empty set is returned. Security — needs context — confirm req.body.role cannot be set by the client; if it can, this is an authorization bypass.

The full workflow

  1. Generate the diff with git diff and confirm it contains no secrets or restricted code before pasting
  2. Give the model the change's intent so it can judge correctness, not just style
  3. Triage the findings yourself — dismiss the false positives and fix the real ones
  4. Send the improved change to a human reviewer; the AI pass supplements review, it does not replace it

Watch out for

AI reviewers both miss real bugs and invent ones that are not there — around a quarter of developers estimate roughly one in five AI suggestions are wrong or misleading, and even developers who rarely see errors will not merge without human review. Never let an AI pass substitute for a human reviewer or your own judgment.

Do not paste code covered by an NDA, customer data, or credentials into a consumer tool to get a review. Use an approved enterprise tool, and remember the merged diff is your responsibility, not the model's.

The model can cite a best practice or coding standard that does not exist. Verify any rule it invokes against a real source before you act on it.

Where this comes from

Every use case on this site is grounded in real reports from working software developers — not invented by us.

More AI use cases for software developers

← All 6 use cases: How Software Developers Use AI