人月神话，Agent 又演了一遍（中英切换）

In 1975, Fred Brooks wrote the sentence software people have quoted for fifty years: adding manpower to a late software project makes it later. Not because the new people are dumb, but because every extra person adds splitting, handoff, alignment and merge costs that eat the extra hands.

Fifty years on, we thought we had finally found the exception. Agents need no onboarding and no meetings, and a copy costs one second. So Claude Code, Codex and Kimi Code all shipped "dynamic concurrency": halfway through a task, the main agent decides on its own to spin up a crew of sub-agents working in parallel.

Brooks won again.

This time there is a controlled experiment: Han Li, HanHaoNing Li, Ziqian Jiang and Yiling Lou, When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks (arXiv:2610.10263) ran three frontier coding agents — Codex (GPT-5.4), Claude Code (Claude Opus 5) and Kimi Code (Kimi K3) — on 354 tasks, each task twice: once with concurrency on, once with it off, with the same model, prompt, environment and time budget. That is 2,124 executions, 11.2 billion tokens, about $20,780 at standard API rates. Tasks range from fixing a single SWE-bench Verified issue to rebuilding whole repositories from scratch and sustained multi-unit development (LoopsBench, mean reference size 26.8K lines).

The extra money didn't buy time

Start with the bill. With concurrency on, token use is 1.41–3.31× sequential (Claude Code 1.41×, Codex 3.31×). Per solved task it looks worse: Codex is the only one of the three whose solved count went up slightly, yet under concurrency it spends 24.12 million tokens per solved task versus 7.69 million sequentially.

Now time — the whole reason people turn concurrency on. In 14 of 15 agent × benchmark combinations, mean runtime went up with concurrency. Claude Code on SWE-bench Verified takes 27.8 minutes per task with concurrency and 17.5 minutes without, while solving fewer tasks. Looking only at the 366 cases both modes solved, the concurrent run was faster in 102 (27.9%), and at least 20% faster in only 46 (12.6%).

You thought you were buying "eight workers at once, an hour becomes eight minutes". What you got was eight bills and a main agent waiting for everyone to hand in their homework.

On small jobs it actively hurts

On bounded tasks like SWE-bench Verified:

• Claude Code: task pass rate 83% → 59% (−24 points);
• Kimi Code: 77% → 59% (−18 points);
• Codex: 71% → 71%, unchanged.

Pooling short and long tasks in a paired test, the declines for Claude Code and Kimi Code are statistically significant; Codex's small gain is not.

Concurrency isn't useless. On the longest benchmark, LoopsBench, Claude Code goes from 7.1% to 21.4% (+14.3), Codex from 21.4% to 25.0%, Kimi Code flat. Order the four long-horizon benchmarks by implementation size, and the average test-pass difference from concurrency climbs from −8.29 points on RepoZero to −0.04 on NL2Repo, +1.24 on ProgramBench and +4.31 on LoopsBench. The bigger the job, the more concurrency pays; when the job isn't big enough, coordination eats the gain first. That is Brooks's law, agent edition.

The failure list reads like a project post-mortem

The authors hand-annotated all 1,062 concurrent trajectories; 650 showed concurrency-specific failures, 804 instances in total. Match the biggest categories against incidents you have lived through:

• Shared state and merge (33.2%): two agents edit the same file and overwrite each other's deliverables. "Concurrent writes" alone is 26.5% of all instances and 62.9% of Codex's. Two sub-agents each deleted and recreated /tmp/t1 as a fixture, and one carried on unknowingly with the other's file; another sub-agent replaced the shared system git executable.
• Execution governance (29.0%): sub-agents killed before finishing (15.9%), results arriving too late to merge, failed work nobody takes over.
• Task orchestration (28.5%): too many workers burning the budget (19.2%), or work that looks parallel while the critical path stays serial.

Three concrete stories:

• Kimi Code rebuilding the command-line tool seqtk: a 40-minute task. At minute 17.5 it hands 22 subcommands to 20 sub-agents in one batch, all started within 11 seconds. The main agent assumes a sub-agent timeout of two hours — longer than the whole task budget — then waits for the full batch and never makes another tool call. At the deadline 18 sub-agents are aborted; the one assigned to the seq command never wrote its implementation. 92 of 440 tests pass.
• Claude Code on a Rust port task: the main agent had already built the port, checked it and put it in the output directory — it passes all 39 official tests. Near the deadline it starts a ten-minute blocking wait on an unfinished sub-agent, and the run is terminated before a final response.
• Kimi Code rebuilding a log highlighter: 17 sub-agents investigate behaviors in parallel; none is assigned to implementation. The main agent waits for every report before writing code and is still planning the implementation when time runs out. 0 of 785 tests pass.

Not one of these is "the model wasn't smart enough". They are all management incidents: no owner, a wrong schedule, nobody calling time, two people editing one file, an 80K-character handoff brief nobody can absorb. Brooks counted communication paths between people. Agents swapped meetings for a shared folder, and the communication cost came back as merge conflicts.

The three cases where parallel actually pays

The paper also examined 131 pairs where concurrency did better, and they fall into three groups:

• Complementary work: cleanly separated pieces go to different sub-agents while the main agent writes the core and integrates. In one NL2Repo task both modes passed everything, but concurrency cut wall time from 734 to 468 seconds.
• Alternative attempts, then selection: the main agent and a sub-agent each build a version and combine the best of both. In one ProgramBench task the concurrent run passed 292/391 tests; the sequential run failed to build, 0/391.
• Independent validation: a sub-agent checks a key assumption and corrects the main agent in time. In a security-lab task, a sub-agent found the P-256 curve-order requirement for ECDSA, the main agent fixed its algorithm, and the sequential run failed.

All three have one thing in common: the main agent actually acts as foreman — it splits cleanly, collects the results, and checks the work.

Boundaries

Only three agent + native-model pairs (July 2026 configurations), five benchmarks, all with time budgets; long-horizon runs are too expensive to repeat many times; the failure taxonomy is hand-annotated (Cohen's κ = 0.77). A next generation with better orchestration will move the numbers. The direction is harder to move: what concurrency is worth depends on whether the main agent can manage, and right now it mostly can't.

Before you turn on multi-agent parallelism next time

First, default off, turn on per task. Bug fixes, one-function changes and single endpoints: run sequentially. Turn it on only when the task is big enough to split into pieces that don't depend on each other. In the paper the switches were Codex's multi_agent / multi_agent_v2, Claude Code's Dynamic Workflow and Kimi Code's swarm_mode; check your version's docs for exact usage.

Second, write the org chart before you turn it on. Put it in the prompt: who owns each directory or file, what the interfaces between modules look like, who does the final integration and full test run, and that sub-agent timeouts must be shorter than the total budget. Isolate where you can — give each sub-agent its own git worktree:

git worktree add ../wt-parser -b agent/parser
git worktree add ../wt-cli -b agent/cli

Each writes its own branch and the main agent (or you) merges, instead of everyone writing into one directory.

Third, A/B it on one real task from your last week. Same task, concurrency on and off, one run each; record wall-clock time, tokens and tests passed. If parallel isn't faster on your own work, you have your answer.

The judgment is simple: sub-agents are not free hands; they are reports who need managing. Parallel agents aren't short of hands, they're short of a foreman — and until the main agent learns to be one, the foreman has to be you.