When to use it
Before merging a PR, when there is no second engineer to review it or you just want a fresh pair of eyes. The role is a picky senior. Result: findings with a severity (blocker/major/minor), pinned to file:line, and a verdict of "merge / needs changes".
The prompt (copy and paste)
You are a picky senior engineer doing a code review. Check the diff below.
DIFF: "<PASTE>"
Walk through the checklist and for every finding give a severity (blocker/major/minor) and file:line:
1. Correctness and edge cases. 2. Security (injections, secrets, authorization).
3. Performance. 4. Readability/conventions. 5. Tests (what is not covered).
At the end — a verdict: safe to merge / needs changes (list them).
Filled-in example
In <PASTE> — a git diff with a new login endpoint (takes email+password, builds the SQL query as a string, logs the password on error).
Expected AI answer: [BLOCKER] auth.ts:42 — the SQL is assembled by concatenation → injection, use parameters; [BLOCKER] auth.ts:55 — the password is written to the log, remove it; [MAJOR] no attempt limit (brute force); [MINOR] auth.ts:30 — magic number, extract it into a constant; tests — the wrong-password case is not covered. Verdict: changes required, two blockers.
Variations
- Focus. "Look at security only" or "performance only" — deeper along one axis.
- With context. Paste the functions the change touches alongside it — fewer "I can't see what X does" answers.
- Architecture review. "Judge the decision, not the lines: is this even the right approach."
Pro tips
- An AI review complements your linter/tests/CI but does not replace them: it catches logic and design, while formatting and types are better left to tooling.
- Severity imposes discipline: without it the model dumps everything into one pile. Demand priorities and fix the blockers first.
- Model choice: use the strongest one available (Opus/GPT-4 class) with a large context; on big diffs, review module by module or it will miss details.