# Reviewing AI-generated PRs: the 10-minute checklist > Source: > Published: 2026-10-21 18:55:35+00:00 AI-generated PRs have a tell: they're *too* clean. Perfect formatting, thorough comments, confident summaries. And that's exactly why they need a different review: the polish hides the same failure modes every time. Open the file list first, not the diff. Agents are notorious for scope creep: reformatting untouched files, "fixing" adjacent code, adding dependencies for one helper function. If the PR touches files outside the task, that's your first question, not your first approval. Agents write tests that pass, not tests that protect. Check: This is where AI code most consistently underperforms. Look for: `except:` / empty catch blocks Ask: "what happens when this fails?" If you can't answer from reading the code, neither can the on-call engineer. Agents don't think adversarially. Scan for: You don't need a full audit, just the OWASP top-10 instincts applied for two minutes. Not style, *judgment*. Did it pick the simple approach or the clever one? Did it add an abstraction for a single use? Did it duplicate something that exists three files over? Agents optimize for completing the task, not for the codebase's future. That's your job, and it's the part that takes the longest to learn and the least time to check once you know the smell. Everything above that's mechanical belongs in CI, not in your 10 minutes: The checklist above reviews the code. Spend one of your ten minutes reviewing the *story* the PR tells about the code, because AI-written descriptions are fluent, confident, and occasionally fictional. This isn't paranoia; it's calibration. The description is generated by the same process that generated the code, with the same confidence and the same blind spots. Trust it exactly as much as you'd trust a summary written by someone who skimmed. The hardest AI PRs to review are the ones where every line is locally fine and the whole thing is wrong. The agent added a utility that already exists two folders over. It solved the problem in the controller when your architecture solves it in the service layer. It introduced a second state-management pattern next to the one the codebase standardized on. Line-by-line review waves these through, because each line is defensible. The defense is the file list from minutes 0–2 and one question: **"If a new hire had written this, where would I tell them this code belongs?"** If the answer is "not here," the review is a redirect, not a line edit. Ask for the approach change early and specifically, naming the existing pattern to follow. Agents take structural feedback well; it's the feedback they almost never get, because reviewers default to commenting on lines. A related tell lives in the commit history. One giant commit named "implement feature" is normal for agents and useless for review; a sequence of small commits, each doing one thing, is reviewable. You can't rewrite the agent's habits, but you can set the bar in your context file: small commits, messages that say why, no unrelated changes in the same commit. Review quality is partly a function of what the reviewer is handed, and shaping the input is cheaper than straining over a bad one. Reviewing human code, you ask "is this correct?" Reviewing AI code, ask "what did it *not* consider?" The agent did the typing. Your review is the engineering. **This checklist is published on [NotVibesCoded](https://www.notvibescoded.com/articles/reviewing-ai-generated-prs-checklist)**, alongside field guides on context files for coding agents, database migrations with AI, and shipping AI-built software without the slop.