This Prompt Gets You Senior Engineer Code Reviews From Any AI
Why this prompt matters
Generic 'review my code' prompts produce generic responses: vague suggestions, no line references, no prioritisation. This prompt enforces a specific output structure that separates critical bugs from architecture concerns from style improvements — the same mental model a senior engineer uses when reviewing a PR. The 'What's Done Well' section is intentional: it keeps the feedback calibrated and makes it easier to act on criticism when you also know what to preserve.
What we use it for
Developers who want high-quality code review feedback without blocking on a colleague's availability. Works for any language or framework — paste the function, class, or diff and get structured, specific feedback in seconds.
Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows: **Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code. **Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode. **Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant. **What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note. Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why. [PASTE YOUR CODE HERE]
<p>Asking an AI to "review my code" produces the same generic output every time: a list of things to consider, with no prioritisation, no line references, and advice that could apply to any codebase. The prompt below solves this by enforcing the exact structure a senior engineer uses when doing a real pull request review.</p>
<h2>The prompt</h2>
<pre><code>You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows:
**Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code.
**Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode.
**Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant.
**What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note.
Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why.
[PASTE YOUR CODE HERE]</code></pre>
<h2>How to use it</h2>
<p>Replace <code>[PASTE YOUR CODE HERE]</code> with the function, class, module, or diff you want reviewed. Works best with Claude Sonnet, GPT-4o, and Gemini 2.5 Pro — all of which have enough context window to handle files up to a few hundred lines without needing to split them.</p>
<p>For larger files, paste the most critical section (the function with the bug, the new class, the changed method) rather than the entire file. If context is important, add a brief description before the code: "This is a Node.js Express middleware that handles authentication. The relevant database schema is users(id, email, password_hash, role)."</p>
<h2>Why the structure matters</h2>
<p>The four-section structure maps to how experienced engineers actually triage feedback. Critical Issues are blocking — they should be fixed before merge. Architecture Concerns are non-blocking today but become blocking at scale. Improvements are for the nice-to-have pass. Separating these prevents the common failure mode of AI code review where a style nitpick gets the same weight as a SQL injection vulnerability.</p>
<p>The instruction to show corrected code (not just describe the fix) is the most important constraint. Without it, AI reviewers tend to gesture at the problem — "the error handling here could be improved" — without telling you what to type. The corrected code requirement forces specificity.</p>
<h2>Adapting for specific contexts</h2>
<p>Add context at the top of the prompt for better results: specify the language and framework, the deployment environment (serverless, containers, embedded), performance constraints, or team conventions. For security-sensitive code, add "Pay particular attention to input validation, SQL injection, XSS, and authentication edge cases" to the Critical Issues section. For performance-critical paths, add "the function is called 10,000 times per second in production."</p>
<p>The prompt works across any programming language. It has been tested on Python, TypeScript, Go, Rust, Java, and SQL with consistent results across all three frontier models.</p>