The 25 Best AI Prompts for Code Review

Code review goes wrong in two familiar ways. Either the reviewer rubber stamps everything with "LGTM" because the diff is long and they are tired, or they nitpick style and miss the actual bug that is sitting in plain sight three lines above the comment thread. AI is genuinely good at the unglamorous middle of that work, which is reading every line carefully, asking obvious questions, and surfacing patterns a human reviewer would skim past on a Friday afternoon. It will not replace judgment, but it will catch the things you would be embarrassed to miss.

Below are 25 prompts I run against pull requests, diffs, and raw source files when I am reviewing code. Each one expects you to paste the diff, the file, or the PR description into {{clipboard}}. Once you find the five or six that fit the kinds of repos you actually work in, keep them somewhere a keystroke away so you can fire them without breaking your reading flow.

---

Download Free for macOS

Reviewing a pull request end to end

1. Full pull request review

You are an experienced senior engineer reviewing a pull request. I will paste the full diff along with the PR description if I have one. Walk through the change the way a careful reviewer would: first understand what the author is trying to do, then evaluate whether the code actually does it.

Here is the PR:

{{clipboard}}

Produce a review with these sections:

1. Intent: one paragraph summarizing what the PR is trying to accomplish, in your own words. If the description and the code disagree, flag that.
2. Correctness: any logic errors, off by ones, missed edge cases, null or undefined handling, race conditions, or misuse of library APIs.
3. Side effects: anything that changes behavior outside the scope of the stated intent. Unexpected state mutations, shared module changes, config drift.
4. Risk: a rough risk level (low, medium, high) with a one line reason.
5. Blocking issues: list each one with file path, line number, and a concrete suggestion. Do not list style nits here.
6. Nits: style, naming, small improvements, marked optional.
7. Verdict: approve, request changes, or ask the author to explain before you decide.

Be specific. No hand waving. If the diff is too large to review seriously in one pass, say so and tell me where to focus first.

2. Explain a diff in plain English before reviewing it

Before I review this diff in detail, I want a plain English explanation of what changed. Not line by line. I want the intent, the shape of the change, and the things I should keep in mind while I read it.

Here is the diff:

{{clipboard}}

Give me:

1. A two or three sentence summary of what this change does to the system from an outside observer's perspective.
2. The three most important files to understand first, in the order I should read them.
3. Any file in the diff that looks unrelated to the stated change and might be scope creep.
4. A list of the symbols (functions, classes, types) that were added, modified, or removed, grouped by file.
5. One or two questions a careful reviewer should ask the author based purely on reading this diff.

Do not evaluate quality yet. Just orient me. Keep it under 300 words.

3. Compare the PR description against the diff

I want to know whether the PR description matches what the code actually does. Authors sometimes write a description for the version of the change they intended to make, not the version they shipped.

Here is the PR description followed by the diff:

{{clipboard}}

Produce:

1. A bulleted list of every claim the description makes.
2. For each claim, mark whether the diff supports it, partially supports it, contradicts it, or is silent on it.
3. A list of things the diff actually does that the description does not mention.
4. A verdict: is this description accurate enough to merge, or should I ask the author to update it before approving?

Cite file names and line ranges when you point to specific evidence. Be literal, not charitable.

Security review

4. Security audit of a code change

You are reviewing this diff specifically for security issues. Ignore style, ignore readability, ignore performance. I only want you to find things that could be exploited or that weaken the security posture of the system.

Here is the diff (and the file context if I included it):

{{clipboard}}

Look for:

1. Injection of any kind: SQL, command, LDAP, NoSQL, XPath, HTML/XSS, template injection.
2. Authentication and authorization gaps: missing checks, wrong checks, broken access control, privilege escalation, tenant leakage.
3. Secrets handling: hardcoded credentials, tokens in logs, secrets in error messages, weak secret generation.
4. Input validation gaps: missing bounds checks, unvalidated deserialization, unchecked file paths, open redirects, SSRF.
5. Cryptography misuse: weak algorithms, weak randomness, custom crypto, hardcoded IVs, missing integrity checks.
6. Data exposure: PII in logs, overly verbose errors, debug flags left on, sensitive data in URLs or referer headers.
7. Dependency risks: new dependencies added, known vulnerable versions, unmaintained packages.

For each finding, give file, line, severity (low/medium/high/critical), a one line explanation of the risk, and a concrete fix. If you find nothing, say so and briefly note what you checked.

5. Review an authentication or authorization change

This PR touches authentication or authorization code. These changes have an outsized blast radius if they are wrong. I want a careful, slightly paranoid review.

Here is the diff:

{{clipboard}}

Answer each of the following:

