The batch size of software

There is a strange moment in working with a coding agent when you realize you can ask for much more.

You were going to ask for a function. You ask for the feature. Then the tests, the interface, the migration. The agent keeps going. Why interrupt it?

Suppose you ask it to add CSV exports to an application. It returns a download button, an endpoint, a background job, and a small storage abstraction. The tests pass. Then you try exporting a filtered table and discover that the file contains every row.

The agent understood “export” differently. That decision now lives in several places.

The mistake might have been cheap to discover after the first working request. By the time the feature looks finished, correcting it means finding everything that grew around it.

What is in a batch?

Software has always been made in batches: releases, pull requests, commits. Agents introduce another choice: how much work to delegate before asking for evidence that the direction makes sense.

It is tempting to measure this in lines of code. But a thousand-line mechanical rename can be easier to judge than a ten-line change to who can see a customer's data.

I think the more useful batch size is the amount of work built on assumptions we haven't checked yet.

For the export feature, those assumptions include what “all rows” means, whose permissions apply, and whether the file should reflect the table as it looked when the user clicked. Once those are settled, the agent may have plenty of ordinary implementation work it can do independently.

This is why splitting a large diff into ten commits afterward doesn't necessarily make the work incremental. The opportunity to correct an early assumption has already passed. A checkpoint matters when its result can change what happens next.

The principle predates AI. A 2018 study of code review at Google examined roughly nine million changes from 2014 to 2016. The median change modified 24 lines. Initial feedback took a median of under an hour for small changes, compared with about five hours for very large ones.

That is an observation about one engineering environment, not a prescription for 24-line pull requests. But it is a useful reminder that a large software organization can operate through very small changes.

The expensive part of being wrong

In an April 2025 post, Andrej Karpathy described a rhythm for AI-assisted coding. One instruction was: “Describe the next single, concrete incremental change we're trying to implement.” He followed it with choosing an approach, reviewing, testing, and committing.

The important word there is “next.” You are allowed to learn something before deciding what follows.

Consider two ways to divide the export feature. One is by layer: database work, then endpoint, then interface, then tests. Each task sounds small. Yet you might finish three of them before a user can tell you the export is wrong.

Another is to make one authorized request export the currently filtered rows, even if the button is ugly and large files are still unsupported. That crosses several layers, but answers an important question. You can then decide whether a background job is necessary at all.

A small batch should close a question. Merely finishing a file doesn't do that.

This gets more valuable when code is cheap to produce. An agent can make an uncertain decision look established very quickly. It can give it types, tests, documentation, and a pleasing interface. You then have to distinguish the work worth keeping from the work that faithfully implements the wrong idea.

Deleting generated code may be cheap. Discovering which assumptions it spread through the system can still be expensive.

There is a human cost too. Simon Willison described losing a “firm mental model” of his software as unreviewed AI-generated code accumulated. You can end up owning a working system while becoming less able to reason about its next change.

A long leash with short feedback

None of this means an agent should ask permission after every function. Constant supervision has a cost. You have to stop thinking about one thing, reconstruct another, answer a question, and switch back. Enough interruptions make delegation pointless.

Long assignments and short feedback loops can coexist. An agent can run tests, inspect a browser, compare outputs, and correct itself without calling you over each time. The useful boundary is where it encounters a decision its available feedback cannot settle.

“Does this output preserve the filter?” may be testable. “Should this export include data the user cannot currently see?” needs a clear policy. A passing build cannot supply one.

Anthropic's March 2026 experiments with long-running agents make this trade-off unusually concrete. For one game-maker prompt, a solo run took about 20 minutes and cost $9; its fuller harness took about six hours and cost $200, with better output in the author's assessment. This was a demonstration, not a controlled estimate of the return on checkpoints.

Later, with a more capable model, the author removed the explicit sprint structure and moved evaluation to the end of the run. Some scaffolding had become unnecessary. The useful amount of supervision depended on the task and the model.

That seems like the right ambition for a software factory: let it carry out a large assignment, while giving it ways to discover errors before more work depends on them. Where feedback is strong, leave it alone. Where an assumption is both uncertain and consequential, arrange an earlier check.

Spend the speed on learning

There is a less obvious possibility here. Agents can make small batches cheaper too.

Part of the reason to bundle work is the overhead of setting it up, writing tests, preparing a review, and explaining what changed. Agents can help with those chores. We don't have to spend every improvement in generation speed on a larger pile of code.

DORA's guidance on small batches makes an important qualification: splitting development into pieces and then bundling them for testing or release still delays feedback. The same applies inside an agent session. Ten tasks completed before anything is exercised can amount to one large bet.

Before delegating a feature, I would ask: what could we learn early that would make the rest of this work unnecessary?

For a migration, it might be whether old and new readers agree on one awkward record. For retrieval, whether a handful of difficult queries return useful evidence. For a new interface, whether someone can complete the main action without an explanation. These checks won't settle everything. They can prevent a lot of polished work on a bad premise.

As those questions get answered, larger batches become reasonable. Repetitive work with clear rules deserves more freedom than unfamiliar work whose requirements are still moving.

The next time an agent offers to build the whole thing, it may be worth letting it. First, decide how it will find out that it is wrong.

Cheap implementation gives us a choice: build more before we learn, or learn more before we build.