5 Prompt Patterns for AI-Assisted Code Review

AI won't replace human code reviewers, but it can catch a surprising number of issues before a human ever looks at the code. The problem is that most developers paste in code and say "review this," which produces vague, surface-level feedback that's mostly about naming conventions.

The real power of AI code review comes from targeted prompts. Instead of asking for a general review, you ask for a specific type of review — security, performance, readability, bug detection, or architecture. Each produces deeper, more actionable feedback than a single "review everything" prompt.

These five patterns are designed for working developers who want useful feedback, not AI theater.

Pattern 1: The Security Audit

This pattern checks code for common vulnerabilities. It's not a replacement for proper security tooling, but it catches issues that are easy to miss during regular development.

You are a senior application security engineer conducting a code review.

Review the following code for security vulnerabilities:

[Paste your code here]

Check specifically for:
1. Injection vulnerabilities (SQL injection, XSS, command injection)
2. Authentication and authorization flaws
3. Sensitive data exposure (hardcoded secrets, logging PII, insecure storage)
4. Input validation gaps
5. Insecure dependencies or patterns

For each issue found:
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Line number(s) affected
- Description of the vulnerability
- Concrete fix (show the corrected code)

If no issues are found in a category, skip it — don't invent problems. Only flag real concerns.

Why it works: The checklist of five categories ensures comprehensive coverage. Requiring line numbers and corrected code makes the feedback immediately actionable. The instruction to skip empty categories prevents the AI from padding the review with non-issues to seem thorough.

Example output snippet:

CRITICAL — SQL Injection (Line 23)

The query concatenates user input directly: query = f"SELECT * FROM users WHERE id = {user_id}"

>

Fix: Use parameterized queries:

python

> cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
>

Pattern 2: The Performance Reviewer

This pattern identifies code that works correctly but could be significantly faster or more resource-efficient. It's particularly useful for code that handles large datasets or runs in hot paths.

You are a performance engineer reviewing code for efficiency.

Here is the code and its context:
- Language/framework: [e.g., "Python 3.12 with pandas"]
- Expected data scale: [e.g., "processes 100K+ rows per run"]
- Current performance concern: [e.g., "takes 45 seconds, needs to be under 10"]

[Paste your code here]

Identify performance issues in order of impact (biggest bottleneck first):

For each issue:
1. What's slow and why (be specific — O(n²) loop, unnecessary memory allocation, etc.)
2. Suggested optimization with code example
3. Expected improvement (order of magnitude estimate is fine)

Also flag:
- Any unnecessary allocations or copies
- Opportunities for caching, batching, or lazy evaluation
- Database queries that could be optimized (N+1 problems, missing indexes)

Don't suggest micro-optimizations that sacrifice readability for negligible gains. Focus on changes that would make a meaningful difference at the stated scale.

Why it works: Providing the data scale lets the AI calibrate its advice — O(n^2) matters at 100K rows but not at 50. Ordering by impact ensures the biggest wins come first. The instruction against micro-optimizations prevents the AI from suggesting things like replacing for loops with map() for trivial performance gains.

Example output snippet:

Issue 1: N+1 Query Pattern (Lines 34-41) — High Impact

The loop executes a separate database query for each item in the list. At 100K items, this means 100K individual queries.

>

Fix: Batch the IDs and use a single WHERE IN query:

python

> item_ids = [item.id for item in items]
> results = db.query(Item).filter(Item.id.in_(item_ids)).all()
>

Expected improvement: ~100x faster (1 query vs 100K queries)

Pattern 3: The Readability Reviewer

This pattern focuses on code clarity — making code easier to understand, maintain, and modify. It's especially useful for code that other team members will need to work with.

You are a senior developer reviewing code for readability and maintainability.

Review this code as if a new team member will need to understand and modify it next month:

[Paste your code here]

Evaluate:
1. **Naming**: Are variable/function names clear and descriptive? Flag any ambiguous names.
2. **Complexity**: Are there functions doing too many things? Suggest how to break them up.
3. **Comments**: Are there missing comments where intent isn't obvious? Are there unnecessary comments that just restate the code?
4. **Structure**: Is the code organized logically? Could the flow be simplified?
5. **Error handling**: Are failure cases handled clearly, or are they swallowed/ignored?

For each suggestion:
- Quote the specific code
- Explain why it hurts readability
- Show the improved version

Focus on changes that genuinely improve comprehension. Don't flag style preferences that are subjective (e.g., single quotes vs double quotes).

Why it works: The "new team member" framing sets the right bar for clarity — it's not about perfection, it's about comprehensibility. Asking the AI to distinguish between genuinely confusing code and subjective style preferences prevents nitpicky feedback that wastes time.

Example output snippet:

Naming — Line 12: d is ambiguous

javascript

> const d = calculateDaysBetween(start, end);
>

Rename to communicate the meaning:

javascript

> const daysBetweenDates = calculateDaysBetween(start, end);
>

