AI Code Review Prompts: A Reusable Workflow for Safer, More Useful Programming Feedback

Overview

An AI coding assistant can inspect a diff, explain unfamiliar code, suggest tests, and identify possible failure paths. Its usefulness depends heavily on the context and constraints you provide. A short request such as “review this code” often produces broad comments, misses project-specific requirements, or presents guesses with more confidence than the evidence supports.

A better approach is to treat an AI code review prompt like a small review specification. State the language, framework, change purpose, expected behavior, risk areas, and review limits. Ask for evidence from the supplied code, require severity labels, and make the assistant distinguish confirmed defects from questions or suggestions.

Before sending code to an external AI tool, check your organization’s rules for proprietary code, credentials, personal data, customer records, and regulated information. Remove secrets and use a minimized diff where possible. Repository-connected tools and IDE assistants may receive additional context from open files, indexed code, or configuration, so inspect their context and sharing controls rather than assuming that only the selected lines are included.

Use AI feedback to improve human review; do not treat it as a merge decision. Every actionable finding should be reproduced, tested, or verified against the repository’s requirements before a developer changes production code.

Checklist by scenario

1. General pull-request review

Use this prompt when you want a first pass over a focused change:

Act as a careful code reviewer. Review the diff below using only the supplied context and clearly label assumptions.

Language and framework: [language, version, framework]
Change purpose: [what this change is intended to do]
Requirements or acceptance criteria: [requirements]
Relevant constraints: [performance, compatibility, style, operational limits]
Testing already performed: [commands and results]

Review the diff for:
1. Functional bugs and incorrect edge-case behavior
2. Security and privacy risks
3. Error handling and observability problems
4. Regressions in compatibility or performance
5. Missing or weak tests

For each finding, provide:
- Severity: blocker, high, medium, low, or suggestion
- Location: file and line, if supported by the supplied diff
- Evidence: the exact code path or assumption involved
- Impact: what could happen
- Minimal fix or test to investigate

Do not invent repository behavior. If evidence is insufficient, mark the item as a question. End with a short list of areas that appear adequately covered.

Diff:
[ paste the focused diff here ]

Give the assistant the smallest useful context: the diff, related interface or type definitions, and the relevant requirement. A full repository dump can increase noise and expose unnecessary proprietary material.

2. Security-focused review

A security prompt should name the trust boundaries rather than asking vaguely for “security issues.” Identify user-controlled inputs, authentication assumptions, authorization checks, sensitive data, external services, file operations, and database queries.

Review this change specifically for security risks.

Trust boundaries: [browser/API/job queue/third-party service]
Untrusted inputs: [parameters, headers, files, messages]
Sensitive assets: [tokens, personal data, internal records]
Authentication and authorization model: [brief description]
Deployment assumptions: [runtime, network, permissions]

Check for injection, broken authorization, unsafe deserialization, secret exposure,
path traversal, insecure defaults, excessive data exposure, replay or race conditions,
and denial-of-service risks. For each possible issue, explain the attack precondition,
affected asset, evidence in the code, and a safe verification step. Do not claim a
vulnerability is confirmed when required configuration or surrounding code is missing.

Security output needs especially careful validation. An assistant may identify a plausible pattern without understanding middleware, network controls, database permissions, or deployment configuration. Treat the response as a list of hypotheses for a developer to test.

3. Test-generation and regression review

Use a separate prompt when the main question is whether the change has adequate coverage:

Analyze this change for missing tests. First summarize the behavior that changed.
Then create a test matrix covering happy paths, invalid input, boundary values, authorization,
concurrency or retries where relevant, and backward compatibility.

For each proposed test, include:
- Given/when/then or equivalent setup
- Expected result
- Why the case matters
- Whether it is a unit, integration, contract, or end-to-end test

Use the existing test style shown below. Do not invent helpers, fixtures, endpoints, or APIs;
flag anything that must be confirmed in the repository.

Existing test examples:
[ paste representative tests ]
Change under review:
[ paste diff or relevant files ]

Ask for a test matrix before asking for test code. This makes it easier to spot missing scenarios and prevents the assistant from producing plausible-looking tests that do not exercise the changed behavior.

4. Refactor, dependency, or unfamiliar-code review

