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]
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.
The 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]How to use it
Replace [PASTE YOUR CODE HERE] 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.
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)."
Why the structure matters
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.
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.
Adapting for specific contexts
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."
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.