AI coding assistants and agents have changed what a small team can ship. They've also moved the bottleneck. Research from Faros AI found that as AI adoption grows, review time and incident counts can grow faster than the productivity gains. Google's DORA research on AI-assisted development reaches a similar conclusion: AI amplifies whatever process you already have.

Here's the review workflow we use on our own sprint teams and recommend to clients.

Principle: AI writes, humans own

Every change has a named human owner who can explain what it does, why, and how it was tested. "The AI wrote it" is never the answer in a post-incident review.

1. Keep pull requests small

AI makes it trivially easy to produce 2,000-line PRs, and nobody reviews those properly.

  • Aim for under 400 changed lines per PR, excluding generated files and lockfiles
  • One concern per PR: refactor, feature and migration go separately
  • Use stacked PRs or feature flags to ship large features in slices

2. Write the PR description for the reviewer

Require a template:

  • What and why, in two sentences
  • How it was tested: commands, screenshots, test names
  • Risk: data migrations, auth changes, performance-sensitive paths
  • AI context: which parts were generated, and anything the author isn't sure about

That last item is the most useful line in the template. It tells the reviewer where to look hardest.

3. Automate the boring checks

Humans should never spend review time on things a machine can check:

  • Formatting, lint and typecheck in CI, blocking merge on failure
  • Unit and end-to-end tests on the golden path
  • Secret scanning, plus dependency and licence checks
  • SAST (CodeQL, Semgrep or similar) for common vulnerability patterns
  • Bundle-size and performance budgets on frontend routes

4. AI first-pass review

Run an AI reviewer on every PR before a human looks at it. It's good at:

  • Spotting off-by-one errors, unhandled errors and null cases
  • Noticing missing tests for new branches
  • Flagging inconsistencies with patterns used elsewhere in the repo
  • Summarising large diffs for the human reviewer

Treat its comments as suggestions: the author resolves or dismisses each one, with a reason.

5. Human review focuses on what AI can't judge

  • Intent: does this solve the actual product problem?
  • Architecture: is this in the right place, and will it scale with the roadmap?
  • Security and data: auth checks, tenancy boundaries (row-level security) and PII handling
  • Operability: logging, metrics, failure modes and rollback

Use CODEOWNERS so changes to auth, billing, infrastructure and migrations always get the right reviewer.

6. Watch the dependencies

AI models sometimes invent package names, and attackers register them ("slopsquatting"). Defend against it:

  • New dependencies need explicit approval in review
  • Lockfiles are committed and checked in CI
  • Prefer well-known packages, and check download counts and maintainers before adding one

7. Measure the system, not the individual

Track at team level:

Metric Healthy signal
PR size (median lines changed) Stable or shrinking
Time to first review Under one working day
Change failure rate Flat or falling as output rises
Time to restore after an incident Falling
Rework rate (code changed again within 2–3 weeks) Low

The DORA metrics remain the best-tested framework here.

When an MVP was built AI-first

If your codebase was mostly generated before any of this existed, start with the security and testing pass in our vibe-coded MVP rescue checklist, then adopt this workflow for everything new.

Bottom line

AI makes writing code cheap; understanding code is still expensive. Small PRs, automated guardrails, AI first-pass review and clear human ownership let you keep the speed without the incidents.

Want a team that already works this way? Our custom software engineers plug into your repo and review process from day one. See pricing or book a call.

Frequently asked questions

Can AI review code instead of humans?

AI reviewers are good at catching bugs, inconsistencies and missing tests on a first pass, but a human must still own the change: they understand the product intent, the architecture and the risk. Use AI to make human review faster, not to replace it.

Why are AI coding tools causing more incidents?

Output rises faster than review capacity. Large AI-generated pull requests get skimmed, subtle logic errors and security issues slip through, and nobody fully understands the code later. Process, not the tools, is usually the problem.

What is slopsquatting?

An attack where criminals publish malicious packages under names that AI models tend to hallucinate. If a generated import is installed without checking, the malicious package runs in your build. Lockfiles and dependency review prevent it.