Reviewing AI-Written Pull Requests: A Code Review Workflow That Scales

AI coding agents produce clean-looking pull requests faster than teams can read them. Here is the review checklist, PR size limit, CI gates, and template we use to keep quality high at volume.

Admin

10 September 2026·8 min read

Why AI-written pull requests need a different review

Reviewing AI-written pull requests is now most of what a senior engineer does at Soaiverse. When coding agents produce the majority of diffs, the review step stops being a courtesy and becomes the main quality control in the system. A code review workflow for AI-generated pull requests has to handle three things that human-written PRs rarely combine: volume, plausibility, and hidden assumptions.

Volume. An agent can open more PRs before lunch than a small team used to open in a week. If review takes the same time per PR as before, review becomes the bottleneck and reviewers start skimming. Skimming is where defects get through.

Plausibility. Agent output is syntactically clean, well named, and commented. It reads like good code. Reviewers have learned over years that messy code deserves scrutiny and tidy code probably works; that heuristic is now wrong. The polish is free, so it tells you nothing.

Hidden assumptions. An agent fills gaps in the brief with defaults: a timezone, a locale, a currency precision, an ordering, a "this id comes from the session" that actually comes from the request body. None of these appear in the diff as a decision. They appear as a line that looks obvious.

Google's code review guide tells reviewers to look at design, functionality, complexity, tests, naming, comments, and consistency. All of that still applies. What changes is the weighting: design and functionality against intent matter more, and style matters less because the agent already handled it.

The checklist we run on every AI-generated pull request

We keep this checklist short enough to actually use. The reviewer answers each question in the review comment, not in their head.

1. Intent: does the diff do what the task said, and nothing else?

Read the task or issue first, then the diff. Never the other way round.
Look for unrequested changes: an extra endpoint, a refactor of an unrelated file, a new utility "for convenience". Agents add these because they were cheap to produce, and each one is unreviewed surface area.
List the assumptions the diff makes, especially the ones it does not state. Where does each id, timestamp, and user come from?

2. Tests: do they test the behaviour or the implementation?

Agents write tests readily, and many of them assert that the code does what the code does. A test that mocks the thing under test is not a test.
Look for the failure cases the task implies: an expired token, a duplicate submission, a missing field, a concurrent write.
Run the tests locally when the PR touches money, auth, or data migrations. CI green is necessary, not sufficient.

3. Security: what would an attacker do with this diff?

Every route: is authorisation checked against the session, not a client-supplied id? Is input validated with a schema before use?
Any new dependency: is it real, maintained, and the package you think it is? Agents occasionally suggest packages that do not exist or are typosquats of ones that do.
Any prompt or model call: is user input separated from instructions, and is model output treated as untrusted? The OWASP Top 10 for LLM applications is the checklist we use here.
Secrets in code, personal data in logs, and error messages that leak internals.

4. Dependencies: did the lockfile change, and why?

A one-line feature should not add three packages. If it did, ask whether the standard library or an existing dependency covers it.
Check licences on anything new.
Prefer the version already in the repo when an agent proposes an upgrade "to fix a type error".

5. Performance: what happens at ten times the data?

Loops that call the database (N+1) are the most common agent-introduced performance defect we see, because the code is correct and reads naturally.
Unbounded queries with no pagination, missing indexes on new foreign keys, and synchronous calls to external APIs inside request handlers.
On the frontend, anything that runs on every render or ships a large dependency to the client.

PR size limits are the real lever

The single most effective change we made was a hard size limit. Our rule: an AI-generated PR is at most 300 changed lines, excluding lockfiles, generated files, and snapshots. Above that, the agent is asked to split the work and the reviewer declines to review.

The reason is arithmetic. Review quality decays with diff size faster than reviewers notice, and the agent does not care whether it produces one PR or four. Small PRs also make the intent check trivial: a 100-line diff that does two things is obvious; a 1,200-line diff that does seven is not.

A related rule: one PR, one concern. Refactors and behaviour changes are separate PRs even when the agent produced them together. Moving code and changing code in the same diff is unreviewable.

CI gates that do the mechanical review

Anything a machine can check, a machine should check before a human looks. Our baseline gates on every PR:

Type check and lint, with warnings treated as errors on new code.
The full test suite, plus a coverage floor on changed files so an agent cannot ship untested branches.
Dependency audit and a check that the lockfile matches the manifest.
Secret scanning.
A migration safety check: no destructive migration without an explicit label and a reviewer who owns the data.
For LLM features, the eval suite, which we treat exactly like unit tests.

Martin Fowler's writing on continuous delivery is old by industry standards and still the clearest argument for this: every commit should be provably releasable, and the way to prove it is automation, not inspection. Agents just raise the stakes.

Ownership and accountability

An agent cannot be paged. Every PR has a named human author who is accountable for it, regardless of how much of the diff the agent wrote. That person prompted the agent, read the output, and chose to open the PR. The reviewer is a second human. Two humans, always, for anything that reaches main.

This matters for culture as much as for correctness. "The agent did it" is not an acceptable postmortem finding, and the way to prevent it from becoming one is to never let a diff enter the repo without a human who will say "I did this".

We also ask the author to record what the agent was asked to do. Prompts and agent transcripts are not committed, but the PR description carries the brief. When a defect surfaces later, knowing what was asked is often more useful than knowing what was produced.

A PR template that makes the checklist unavoidable

This is close to the template in our repositories. It is short because long templates get pasted over.

## What and why
<!-- One or two sentences. Link the issue. -->

## How it was built
- [ ] Agent-assisted (tool: ____ ), brief summarised below
- [ ] Hand-written

Brief given to the agent:
> ...

## Assumptions made
<!-- Timezone, locale, ordering, where ids come from, defaults. -->

## Review checklist (author fills, reviewer verifies)
- [ ] Diff matches the brief; no unrelated changes
- [ ] Tests cover the failure cases, not just the happy path
- [ ] Auth checked against the session; input validated with a schema
- [ ] No new dependencies, or each one justified below
- [ ] No N+1, unbounded queries, or sync external calls in handlers
- [ ] Under 300 changed lines (excluding generated files)

## Rollback
<!-- How to undo this if it misbehaves in production. -->

The "assumptions made" section catches the most defects. Forcing the author to write down what the agent assumed turns a hidden decision into a visible one, which is the whole problem with AI-written code in one sentence.

What this looks like after a few months

Review gets faster, not slower, once the gates and the size limit are in place, because reviewers stop reading style and start reading intent. The agent output improves too: a reviewer who keeps rejecting N+1 queries adds that rule to the agent's standing instructions, and the defect stops appearing.

GitHub's research on Copilot found developers completed tasks faster and reported less frustration with AI assistance. Our experience is that the speed is real, and the benefit only compounds if review keeps pace. A team that lets review quality slide has gained a fast way to accumulate defects. Martin Fowler's site has a running series on exploring generative AI in delivery that reaches a similar conclusion from a different direction: the tooling changes the shape of the work, not the need for judgement.