A coding agent is usually treated like a very fast pair programmer: give it a task, wait, inspect the diff. That works until a job has four independent pieces and the slowest possible approach is asking one agent to finish them in sequence.
The obvious answer is parallelism. The dangerous answer is letting several agents write into the same checkout.
I built ia-team around a stricter model: the lead agent breaks up the job, every teammate works in a throwaway Git worktree, and the only thing that comes back is a patch. Nothing lands on the real branch until the lead has read it and applies it on purpose.
The boundary is more important than the model
Each run starts from the same repository state. The assigned agent gets a brief, its own directory and a timeout. It can edit, run tests and even make commits inside that worktree. The result is still captured as a patch against the starting point.
team sprint \
"codex: implement the text summarizer and tests" \
"claude: implement the async queue and tests" \
"groq: write the README with usage examples"This produces three isolated changes in roughly the time of the slowest task. The lead can inspect every report and diff before applying anything. A failed run keeps its logs; a good run still has to earn its way into the branch.
Parallelism is useful only when review remains serial and deliberate.
I measured it instead of assuming
I ran the same two medium-sized tasks in two clean arenas. The first task was a text truncation module with sentence-aware behaviour and edge cases. The second was an asynchronous queue with concurrency limits, retry backoff and AbortSignal cancellation. Both needed tests and documentation.
In the team run, Codex handled the first module, Claude handled the second and Groq wrote the README. In the solo run, Claude did the entire job.
The team was 2.9× faster in wall-clock time. Anthropic spend fell from $1.22 to $0.47, with 22,842 Codex plan tokens and a free Groq task absorbing the rest. Its own suites reported 17 passing tests against 14 in the solo run.
Those numbers are not a universal benchmark. They describe two tasks, one machine and the specific plans I already had. But they were enough to answer the practical question: for independent work, the coordination overhead did not erase the parallelism.
The cross-test failure taught the real lesson
Then I ran each implementation against the other side's tests. Most of them failed.
The code was not obviously worse. The specification said to “handle a limit below 10,” and two defensible interpretations appeared. One implementation threw a RangeError; the other accepted the value and truncated anyway. One exported a function directly; the other exported an object containing the function.
Two correct solutions were incompatible because the interface had not been fixed. A solo agent can hide that ambiguity because there is nobody to collide with. Parallel agents reveal it immediately.
The fix is not a smarter routing algorithm. It is a small contract written before the sprint:
- which agent owns which files;
- the exact function signatures and exports;
- shared error behaviour and data shapes;
- the command that proves a patch is done.
Split by files, not by vague themes. If two agents need the same central file, the work probably is not independent yet.
When I do — and do not — reach for a team
I use parallel agents when the work has visible seams: a route, a UI component, a test suite and a document; several independent modules; a wide migration where each directory can be owned separately.
I stay with one agent when the change is conceptually indivisible, when every part shares mutable state, or when writing the contract would take longer than doing the work. Parallelism is not free. Its price is the specification and the final review.
That trade is worth making more often than I expected. The lead remains responsible, the repository stays clean, and the cheap or free model can take the mechanical work without being trusted with the merge button.
Try the project or inspect the experiment.