Will Larson's small-change: Imprint lets CI decide which agent-era PRs get a fast approve-or-ignore review

Will Larson writes that the average engineer at Imprint now merges about 4x the pull requests they did two years ago, two teams are at 10x, and one engineer merges 25x the weekly PRs of the average engineer from two years back. He reports incidents down 42% and critical incidents down 78% half over half. The cost showed up in review: the median pull request review went from about 33 minutes to about 77, and he says the slope tracks merge volume closely.

His post starts by asking what review is for. He lists four jobs: knowledge sharing, catching errors, catching malicious changes, and compliance. He argues each now has a better home. Knowledge sharing moves to clusters of pull requests instead of single ones. Errors are better caught by CI and harness verification such as pstack. Abuse is better caught by fixed rules, auditing and log inspection. Compliance still requires independent human review in some repositories.

How small-change works

When a pull request is marked ready, CI decides whether it is a small-change and reports that as a GitHub check that people cannot edit. A label exists for filtering, but the check is what counts. A change qualifies only if all of these hold:

• It is under 1,000 lines.
• Imprint's AI code review bot raised no p1 or p2 findings.
• The author has 10 or more prior merged PRs in every service or application it touches.
• It touches fewer than N services (1 in the frontend monorepo, 3 in the backend one), and no shared libraries.
• A per-repository .small_change file can exclude paths, such as a service that moves money.

Two shared skills run in engineers' harnesses on top of that. review-small-change sweeps open small-changes and approves those whose checks all pass and that avoid sensitive topics like payments and security. It has only two moves, approve or ignore, and never comments. review-pr-cluster reviews batches of PRs to find recurring themes and suggest new verifications. The social rule is that any error from a small-change is a system failure, to be fixed in the AI review, the verifications, CI or the harness.

Why it matters for code review

Larson names the failure mode the approve-or-ignore rule is meant to avoid, "meat proxy review," a term he links to Simon Willison. A team overwhelmed by reviews has each reviewer run their local harness over the PR. The PR fills with comments the reviewer may not even agree with, the author's harness answers them, and the whole exchange becomes "an illusion that doesn't facilitate learning." His fix is to invest in one central review mechanism and the harness loop that addresses its feedback, then simply stamp approval. Imprint's other lever is fleet, a centrally orchestrated cloud harness he compares to Stripe's Minions, which decides how many independent reviewers each change needs, sometimes just one human.

He is candid that it is early. About 10% of changes qualify, the scheme took about two days of part-time work to roll out, and "folks have not been uniformly excited." He says it will succeed or fail on whether verification can grow fast enough to widen that 10%. Read with Anthropic's risk-tiered review on the Claude Code team, Kleine's always-on fleet with AI review capped at two rounds, and Stripe's Minions harness.