AI Code Review Prompts: A Practical Checklist for Finding Bugs and Risks

Overview

An AI coding assistant can identify overlooked conditions, explain unfamiliar code, suggest tests, and highlight suspicious patterns. It cannot reliably replace repository context, automated checks, or human ownership of a change. The quality of an AI review depends on the inputs you provide and the questions you ask.

A useful code review prompt template should define four things:

• Scope: Which files, functions, or changed lines should be reviewed?
• Context: What does the feature do, and what constraints matter?
• Review criteria: Should the model focus on correctness, security, performance, or another risk?
• Output format: How should findings be prioritised and evidenced?

Give the model the smallest useful context first. A pull request diff, relevant tests, interface definitions, configuration, and a short description of expected behaviour are often more useful than an entire repository pasted without explanation. If the review depends on external documentation or internal standards, supply the relevant excerpts or use a grounded workflow; the RAG prompting best practices guide covers ways to keep answers tied to provided material.

Checklist by scenario

1. General correctness and bugs

Start with a narrow review that asks the model to reason about behaviour, not style. Include the intended result, inputs, side effects, and relevant invariants.

Act as a careful code reviewer. Review the following change for functional bugs and incorrect assumptions.

Context:
- Feature or task: [describe the intended behaviour]
- Inputs: [valid, invalid, empty, and unexpected inputs]
- Important invariants: [rules that must always remain true]
- Relevant code and tests:
[insert code, diff, or file references]

For each potential issue, report:
1. Severity: blocker, high, medium, low, or observation
2. Exact file and line or code location
3. Why the behaviour is incorrect
4. A realistic input or execution path that exposes it
5. A focused fix or test suggestion

Do not report formatting preferences. If you cannot establish a problem from the supplied context, label it as an assumption rather than a finding.

2. Edge cases and failure paths

AI prompts for finding bugs become more useful when they explicitly name boundaries. Ask for a scenario table covering empty values, limits, retries, timeouts, duplicate requests, partial failures, and concurrent operations where relevant.

Review this change specifically for edge cases and failure handling. Build a table with these columns: scenario, expected behaviour, observed behaviour, evidence, and missing test.

Consider:
- null, empty, malformed, and unusually large inputs
- minimum and maximum numeric or date values
- duplicate and out-of-order requests
- timeouts, retries, cancellation, and partial service failures
- permissions changing during an operation
- concurrent updates and repeated execution
- missing, stale, or contradictory configuration

Only identify scenarios relevant to this code. Separate confirmed defects from questions that require repository context.

3. Security review

For an AI security code review, state the trust boundaries and sensitive assets. Ask for evidence of a data flow rather than a list of generic vulnerabilities. Avoid sending secrets, private keys, customer data, or proprietary material to a tool unless your organisation permits it.

Perform a security-focused review of this change.

Trust boundaries:
- Untrusted inputs: [user input, webhook, file, API response, etc.]
- Privileged components: [services, jobs, database roles]
- Sensitive assets: [tokens, personal data, financial records, internal data]

Check for plausible data flows involving:
- injection into interpreters, queries, templates, or commands
- broken authentication or authorisation
- insecure direct object access
- accidental disclosure through logs, errors, or responses
- unsafe file, URL, redirect, deserialisation, or dependency handling
- weak validation, rate limits, or replay protection

For every finding, identify the source, sink, missing control, and practical exploit condition. Do not claim a vulnerability without pointing to code or configuration that supports it.

4. Performance and resource usage

Performance findings need workload assumptions. Tell the model the approximate data size, request frequency, latency target, and resource constraints when those details are known. Otherwise, ask it to identify questions and risk areas rather than asserting that code is slow.

Review this code for performance and resource risks under the following workload: [describe volume, concurrency, and latency expectations].

Look for unnecessary repeated work, inefficient queries, unbounded memory or queue growth, excessive network calls, blocking operations, poor pagination, and avoidable serial processing.

For each concern, explain:
- the operation and its likely complexity or cost
- the workload under which it matters
- whether the concern is measured, inferred, or hypothetical
- the least invasive improvement
- a benchmark, trace, or test that would confirm it

5. Tests and maintainability

Ask the model to assess whether tests prove behaviour instead of merely increasing line coverage. It can also identify confusing interfaces, duplicated rules, hidden coupling, and future maintenance risks.

