Batch Edits by Concern to Keep Diffs Reviewable

A pattern where you have Claude group a large change into separate batches by concern — pure refactor, behaviour change, formatting, dependency bump — and produce them as distinct commits or steps rather than one entangled diff.

A diff that mixes a rename, a new feature, and a reformat is nearly impossible to review: the reviewer can't tell which lines carry risk. Separating by concern gives each diff a single job, so a mechanical refactor can be skimmed and the one behaviour-changing batch gets the real scrutiny. It also makes reverts surgical — you can drop the feature without losing the refactor.

Any change where you're tempted to also 'clean up while I'm here'. Whenever a diff would carry more than one kind of change, split it.

Small, single-purpose changes that are already one concern. And don't over-split to the point of commits that don't individually build — each batch should still leave the tree working.

This change mixes several concerns. Split the work into separate batches, each with a single purpose — e.g. (1) pure refactor, no behaviour change, (2) the new behaviour, (3) formatting/imports. For each batch, list the files and give it a one-line commit message. Make sure the tree builds after each batch. Then implement them in that order.

Adding a feature, Claude would have touched the same files it was reformatting. Instead it produces three commits: 'refactor: extract validation (no behaviour change)', 'feat: add coupon support', 'style: reformat touched files'. The reviewer approves the first and third in seconds and spends their attention on the middle one.

Ask Claude to sequence the batches so the risky, behaviour-changing one is smallest and lands last, on top of the already-merged mechanical changes. Isolating risk into the tiniest possible diff is the single biggest lever on review quality for large changes.

• Letting a 'quick cleanup' ride along in a feature diff, hiding the one change that actually needed review.
• Splitting into batches that don't each build, so bisecting later lands on a broken commit.
• Over-fragmenting into dozens of micro-commits that obscure the story instead of clarifying it.