Review AI-Written Code: Look for "Plausible and Wrong"
Added 2026-11-05
AI code rarely fails on syntax; it fails on unexamined assumptions.
This code was generated by an AI: [code or summary]. Review it for things that look right but are wrong: 1) list the assumptions it makes without checking — input ranges, call order, external state; 2) find where it can fail silently, producing a wrong result without an error; 3) flag error handling that looks complete but only covers the happy path; 4) separate parts that follow framework convention from API usage the model invented, which need a check against the docs; 5) give the tests that must be added, each naming the failure it would catch. Do not rewrite the whole block.
Site original
Chinese original
Replace these placeholders 1
Swap the bracketed parts for your own details before sending.
[code or summary]
How to use
The dangerous thing about AI code is not being obviously wrong; it is being plausibly wrong.
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.
Good for
- The code runs and the tests pass, but something feels off — especially when an AI produced the whole implementation in one shot.
- You are reviewing a teammate's or an AI's change, they are confident, and you need to separate "looks reasonable" from "actually safe".
Not for
- The code does not run at all: get it running first, then review.
- You only want consistent naming and indentation: a linter or formatter is more reliable than asking someone to judge style line by line.
Example
Input
AI-generated list endpoint: `page = int(request.args.get("page", 1))`, then `offset = page * size`, and `size` is string-concatenated straight into the SQL LIMIT clause.What you get
Flag two "plausible but wrong" spots: 1) the base of `page` is unspecified, so a 0-based offset silently skips the first page — state the convention and validate the boundary; 2) `size` has no allowlist or cap, so it can be huge, negative, or carry an injection fragment — LIMIT must not be string-concatenated. Add that behavior for empty results and out-of-range pages is undefined. For each, give the input that triggers it and the minimal fix; do not comment on naming or formatting.
Common mistakes
- Sending only "check this AI code for problems" with no intent or runtime context gets you a generic checklist.
- Asking it to rewrite the block gets you another version of the code instead of review comments you can verify.
Try tweaking it like this
- Adding "report only what can cause wrong data, security issues, or silent failure; otherwise stay silent" cuts filler sharply.
- Replacing "rank by severity" with "for each item, give the triggering input first, then the minimal fix" yields reproducible evidence.