Review the change for test quality and maintainability.

Identify:
- important behaviours that are not tested
- tests that pass without proving the intended behaviour
- missing negative, boundary, integration, or regression cases
- brittle mocks or assertions
- unclear names, excessive branching, duplicated business rules, and hidden side effects

Return a prioritised list. For each item, include the smallest useful test or refactoring step. Preserve the current architecture unless the supplied context shows that it cannot meet the requirement.

6. Breaking changes and compatibility

Use a separate prompt when a change affects APIs, schemas, events, configuration, database migrations, or shared libraries. Compatibility often depends on consumers that are outside the immediate diff.

Check this change for compatibility and migration risks.

Review public interfaces, request and response shapes, defaults, error behaviour, database changes, events, configuration, and generated clients. Consider older clients, rolling deployments, retries, cached data, and rollback.

Report:
- what could break
- which consumers or versions are affected
- whether the change is backward compatible
- required migration or rollout steps
- tests that should run before release

Mark any conclusion that requires information not included in the supplied repository context.

These prompts can be used independently or combined through prompt chaining: first summarise the change, then perform focused reviews, then ask for a consolidated report. Keeping stages separate makes it easier to inspect which prompt produced a finding.

What to double-check

AI output is a review aid, not proof that a defect exists. Before changing code, apply this verification checklist:

1. Reproduce the path. Can you demonstrate the reported behaviour with a test, trace, local run, or carefully reasoned execution path?
2. Check the complete flow. The model may miss validation, middleware, type guarantees, database constraints, feature flags, or downstream handling.
3. Inspect the base branch. A warning may already exist, be fixed elsewhere, or be introduced by an interaction with another unreviewed change.
4. Separate severity from confidence. A potentially serious issue with weak evidence needs investigation; a confirmed low-impact defect still needs an appropriate response.
5. Ask for counterarguments. Give the model a suspected finding and ask what repository evidence would disprove it. This is useful for reducing false positives.
6. Run normal engineering checks. Use tests, linters, type checks, dependency checks, static analysis, and security tooling appropriate to the project.

For teams, record accepted findings, false positives, and missed issues. A small set of representative pull requests can become an evaluation set for comparing prompts or AI developer tools. The LLM evaluation guide and prompt evaluation framework provide useful structures for measuring consistency, accuracy, and reliability.

Common mistakes

• Using “review this code” as the complete prompt. It gives no definition of risk, expected behaviour, or useful output.
• Providing only the changed function. Missing callers, types, schemas, tests, and configuration can produce confident but incorrect conclusions.
• Requesting every possible issue at once. Broad prompts often return repetitive style comments and generic security advice. Use focused passes.
• Accepting severity without evidence. Require a location, execution path, and affected assumption for each material finding.
• Leaking sensitive code or data. Remove secrets and minimise proprietary context. Follow the controls approved for your development environment.
• Letting the model rewrite immediately. First establish the issue and expected fix; then review any generated patch as carefully as the original change.
• Ignoring language and framework conventions. Add project-specific instructions, supported versions, error-handling rules, and testing conventions to the review context.

If you are selecting a tool for a team, compare repository access, context controls, audit options, supported workflows, and review ergonomics rather than judging a tool from one response. The AI coding assistant comparison can help structure that decision.

When to revisit

Keep this checklist as part of the pull-request workflow, but revisit it whenever the underlying assumptions change. Review the prompts after a major language, framework, database, authentication, or deployment change. Update the security section when trust boundaries, data types, permissions, or third-party integrations change. Update the compatibility section when APIs, schemas, release strategies, or supported client versions change.

It is also worth reviewing the prompts before seasonal planning cycles, onboarding a new team, adopting a different AI coding assistant, or changing repository guidance. Every quarter, sample completed reviews and ask:

• Which useful defects did the prompts miss?
• Which findings were repeatedly irrelevant?
• Are severity labels and evidence requirements still clear?
• Do examples reflect the languages, frameworks, and architectures the team actually uses?
• Are developers verifying findings, or treating generated comments as decisions?

Start with the general correctness prompt for the next pull request. Add only the scenario checks that match the change, verify each material finding against the repository, and save the strongest examples for future few-shot guidance. For a broader library of reusable coding workflows, see AI prompts for developers. A focused, evidence-based process will usually produce more value than a longer prompt.