Code review prompts

The task

You need a model to review code or a diff before it ships. The goal is not praise, refactoring trivia, or a summary. The goal is to find bugs, regressions, unclear ownership, and tests that should exist. If you are choosing a model or agent surface first, see which model for coding work.

Why the old approach is outdated

“Review this code” gives the model permission to comment on everything. It may spend attention on style while missing the behavior that changed.

Code review prompts work better when they say what kind of risk matters and what evidence the reviewer should cite.

For review output, ask for visible evidence and failure modes rather than hidden scratch work. The chain-of-thought and reasoning models concept explains that distinction.

The current approach

Review this diff like a production code review.

Focus on bugs, behavioral regressions, security or data-handling risk, and missing
tests. Ignore style-only comments unless they hide a real maintenance problem.

For each finding, cite the file and line, explain the failure mode, and state the
smallest fix. If you find no blocking issue, say that and list remaining test gaps.

<diff>
{{diff}}
</diff>

When to use a different model

Use ChatGPT or Codex surfaces when the review should connect directly to implementation or a larger coding workflow. Use Gemini when the review evidence includes diagrams, screenshots, or document images as well as code.

What to avoid

• Asking for compliments before findings.
• Letting the model rewrite the code before it names the bug.
• Asking for broad architecture advice on a small diff.
• Treating “no issues found” as proof. Run tests and inspect the risky paths yourself.