Short answer: adding more AI coding agents does not shrink a schedule in proportion. Agents write code quickly, but deciding what to build, reviewing the output and merging many changes into one working system still consume human time. That is Brooks's law in new clothes. In The Mythical Man-Month (1975), Fred Brooks observed that "adding manpower to a late software project makes it later." As of October 2026, the available research suggests the same dynamics show up when teams scale up AI coding agents. This guide explains why, what the data says, and how to split work and design review so parallel agents help rather than hurt.

What is Brooks's law? The three reasons from The Mythical Man-Month

Brooks drew the lesson from managing IBM's OS/360 effort. As the Wikipedia summary notes, Brooks himself called the law an "outrageous oversimplification," but one that captures a real tendency. He pointed to three causes:

1. Ramp-up time. Newcomers are unproductive while they learn the codebase and past decisions, and the people teaching them slow down too. New contributors can even make negative progress by introducing bugs.
2. Communication overhead. Coordination paths grow combinatorially. If n people all coordinate with each other, there are n(n-1)/2 channels: 3 for a team of three, 10 for five people and 45 for ten.
3. Limited divisibility. Cleaning hotel rooms scales with more hands; much of software does not. In Brooks's famous line, nine women can't make a baby in one month.

The law has exceptions worth remembering. It mainly applies to projects that are already late. Adding people early, or giving them clearly defined side work such as QA or documentation, keeps ramp-up costs low. Good modularity lets small teams own sub-problems while a top-level team handles integration, though splitting tightly coupled work along the wrong lines makes things worse. Those exceptions turn out to be the design rules for running AI agents.

Do AI coding agents escape Brooks's law?

At first glance agents look immune. They need no onboarding sprint, no stand-ups and no coffee breaks. Map each of Brooks's causes onto agent workflows, though, and the costs have moved rather than vanished. Jan van den Berg's essay, which topped Hacker News on October 27, 2026, puts it plainly: the law has mutated. Someone still has to define "done," review the code, catch hallucinations and stitch the pieces together, and that someone is you.

The shape of communication cost changes too. Let agents coordinate peer to peer and channels multiply just as on a human team. Route everything through one orchestrator or one human and the channels shrink, but that hub becomes the bottleneck. In its write-up on building a multi-agent research system, Anthropic says early versions spawned 50 subagents for simple queries and, given vague instructions, had several subagents run the same searches. Duplication dropped only once each subagent got an explicit objective, output format, tool guidance and task boundary. That is a staffing problem any engineering manager would recognize.

What the data shows: more code, longer reviews

An October 9, 2026 Ars Technica report covers a study by Harvard researchers Fiona Chen and James Stratton. Using aggregated Jellyfish engineering analytics, they examined work events from more than 700,000 employees at over 700 software firms between 2021 and March 2026. After firms introduced AI coding agents, lines of code rose 30% on average, commits 20% and pull requests 23%. Yet the resolution rate for Jira-tracked issues and epics did not change in a statistically significant way.

The gap was absorbed downstream. Average time from PR submission to merge grew 49%, the share of PRs with changes requested nearly doubled, and comments per PR rose 35%. The share of workers doing code review rose 14%. Two caveats matter: this is an observational before-and-after study, not an experiment that varied the number of agents, and it does not capture tool improvements after March 2026. Still, the pattern is classic Brooks: speeding up one stage does not raise output if the next stage stays the same size.

Perceived speed and measured speed can diverge

In METR's early-2025 randomized controlled trial, 16 experienced open-source developers working on 246 real issues took 19% longer when AI was allowed. They had expected a 24% speedup and afterward still believed they were 20% faster. In a February 2026 update, METR said developers are likely faster with late-2025 tools, but its new data is a weak signal: many developers declined to work without AI, and time spent was hard to measure for those running multiple agents concurrently. If you are judging parallel agents by feel, you may be misjudging them.

Which tasks suit multi-agent software development

Anthropic reports that its multi-agent setup excels at breadth-first research with many independent directions. On an internal eval, a lead agent plus subagents beat a single agent by 90.2%, and running subagents in parallel cut research time by up to 90% on complex queries. The same post is candid about the limits: most coding tasks involve fewer truly parallelizable pieces than research, and work where agents must share the same context or have many dependencies is not a good fit today. It is also expensive. Anthropic says agents use about 4x the tokens of a chat, and multi-agent systems about 15x.

How to split work and review for parallel coding agents

1. 1

   Check divisibility first

   Break the work down and list which files and interfaces each piece touches. If two pieces change the same file or shared type, sequence them instead of running them in parallel. Work that cannot be split is usually faster with one agent and one human owning it end to end.

2. 2

   Write ownership and acceptance criteria

   Give every agent an objective, the directories it may modify, the expected output and the tests it must pass. Vague prompts like "improve this" lead to duplicated effort and agents overwriting each other.

3. 3

   Isolate the workspaces

   Run each agent on its own branch or git worktree so runs cannot clobber each other and failed attempts are cheap to discard. Check for shared resources such as databases, ports and build caches.

4. 4

   Put automated checks before human review

   Require type checks, linting, unit and integration tests to pass before a person looks. Use AI review as a first filter; keep the final judgment on intent and design with a human reviewer.

5. 5

   Size concurrency to review capacity

   Decide how many PRs, and of what size, your team can review properly each day, and do not run more agents than that. A growing review queue is the signal to cut agents and shrink PRs.

6. 6

   Measure lead time, not output volume

   Compare time from request to deploy, review wait time and revert rate before and after. As the Harvard data shows, volume metrics can climb while completion metrics stay flat.

Risks and limits: the debt fast code leaves behind

The hidden costs arrive late. Each agent writes code that is locally plausible for its own prompt, but merged together you can get duplicate implementations, inconsistent error handling and naming drift. When nobody holds the whole design in their head, incidents take longer to diagnose. Brooks's idea of conceptual integrity, a system that looks as if one mind designed it, still argues for keeping architecture decisions and final merge rights with a small number of people.

Watch the bill as well. Token spend grows with agent count, and failed attempts count too, so parallelism that does not save reviewer time mainly adds cost. The figures cited here come from specific samples and periods; your results will depend on language, codebase maturity and test coverage. Re-measure with the same metrics whenever you adopt a new model or tool.

Developer sentiment about agent workflows shifts quickly. The theddari Telegram AI trends page tracks which tools and case studies AI communities are discussing, and the blog trends page collects practitioner write-ups. When a claim goes viral, check the original study's sample and method before acting on it.

Page Reference

Trendstheddari.com›TrendsTelegram · AILive posts from AI channels

Page Reference

Trendstheddari.com›TrendsBlog PostsSummarized Naver blog posts

The bottom line: AI coding agents can fall into the same trap as adding people, but Brooks's own exceptions show the way out. Well-divided tasks, clear roles, early involvement and clean module boundaries let you capture real parallel gains. Treat the number of agents as an output of your design, not an input. Confirm you can split, verify and review the work first, then choose concurrency within those limits.