How to break work into tasks AI coding agents can finish

The agent says it's done. The diff is 900 lines across nineteen files, it touches three things you never asked about, and somewhere in the middle it quietly changed how errors are handled.

Now you spend an hour working out which 700 of those lines you actually wanted.

This is the most common way agent work goes wrong, and it's almost never a model problem. It's a sizing problem, decided before you typed a word.

Big tasks fail late, which is what makes them expensive

A hard task fails fast. The agent hits something it can't reason about, says so, and you're out five minutes.

A big task fails late. Everything looks fine for twenty tool calls. The agent makes steady, confident progress on a plan that took a wrong turn at step four, and by the time you notice, that turn is load-bearing for everything built on top of it.

Three things compound as a task grows:

• Ambiguity multiplies. Every underspecified detail is a coin flip. Ten decisions at 90% odds each leaves you a 35% chance of a clean result.
• Context fills up. A long job burns the window rediscovering files, and the constraint you gave at the start stops being visible by the end.
• Review degrades. Nobody reviews a 900-line diff properly. You skim it, approve it, and inherit whatever was in there.

Halving a task doesn't halve the risk: it cuts the exponent. That's why it helps far more than it feels like it should.

The one-sitting test

The rule of thumb worth internalising: a task is the right size when you can state, before the agent starts, exactly how you'll know it worked.

Not "the feature is done." Something you could check in under a minute: a test that goes green, an endpoint that returns the right shape, a page that renders real data.

If you can't name that check, you don't have a task. You have a project, and you're about to hand it over as though it were a task.

A few bounds that hold up in practice:

• One concern per task. "Add the endpoint" and "rate-limit the endpoint" are two cards, not one.
• Watch the file count. If it touches a dozen files with no shared reason to change, it's probably two tasks wearing a coat.
• Split on the ands. If your brief needs the word "and" twice, you've already written the task list.

Cut along seams you can verify

The instinct is to split by layer: one task for the schema, one for the API, one for the UI. It looks tidy, and it's usually the wrong cut: none of the pieces can be verified alone. You don't know whether any worked until all three land.

Cut vertically instead. The thinnest slice that goes end to end and does something: one field, saved and displayed. One route, with its test. Then the next slice.

Vertical slices leave a working system at every step, so a break is diagnosable : the last slice did it. Horizontal layers leave three unverified halves and a debugging session at the end.

Be honest: splitting isn't free

Two costs worth naming, because "smaller is better" breaks down at the extremes.

Some work genuinely doesn't split. An atomic rename, a schema change and its backfill, a version bump on both sides of a wire. Cut those in half and you get a broken repo in between. They're big because the change is big, not because you were lazy. Give them one agent, one focused session, and a plan you've read before it starts.

Over-splitting has its own tax. Fifteen micro-cards each need their own brief and context. If explaining a task takes longer than doing it, batch it with its neighbours.

The target isn't "as small as possible." It's small enough to verify, big enough to be worth a session.

Right-sized tasks make everything downstream easier

Once tasks are the right size, the brief gets easy, and that's the real unlock. A well-sized task has an obvious spec: what changes, what stays, how you'll know. Three sentences, not a page.

It also produces a diff you can review at full attention, in the two minutes it deserves. And the agent has less room to invent scope, because there's less room in the task.

Where the list lives matters

Most people keep this list in their head, which is why it's gone by Wednesday. The careful split you did on Monday evaporates, and you're back to pasting paragraphs into a terminal.

SanuDesk is a desktop app built around that list. A Kanban board sits next to your agents: one card per task, the brief in the notes, and a deploy button that hands it to a fresh Claude Code, Codex or Gemini session. That session starts with the card and nothing else: no leftover context from the last three jobs, no drift from one that ran too long.

Because sessions tile side by side in one grid, splitting work stops being theoretical. Three well-sized cards become three panes running at once, each finishing something you can check. Loops take the jobs that come back every week (dependency bumps, triage passes) and run them on a schedule so they never reach the board at all.

It's bring-your-own-model, so you're driving accounts you already pay for, and the free tier gets you the board and the grid without an account of ours.

Try it on the next thing you were about to hand over

Take the task you were going to hand an agent this afternoon and write down, in one sentence, how you'd verify it. If that sentence needs an "and," you've found your split.

Download SanuDesk free and put your next three tasks on a board, or see how the grid, cards and Loops fit together on the features page.