How to split a backlog into tasks parallel AI agents won't fight over

You can give six AI agents six tasks in under a minute. Whether that saves you a day or costs you one is decided entirely in that minute — before any of them writes a line.

The tooling questions (worktrees, tiling, broadcast) are real but downstream. The upstream question is whether the six tasks were independent in the first place. Six tasks that all touch routes.ts aren't parallel work; they're one task being attempted six times, and you'll pay for it at merge.

Rule 1: split by file ownership, not by feature

The intuitive split is by feature — "you do search, you do export, you do billing." The split that actually works is by which files get written.

Before dispatching, ask for each task: which files will this touch? If two tasks answer with the same file, they are not parallel, no matter how unrelated the features sound. Search and export both register a route. Both edit the router. That's a conflict, scheduled.

You don't need perfect foresight. A rough map is enough:

Two of those three collide. Which leads directly to the fix.

Rule 2: land the shared edits yourself, first

The shared file in the table above is routes.ts. It's five lines of work. Do it yourself, before dispatching: add all three route registrations pointing at handlers that don't exist yet, commit to main, and let each agent branch from that.

Now each agent's job is "make lib/export/csv.ts exist and satisfy this signature." Nobody touches the router. The conflict is gone because the contested edit happened once, up front, by one writer.

This generalizes. Interfaces, type definitions, schema migrations, config keys, translation-file keys — anything several tasks need to agree on should be committed to the base branch before any agent starts. Ten minutes of your own work removes hours of merge archaeology, and it's the single highest-return habit in parallel agent work.

Rule 3: size tasks to your review capacity, not the agents'

Agents will happily accept a task that produces a 900-line diff. You will not happily review six of those.

The real constraint on fleet size isn't your machine or your token budget — it's how much generated code you can genuinely read in a day. Everything you don't read either goes in unreviewed or piles up. Both are worse than having run fewer agents.

A practical target: each task should produce a diff you can review in about fifteen minutes. Roughly a few hundred lines. Tasks bigger than that should be split, not because the agent can't do them, but because you can't check them.

This also improves the output. A tightly scoped task ("add pagination to the list endpoint, tests included") has a verifiable done-condition. A broad one ("improve the API") produces an agent making architectural decisions on your behalf across files you weren't watching.

Rule 4: order by feedback, not by importance

Given six ready tasks, don't start the six most important. Start the ones whose results change what the other tasks should be.

If you're unsure whether the new caching layer works at all, that task should run alone and first. Five agents building on an approach that turns out to be wrong is the most expensive thing a fleet can do, and it's a scheduling mistake, not a technical one.

The sequencing that holds up:

1. Uncertain-and-foundational — run alone, verify, commit to base.
2. Independent-and-well-specified — the parallel batch. This is where a fleet actually earns its keep.
3. Dependent-on-review — anything that should follow from what batch 2 reveals.

Most backlogs contain more batch-2 work than people expect: tests, migrations of a pattern across files, documentation, small isolated endpoints, dependency upgrades. Those are the tasks worth parallelizing hard.

A dispatch checklist

Before you hand out work, run the list:

• Does each task name the files it will write?
• Do any two tasks name the same file? If yes, extract the shared edit and land it first.
• Is each task's done-condition checkable without asking the agent? (A test passes, an endpoint returns 200, a build succeeds.)
• Is each expected diff reviewable in ~15 minutes?
• Is anything in the batch dependent on an unverified assumption? If yes, pull it out and run it first, alone.

Five questions, two minutes. It's the cheapest step in the whole workflow and the one most often skipped, because dispatching feels like progress and planning doesn't.

Then the tooling

Once tasks are genuinely independent, the mechanics are straightforward: a git worktree per task so nothing collides on disk, one session per worktree, and a way to see all of them at once so you know which are running and which are waiting.

That ordering matters. Good tooling on top of bad decomposition gives you a very tidy view of six agents editing the same file. The tooling is what makes parallel work legible; the decomposition is what makes it parallel.