Code review for AI-generated code
Review has to assume volume: agents produce more code than a human wrote, so review attention is spent where machines can't help — intent, domain correctness, and test honesty — and never on what CI already checks.
What a human reviewer checks
- Intent-match — does the change do what the task brief and acceptance criteria asked, and only that?
- Domain correctness — are the business rules right? SME sign-off is required where the change is flagged domain-sensitive.
- Test honesty — do the tests assert real behaviour, or were they written to pass? (See AI-generated-test review.) This is the single biggest defence against an agent grading its own homework.
- Security-sensitive surfaces — auth, payments, migrations, PII get an extra scrutiny tier.
What a human reviewer does not check
- Style or formatting — decided by the formatter.
- Coverage, scan results, lint — decided by CI at the merge gate.
If you find yourself commenting on formatting, the config is wrong — fix the config, not the PR.
The rules
- A human always merges. No agent self-merges, regardless of confidence.
- AI-provenance declaration on every PR: which agent, model, and prompt or skill produced the change. Feeds the AI provenance trail (standard to follow) and incident blast-radius queries.
- Size limits. PRs are small enough to review honestly; oversized PRs are split, not rubber-stamped.
- AI first-pass, human final. An agent reviews the diff first (security, intent, obvious defects); the human reviews what's left. The AI pass raises the floor; it never replaces the human.
- Extra-scrutiny tiers. Auth, payments, data migrations and PII-handling changes require a second reviewer and, where relevant, Security sign-off.
The anti-patterns to refuse
- Rubber-stamping agent output because it looks plausible and CI is green.
- Reviewing the mock — approving tests that assert against test doubles rather than behaviour.
- Scope creep — an agent "improving" unrelated code in the same PR; send it back.