TL;DR
Running coding agents side by side overlaps their run time, not yours. Writing each prompt, answering questions, reviewing and merging still happen one task at a time, and switching between sessions slows each of them. Parallel work pays when tasks are independent and each agent runs long compared with the attention it needs from you. It costs more when tasks share files, wait on each other or need an open decision. Compare both setups on end-to-end time and rework before adding sessions.
Six tickets with the traps built in
A preprint published on 27 September 2026 studied how developers supervise parallel coding sessions, and its test projects look like an ordinary backlog (ParallelPilot, arXiv 2609.33113). Each project had six tickets. Two changed the same file, two formed a chain in which the second needed the first, and two could be built on their own. One of the six also needed a product or policy decision. Only a third of the work could simply be handed out at once.
Sixteen developers had 20 minutes per project with GitHub Copilot and as many sessions and worktrees as they liked. Without the researchers' supervision tool, they peaked at an average of 2.31 agents at once. Beforehand, 14 of them said switching between sessions felt mentally taxing, and 15 had trouble reconstructing what their agents had decided. In an earlier round of interviews, one developer found that overlapping work in the same repository took longer to reconcile than doing it in sequence would have.
Two public questions show the strain from opposite ends. In April 2026 a developer who had used Claude Code daily for a year asked on Hacker News how others keep any flow, because managing two or three agents at a time left them exhausted from context switching. In September 2025 a new Codex user asked on the OpenAI developer forum how to run local agents on separate branches at once, because some tasks took 20 to 30 minutes and they wanted more done while waiting.
Where the time actually goes
For every task you still write the prompt, answer the agent's questions, read the result, decide whether it is right, redirect it and merge it. Those steps happen in one head, one after another, however the agents were scheduled.
Parallel work saves time when each agent's run is long compared with the attention it needs from you, and when the tasks create no reconciliation work for each other. Claude Code's documentation on agent teams says the same about task size: too small, and coordination overhead exceeds the benefit (Claude Code agent teams).
Tokens cost money too. Anthropic reported that in its research system, multi-agent runs used about fifteen times as many tokens as a chat, and noted that most coding tasks involve fewer truly parallelizable tasks than research (Anthropic engineering, June 2025).
Sort the backlog before opening a second session
In the study's formative interviews, parallel work paid off when tasks were separable enough that agents would not overwrite, duplicate or contradict each other. Sort the backlog for that first:
Comparison
| Question about the task | Fine alongside other agents | Better run in sequence |
|---|---|---|
| What does it change? | Nothing: research, investigation, explanation or review | A file or module that another task also changes |
| What does it need first? | Everything it needs exists now | An interface, schema or result another task will produce |
| Is a decision open? | No | A product, policy or design choice nobody has made yet |
| How sure is the approach? | You could write its acceptance check today | Exploratory; its result will change what you ask next |
| What does it run against? | Nothing shared, or its own copy | A shared database, port, container or account |
| How hard is it to review? | Narrow, from a plan you wrote | Broad enough that you would have to study it |
Claude Code suggests starting agent teams on research and review, which avoid the coordination problems of parallel implementation, and recommends a single session or subagents for sequential tasks, same-file edits and work with many dependencies. Simon Willison named research and proofs of concept, explanations of existing code, small maintenance tasks and work he had specified himself, and said the bottleneck was how fast he could review the results (Simon Willison, October 2025).
In Google Research's controlled tests of agents coordinating with each other, multi-agent setups improved a parallelizable financial task by 80.9% and degraded a strictly sequential planning task by 39 to 70% (Google Research, January 2026). Those were not coding benchmarks, so take the direction, not the numbers. The article on running coding agents in parallel without them overwriting each other's changes covers the runtime row of the table in detail.
Count your review capacity before the results arrive
When three agents finish within ten minutes of each other, the results queue on you, and an agent waiting for an answer makes no progress. Before adding sessions, spend a week noting the minutes from "agent finished" to "accepted, redirected or discarded", and how many questions the agents bring back. That gives the results per hour you can actually close: your ceiling, whatever the tool allows.
Then shape the work to fit:
- Stagger the starts so the finishes do not land together, longest run first.
- Keep one task in the foreground. The others should be ones you can check late without harm: research, review, or a well-specified change.
- Write one line per session when you start it: the goal, the files it owns, what done looks like and what would make you stop it. Eleven of the study's sixteen participants reported trouble recalling what earlier sessions had accomplished.
- Look at each plan before it edits, and do not leave sessions alone for long; Claude Code warns that unattended teams increase the risk of wasted effort.
- Start small. Claude Code suggests three to five teammates for agent teams run by a lead session. When you are the lead yourself, start at two and add one only when your record shows spare capacity.
When the results go to other reviewers instead of to you, the same limit moves to the team's queue; the article on keeping up with code review when agents open pull requests faster than people can review them deals with that version.
Compare the two setups on your own backlog
The answer comes from your own tasks:
- Pick two comparable batches of six to ten real tasks each, with the mix of work you normally get.
- Run one batch with one agent at a time and the other with two or three in parallel. Next time, swap which goes first, so getting better at the tasks does not favour one setup.
- Record the same things for both: elapsed time from the first prompt to the last merge, your active minutes, redirections, time spent reconciling overlapping changes, tasks reopened, reverted or fixed within two weeks of merging, and tokens or cost from your tool's usage report.
- Keep the parallel setup only if end-to-end time falls and rework does not rise. If elapsed time drops while reopened tasks climb, find out why before counting the saving: rushed review is one explanation, interference between tasks or a harder task mix are others.
A sample this small gives a direction for your tasks, not a benchmark.
Paqad does not schedule parallel agents, isolate separate changes or tell you how many sessions you can supervise. Within one substantial change it takes the sequential route on purpose: on graduated and full lanes in Claude Code and Codex CLI, each mandatory stage runs in a fresh stage worker, one at a time, with the change's evidence bundle as the only memory passed between them. A decision pause returns to the main conversation, which asks you, so the decisions for that change reach you in one place and in order. On the fast lane and other tools, stages run in the main session. Paqad's documentation describes how a change passes from one stage worker to the next.
Frequently Asked Questions
When does running several coding agents at once create more work than it saves?
When your attention per task is large compared with the agent's run time, or when the tasks touch the same files, depend on each other or wait on a decision. The extra work tends to arrive late, as reconciliation, rework after merging and review you rushed, so judge the setup on finished and stable work, not on how busy the sessions looked.
Which tasks are independent enough to proceed without constant coordination?
A quick test: could you write every prompt now, without seeing any other task's result, and merge the results in any order? If either answer is no for a pair of tasks, they belong in sequence or need a shared piece landed first.
How much review and decision capacity do I have for the results arriving together?
Decisions can run out before reading time does. Count the questions agents brought back last week as well as the review minutes; an unanswered question stops a session, while an unread result only waits. If questions pile up, cut the number of sessions before making any task smaller.
Which dependencies or uncertainty should make a task sequential instead?
Run it first, on its own, when its result will change what you ask next: a spike, an investigation of unfamiliar code, or a choice between two designs. Also run it alone when a failure in it would invalidate the others, such as a shared migration or a change to a common interface.
How will I compare end-to-end completion and rework against running fewer agents?
Measure from the first prompt to the last merge, not from the first prompt to the last agent finishing, because waiting for review belongs to the cost. Count rework for a fixed period after merging, and repeat the comparison after a tool or team change, since the balance can move either way.