Code Review Prompt Templates: Use AI to Find Bugs, Risks, and Maintainability Issues

Overview

An AI code review is most useful when the prompt gives the model a defined role, enough repository context, a specific review goal, and a structured output format. A vague request such as review this code may produce a long list of general observations. A focused prompt is more likely to surface findings that a developer can reproduce, prioritize, and act on.

Before using any template, prepare the smallest useful review package: the changed code, relevant surrounding functions, the diff, applicable language or framework conventions, and tests that describe expected behavior. Avoid including secrets, credentials, private keys, production data, or unrelated proprietary material. If the model does not have repository access, state what it cannot inspect rather than asking it to infer missing context.

The templates below are designed to be adapted rather than copied unchanged. Replace the bracketed fields with details from the pull request, then ask the model to distinguish confirmed issues from risks that require verification. For broader prompt design patterns, see this AI prompt templates guide for developers.

Checklist by scenario

1. General pull-request review

Use this as a first-pass review when you want coverage across correctness and maintainability:

Act as a careful senior software reviewer. Review the following pull request for correctness, regressions, security concerns, test gaps, performance problems, and maintainability issues.

Context:
- Repository or service: [name]
- Language and framework: [details]
- Intended behavior: [short description]
- Relevant constraints: [compatibility, latency, database, or deployment constraints]

Review only the supplied diff and context. For each finding, provide:
1. Severity: blocker, high, medium, low, or informational
2. File and line or code location
3. The specific problem
4. Why it matters
5. A minimal suggested fix
6. A validation step or test

Separate definite issues from questions and possible risks. Do not praise unchanged code, and do not report style preferences unless they affect readability, correctness, or project conventions.

This format encourages actionable findings instead of an unranked collection of comments. The request to identify a validation step is especially useful: it gives the human reviewer a way to test whether the concern is real.

2. Bug and regression analysis

For debugging prompts, describe the expected behavior and include the failure mode if known:

Analyze this change for defects and regressions.

Expected behavior: [what should happen]
Observed behavior: [error, incorrect output, or user-visible symptom]
Previous behavior: [what changed, if known]
Inputs and edge cases: [examples]

Trace the relevant control flow and identify the smallest code path that could produce the problem. Return:
- suspected cause
- evidence from the supplied code
- conditions required to reproduce it
- a minimal fix
- tests that would confirm or reject the diagnosis

If the evidence is insufficient, list the missing information instead of presenting a guess as a confirmed bug.

3. Security-focused review

A security prompt should name the trust boundaries and data types involved. It should not ask the model to declare code safe in general:

Review this change for security weaknesses. Focus on input validation, authorization, authentication assumptions, injection risks, sensitive-data exposure, unsafe file or network operations, dependency usage, and error handling.

Trust boundaries: [browser to API, user to admin action, service to database, and so on]
Sensitive data: [types of data handled]
Threat assumptions: [relevant attacker capabilities]

For each concern, explain the attack path, the affected input or permission boundary, and a practical remediation. Mark findings as confirmed, plausible, or requires verification. Do not infer that a control exists unless it appears in the supplied code or context.

Use a separate security review rather than assuming that a general code review will cover threat modeling. For application-level prompt risks, consult the prompt injection defense guide when the reviewed software includes an LLM or agent.

4. Test coverage and test quality

Ask the model to map behavior to tests, not merely count test files:

Review the changed code and existing tests for coverage of intended behavior.

Identify:
- important paths without a test
- boundary and invalid-input cases
- authorization or failure paths
- tests that may pass without proving the expected behavior
- missing regression tests for the reported change

For each gap, propose a concise test case with setup, action, expected result, and cleanup. Prefer tests that fit the existing project style. Do not recommend tests for behavior that is outside the stated scope.

5. Performance review

Performance findings need workload context. Include expected scale, frequency, and resource constraints where available:

Inspect this change for avoidable performance problems under the following workload: [request volume, data size, concurrency, or batch characteristics].

