How do you review AI-generated code so you don't trust it blindly?

Question

Accepted Answer

AI-generated code is a **draft from a confident but fallible author**. It often looks correct and compiles, yet hides subtle bugs, invented APIs, or security holes. A disciplined review keeps the speed without the risk.

## The review checklist

- **Read every line.** If you skim, you ship bugs you can't explain later. No exceptions.
- **Verify it solves the actual problem** — not a similar-looking one. AI optimizes for plausible, not correct.
- **Run the tests and the linter.** Add tests for the cases you care about; don't trust AI's own tests blindly either.
- **Check edge cases** — empty input, nulls, large values, concurrency, boundary conditions.
- **Check security** — SQL/command injection, unsanitized input, secrets in code, unsafe deserialization.
- **Check performance** — accidental O(n²) loops, N+1 queries, unbounded memory.
- **Confirm APIs exist** — AI hallucinates method names and library functions that look real.
- **Never paste code you don't understand.** If you can't explain it, you can't maintain or debug it.

## A practical flow

```text
1. Read the diff fully  →  do I understand every line?
2. Does it solve the real problem, including edge cases?
3. Run: tests + linter + type checker
4. Scan for security + performance red flags
5. Only then: commit (with a message that reflects what it really does)
```

Treat AI like a fast junior developer: helpful, productive, but whose output you always review before it lands. The responsibility for shipped code stays with you, not the model.

## Why it matters

The danger of AI code isn't that it's obviously broken — it's that it's *plausibly* broken, passing a casual glance while harboring a bug or vulnerability. Reviewing every line, running tests, and refusing to ship code you don't understand is what separates using AI as a force-multiplier from quietly accumulating technical debt and security risk you can't account for.