Code review is the last human checkpoint in the delivery pipeline, and it is also the one that gets squeezed the most. When a team is shipping fast, reviews are rushed, comments are shallow, and critical issues slip through into production. AI assistants can take on a large share of this work, but only if you ask them correctly. The difference between a useless AI review and a genuinely useful one is almost always the prompt: generic instructions produce generic analysis, while specific prompts produce specific findings.
This guide is about writing code review prompts that work. We will cover why generic prompts fail, how to set up persona and context, how to define quality criteria, and how to build prompts for security, performance, readability, and architecture. Every section includes patterns you can adapt to your own codebase.
Why Generic Prompts Produce Generic Reviews
Ask an AI assistant to "review this code" and you will get a review that could apply to any file in any project: some vague notes on naming, a reminder to add error handling, and a closing remark that the code "looks good overall." None of that is actionable, and none of it reflects the risks that actually matter in your system.
The reason is simple: the model has no idea what your project values. It does not know whether this code handles payment data, whether the endpoint runs at high traffic, whether the team prefers composition over inheritance, or what failure looks like in production. Without that context, the model optimizes for generic code quality, which is a poor proxy for your actual review criteria. Specific prompts fix this by supplying the missing context and the specific lens you want applied.
Build the Foundation: Persona and Context
Every good review prompt starts by defining who the assistant is and what it should focus on.
The persona prompt
Instead of a generic reviewer, assign a specific role. A prompt like "You are a senior security architect reviewing a pull request for a public-facing API" produces different findings than "You are a staff engineer focused on maintainability." The persona sets the priority order: a security architect will hunt for injection, auth, and data exposure, while a maintainability engineer will focus on structure and readability. Choose the persona to match the risk you want to address in this review.
Project context and constraints
Supply the facts the model cannot infer: what the system does, what framework and language are used, what the team's conventions are, and what constraints exist. A line like "This service handles user-submitted content in Python, uses the Django framework, and must keep request latency under 200 milliseconds" changes the entire review. The model can then judge the code against real requirements instead of generic best practices.
Set Quality Standards and Metrics
For a review to be useful, the criteria must be explicit and, where possible, measurable. Tell the model what the team considers good: linting standards, complexity thresholds, test coverage goals, and architectural principles such as SOLID or domain-driven design.
Ask the model to grade findings by severity and to distinguish between blocking issues, should-fix issues, and nits. A review that says "three critical issues, two of which would cause data loss in the retry path" is actionable; a list of ten equal-weight observations is not. Explicit standards also make the review comparable across runs, which is what you need if you want to measure whether code quality is improving over time.
Security-Focused Review Prompts
Security reviews need their own prompt structure because the failure modes are specific. Ask the assistant to role-play a security reviewer and to trace data flows from input to storage or external call. Request checks for injection, authentication and authorization bypass, unsafe deserialization, secrets in code, and improper error handling that leaks internal information.
Make the scope concrete: "Assume this code is reachable by unauthenticated users. Identify every path where user input reaches a database query, a shell command, or a response body." This forces the model to think like an attacker rather than a reader. Ask for evidence, not opinions: for each finding, request the exact lines and the scenario that triggers the problem.
Performance and Scalability Prompts
Performance reviews require the model to reason about data volumes and access patterns. Tell it the expected scale: requests per second, rows in the relevant tables, payload sizes. Then ask for specific analysis: N+1 query patterns, missing indexes, accidental O(n) operations inside loops, unbounded result sets, blocking calls in hot paths, and resource leaks.
A strong pattern is to ask for a cost model: "For each function in this module, estimate its cost at 10x the current traffic and identify which one fails first." This turns the review into an exercise in reasoning about bottlenecks, which is far more useful than a generic list of performance tips.
Readability and Architectural Compliance Prompts
For readability, ask the model to review as a maintainer who will own this code in six months. Request an assessment of naming, function length, comment quality, and the readability of control flow. Ask for concrete refactor suggestions, not just criticism: "Suggest the smallest refactor that makes this function readable."
For architecture, supply the intended design and ask for compliance checks. "This module is supposed to follow a repository pattern and keep business logic out of controllers. Identify every violation." Architecture reviews work best when the prompt states the intended structure explicitly; without it, the model invents its own idea of good architecture, which may conflict with your design.
Handle Large Codebases: Chunking and Context
Long files and large diffs defeat even good prompts. The model can only reason about what fits in its context window, and context crammed with unrelated code produces diluted reviews. Solve this by chunking: review file by file, or by feature, with a shared project brief included in each prompt.
Define the review unit before you start. A common split is per-file for implementation details and per-feature for cross-cutting concerns like auth or error handling. Keep a standing project brief, a short paragraph with the system description and conventions, and prepend it to every review prompt. This gives each chunk the context it needs without blowing up the window.
Iterate: Measure and Improve Your Prompts
Prompts are code, and they deserve the same treatment: version them, test them, and improve them. Start by running your prompt on a known buggy commit and checking whether it finds the planted issues. That calibration run tells you if the prompt is sharp enough.
Track two numbers: the precision of findings (how many are real issues) and the coverage of known risk areas. If the model misses security issues on a security-focused prompt, tighten the scope and add explicit checks. If it cries wolf, add constraints and ask for severity ranking. Keep the winning versions in your team's documentation so the review process improves even as people change.
Ready-to-Use Prompt Templates
Here are three templates to start with.
Security review: "Act as a senior application security engineer. This [service] is reachable by unauthenticated users and handles [data type]. Review the attached code for injection, auth bypass, unsafe deserialization, secret leakage, and information disclosure. For each finding, give the trigger scenario, severity, and suggested fix. Ignore style issues."
Performance review: "Act as a performance engineer. This endpoint handles [requests per second] and queries a table with [rows]. Identify N+1 queries, missing indexes, accidental quadratic behavior, unbounded reads, blocking calls in hot paths, and resource leaks. Estimate which function fails first at 10x traffic."
Readability and architecture review: "Act as a senior maintainer. The project uses [stack] and follows [conventions/architecture]. Review for readability, naming, function length, and compliance with our intended structure. For each issue, propose the smallest fix. Distinguish blocking, should-fix, and nit."
Reviewing Tests, Errors, and Edge Cases
Code review prompts that only look at production code miss a whole class of problems. The tests, the error handling, and the edge cases are where the real risks hide, and they deserve their own prompts.
Ask for a test review with a specific lens: "Review the tests for this change. List the behaviors that are tested, then list the behaviors that should be tested but are not: failure paths, boundary values, permission checks, and state transitions. Identify tests that pass without actually asserting anything." Weak tests are a common source of false confidence, and a model focused on test quality will find them faster than a human skimming a diff.
Error handling deserves a separate pass. Ask the model to trace every error path: what happens when the database times out, when a third-party API returns an unexpected shape, when a required field is missing, when the queue is full. For each path, request the exact behavior: is the error caught, logged, and translated into something the caller can act on, or does it crash the process or leak internals?
Edge cases are where the specificity of your prompt pays off. Tell the model the boundary conditions of your domain: empty inputs, maximum sizes, duplicate records, concurrent writes, timezone boundaries, pagination overflow. Ask it to check each one against the code. A prompt that lists your known edge cases will reliably surface the ones the code does not handle.
Integrating AI Review into the Team Workflow
The best prompt in the world produces nothing if the review results do not reach the right people at the right time. Integration is a workflow problem as much as a prompt problem.
Start by defining when AI review runs. The most useful point is right after a pull request is opened, before human reviewers spend their attention: the AI does the mechanical pass, the human does the judgment pass. Some teams also run a lighter AI check on every commit for obvious issues, reserving the full review for pull requests.
Route the output where decisions happen. Post findings in the pull request thread, tag the owner for critical issues, and keep a summary in the commit message or the review log. Findings that live only in a chat window or a scratchpad will be ignored; findings that appear in the review thread get addressed.
Define the escalation rules explicitly. Critical findings should block merge until resolved, should-fix findings should be resolved in the same iteration, and nits should be batched so they do not create noise. If the AI produces too many false positives, tune the prompt before you tune the workflow; teams stop trusting a tool that cries wolf.
Finally, review the reviewer. Once a quarter, compare the AI's findings against the issues that actually caused incidents or rework in production. That comparison tells you which prompts are earning their keep and which lenses need to be sharpened.
Frequently Asked Questions
How much context should I include? Enough that the model never has to guess your stack or your conventions, but no more. A project brief of a few sentences plus the specific review scope is usually right.
Should I use AI review as a gate before human review? Yes, as a first pass that catches mechanical and obvious issues. Keep the human reviewer for judgment calls, design trade-offs, and team-specific knowledge.
What if the AI misses issues? It will. No review tool catches everything. Combine AI review with targeted human review, tests, and static analysis, and treat the AI as one layer, not the whole gate.
Can I trust severity ratings? Use them as a triage hint, not a verdict. Severity depends on context the model may not fully have, so have a human confirm anything marked critical.
How do I keep prompts consistent across the team? Store them in the repository or team documentation, version them, and update them when the project's standards change.
The value of AI code review is not automation for its own sake; it is raising the floor of every review so humans can spend their attention where it matters most. Specific prompts are the difference between an assistant that summarizes and an assistant that audits. Build the context, define the lens, measure the results, and the review process will get better with every iteration.
