Prompt Engineering

Review AI-Generated Code

AI wrote it; review it with extra suspicion: strict correctness review of the diff, because generated code fails confidently.

Overview

AI-generated code has a signature failure mode: it looks right. It compiles, reads cleanly, handles the happy path — and invents an API, drops an edge case, or quietly changes behavior it wasn't asked to touch. This setup reviews AI-generated changes as diffs under strict correctness: the twelve correctness checks plus diff criteria (does the change do ONE thing? is changed behavior covered by changed tests? what's the regression risk in touched paths?), with every finding flagged and the verdict withheld until the checklist is done.

Workflow

Review the diff, not the file
Diff scope flags unrelated changes — the assistant's favorite way to expand its own scope.
Verify every external call
Invented APIs are the signature AI failure: each external symbol the diff introduces deserves a checklist pass.
Demand changed tests for changed behavior
The diff criterion that catches the silent behavior change generated code loves to slip in.

Why This Works

Strict style removes the benefit of the doubt that fluent code unearns
Diff criteria catch scope expansion — the AI failure mode reviews built for humans miss
One review contract scales to whatever volume the assistant produces

Best for

Teams adopting AI coding agents with a review gate
Diffs accepted under time pressure from a confident assistant
Codebases where generated code volume outpaces human review

Not for

Validating AI output FORMAT (JSON, structure) — that's the AI Output Validator
Re-generating the code — review the diff that exists; regeneration re-rolls the risk

Use cases

Gating Copilot/agent-written changes before they enter the codebase
Catching the invented API call that compiles against nothing
Flagging the unrequested "improvements" hiding in the diff

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

REVIEW OBJECTIVE
Review this AI-generated change with extra suspicion before it enters the codebase.
Primary focus: correctness — find the ways this code produces wrong results or fails.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a diff — judge the CHANGE, not the whole codebase. Removed lines matter as much as added ones.

REVIEW CRITERIA
- Logic errors and inverted conditions
- Edge cases: empty, zero, negative, maximum, duplicate inputs
- Null/undefined/None handling before dereference
- Error paths: propagation, swallowed exceptions, partial failure states
- Concurrency: race conditions, unawaited async results, shared mutable state
- Breaking changes to public APIs or contracts
- Backward compatibility of serialized data, schemas, and protocols
- Regression risk in the touched code paths
- Whether the changed behavior is covered by changed tests
- Whether the diff does one thing — unrelated changes flagged

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Are inputs validated at the boundaries where they enter?
2. Are edge cases handled: empty, zero, negative, maximum-size inputs?
3. Any off-by-one errors in loops, slices, or range checks?
4. Is null/undefined handled before every dereference?
5. Do error paths return or propagate correctly — nothing swallowed silently?
6. Are async operations actually awaited and their failures handled?
7. Any race conditions on shared state or check-then-act sequences?
8. Are return values of fallible calls checked?
9. Are type coercions and implicit conversions intentional?
10. Are comparison boundaries correct (< vs <=, exclusive vs inclusive)?
11. Is there dead or unreachable code hiding an intent mismatch?
12. Does the code do what its name and comments claim it does?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Flag every finding, regardless of size.
- No praise padding — findings only.

FINAL VERDICT
- End with a verdict: APPROVED or CHANGES REQUIRED — and list the findings that block approval.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the diff here]

Related Resources

Explore more resources that work well with this one.