{"slug": "speeding-up-code-review-with-small-change", "title": "Speeding up code review with `small-change`", "summary": "Imprint reports its average engineer now merges 4x more pull requests than two years ago, with two teams merging 10x their prior volume and one engineer merging 25x the weekly PRs of the 2022 average, while incidents fell 42% and critical incidents 78% half-over-half. To counter review time rising from a p50 of about 33 minutes two years ago to about 77 minutes, Imprint built a `small-change` workflow in which an `ai-code-review` bot and a `review-small-change` tool approve narrow, non-draft changes that pass all checks, with per-path customization via a `.small_change` file. About 10% of changes currently qualify as small-changes, and Imprint says the approach's success depends on expanding that percentage alongside more comprehensive verification.", "body_md": "Imprint’s average engineer is merging 4x more PRs than 2 years ago. Yay. Aggregated behind the average is something even more interesting: we have two teams that are merging 10x their PRs over that period. One engineer is merging 25x the PRs per week of our average engineer two years ago, and a number are merging 10x. That’s pretty neat, and the slope of the line suggests our average in a year is going to look much closer to today’s p90 than today’s p50. Even more importantly, we aren’t just shipping more, our quality has improved: incidents are down 42% half-over-half, and critical incidents are down 78% half-over-half. I think we’ve always known the quality/velocity tradeoff wasn’t a particularly useful construct, but that’s undeniable today.\n\nAs we’ve walked this path, we–[like everyone else](https://claude.dev/blog/solving-code-review-at-anthropic/)\nprogressing down it–have run into the problem of pull request review. The p50 pull request review took about 33 minutes to complete\n2 years ago, but now takes us about 77 minutes. The slope here correlates tightly with the number of\npull requests getting merged. Tightly enough that addressing it became one of my priorities for the week.\n\nWe solved it! Just kidding, we’ve absolutely not solved it, but I think our current\napproach is an interesting one, which we call the `small-change`.\n\nThere are four reasons we review pull requests:\n\nIn the modern development paradigm, we think there is a better solution for each of these problems. But, we also want to make these changes very cautiously.\n\n`small-change`\nWe believe we move fast by finding narrow, contained ways to validate new practices,\nso to iterate our way into an effective solution, we’ve developed the concept of a\n`small-change`. Here’s how it works:\n\n`ai-code-review` automated review bot`N` distinct services or applications. `.small_change` file which allows per-path customization while we continue to tune the behaviors.\nFor example, a service dealing with money movement can be excluded`review-small-change` which takes a list of repositories and reviews all open, non-draft, small-changes,\nincluding providing approval if they meet the review’s criteria (all checks pass including `review-pr-cluster` which reviews batches of pull requests to identify common themes that came up, and suggest opportunities\nfor discussion and adding verifications\nThis took about two days of infrequent attention to implement and rollout, although I imagine we will be tuning the knobs here for a long time. Maybe forever.\n\nI’ll be honest, it’s too early to give a useful result here.\nFrom early results, about 10% of changes qualify as a `small-change`.\nThose are now eligible for very fast approval, and generally get it unless\nthey trip a flag, generally due to touching a security or money adjacent topic.\n\nWhile 10% is a small percentage, the core concept here is working,\nand ultimately will succeed or fail based on our ability to expand\nthat percentage over the next few months in tandem with expanding\nour verification mechanisms to be increasingly comprehensive.\nThis is ultimately going to fail or succeed depending on our ability\nto improve our verifications, which does require more difficult sorts of techniques\nto accomplish in [low scale-complexity, high domain-complexity](https://lethain.com/quality/) software\nthan in the high scale-complexity, low domain-complexity products where many techniques\nlike incremental rollouts are exceptionally effective. (Don’t get me wrong,\nthey still work, they just provide less coverage when most users have different configuration and behavior.)\n\nFolks have not been uniformly excited about this, it’s a substantial change from how we’ve learned to be good engineers, and it’s uncomfortable to reevaluate whether a long-held best practice has become merely dogma. The most energizing part of the current cycle is that we get to reevaluate these practices we grew up on every week; the most painful part of the current cycle is that we’re likely to fall behind if we ever stop reevaluating them.", "url": "https://wpnews.pro/news/speeding-up-code-review-with-small-change", "canonical_source": "https://lethain.com/small-changes/", "published_at": "2026-10-17 12:00:00+00:00", "updated_at": "2026-10-17 14:03:33.712671+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Imprint", "ai-code-review", "review-small-change", "review-pr-cluster", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/speeding-up-code-review-with-small-change", "markdown": "https://wpnews.pro/news/speeding-up-code-review-with-small-change.md", "text": "https://wpnews.pro/news/speeding-up-code-review-with-small-change.txt", "jsonld": "https://wpnews.pro/news/speeding-up-code-review-with-small-change.jsonld"}}