Running AI Coding Tasks in Parallel Without Merge Conflicts
The naive version of Run All is a race.
The useful version reads the plan first, separates the groups that touch different files, and puts the ones that would collide into a single lane.
Short answer
Only run cards at the same time if something predicts which of them will touch the same files first. Groups predicted to touch different files can run in parallel, each in its own git worktree; groups predicted to collide belong in one sequential lane. Two agents then never edit a file at the same moment.
What this covers
- In Pathrule, groups predicted to touch different files run at the same time, each in its own git worktree; groups predicted to touch the same files are merged into a single sequential lane.
- That means two agents never edit one file at the same moment, so the user never arbitrates a merge conflict they did not create.
- The prediction is the valuable part: a board of ten cards is not ten independent jobs, and sequencing only the colliding subset is what buys the speed.
- Turned off, every group runs sequentially, which is the safe default for a board whose cards all touch the same area.
What has to be true before Run All is safe
- Each concurrent run has its own checkout, so two agents never share a working copy.
- Something has predicted which cards touch overlapping files.
- Cards predicted to collide are sequenced rather than raced.
- A failure in one lane does not poison the others.
- Landing each branch is a deliberate step, not an automatic push.
Run All is a promise you have to keep
A board with a Run All button makes an implicit promise: press this and the work happens. If pressing it produces four agents editing the same three files, the promise is broken in the most expensive way possible, because you now have to untangle changes nobody wrote deliberately.
So the question is not whether to run cards in parallel. It is what the system knows before it starts.
Predict, then separate
Before anything runs, Pathrule predicts which files each group of cards will touch. Groups that touch different files run at the same time, each in its own git worktree, which means each agent has a physically separate copy of the repository and cannot overwrite another's edits.
Groups predicted to touch the same files are merged into a single sequential lane. They still run; they just run one after another, in an order, which is exactly what you would have done by hand if you had read all ten cards first.
That is the whole idea, and it is worth stating plainly because it is easy to over-engineer: the speed does not come from running everything at once. It comes from sequencing only the subset that actually collides.
What the user never has to do
The design goal is that you never arbitrate a merge you did not ask for. Two agents do not edit one file at the same moment, so the conflicts that appear are the ordinary kind that come from your branch diverging from main, not the exotic kind that come from your own tooling racing itself.
Turned off, every group runs sequentially. That is the right default for a board whose cards all sit in the same area of the codebase, and it costs you nothing but wall-clock time.
Prepared context is what makes a lane worth running
Parallelism is only useful if each lane produces something worth keeping. On this board a card does not start from a sentence; it starts with the context its run needs already assembled, and with a plan if auto plan is on.
There is no prepare context button and no run anyway. Preparation is claimed atomically, so two runs cannot prepare the same card twice, and what it produces is a receipt you read afterwards rather than a dialog you had to dismiss beforehand.
The [board settings documentation](/docs/studio/board-settings) covers parallel runs alongside the other three decisions that govern how much a board full of agents does without you.