The short answer
Before reading: classify risk. During reading: cap diff size per sprint, enforce tests, and read for invariants and failure modes—not cleverness. After reading: write the next action or explicitly park rework—never “looks fine” without evidence.
How this differs from normal code review
Traditional review assumes a human author with intent you can interrogate. AI-assisted output can be locally plausible everywhere and globally wrong on edge cases. Timeboxing forces you to prioritize invariants: auth, concurrency, data boundaries, and tests—before nitpicking style.
Risk tiers before you read line one
Tier A: permissions, money movement, PII, crypto, distributed systems. Tier B: core business logic with weak tests. Tier C: mechanical refactors with strong coverage. Your reading depth and required reviewers should track tiers—not every PR deserves the same ceremony.
Diff budgets and timeboxes
If a single “sprint” tries to review a four-thousand-line AI refactor, you are doing theater. Split work: generation sprint, consolidation sprint, review sprint. Smaller diffs reduce the odds you rubber-stamp because fatigue arrived before comprehension.
Test gates you cannot skip
Minimum: unit tests for changed behavior, typecheck or compile, and a smoke path for user-visible flows when UI changed. AI can write tests—treat tests as part of the generation sprint, not a separate optional pass.
Reading order for AI output
Start with data invariants and error handling, then control flow, then naming. Style last—formatters exist. If you start with style, you will run out of attention before correctness.
When to reject and reset
Reject when the change mixes unrelated concerns, lacks tests for new branches, or hides behavior behind clever abstractions you cannot explain in one paragraph. “Reject” is not moral judgment—it is refusing to merge ambiguity into production.
Team norms that prevent review theater
Publish a team default: maximum AI-generated diff without design note, required pairing for Tier A, and explicit labeling in the PR body when assistants were heavily used. Transparency reduces guesswork and blame after incidents.
Worked examples (compressed)
Mechanical rename across modules: Tier C if tests cover behavior. Review sprint focuses on import paths, missed references, and CI green—style nits last. If the diff explodes, split into two PRs even if the AI “could do it in one go.”
Auth change suggested by a model: Tier A. Require explicit threat model notes: session fixation, CSRF, token lifetimes, and rollback. If the PR cannot explain those in plain language, it is not ready—regardless of how confident the prose sounds.
Generated tests that pass immediately: suspicious. Spend review minutes ensuring tests assert meaningful behavior, not `expect(true)`. AI can satisfy coverage metrics while failing to protect invariants.
Mixed human and AI commits: label them. Reviewers allocate attention differently when they know which sections were typed under time pressure versus generated wholesale. Transparency reduces unfair blame and unfair trust.
Practical takeaway
Review AI-generated code like flight checks: risk tier, diff budget, tests, invariants—then stop when the box ends. Speed without bounded review is how teams ship subtle bugs at scale.
Frequently asked questions
Is this only for senior engineers?
No—junior engineers benefit most from explicit gates. Seniors already pattern-match risk; juniors need checklists so review does not become vibes.
Should AI output get stricter review than human output?
Often yes for subtle correctness risks—not because humans are better, but because generation can be fluent while wrong. Calibrate by domain.