Skip to content
Published on

Does Running Five Agents Really Make You Five Times Faster — The Bottleneck in Parallel Work Is Not Generation

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

Five diffs arrived simultaneously at two in the afternoon

Five agents were run at once against the same issue. Twenty minutes later there were five branches, each containing between 300 and 900 lines of change. Three approaches are similar and two are different. Four pass the tests and one fails.

What happens next is usually this. Reading all five takes two hours. Two hours later you choose one, and once you have chosen, the good parts in the other four feel wasted. So you start grafting bits across and end up building a sixth version by hand. The twenty minutes spent on generation was certainly saved, and the two and a half hours attached afterwards is time that did not exist before.

This post is about where that two and a half hours comes from.

What environments like this actually sell is not a model

Orca is a tool aimed squarely at this trend. The repository description introduces it as an ADE for handling a swarm of parallel agents, and states that it runs whichever CLI agent you like on your own subscription. In other words it is not a product that sells a model.

The first feature the README leads with is parallel worktrees. It says it sprays one prompt at several agents, puts each in an isolated git worktree, compares the results, and merges the winner. The rest of the features run in the same direction: comment on individual lines of a diff and send it back to the agent, open GitHub and Linear issues inside the app and create a worktree straight from them, attach worktrees on remote servers over SSH, click a UI element in the browser and put its HTML, CSS, and a cropped screenshot into the prompt.

Lay the list out and the common thread shows. What this product sells is not the ability to produce code but the surface on which a human can cope with what has been produced. Isolation, comparison, comments, merge. Precisely the tools of review and integration.

The isolation part you can try today with git alone

The first thing that hurts with parallel agents is several actors touching one directory. That is solved by a basic git feature. Below are commands I actually ran and verified.

# inside the repository, create a new branch and attach a separate directory
git worktree add -b try/a ../wt-a
git worktree add -b try/b ../wt-b

git worktree list
# /path/main-repo  2072b5c [main]
# /path/wt-a       2072b5c [try/a]
# /path/wt-b       2072b5c [try/b]

Each directory has a completely separate file tree and build outputs, while the .git object store is shared. The result is similar to cloning the repository five times, but it costs far less disk and fetch time.

There is one place that catches you when cleaning up.

git worktree remove ../wt-a
git branch --list
# * main
#   try/a      <- the worktree is gone but the branch remains
# + try/b      <- the plus sign means another worktree holds it

Removing a worktree leaves the branch behind. This is usually the reason experiment branches accumulate. And a branch marked with a plus is checked out by another worktree, so it cannot be checked out again here. It is a constraint you will certainly meet when running things in parallel, so it is better to know about it in advance.

The bottleneck does not disappear, it relocates

Once isolation is solved, the next wall appears. Even if generation is five times faster, there is one person reading.

This relationship is captured in one line of queueing theory. Call the average number of jobs sitting in the system L, the arrival rate lambda, and the average time in system W; then L is the product of lambda and W. Flip it and W is L divided by lambda.

Raising the number of agents to five means raising lambda fivefold. If review capacity is unchanged, L inside the system — the inventory of diffs waiting for review — piles up. When inventory piles up, the time in system W of each diff grows. A diff whose time in system has grown finds that the base branch moved in the meantime, producing conflicts, so it has to be fixed and queue again.

The conclusion is clear even without numbers. If you do not raise review capacity alongside, parallelization raises inventory, not completion speed. The two and a half hours at two in the afternoon comes from here.

So what to look at is not the generation features but the selection features

Seen this way, the question to ask when choosing a parallel agent tool changes. Not how many you can run at once but how cheaply you can discard four out of five.

There are three ways to lower the cost of discarding. First, let the machine drop candidates before a human reads them. Run tests and lint automatically in each worktree and take the failures out of the review set — this works with a script and no tool at all. Second, put comparisons side by side. Read five in sequence and you forget the earlier ones; look at five versions of the same file side by side and only the differences remain. Third, stop making a human graft the fixes back across. This is why you need a feature that lets you comment on a diff and send it straight back to the agent. The Orca feature list we saw above is concentrated on exactly these three.