1. What identity is being established and how is it verified?
2. What resource is being protected and what permission is being checked?
3. Is the permission check before or after the action is taken?
4. Can the caller influence the identity or the permission check through input (for example, by passing a user_id in the body)?
5. Does this change affect admin level access or service to service trust?
6. Are there cached permissions, session tokens, or JWTs whose expiry behavior could change?
7. What happens if this check throws an exception? Does the system fail open or fail closed?

At the end, list any test that should be added to lock this behavior in. Prioritize tests that would catch a regression rather than tests that confirm the happy path.

6. Check for common injection vulnerabilities

Scan this code specifically for injection vulnerabilities. Do not evaluate anything else.

Here is the code:

{{clipboard}}

Walk through every place where external input reaches a sink. For each input to sink path, tell me:

1. The source of the input (HTTP body, query param, header, cookie, file contents, message queue, external API response, and so on)
2. The sink it reaches (SQL query, shell command, HTML template, eval, system file path, external HTTP call, etc.)
3. Whether the input is validated, escaped, parameterized, or sanitized along the way, and how
4. Whether that protection is sufficient for the sink in question
5. A severity rating and a concrete fix

If there is no exploitable path, say so. If the protection depends on an upstream caller doing the right thing, flag that as a trust assumption.

Performance and efficiency

7. Find performance problems in a diff

Review this code change for performance issues. I am not interested in micro optimization, I want the things that will actually matter under load.

Here is the diff or the file:

{{clipboard}}

Look specifically for:

1. N+1 queries, missing batch operations, or repeated database calls inside loops.
2. Quadratic or worse algorithms where the input is user controlled and can grow.
3. Unbounded memory growth: lists that accumulate without limits, caches without eviction, event listeners that never unsubscribe.
4. Blocking calls in async code paths, or async calls in hot request handlers that do not need to be there.
5. Unnecessary work: duplicate computations, repeated JSON serialization, redundant network calls.
6. Missing indexes implied by new query patterns.
7. Anywhere the code fetches more data than it uses.

For each finding, give file and line, a one sentence explanation of why it matters, an estimated impact (noticeable only at high load, always slow, dangerous under growth), and a concrete alternative.

8. Review a database query change

This PR changes a database query or adds a new one. I want to make sure the query behaves well under real world data, not just on the test database.

Here is the query and any surrounding code:

{{clipboard}}

Tell me:

1. What indexes this query assumes exist. Name them.
2. What the query plan is likely to look like for a table with a million rows, assuming those indexes exist and assuming they do not.
3. Any filter predicate or join condition that is not likely to be index backed.
4. Whether the query is susceptible to N+1 if called inside a loop.
5. Whether it locks rows or tables in a way that could cause contention.
6. Whether it returns more columns or rows than the caller actually uses.
7. What happens to this query when the dataset is 100x the current size.

If the query needs a new index, state exactly which columns and in which order.

9. Hot path review

The file I am pasting is on a hot path. It runs on every request, every tick, or every frame. I want you to treat every allocation, every call, and every branch as expensive and call out anything that should not be there.

Here is the code:

{{clipboard}}

For each line or block, tell me:

1. Is there work being done here that could be done once at startup or cached?
2. Is there any object allocation in a loop that could be pooled or hoisted out?
3. Is there a map, filter, or reduce that could be a single pass?
4. Is there a log line that is cheap in isolation but expensive at this frequency?
5. Is there a defensive check that is unnecessary given the invariants of the caller?

Only flag things that would actually matter at high frequency. Do not chase micro optimizations that the compiler or runtime will handle. At the end, summarize whether this code is hot path safe or needs a rewrite.

Readability and naming

10. Suggest better names for unclear variables, functions, and types

I want you to review the names in this code and suggest better ones where they would help a reader understand the intent faster. Do not rename everything. Only flag names that are genuinely unclear, misleading, or inconsistent with the rest of the file.

Here is the code:

{{clipboard}}

For each name you flag, give me:

1. The current name
2. Why it is confusing (too short, misleading type, hides intent, inconsistent with siblings, wrong part of speech, ambiguous abbreviation, and so on)
3. Two or three alternative names ranked by fit
4. A one line justification for your top choice

Respect the conventions of the language and any patterns already present in the file. Do not suggest hungarian notation. Do not suggest overly verbose names that would hurt line length.

11. Flag code that is hard to follow

I want to find the parts of this code that a reader would have to stop and reread. Not because they are wrong, but because they are hard to follow on the first pass.

Here is the code:

{{clipboard}}

Identify:

