When does running several coding agents actually beat running one?

There is a principle and it is unglamorous: parallelism pays when the work is genuinely independent, and costs when it is not.

That sounds obvious and it is the whole thing, because most coding work is not independent. Two agents editing the same module produce a merge problem plus two partial understandings of a decision neither of them made.

Where the split reliably wins:

• Breadth over the same question. Several agents reading different parts of a codebase to answer one question, each reporting a summary. No shared writes, and the context problem is the thing being solved.
• A fan-out over a work list. Fifty files needing the same mechanical change. Independent by construction.
• Independent verification. One agent produces, another tries to falsify it. This is the highest-value pattern I use and it is not really parallelism, it is adversarial review.

Where it reliably loses: one feature, split across agents by layer. They will disagree about the interface and you will arbitrate.

Add a second principle that comes from measuring it: the reconciliation cost scales with how much they had to agree on.

If the outputs are independent artefacts — a summary each, a file each — merging is trivial. If the outputs are opinions about the same design, merging is a meeting.

So before splitting, ask what has to be true for the pieces to fit together, and how much of that is written down. If the answer is "it is in my head", the agents will each invent a different version of it and you have created work.

The practical version: make the contract explicit before the fan-out. Interfaces, file boundaries, naming, what each is responsible for. Doing that costs ten minutes and it is exactly the ten minutes that decides whether the split helps.

Worth flagging the approval-first framing in that batch of launches, because it is addressing a real problem rather than a workflow preference.

Several agents acting concurrently means several chances to do something irreversible, and it is much harder to keep track of what was done and by which one. A single agent you are watching is reviewable. Five agents working in parallel are not, in practice — people approve the fifth one the way they approve a cookie banner.

The setups I have seen work make the isolation real: each agent in its own working copy, changes surfaced as diffs, nothing touching a shared environment until a person merges. That way the concurrency is in the producing and the serialisation is in the accepting, which is the correct place for it.

One more consideration that decides it for a lot of teams: cost scales linearly and quality does not.

Five agents on a task cost roughly five times as much. The output is better when the work was genuinely parallel and roughly the same when it was not, minus your reconciliation time.

So the honest test is whether you would pay five times for that answer. For a hard question with real consequences, frequently yes. For a routine change, almost never — and routine changes are most changes.