Small Batches §

Pattern: A named solution to a recurring problem.

Keep every unit of change small enough to finish, verify, merge, and undo within hours, so feedback arrives while a mistake is still cheap to fix.

Also known as: Working in Small Batches, Small Steps

An agent can write 2,000 lines before lunch. Nobody can review 2,000 lines before lunch, and nobody can say which of those lines broke the build when the merge goes red at 4 p.m. The cost of producing a change has fallen through the floor. The cost of checking it, landing it, and backing it out hasn’t moved. Small Batches is the old discipline that keeps those two costs in proportion, and it matters more now than it did when people wrote all the code.

Understand This First §

Context §

This is an operational pattern. It governs the size of every change that moves through your delivery system: the step an agent takes before it runs the tests, the pull request a reviewer reads, and the release that reaches users. A batch is the amount of work that passes through one of those checkpoints at once.

The idea comes from lean manufacturing, where shrinking the lot size on a production line exposed defects sooner and cut the inventory sitting between stations. Software teams adopted it through Extreme Programming’s small releases and later through continuous delivery. The DevOps Research and Assessment (DORA) program treats it as a core capability and puts the warning bluntly: “Any batch of code that takes longer than a week to complete and check is too big.” DORA also counts a batch as finished only when it’s deployed and receiving feedback, not when the code is written. With agents doing the typing, that definition matters: a batch is measured by how long it takes to check and land, and those steps run at human and pipeline speed.

Problem §

You ask an agent for a feature and it delivers the whole feature in one pass: new endpoints, a schema change, updated callers, and a refactor it decided was necessary along the way. The change is plausible everywhere and verified nowhere in particular. Review stalls because no one can hold it in their head. When something breaks after the merge, the cause could be any of a dozen interleaved edits, and reverting the whole thing throws away the parts that worked.

How do you keep the speed agents offer without letting each change grow past the point where anyone can check it or cleanly undo it?

Forces §

Solution §

Cap every unit of change at what can be finished, independently verified, merged, and if necessary reverted within hours to a day, and let the agent move forward only from a known-good state. Small means small in time and in purpose, not only in line count: one reason to change, one check that proves it worked, one clean point to stop.

Apply the cap at all three levels where work passes a checkpoint:

The usual obstacle is the change that “has to” land together. Three techniques let unfinished or interdependent work merge in small pieces without breaking anything. A Feature Flag ships code dark and exposes it later. Parallel Change adds the new form of an interface, migrates callers, and removes the old form as separate merges. Branch by abstraction puts an interface in front of the component you’re replacing, so the old and new implementations live side by side on the mainline until the switch. With those three, a feature that seemed to need one giant merge becomes a series of ordinary ones.

The economics explain why this works and where it stops. Donald Reinertsen framed batch size as a tradeoff between transaction cost (the fixed overhead of pushing a batch through) and holding cost (what it costs to delay feedback and leave defects undiscovered). Total cost traces a U-shaped curve, and the bottom of the curve moves when either cost changes. Agents raise holding cost, because they pile more unchecked work into the same hour. Fast CI, automated checks, and cheap deploys lower transaction cost. Both push the optimal batch smaller, and the practical lever is the second: if a small change is painful to land, fix the pipeline rather than enlarging the change.

Write the cap down where the agent will read it. An Instruction File that says “stop after each step, run the tests, commit; one pull request per logical change; if the diff would exceed a few hundred lines, propose a split before writing code” turns a team habit into a default the agent follows. Then measure it: the distribution of diff sizes, time from first commit to merge, change failure rate, and how long it takes to find the commit behind a regression.

Warning: Splitting a big change into five pull requests that only work once all five have merged isn’t small batches. It’s one large batch in five envelopes. Each batch must leave the mainline working and deployable on its own; if it can’t, the split is cosmetic and the risk is unchanged.

How It Plays Out §

A developer asks an agent to add multi-currency support to a billing service. The agent returns a 2,400-line branch that touches pricing, invoicing, and the database schema. Review drags on for three days, the branch drifts from the mainline, and a rounding regression ships with the merge. Nobody can tell from the diff which part caused it, so the team reverts everything.

The second attempt starts with a different prompt: list the batches first. The agent proposes six, starting with a currency column that has a default value and changes no behavior, then a conversion module behind a flag with its own tests, then invoicing that reads the new column while the flag stays off. Each batch merges, deploys, and runs for a day before the next begins. When the fourth batch shows a rounding difference in staging, the culprit is a 180-line change, and the fix takes an hour.

A platform team rolls out coding agents across its repositories. Deployment frequency climbs within a month, and so does the change failure rate. Looking at what failed, they find the median agent-authored pull request has grown to several times the size of the human-authored ones, and most failures sit in the largest changes. They add a size ceiling to every repository’s agent instructions, require the agent to split anything bigger into stacked changes that each pass CI on their own, and track diff size on the same dashboard as failure rate. (The scenario is illustrative, though it follows the shape DORA describes: AI adoption tends to raise delivery instability, and working in small batches counters it.)

Example Prompt: “Before writing any code, list the smallest sequence of changes that delivers this feature. Each change must merge on its own with all tests passing and leave the app working. Implement only the first one, run the tests, and commit. Then stop and show me the diff.”

Consequences §

Benefits. Feedback arrives within hours instead of weeks, so a wrong assumption costs a small change rather than everything built on top of it. Review becomes a real read instead of a skim, which keeps the human check meaningful as agent output grows. When something breaks, the failing change is small enough to identify by inspection and cheap enough to revert without losing good work. Compounding Error gets interrupted, because an independent check sits between every few agent steps instead of at the end of a long run. And the mainline stays close to every branch, so merges stay boring.

Liabilities. Each batch pays the fixed overhead again: another CI run, another review, another deploy. If that overhead is high, small batches feel slow until the pipeline improves, and Reinertsen’s curve is a reminder that smaller isn’t always cheaper when transaction costs dominate. Splitting work well is a skill, and asking an agent to plan the sequence first adds a step that some tasks don’t need. Flags and parallel interfaces left in place after their batches land become debt that needs its own cleanup.

Smaller changes arrive more often, so a team whose reviewers are already the constraint will see the queue’s count rise even as each item gets easier. Machine-written slices can also cost more attention per line than a colleague’s. Pair this pattern with attention to Review Bottleneck rather than expecting it to fix review capacity on its own.

A small batch is only as safe as the check that closes it. If the tests pass no matter what the agent changed, every “verified” step is an unverified one with a commit attached. Reverting a commit also doesn’t un-run a migration that already rewrote the data, or recall a message an earlier batch already sent. Changes with effects outside the repository stay cheap to undo only when they’re built to be reversed, which is the job Parallel Change does for schemas and interfaces.

Related Articles §

Sources §