1. Functions that are doing more than one thing at the same level of abstraction.
2. Long parameter lists that could be a struct, a type, or an object.
3. Boolean flags that change control flow, which should probably be enums or separate functions.
4. Nested conditionals more than three levels deep.
5. Any place where the happy path is buried under error handling instead of the other way around.
6. Comments that apologize for the code instead of explaining it.

For each finding, show the location and propose a concrete refactor that would improve clarity. Do not propose refactors that are bigger than the problem.

12. Check consistency with the rest of the codebase

I am going to paste a new file or a significant addition. I want you to check whether it follows the conventions of the surrounding code I will also paste, and flag anywhere it drifts.

Here is the new code and some example files from the same codebase:

{{clipboard}}

Look at:

1. File and folder organization: does this fit where files like it normally live?
2. Naming conventions: cases, prefixes, suffixes, the shape of function and type names.
3. Error handling style: return values, exceptions, result types, panic vs log.
4. Logging style: levels, structured vs string, where logs happen.
5. Import ordering and grouping.
6. Test file location and naming.
7. Comments and doc comments: are they written the same way?

For each drift you find, show the examples from the existing code and the mismatch in the new code. Separate "must fix" from "would be nicer to match."

Architecture and design

13. Design review for a new module or feature

This PR introduces a new module, service, or feature. I want a design level review, not a line by line review.

Here is the code and any design notes I have:

{{clipboard}}

Answer:

1. What responsibility does this new code own, in one sentence?
2. Is that responsibility already owned by something else in the codebase?
3. What abstractions does it introduce and are they paying rent? Are they solving a real problem or adding ceremony?
4. What coupling does it create with existing code, and is that coupling appropriate?
5. If I had to delete this code in six months, how hard would that be?
6. What would a simpler version of this look like? Not a worse version, a simpler one. Describe it briefly.
7. What would a more flexible version look like, and is that flexibility worth it now?

At the end, give a verdict: ship as is, ship with the one most important change, or redesign before merging.

14. Review a refactor that moves or restructures code

This PR is a refactor. No new behavior, but code is moving around. I want you to help me check that the move is clean and not accidentally changing things.

Here is the diff:

{{clipboard}}

Produce:

1. A summary of what moved where.
2. Anything that looks like a behavior change hiding inside the refactor (default values, order of operations, error handling differences, imports that no longer match).
3. Any dead code the refactor exposed that could now be deleted.
4. Any tests that need to be moved along with the code they were testing.
5. A list of external callers that might break because of signature changes or module path changes.
6. A verdict on whether the refactor is pure (behavior preserving) or not.

If it is not pure, list every behavior delta you found.

15. Check layering and dependency direction

I want to make sure this change does not break the layering of the system. Layers should depend inward, not outward.

Here is the diff and a short description of the layer or module boundaries:

{{clipboard}}

For every import, function call, and type reference that crosses a boundary, tell me:

1. Which layer is calling which
2. Whether that direction is allowed
3. Whether the call could be inverted or moved to maintain the proper direction
4. Whether there is a leaky abstraction being pulled through (for example, a database type appearing in a UI layer)

List all violations with file and line. For each, propose the minimum change that fixes the direction.

Test coverage and quality

16. Audit the tests included in this PR

Review the tests in this PR. I care about whether they actually lock in the intended behavior, not about coverage numbers.

Here are the tests and the code they test:

{{clipboard}}

For each test, tell me:

1. What behavior is this test actually checking?
2. Would it fail if the code it covers was silently broken? Try to identify tests that would pass even if the implementation was wrong.
3. Does it test edge cases, or only the happy path?
4. Does it use real data shapes or oversimplified fixtures that hide real problems?
5. Does it depend on mocks that could diverge from the real dependency over time?
6. Is the test name a description of the behavior or just a restatement of the function name?

At the end, list any missing test I would expect to see for this change, ranked by how likely the missing case is to regress.

17. Suggest missing test cases

Here is a piece of code that I want to write more tests for. Do not write the tests yet. Just give me a list of cases I should cover.

Here is the code:

{{clipboard}}

For each function or method, list:

1. The happy path case (one or two, not more).
2. The obvious edge cases: empty input, single element, very large input, null or undefined, zero, negative numbers, unicode, trailing whitespace, duplicate keys, and so on, but only the ones that actually apply to this function.
3. The less obvious edge cases that I will forget: concurrent calls, timezone quirks, floating point precision, boundary between types.
4. Error paths: what happens when a dependency fails, times out, or returns something unexpected.
5. Any case where the behavior is underspecified and I should decide before writing the test.

Keep the list tight. Do not invent cases that do not apply to this code.

18. Check if a test is testing the right thing

I am worried that this test is coupled to the implementation rather than the behavior. I want you to check.

Here is the test and the function it tests:

{{clipboard}}

Tell me:

