AI makes code review worse before it makes delivery better. That's the part too many teams still don't want to admit. AI-generated PRs are rejected or need significant revision over 2.5 times more often than human-authored ones, and they wait over 5 times longer to even get picked up for review. SonarSource's 2026 State of Code Survey also found that 96% of developers don't fully trust the functional accuracy of AI-generated code. That trust gap is the bottleneck.
The May 2026 backlash against spec-driven development gets interesting. Yes, people call it “waterfall with markdown,” “token-burning ceremony,” and a productivity trap. Some criticism is fair. GitHub Spec Kit can create a lot of files. Kiro, OpenSpec, Traycer, Vibe Kanban, and BMAD all make tradeoffs. Simon Willison has pushed hard on practical review habits. Birgitta Böckeler's spec-first, spec-anchored, and spec-as-source framing is useful because it separates lightweight discipline from bloated ritual. Addy Osmani's six-section spec format is useful for the same reason. It gives you enough structure to review against something real.
If you want to know how to review AI-generated PRs without slowing your team to a crawl, keep it simple. Anchor review to the spec. Automate baseline checks before human review. Use trust tiers so you only spend deep attention where it matters.
Table of Contents
- The New Bottleneck AI Is Creating
- Anchor Reviews to the Spec Not the Code
- Automate All Baseline Quality Checks
- Use a Trust Tier System for Human Review
- Your Self-Review Playbook
The New Bottleneck AI Is Creating
The old bottleneck was writing code. The new bottleneck is reviewing code you don't trust.
AI spits out more code than a small team can safely inspect. Worse, AI-assisted PRs have a 32.7% acceptance rate on first review, compared to 84.4% for human-authored PRs, and they're roughly 1.5 to 1.8 times larger than unassisted PRs. They also sit in the queue for about 1,000 minutes versus 200 minutes before review starts, according to the verified survey data above. That's not acceleration. That's a backlog with better branding.
Practical rule: If your AI output reaches humans before CI, linting, tests, and basic security checks, your review process is broken.
This is the same failure pattern you see in content workflows too. If work enters review before it meets the minimum bar, approval becomes the bottleneck. The PostPulse content approval guide makes the same point in a different domain. Bad upstream discipline creates downstream drag.
Anchor Reviews to the Spec Not the Code
If you open the diff first, you've already made review harder.
Start with intent. Then inspect implementation. A key failure pattern is intent drift from underspecified prompts. The fix is precise specs with EARS acceptance criteria and a commit that points back to the spec, like feat(auth): magic link, refs specs/004-magic-link/spec.md, as explained in this spec-driven development breakdown.
What to compare
Use the spec as the source of truth. Not the PR description. Not the agent's explanation.
- Acceptance criteria: Did the change satisfy the required behavior?
- Scope boundaries: Did the agent add extra “helpful” work you didn't ask for?
- Validation scenarios: Do the tests cover the cases the spec says matter?
Addy Osmani's six-section spec format is useful here because it forces the basics into one place. If your specs are weak, fix that first. This guide on AI-ready product spec sheets is a solid reference for keeping them reviewable instead of bloated.
Review against the spec, not the story the code is trying to tell.
The ADR pattern from the Claude Code architecture decisions thread matters too. If the PR changes architecture, record the decision. Don't bury it in comments.
Automate All Baseline Quality Checks
A human should never waste time finding what a machine can reject in seconds.
Before anyone reads a line, the PR should pass:
- Linting and formatting
- Type checks
- Unit and integration tests
- SAST and secret detection
- Coverage and complexity thresholds
Teams that automate baseline checks before human review report a 68% reduction in PR review turnaround time while maintaining code quality standards, according to Codacy's writeup on the AI PR bottleneck.
If you need a plain-English refresher on test automation fundamentals, this guide to automated testing is worth a skim.
The concern people raise in threads about AI is simple. Agents skip best practices. That fear showed up in the Reddit discussion about good practices being lost. The answer isn't more meetings. It's hard gates.
For security-sensitive changes, pair your gatekeeper with a manual audit habit. This vibe coding security audit piece covers the kinds of issues that look fine in a diff and still blow up later.
A quick visual example helps:
Use a Trust Tier System for Human Review
Not every PR deserves the same attention. Pretending otherwise is how teams burn out.
Tier 1
Review every line when AI touches identity, access, or state. Experts advise treating that code as high risk by default. Also, 82% of AI test suites fail to validate edge cases, so test files need targeted skepticism, not blind trust, as noted in this guide on reviewing AI-generated PRs.
Tier 2
Use sampling review for medium-risk work. UI components, CRUD boilerplate, adapter code, internal tooling. Check the structure, inspect a few files thoroughly, verify the tests exercise logic, then move on.
Tier 3
Skim and approve low-risk changes. Docs. generated files. trivial config cleanup. dependency bumps with clear scope.
Demand evidence over explanations. Passing tests, reproducible edge cases, and enforcement proof matter more than a confident PR summary.
This keeps senior attention where it belongs. Architecture. data flow. business logic. failure modes.
Your Self-Review Playbook
If you work solo, you are the reviewer. Act like one.
Use this checklist before merge:
| Check | Question |
|---|---|
| AI gate passed | Did CI, lint, tests, and security checks pass before you started reviewing? |
| Spec match | Does the PR satisfy the acceptance criteria and stay inside scope? |
| Trust tier | Is this Tier 1, 2, or 3 work? Are you reviewing at the right depth? |
| Test quality | Do the tests prove behavior, or do they just mirror implementation? |
| Risk scan | Did the change introduce new dependencies, auth logic, state changes, or architecture drift? |
| Maintenance cost | Will you understand this code in a month without asking the model what it meant? |
If the PR fixes a bug, write or update the bug report first. A clean issue description makes self-review less fuzzy. This bug report template helps keep the acceptance bar obvious.
The anti-ceremony version of spec-driven development is simple. Keep the spec short. Keep the PR small. Keep the robot checks strict. Use full review where the blast radius is real. Sample the rest. That's how you review AI-generated PRs without turning yourself into a full-time janitor.
Tekk.coach is built for this workflow. Connect your GitHub repo. Describe the problem. Get a structured spec. Ship.
Part of the Spec-Driven Development pillar — a 52-page honest playbook on shipping with AI coding agents.