Prompt Code Review

Writing code-review prompts for LLMs

A code-review prompt is the instruction you give to ChatGPT, Claude or GitHub Copilot Chat so it inspects a diff before you open a pull request. The trend exploded in 2023 with GitHub Copilot Chat, then with Cursor agents and Aider, and finally with managed services like CodeRabbit, Greptile and Cody that drop in-line comments straight into the PR via GitHub Actions. The quality of the review depends almost entirely on the prompt: a vague “review this” produces generic checklists, while a structured prompt produces actionable suggestions.

A reusable template that works across models:

You are a senior {language} developer reviewing this PR.
Code:
```{language}
{code}
```
Review for:
1. Correctness / bugs
2. Performance issues
3. Security vulnerabilities (OWASP Top 10)
4. Readability and maintainability
5. Testing gaps
Provide actionable suggestions with line refs.

Specificity beats verbosity

Generic prompts produce generic feedback. Pin the style guide (PEP 8, Google Java Style, Airbnb JavaScript, gofmt), the framework version (Django 5.0, React 19, Spring Boot 3) and the project conventions (“we use Tailwind utility classes, no CSS modules”). For multi-file context use GitHub Copilot Workspace, Cursor or Aider — they pull surrounding files into the model context automatically.

Concern-specific prompt variants

• ORM heuristics: “Review for N+1 queries and missing select_related / eager-loading.”
• Concurrency: “Check for race conditions, missing locks, and incorrect async/await usage.”
• Security: “Look for SQL injection, XSS, SSRF, CSRF and broken authentication per OWASP Top 10.”
• Performance: “Suggest optimisations for the hot path and flag O(n²) loops.”
• Output formats: structured JSON (Cursor agents), Markdown bullets, inline GitHub PR comments via gh pr review --comment.

Common pitfalls of AI code review

LLMs do not run code, so they miss runtime issues, flaky tests and environment-specific bugs. They also produce false positives (suggesting fixes that break working code), missing context (project-specific patterns unknown to the model), and hallucinated APIs (recommending methods that do not exist in the library version you use). A useful mental model is the trust hierarchy: ML model alone < human reviewer alone < (model + passing tests) < (model + human + tests).

Anti-pattern: rubber-stamp approval — treating “LGTM by AI” as a green light. It produces false confidence and merges critical bugs. Use the LLM to surface candidates, not to decide.

Integration paths

• GitHub Actions + Anthropic/OpenAI API: on: pull_request + gh pr comment — drops review automatically.
• CodeRabbit, Greptile, Cody, Qodo — managed services with PR-level UI.
• Continue.dev, Cursor, Aider — IDE-level review before push.
• Claude in IDE via the Anthropic VS Code extension.

FAQ

Can the LLM replace the human reviewer? No — it complements. It is great at surface-level issues (style, obvious bugs, security checklist) but bad at architectural decisions and at understanding business intent.

Is it better to send the diff or the full file? The diff is better for PR context (shorter, focused), but include 5-10 lines of context around each change. Send the full file when the LLM needs to understand the broader structure (refactors, large rewrites).

Can the model auto-approve PRs? Technically yes, practically dangerous. Use it to flag risks and trigger human review. Auto-merging on LLM approval has already caused production incidents (security holes, broken builds).

Which model gives the best reviews? Claude 3.5 Sonnet, GPT-4o and Gemini 1.5 Pro perform similarly on benchmarks. The differentiator is the prompt and the context you provide — not the model.