1. What behavior the test is checking, in one sentence.
2. Whether it would still pass if I rewrote the function to a different correct implementation.
3. Every place the test reaches into internal state, uses private APIs, or asserts on implementation details.
4. Whether the test would catch the bug it was presumably written to catch. If you cannot infer the bug, say so.
5. A rewrite of the test that is about the same length but checks the behavior instead of the implementation, if an improvement is possible.

If the test is already good, say so. Do not fake improvements.

Bug hunting

19. Find bugs in a single file

Read this file carefully and tell me what is wrong with it. Do not grade style. Do not suggest refactors. I only want bugs, defined as "behavior that will be wrong in some real world case."

Here is the file:

{{clipboard}}

For each bug you find, give:

1. File and line
2. A concrete input or sequence of events that triggers it
3. The expected behavior
4. The actual behavior
5. Severity: subtle (rare or hard to notice), visible (user will see it), or broken (the thing is not working)
6. A minimal fix

Rank the bugs by severity. If the code is bug free to the best of your reading, say so and mention what you checked before concluding that.

20. Compare two implementations of the same function

I have two versions of the same function and I want to know if they actually do the same thing for all inputs.

Here are version A and version B:

{{clipboard}}

Tell me:

1. A one sentence summary of what each version does.
2. Any input for which they would produce different outputs. If you find one, give the specific input and both outputs.
3. Differences in side effects, exceptions thrown, logging, or performance profile.
4. Differences in error handling.
5. If they are equivalent for all practical inputs, say so and name the edge where they would diverge if any.

Be literal. Do not assume the author's intent. Compare what the code actually does.

21. Investigate a suspected bug

I suspect there is a bug in this code but I cannot find it. Help me find it by reading carefully and asking the right questions.

Here is the code and a description of the symptom I am seeing:

{{clipboard}}

Produce:

1. A list of hypotheses about where the bug could be, ranked by likelihood.
2. For each hypothesis, the single question I could answer (by running the code, adding a log, or reading a related file) that would confirm or reject it.
3. The one place in the code you would add a log line to narrow the search fastest.
4. The one assertion about the state I am assuming to be true that is most likely to be wrong.

Do not guess at the fix yet. I want to be confident about the diagnosis first.

Documentation and comments

22. Review comments and docstrings

Review the comments and documentation in this code. I only want you to flag ones that are misleading, out of date, redundant with the code, or missing where they would materially help.

Here is the code:

{{clipboard}}

For each comment, decide:

1. Keep: it explains intent or a constraint the code cannot express.
2. Cut: it restates what the code already says.
3. Fix: it is wrong or out of date.
4. Move: it is in the wrong place.

For places that should have a comment but do not, explain what the comment should say. Do not suggest writing doc comments on every function just for form. Only where it matters.

23. Generate a README for a new module

I just wrote a new module and I want a README that explains it to someone who has never seen it before. Write it in the voice of the existing project, which I will paste for reference.

Here is the module code and an example README from the same project:

{{clipboard}}

The README should include:

1. A one or two sentence description of what the module is for.
2. The public API: each exported function, class, or type with a one line purpose.
3. A short example showing typical usage. Realistic, not contrived.
4. A list of assumptions the module makes about its environment or callers.
5. Known limitations or edge cases the caller should be aware of.
6. Related modules or files.

Match the style and formatting of the example I pasted. Do not add sections the example does not have just for completeness.

PR feedback and communication

24. Turn technical findings into actionable PR comments

I have a list of review findings and I need to write them as PR comments that are specific, respectful, and actionable. Not passive aggressive, not vague, not patronizing.

Here are my findings:

{{clipboard}}

For each finding, produce:

1. A PR comment under 60 words.
2. A severity label at the start: blocking, suggestion, or nit.
3. A concrete suggestion, ideally with code if the change is small.
4. A question, not a command, when the intent is to understand rather than correct.
5. No "you should have," "why didn't you," or "obviously."

At the end, combine the blocking comments into a single summary comment that the author can address first before looking at the line comments.

25. Rewrite a harsh review comment to be direct but kind

I wrote this review comment and it is too harsh. I need to say the same thing without making the author feel attacked, but without softening the technical point into mush.

Here is the comment and the code it refers to:

{{clipboard}}

Write three rewrites:

1. Direct and kind: the technical point is preserved exactly, the tone is neutral to warm.
2. Inquisitive: rephrased as a genuine question that makes the issue visible.
3. Collaborative: phrased as "what if we" or "one option is," inviting the author to decide.

Each rewrite should be the same length or shorter than the original. No apologizing for the comment, no hedging the feedback. The goal is clarity with respect, not politeness theater.

Tell me which version fits the severity of the issue best.