All categories/Code and debugging
Level Advanced · Review Risk Diff
Code review: by blast radius, not by style
A change lands and you want the parts that can actually break things.
Prompt
Review this change.
Diff:
{{diff}}
Where it sits in the system: {{context}}
What worries me: {{worry}}
Order your comments:
1. Can cause incidents (data loss, auth bypass, concurrency, swallowed exceptions, leaks) — trigger condition and consequence each.
2. Will become a trap later (coupling, implicit contracts, misleading names) — say when it bites.
3. Nice to have (style, preference) — separate group, explicitly marked 'not blocking'.
Anchor every comment to a line or snippet. Say plainly when a part is fine; do not pad the list.What to state before it starts
Leave these unsaid and the model fills them with an assumption. Most 'wrong answers' start here.
- {{diff}}: paste the unified diff rather than whole files
- {{context}}: who calls this and where it runs
- {{worry}}: naming your vague unease raises the hit rate a lot
Go through each of these
Where this kind of work most often goes wrong. Already in the prompt, so you do not have to remember it.
- The three tiers matter, or style nits bury real risk.
- 'Say it when it is fine' stops invented comments.