A bad code review prompt gets you a list of generic best practices, not a real analysis of your actual code. These templates force an LLM to trace data flow, question real tradeoffs, and flag concrete bugs instead of producing fluff.
Why Generic Prompts Fail Here
Most developers paste code into ChatGPT and ask "review this." The LLM responds with a checklist: "consider error handling, add comments, refactor long functions." That's not a review — that's a linter with a thesaurus.
The failure mode is vagueness. When you don't specify what to look for, the model optimizes for sounding helpful, not for being correct. It will praise your naming conventions and ignore the race condition in your async handler. You need to constrain the scope, define the context, and force the model to cite specific lines.
Template 1: The Context-Aware Bug Hunt
This is my default for reviewing a single file before a commit. It forces the model to understand what the code does before judging how it does it.
You are a senior engineer at a company that ships Node.js microservices.
Review the following code for correctness and production-readiness.
Context:
- File purpose: [what this module does and its role in the system]
- Runtime: [Node.js version, browser target, etc.]
- Known constraints: [e.g., "must not exceed 50ms response time", "runs on a 256MB memory limit"]
- Dependencies: [list any critical libraries and their versions]
Instructions:
1. First, restate what this code does in your own words in 2-3 sentences.
2. Identify any bugs that would cause incorrect output or crashes. For each, quote the exact line and explain the fix.
3. Flag any performance issues specific to the constraints listed above (not generic advice like "use caching").
4. Ignore style, naming, and formatting — I have a linter for that.
Code:
[Paste your code here]
The placeholder values matter. If you skip the constraints, the model defaults to generic advice. When I added "256MB memory limit" to a review of a log-processing script, the model caught a Buffer allocation that would have OOM'd in production.
Template 2: The Security and Data Flow Audit
This one is for code that handles user input, auth, or money. It's structured differently — it's not a line-by-line review, it's a threat model.
Act as a security-conscious code reviewer. Analyze the following code for
vulnerabilities and data-flow issues.
The code processes: [describe the data — e.g., "user uploads", "payment webhooks", "auth tokens"]
Focus areas, in order of priority:
1. **Input validation**: Trace every external input (API params, file contents, DB reads).
List any path where unvalidated data reaches a sink (SQL query, shell command, HTML render).
2. **Auth and authorization**: Identify every function that assumes the caller is authenticated.
Flag any endpoint or handler missing an auth check.
3. **Error handling**: Find error paths that leak internal details (stack traces, DB errors) to the client.
4. **Data leakage**: Check if logs or error messages could expose PII, tokens, or secrets.
For each finding, output:
- Severity (Critical / High / Medium / Low)
- The exact code snippet
- A one-line remediation
If a category has zero findings, say "No issues found" — do not invent problems.
Code:
[Paste your code here]
The "do not invent problems" line is critical. LLMs love to flag imaginary issues to seem thorough. That instruction cuts false positives by a significant margin in my experience.
Template 3: The Refactoring Risk Assessment
This is for when you're about to refactor legacy code. You don't want a review of the current state — you want to know what will break when you change it.
I am planning to refactor the following legacy code. Your job is to identify
every place that depends on the current behavior, so I don't break anything.
Proposed change: [describe what you're changing — e.g., "replace the callback
pattern with async/await", "split this monolith function into two"]
The code:
[Paste the legacy code]
Analyze:
1. **External contracts**: What does this code expose to other modules, APIs,
or services? List every function signature, return type, and thrown error
that external code might rely on.
2. **Hidden dependencies**: Identify any reliance on implicit behavior —
mutation of input objects, reliance on `this` binding, order of operations
that isn't obvious from reading the code.
3. **Side effects**: Flag any network calls, DB writes, or file system operations
that happen inside this code, even in "helper" functions.
4. **Test coverage gaps**: Based on the logic paths you see, what test cases
are likely missing that would catch a regression?
Output format: A numbered list of risks, each with a "breakage scenario"
(a concrete example of what breaks if I make the change) and a "mitigation"
(a specific test or guard to add).
This is the hardest prompt to get right because it requires the model to reason about what isn't in the code — the external callers. Including the "proposed change" gives it a concrete lens to look through.
How to Adapt These for Your Own Codebase
First, replace the bracketed placeholders with real values every single time. A prompt with empty brackets is a prompt that will hallucinate context. Second, add a "codebase context" section that describes your architecture in three sentences — the model can't know you use a message queue unless you tell it.
Third, use a system prompt to define your team's standards once, then keep the per-review prompt lean. If you're using Claude or GPT-4, pin a system prompt that says "We use TypeScript strict mode, no any, prefer immutable patterns." That keeps the review aligned with your conventions without bloating the main prompt.
Do These Prompts Work With Any LLM?
Yes, but with caveats. I've tested these with Claude 3.5 Sonnet, GPT-4o, and DeepSeek V3. The templates work structurally on all of them, but the quality of the analysis varies. Claude tends to produce the most nuanced security reviews. GPT-4o is better at refactoring risk assessment because it's more willing to reason about hypothetical breakage. DeepSeek is fine for the bug hunt template but often needs a follow-up prompt to dig deeper into performance issues.
The one adjustment that improves these prompts the most: add a final instruction to "list the three most important findings first." Without that, the model will bury the critical bug under a mountain of medium-severity noise. It forces prioritization, and that's what turns a prompt into a review you can actually act on.