Sizing tasks for coding agents: how big is too big
When a coding agent produces a bad result on the teams we coach, the cause is a task that was too big or too vague far more often than the model. The agent was asked to "add multi-tenancy" or "fix the checkout flow" and did what anyone would do with that brief: it guessed. The rule we use: a task fits a coding agent when the agent can finish it in one session, the end state can be verified by a machine (tests, types, a build) and the resulting diff is one a reviewer can read with attention in about fifteen minutes.
What one session means in practice
A session is the agent’s working memory. When the context fills, the tool compacts or resets, and the agent loses the reasoning that got it there: the file it decided to leave alone, the edge case it noticed in the second module. Work that survives a reset is work that was already committed and tested. So the ceiling for one task is what the agent can hold in context with room left for the tests and the diff. On a typical codebase that means a change confined to a handful of files, with the tests that prove it, and a diff under a few hundred lines. A larger change becomes a sequence of such tasks, each merged before the next begins.
Split by verifiable milestone rather than by file
The decomposition mistake we see most is splitting by file or by layer: one task for the model, one for the service, one for the endpoint, one for the tests. Each task produces code nothing exercises, and on the fourth task the agent discovers the first three do not fit together. Split instead along states the test suite can confirm. "The repository returns tenant-scoped rows, with a test" is a milestone. "The endpoint rejects a request for another tenant, with a test" is the next one. Each milestone is a change plus the tests that prove it, merged before the next starts. This is the checkpoint discipline that makes large refactors and migrations safe to delegate, applied to feature work.
Keep together what has to be reviewed together. A change and its tests are one task. A schema migration and the code that reads the new column are one task, or the second one has nothing to run against.
When to run a planning pass first
If you cannot write the milestones from the ticket, the agent cannot either. For any task touching more than a couple of modules, we run a planning pass: the agent reads the relevant code and proposes the milestones, the files it expects to touch and the tests it will write, and a human edits that plan before any code exists. Ten minutes on a plan replaces an hour of reviewing a diff that went in the wrong direction, and the edited plan serves as the task description for each milestone. Skip it for tasks that are already one milestone, such as a bug with a failing test attached; there, the test is the plan.
Checkpoints, commits and the review budget
Ask the agent to commit at every green milestone, with the test command run before each commit. A commit is a save point to reset to when the next step goes wrong, and a diff you can review in pieces. Then size against the reviewer, since code review is where agent output piles up. A reviewer reads a two-hundred-line diff with attention and a six-hundred-line diff with hope. If the milestones are right, each pull request is small by construction, and the review tier your workflow assigns to it (automated checks only, one reviewer, two) follows from its size and its blast radius. This is the part of redesigning the dev loop around agents that teams feel first.
Signs a task is too big, and what to do mid-flight
The agent rewrites the same file for the third time. The context resets and the agent re-reads code it had already understood. The diff passes three hundred lines and is still growing. The summary says "done" while the test command was never run. Running agents in parallel multiplies all of this: a too-big task on three worktrees produces three unreviewable diffs instead of one, which is why engineers who run several agents at once are the strictest about sizing.
Mid-flight, stop. Commit what is green, discard what is not, and write the remaining work as new milestones. Letting the agent push through yields the four-hundred-line pull request that sits unreviewed for a week; half an hour of re-slicing is cheaper. If the same task shape keeps blowing up, the fix is usually upstream: a context file that does not say where things live, or a test command the agent cannot find, both covered by the week spent making the codebase agent-ready.
Teams that size well use the same model as everyone else and get better results from it. The skill takes a few weeks of practice on a real backlog, with someone looking over the first twenty tasks and saying "too big" before the agent starts. That is where we spend the most time with individual engineers when we work with a team on its delegation practice, because it compounds through everything delegated afterwards.