Reviewing AI-authored pull requests without slowing down

Agent-authored pull requests have a distinct shape: large, internally consistent, and occasionally wrong in ways that read as correct. The prose in the description is clean. The tests are green. The diff looks like something a competent engineer would write. And that's exactly the trap - the usual review habits (skim, look for obvious smells, approve) are tuned to catch sloppy code, and agent code is rarely sloppy. It's confident, which is a different and more dangerous failure mode.

Adjust the review, not the standard

You don't lower the bar for AI-authored PRs - you re-aim it. Three moves catch most of what matters:

• Read the tests first. If the agent wrote tests, ask whether they assert real behavior or just exercise lines so the coverage number goes up. A test that can't fail is worse than no test, because it manufactures false confidence.
• Check the diff size against the task. A three-line fix that touched forty files is a signal, not a convenience. Somewhere in there is a refactor nobody asked for.
• Look for silent scope creep. Agents are eager to help. Renamed variables, "improved" error handling, a dependency bump - each is plausible in isolation and collectively a review you didn't sign up for.

Watch for confident-but-wrong

The specific risk with generated code is plausibility. It will handle the happy path perfectly and get a boundary condition subtly wrong - an off-by-one, a swapped comparison, an assumption about input that holds in the demo and not in production. Spend your attention on the edges: error paths, empty states, concurrency, anything involving money or permissions. That's where confidence and correctness diverge.

Targeted, not slower

None of this means reviews take longer - it means they're aimed. And the way you know where to aim is measurement. Tracking review depth and rework by author type tells you which buckets of work actually need the scrutiny: if AI-authored PRs show a higher rework rate, that's where the careful eyes go. That signal is exactly what the Measure pillar surfaces automatically, and there's a printable starting point in the Code Review Checklist tool.