>

Complexity — Lines 45-89: processOrder() does four distinct things

This function validates input, calculates pricing, applies discounts, and saves to the database. Extract each into a separate function with a clear name.

Pattern 4: The Bug Hunter

This pattern specifically looks for logical errors, edge cases, and conditions that could cause failures. It's different from a general review because it's adversarial — it actively tries to break the code.

You are a QA engineer trying to find bugs in this code. Your job is to break it.

[Paste your code here]

Try to find:
1. **Logic errors**: Conditions that produce wrong results for valid inputs
2. **Edge cases**: What happens with empty inputs, null values, negative numbers, extremely large values, or concurrent access?
3. **Off-by-one errors**: Array bounds, loop conditions, string slicing
4. **Race conditions**: Any shared state that could cause issues under concurrency
5. **Unhandled states**: What happens when assumptions are violated? (e.g., API returns unexpected format, file doesn't exist)

For each potential bug:
- Describe the exact input or condition that triggers it
- What actually happens vs what should happen
- Suggested fix

If the code handles an edge case correctly, don't flag it. Only report genuine risks.

Why it works: The adversarial framing ("try to break it") produces more thorough analysis than asking the AI to "review" the code. Requiring specific trigger conditions prevents vague warnings like "this might have issues with edge cases." The explicit list of bug categories ensures the AI checks all common failure modes.

Example output snippet:

Edge Case — Empty Array Input (Line 8)

calculateAverage(items) divides by items.length without checking for an empty array. Passing [] causes a division by zero, returning NaN.

>

Trigger: calculateAverage([])

Expected: Return 0 or throw a descriptive error

Actual: Returns NaN, which propagates silently through downstream calculations

>

Fix:

javascript

> function calculateAverage(items) {
>   if (items.length === 0) return 0;
>   return items.reduce((sum, item) => sum + item, 0) / items.length;
> }
>

Pattern 5: The Architecture Review

This pattern zooms out from individual lines to evaluate the overall design — how components interact, where coupling is too tight, and whether the structure will scale.

You are a senior software architect reviewing code structure and design.

Here is the code (multiple files are fine — paste each with its filename):

[Paste code with filenames]

Context:
- This code is part of: [Brief description of the system]
- Expected growth: [How will usage/data/features scale?]
- Team size: [How many developers work on this?]

Evaluate:
1. **Separation of concerns**: Are responsibilities cleanly divided, or are there modules doing too much?
2. **Coupling**: How tightly are components connected? Could you change one without breaking others?
3. **Extensibility**: How easy is it to add new features or modify existing behavior?
4. **Error propagation**: Do errors flow clearly, or could failures in one component cascade unpredictably?
5. **Scalability concerns**: What will break first as load increases?

Format your review as:
- **Strengths**: What's well-designed (start positive)
- **Concerns**: Ranked by severity, with specific refactoring suggestions
- **Recommended next refactor**: The single highest-impact structural improvement to make

Why it works: Including context about growth and team size helps the AI calibrate its advice — a solo developer's project doesn't need the same abstraction layers as a 20-person team's. Starting with strengths makes the review more balanced and productive. The "single highest-impact refactor" prevents analysis paralysis.

Example output snippet:

Strengths:

- Clean separation between API routes and business logic

- Consistent error handling pattern across all service methods

>

Concerns (by severity):

1. The UserService directly imports and calls EmailService, PaymentService, and AuditService. This tight coupling means you can't test user logic without mocking three external services. Consider an event-based approach where UserService emits events that other services subscribe to.

>

Recommended next refactor: Extract the notification logic from UserService into an event system. This single change decouples three services and makes the user flow testable in isolation.

Quick Tips for Code Review Prompts

• Include the language and framework. "Review this code" is ambiguous. "Review this TypeScript/Next.js API route" tells the AI what conventions and security patterns to check for.
• Provide context about what the code does. Even a one-sentence description helps the AI understand intent vs implementation, which is where bugs hide.
• Don't paste entire codebases. Focus on the module, function, or file you want reviewed. More focused input produces more useful output.
• Ask for severity ratings. Without them, the AI treats a typo in a comment the same as a SQL injection vulnerability.
• Run multiple patterns on the same code. A security review and a bug hunt will catch different issues. They're complementary, not redundant.

When to Use Templates vs. Write From Scratch

Use these patterns when:

• You want a structured second opinion before opening a pull request
• You're reviewing your own code and need a checklist to catch blind spots
• Your team doesn't have a formal code review process and you want to establish one

Write from scratch when:

• The review needs deep domain knowledge about your specific architecture
• You're reviewing code that interacts with proprietary systems the AI can't understand
• You need a review focused on a very specific concern (e.g., "will this migration work with our Postgres version?")

For teams that run AI code reviews regularly, SurePrompts' Template Builder lets you save customized review prompts with your team's specific standards, security requirements, and coding conventions built in.