For refactors and dependency upgrades, compare behavior before and after rather than focusing only on style. Include public interfaces, supported runtime versions, migration notes available to the team, and commands used to validate the change. For an unfamiliar codebase, first ask the assistant to map the relevant flow, then conduct a narrower review of each boundary.

What to double-check

1. Privacy and context: Remove API keys, passwords, tokens, customer data, private certificates, and unnecessary source files. Confirm how the selected tool handles prompts, repository indexing, retention, access, and administrative controls according to your organization’s approved process. Do not rely on a prompt instruction such as “keep this secret” as a substitute for policy or technical controls.
2. Model and context limits: Check what files, previous messages, tool results, and repository branches are actually available to the assistant. Long context can be truncated or selectively retrieved. Prefer a focused diff with explicit supporting files, and state when a file is omitted.
3. Hallucinations: Verify every cited line, function, configuration value, and API. If the tool references a symbol that is not present, treats a suggestion as an existing behavior, or gives a line location outside the diff, downgrade the response until confirmed.
4. Reproduction: Turn a finding into a failing test, a controlled request, a static-analysis result, or a documented manual check. Run the project’s formatter, linter, type checker, unit tests, integration tests, and security checks as appropriate. For API changes, validate the contract as well; the OpenAPI validation guide can help structure that check.
5. Severity: Require a distinction between a confirmed defect, a likely risk, a question, and a style suggestion. Severity should reflect impact and exploitability in your application, not the assistant’s wording. A missing test may be important without being a production bug; a security concern may require configuration evidence.
6. Human approval: The code owner remains responsible for deciding whether a change is correct, safe, compatible, and maintainable. Record accepted findings and rejected suggestions when the review is consequential, so later reviewers can understand the decision.

For database-heavy changes, combine the AI review with an explicit query check rather than trusting a prose explanation. A focused SQL debugging checklist can expose duplicate rows, null handling problems, and slow joins that a general review may miss. For API debugging, format and compare actual responses with a JSON formatter workflow.

Common mistakes

• Using one giant prompt: A single request for bugs, security, style, tests, architecture, and documentation often produces an unfocused list. Run separate passes with different objectives.
• Submitting only the changed lines: A diff may depend on a type, schema, route, query, or configuration elsewhere. Add the smallest surrounding context needed to interpret it.
• Requesting fixes before confirming the finding: Generated patches can hide the original issue or introduce a new one. Ask for evidence and a reproduction path first, then request a minimal patch.
• Accepting confident language as proof: “This will fail” is not a test result. Check the claim against code, documentation, runtime behavior, or a reproducible test.
• Ignoring repository conventions: A technically valid suggestion may conflict with supported versions, error-handling patterns, migrations, accessibility requirements, or the project’s testing strategy.
• Letting the tool review generated output without requirements: Code can look clean while violating business rules. Include acceptance criteria and examples of expected behavior.

Keep the final human review narrow and concrete. Ask: What changed? What could break? Which evidence supports that conclusion? What test or inspection would disprove it? This keeps an AI-assisted review tied to engineering decisions instead of producing an unprioritized comment list.

When to revisit

Review this workflow whenever your AI coding assistant, IDE integration, repository connector, model selection, or organizational policy changes. A tool may alter how it retrieves files, invokes tests, displays citations, or handles context. Recheck those behaviors before relying on an old prompt or assuming that an earlier privacy boundary still applies.

Revisit the prompt before a major dependency upgrade, authentication change, database migration, public API release, or refactor across shared modules. Also update it when recurring false positives or missed defects reveal a missing project constraint. Add a short “known hazards” section covering conventions such as tenant isolation, retry behavior, feature flags, supported runtimes, or required test commands.

Before your next pull request, use this practical sequence:

1. Confirm that the code and prompt contain no unnecessary secrets or sensitive data.
2. Write the change purpose, acceptance criteria, language, framework, and constraints.
3. Run a focused diff review, then separate security or test reviews if the change warrants them.
4. Sort findings into confirmed defect, risk hypothesis, question, and suggestion.
5. Verify important findings with tests, tools, documentation, or controlled reproduction.
6. Apply only changes that a human reviewer understands and approves.
7. Run the project’s normal validation commands and document unresolved risks.

For adjacent developer workflows, keep the online developer tools checklist available alongside your repository review guide. The goal is not to make AI the reviewer of record. It is to use a repeatable programming tool that improves coverage while leaving evidence, judgment, and approval with the development team.