2026-07-20

Why a TaskSlice has to be small

A language model has a context window. A real software project doesn’t fit inside it — not the requirements, not the existing code, not both at once. TaskSlicing is the answer: requirements aren’t summarized, they’re decomposed. But decomposed into what, exactly — and how small is small enough?

A TaskSlice is not a ticket, it’s a prompt

The obvious mental model is that a TaskSlice is just a smaller ticket: “build the login page” instead of “build user management.” That’s not quite it. A TaskSlice is first and foremost a prompt that fits entirely inside a context window — together with exactly the context that one step needs to be handled correctly. The size of a slice isn’t a matter of taste; it’s a boundary set by the model itself.

That has an immediate consequence: a worker handling a TaskSlice never sees the overall plan. It sees its own step and the context that step needs — nothing more. That’s not a safety mechanism, it’s a direct consequence of the context-window boundary: a larger slice simply wouldn’t fit.

What follows: coordination instead of knowledge

If no single worker knows the overall plan, something else has to hold the ordering and the dependencies. That’s the coordinator’s role: it holds the graph of TaskSlices and distributes them through a durable queue. TaskSlices within a phase run in parallel — as many at once as the deployment’s workers provide — while phases themselves run one after another, separated by barriers.

The difference between a phase and a TaskSlice is really the difference between two questions: a phase answers “what has to be done before the next thing can start?” A TaskSlice answers “what fits into a single prompt?” Together, both answers produce the structure that ends in a Git repository with real history — every TaskSlice leaves its own commit, none overwrites another’s work.

Small isn’t a compromise

The temptation would be to cut TaskSlices larger to save overhead — fewer handoffs, less coordination. But that would give up the one property the whole approach rests on: that every step can be fully checked, because it fits entirely inside the context of the model handling it. A TaskSlice is small because the alternative isn’t “a bit more overhead” — it’s “a step that can no longer be fully checked.”