read every ai diff line by line, or lean on tests, at 15 merges a week code-review

Neither uniformly. Route by blast radius, because that's the thing that actually varies.

What we landed on after about eight months:

• anything touching auth, payments, permissions, migrations or deletion: read every line, run it locally, second reviewer. No exceptions regardless of how small the diff looks. Maybe 15% of PRs
• anything where a wrong result is caught by a test that already exists: skim the diff shape, read the test changes carefully, merge. But if a test was modified rather than added, that's a stop sign — it's the most common way model-written code goes green
• everything else: read it properly, don't agonise

The highest-value rule in there is treating a modified assertion as a blocker. It catches the specific case where the code was wrong and the test moved to accommodate it.

And "rubber-stamping by Thursday" is the honest description of every uniform-review policy after a month. Design for it rather than pretending.

The thing that helped us most wasn't a review policy, it was making the author responsible for the diff being reviewable.

Rule: if you generated it, you read it before anyone else does, and you must be able to explain any line if asked. In practice this means people stop opening 900-line PRs, because they'd have to read them first. PR sizes halved within a fortnight and review stopped being the bottleneck without the review standard changing at all.

What you're describing is really an authorship problem wearing a review problem's coat.

Concrete thing worth adding regardless of policy: a dependency check. Model-written code adds packages, and a diff that quietly pulls in a new transitive dependency is invisible during a line-by-line review of application code.

CI fails if package.json or the lockfile changed and the PR description doesn't say why. Cheap, and it's precisely the category where line-by-line review catches nothing.

Six-minute CI on 1,100 tests is a real asset — you can afford to run the full suite per commit rather than per PR. What I'd check is whether those tests would fail for the interesting kinds of wrong. Coverage says nothing about that. Run a mutation pass over the money paths once and you'll know exactly how much you're allowed to lean on them.

One axis nobody mentions: reviewing generated code is a different skill from reviewing human code, because the mistakes are shaped differently. Humans get things wrong near the edge of what they understood. Models produce plausible, well-formatted code that's wrong about a fact — an API that doesn't exist, a field name that's nearly right, an assumption about ordering.

So read for facts, not for style. The style is always fine. That's the trap.

if you trust the tests you don't need review. if you don't trust the tests, fix the tests. review is a workaround for bad tests