Speeding up code review with small-change
B · Useful, limited Will Larson, a widely read engineering leader, describes a concrete review policy at Imprint with eligibility rules and early numbers; useful practice, but self-reported and too early for outcome data.
Summary based on the full text·Original: about 7 minutes to read
In short
A post (17 October 2026) by Will Larson on how Imprint handles code review now that engineers merge far more pull requests. Median review time more than doubled as volume rose. The response is a "small-change" lane: CI marks narrowly defined, low-risk changes from experienced authors as eligible, and a review skill either approves them or ignores them, never commenting. About 10% of changes qualify so far.
Key numbers
- ~33 to ~77 minutesmedian pull request review time, two years ago vs now
- 4xpull requests merged by the average engineer compared with two years ago
- 42% / 78%half-over-half fall in incidents and in critical incidents
- ~10%share of changes that qualify as a small-change in early results
As reported by the source.
English·Web page·opens lethain.com
What it reports
- The average engineer merges 4x more PRs than two years ago; two teams merge 10x; one engineer merges 25x the old weekly average.
- Incidents fell 42% and critical incidents 78% half-over-half.
- Median (p50) review time rose from about 33 to about 77 minutes, tracking PR volume.
- Eligibility, set by a CI check that people cannot edit: under 1,000 lines; no p1 or p2 findings from the AI code-review bot; author has 10+ merged PRs in each affected service; touches fewer than N services (1 in the frontend monorepo, 3 in the backend); shared libraries excluded; per-path opt-outs (for example money movement).
- A review-small-change skill approves or ignores, avoiding what Larson calls "meat proxy review", where teams paste local-harness comments onto PRs and then use harnesses to answer them.
- A review-pr-cluster skill reviews batches of PRs for common themes, to keep knowledge sharing at the level of clusters rather than single PRs.
- Errors from a small-change are treated as system failures, fixed in review automation and verification.
- Rollout took about two days of intermittent attention.
How they got it
Practitioner account from Imprint's engineering leadership, with internal metrics stated but not shown. No comparison group.
Limits
- Larson says it is too early for useful results; 10% eligibility is the main figure.
- Velocity and incident figures are internal and self-reported, and the incident fall is not attributed to the review change.
- Compliance obligations still require independent human review in some repositories.
Why it matters for companies
As AI raises PR volume, review becomes the queue. The eligibility rules are a template: tie fast approval to author experience, change size, blast radius and automated findings, and exclude sensitive paths. The critique of pasting AI review comments onto PRs is worth acting on: it adds work and removes the learning that review was meant to provide. Success depends on verification improving enough to widen the lane.
Summary based on the full text. Read the original for the full argument and data.Read the original on lethain.com
- Tags
- Coding agents