A Better Code Review Prompt Uses a Diff and a Risk Checklist

“Review my code” often produces a mixture of style suggestions and speculative bugs. A review is more useful when it has a diff, a purpose, and a priority rule. If the diff is hard to understand, Prompt AI to Explain Code Without Inventing What It Does starts with observable behavior rather than guessed intent.

Suppose I changed the scoring formula. I provide a diff and ask: Review the changed lines for behavior regressions. The intended behavior is: nonnegative integer seconds, 100 points at 0, subtract 2 per second, floor at 0. Report only defects you can demonstrate from the diff or a concrete test. For each finding, give the affected line, input that triggers it, observed versus expected result, and severity. Do not spend the review on formatting. This discourages generic “consider adding comments” feedback when the real risk is an off-by-one error or negative output.

A diff alone may omit helper definitions and assumptions. Include the changed function, relevant tests, and a short description of how it is used. If a finding depends on unavailable code, the model should label it as a question, not a confirmed bug.

I verify each finding by running its proposed input or inspecting the code. A review can miss bugs and invent them. Severity should reflect impact on users and how likely the condition is, not the intensity of the model's language.

After behavior review, I might ask separately for readability improvements. Mixing defect detection and style in one pass can make the high-risk findings harder to see. Try it: Give AI a small, non-sensitive diff and a three-item risk checklist. Ask for at most five actionable findings, each with a test case. Reject any finding that lacks evidence. Keep learning: Prompt AI to Explain Code Without Inventing What It Does, Debugging With AI: Reproduce the Bug Before Requesting a Fix, and Use AI to Draft Tests, Then Challenge the Tests.