Put another way, the value of a tool like this is not that it runs several agents. Five terminals do that. The value is in lowering the cost of discarding four.

If all five are similar, you read five times and get one

There is one more layer to go into here. For fan-out to yield information, the candidates have to differ from one another. Throw the same prompt with the same context at the same model five times and you generally get five broadly identical answers. Then the reading cost is honestly fivefold while the information you gain is worth one. This is usually why three of them were similar in the two-in-the-afternoon scene above.

There are three axes for manufacturing diversity. The first is the prompt. Instead of throwing the same requirement at each, nail down and divide the approaches. Have one reuse the existing abstraction, have one create a new module, have one make the smallest possible change. Do that and the comparison becomes a comparison of design choices rather than of implementation taste. The second is the scope of context. Give some candidates only the relevant files and others the tests and the issue too. The third is the executing agent.

That Orca explicitly states it is not tied to a specific model and will attach any CLI agent that runs in a terminal is meaningful on that third axis. Different agents have different default prompts and tool-use habits, so they produce differently shaped answers to the same requirement. That said, this is only an axis the product makes possible; actually designing the diversity remains a human job.

Writing down the current state of this project as it is

To avoid overstating, I write only what I confirmed. The repository was created on 17 March 2026, the license is MIT, and the primary language is TypeScript. The desktop app is marked as supporting macOS, Windows, and Linux, and a Homebrew cask and an AUR package are documented. The mobile companion app is distributed through the App Store and TestFlight on iOS, and as an APK posted to the repository releases on Android.

The README states that it ships every day, and therefore warns that the feature list is always behind and that the release notes are the real list. I read that sentence as both a strength and a warning. A desktop app less than six months old shipping every day also means what worked yesterday may behave differently today. At the time I checked, the number of open issues was over three thousand. In a popular repository that number does not by itself indicate defects, but neither does it stand in for maturity.

In short, this tool is not at the stage where someone else can decide for you whether it is worth using. It is an environment your team's code passes through, so if you adopt it, you have to make that judgment yourself.

An experiment to try this week before installing anything

There is a way to test just the workflow without installing anything. What actually costs money is not the tool but the review, so measure the review side.

# 1) cut three branches from the same issue (run three agents, or try three times yourself)
for n in a b c; do git worktree add -b try/$n ../wt-$n; done

# 2) let the machine drop candidates before a human reads them
for n in a b c; do
  ( cd ../wt-$n && npm test >/dev/null 2>&1 && echo "PASS $n" || echo "DROP $n" )
done

# 3) view only the survivors, side by side at the file level
git diff try/a try/b -- src/

And record two things. How many minutes it actually took to choose one of the surviving candidates, and whether there was any code you grafted by hand from another candidate afterwards. If there was, fan-out is not yet a gain for that team, because the moment you start grafting, the reason for making five in the first place is gone.

Do this measurement for a single week and you will be able to state as a number not whether to buy a tool but how many candidates it makes sense for your team to spray. That number is usually smaller than five.

Summary and sources

Parallel agent environments look like they sell generation throughput, but what they actually sell is the tooling for selection and integration. And the reason that tooling is needed is that the cheaper generation gets, the further the bottleneck moves into review. Measuring your team's review capacity before choosing a tool is the right order.

  • The stablyai/orca repository — feature list, supported agents, installation paths, license. Everything written about Orca in this post was confirmed directly from the repository README and the repository metadata.
  • The official git worktree documentation — the exact behavior of adding, listing, and removing worktrees
  • The git commands in this post were actually run on git 2.50.1 and the output was verified. The final example containing npm test varies by project, so it was not run as written.
Discuss on Twitter • View on GitHub