Check for inefficient queries, repeated computation, unnecessary allocations, blocking operations, unbounded loops, excessive network calls, and poor caching decisions. For each finding, state the likely cost, the condition under which it matters, and how to measure it. Do not recommend optimization when the supplied context does not establish a meaningful bottleneck.

6. Accessibility and user-facing behavior

For interface code, ask for a review of interaction and communication, not just markup:

Review this user-facing change for accessibility and inclusive interaction. Check keyboard operation, focus behavior, labels, names and roles, color or visual-only cues, error messages, loading states, responsive behavior, and screen-reader clarity.

For each issue, identify the affected user interaction, the code location, and a concrete remediation. Distinguish a demonstrated problem from a potential issue that needs testing with the relevant browser, assistive technology, or device.

7. Maintainability and design review

Use this template when the code works but may create future cost:

Review this change for maintainability. Look for unclear responsibilities, duplicated logic, hidden coupling, misleading names, excessive complexity, fragile assumptions, and deviations from the supplied project conventions.

Rank only issues that are likely to affect future changes, debugging, testing, or safe reuse. For each one, explain the maintenance risk and suggest the smallest refactoring that improves the design without expanding the task unnecessarily.

What to double-check

AI-generated review comments are hypotheses until a developer verifies them. Use this checklist before creating an issue or changing code:

• Reproduce the claim. Follow the stated execution path with a realistic input, test, or local experiment.
• Check the full context. A nearby helper, validation layer, type definition, or framework guarantee may resolve the apparent problem.
• Confirm the line and version. Make sure the comment applies to the current diff, not an earlier revision or unchanged code.
• Test severity. A theoretical risk may be low priority if its preconditions cannot occur in the application, while a small logic error may deserve immediate attention.
• Look for duplicates. Multiple prompts or models may describe the same underlying issue in different words.
• Review proposed fixes. A suggested patch can introduce a new race condition, weaken validation, or violate an existing interface.
• Protect sensitive context. Remove secrets and unnecessary personal or production data before sending code to a model or tool.

For repeatable workflows, save representative pull requests and expected findings as a small evaluation set. Then compare prompt changes using criteria such as factual accuracy, useful coverage, false-positive rate, severity calibration, and output consistency. The prompt evaluation framework provides a useful structure for this kind of prompt testing.

Common mistakes

• Providing only a code fragment. Without the contract, caller, data shape, or expected behavior, the model may review an incomplete picture.
• Combining every review goal in one enormous prompt. Separate security, tests, performance, and maintainability passes when each requires different context or expertise. This is a practical use of prompt chaining: one pass can produce focused inputs for the next.
• Requesting certainty. Language such as find all bugs encourages overconfident output. Ask for evidence, confidence, and missing information instead.
• Accepting a patch without review. AI-generated fixes still need tests, code ownership review, and checks against project conventions.
• Using style rules as defects. A personal preference is not automatically a review finding. Include a style rule only when it is documented or tied to maintainability.
• Ignoring model and tool differences. Context limits, repository access, language support, and structured-output behavior can vary. Keep prompts explicit and verify the actual output rather than relying on assumed capabilities. See the AI model comparison guide when selecting a model for a particular review task.
• Allowing untrusted text to control the review. If code comments, issue text, or retrieved files are included, treat them as review data, not instructions. This is particularly important in AI-assisted developer tools.

When to revisit

Revisit these code review prompt templates whenever the workflow or its inputs change. Update them after adopting a new language, framework, repository structure, test strategy, AI coding tool, or model. A prompt that works for a small service may need different context and output limits for a monorepo or a regulated application.

It is also worth reviewing the templates before seasonal planning cycles or major release periods, when review volume, risk tolerance, and required evidence may change. Keep a short change log: record which prompt was used, what useful findings it produced, which false positives appeared, and which important issue it missed. Add anonymized examples to your evaluation set, then adjust one instruction at a time so improvements can be attributed.

For a practical next step, choose one recent pull request and run the general review template plus one focused pass—security, tests, performance, accessibility, or maintainability. Validate every finding, record the misses and false positives, and revise the prompt using that evidence. The goal is not to replace engineering judgment; it is to make review questions more consistent, visible, and easier to test.