Small batches matter even more with AI

One of the more predictable side effects of AI in delivery is that it becomes much easier to create work faster than the rest of the system can absorb it. Code can be generated more quickly, options appear sooner, and teams can make visible progress in far less time than before. That can feel like momentum, and sometimes it is, but it also creates a new temptation: to take on work that is too broad, too fuzzy, or too heavily loaded with dependencies simply because the mechanics of producing it now seem easier.

That is usually where trouble starts.

Small batches have always mattered in delivery, even if many organisations have found ways to ignore that fact for long periods. Work gets bundled together, scope expands, unresolved questions are carried forward, and teams convince themselves that bigger items are more efficient because they reduce coordination overhead or make planning feel tidier. In reality, large batches tend to hide uncertainty, increase waiting, complicate review, and make failure more expensive when it finally arrives.

AI does not change that. It makes the consequences sharper.

When the cost of generating change falls, the cost of poorly shaped change becomes more visible. A team can now create far more in a short space of time, but if the work itself is too large, too ambiguous, or too entangled with other moving parts, then speed at the point of creation quickly turns into delay elsewhere. Review becomes harder, testing becomes heavier, dependencies become more awkward, and the chances of discovering important misunderstandings late in the process rise with them.

That is why small batches matter even more once AI enters the picture.

They do not matter because smaller always sounds neat or agile. They matter because small, well-bounded pieces of work are easier to understand, easier to validate, easier to review, and much less likely to drag a whole chain of assumptions and dependencies behind them. When work is kept narrow enough, the organisation has a better chance of knowing what it is actually trying to achieve, whether it has done the right thing, and what needs to happen next if something is wrong.

One client found this quickly as their AI-enabled ways of working matured. Rather than treating large pieces of work as the norm, they began focusing on very short, tightly bounded slices that could be completed in anything from an hour to a few days. The reason was not ideological. It was practical. Once work became too large, people got lost, dependencies surfaced, ambiguity multiplied, and the chances of successful completion fell away. Smaller slices, by contrast, made it easier to keep context clear, stay close to the problem being solved, and avoid disappearing into work that looked productive but was actually drifting.

That is one of the most useful things small batches do: they make drift easier to spot.

In a slower environment, large batches can remain in motion for quite a while before anyone is forced to confront how uncertain they really are. The work looks active, people stay busy, and progress can be narrated in ways that sound reassuring. AI compresses that illusion. If generation becomes faster but the work remains too broad, uncertainty does not disappear; it simply moves faster through the system. Teams can produce a lot without really reducing risk, and the organisation can mistake output for clarity right up until the point at which review, release, or real-world use starts to expose what was not properly understood.

Small batches help break that pattern because they force sharper thinking earlier. Scope has to be tighter, intent has to be clearer, and dependencies become more visible because there is less room to hide them inside a large item of work. That makes them especially useful in AI-enabled environments, where the machine is perfectly capable of generating a great deal from a weakly framed request. Keeping the batch small limits the damage when the framing is off and increases the chance that learning arrives early enough to be useful.

There is another reason this matters. AI can encourage people to believe that because something can be generated quickly, it is sensible to ask for more of it at once. In practice, bigger requests often create exactly the opposite of what was intended. Context gets muddier, important questions get deferred, and the output becomes harder to reason about because too many concerns have been bundled together. What looked like acceleration begins to feel more like overload. Small batches are one of the simplest ways of resisting that trap, because they keep the problem narrow enough for judgement to remain strong.

They also improve the wider system around the work. Review is lighter, testing is more focused, feedback arrives sooner, release becomes less risky, and the cost of getting something wrong is lower because less has been committed at any one time. All of that was true before AI, but it becomes more valuable when the pace of change increases, because the system has fewer opportunities to recover from large, ambiguous, heavily coupled work moving through it at speed.

This is why organisations that are able to make good use of AI usually become more disciplined about shaping and slicing work, not less. They do not treat the technology as a reason to load more complexity into a single request. Instead, they use it to increase the speed and quality of progress within tighter boundaries. They recognise that smaller batches are not a constraint on acceleration. They are one of the conditions that make acceleration safer and more useful.

Seen this way, small batches are not really a delivery tactic. They are a way of protecting clarity in a faster system.

That matters for leaders as much as it does for teams. If leadership responds to AI by pushing for larger throughput without improving how work is framed and bounded, the organisation can end up generating more change with less control. The pressure lands in review, assurance, release, and operations, and people start to experience the pace as fragmentation rather than flow. When work is kept smaller, on the other hand, it becomes easier for the whole system to absorb change without losing coherence.

AI makes it easier to create more, but that does not mean more should be carried in a single piece of work. If anything, the opposite is true.

The faster the system becomes at producing change, the more important it is to keep that change small enough to understand, validate, and move safely. That is why small batches matter even more with AI. They help ensure that speed becomes progress rather than just volume.