Brooks' Law in the Age of AI Agents: Why 9 Agents Won't Speed Things Up
By Arash Latifi — Founder, The DevArt
What happens to Brooks' Law (adding manpower to a late project makes it later) in 2026, when the "manpower" is AI agents? Grounded in a fresh HN discussion.
TL;DR — Brooks' Law didn't die; it mutated: instead of managing people, you now manage agents — and "adding agents to a project with unclear requirements gets you the wrong answer faster."
What Brooks' Law is, and why it still matters
In 1975, Fred Brooks wrote in The Mythical Man-Month: "Adding manpower to a late software project makes it later" — drawn from his experience managing IBM's OS/360 project. The mechanism is simple: every new person adds coordination overhead — onboarding, context transfer, and time others spend explaining.
The HN post that sparked this
Yesterday (October 27), an article titled "The Mythical Man-Month in the Age of AI" hit 234 points on Hacker News. The author describes watching four people struggle to connect a laptop to a screen and quipping that adding people won't speed it up — then asking whether Brooks' Law survives AI agents.
His answer: it mutated rather than vanished.
- Sequential tasks remain sequential: "nine agents still can't deliver a baby in one month."
- Coordination overhead didn't disappear; it shifted — from managing people to managing agents.
- Someone still has to define "done," review the code, catch hallucinations, and stitch the pieces together. That someone is you.
- Throw nine autonomous agents at one codebase without clear orchestration and they will happily rewrite each other's work in a high-speed loop.
His 2026 formulation: "Adding agents to a project with unclear requirements gets you the wrong answer faster."
What the HN comments added
The discussion under the post is genuinely useful:
- One solo developer noted the cost still sits in coordination and understanding, not typing: AI makes producing code cheaper, but reviewing it, keeping the design coherent, and remembering why things were done takes the same attention. Small, well-bounded tasks with tests work well; open-ended multi-file changes create hard reviews.
- Another commenter argued agents shine at exploring a problem space through trial and error — reverse engineering, performance work, anything grindy. That's a much smaller problem space than what's being sold.
- A contrarian take: when requirements are unclear, a fast wrong answer is now the best way to find the right requirements — you quickly learn what you don't want.
Where to add agents — and where not to
| Situation | Add agents? | Why | |---|---|---| | Independent small tasks with clear tests | Yes | Coordination cost is near zero | | Problem exploration, reverse engineering, perf work | Yes, even swarms | Errors are cheap; trial-and-error helps | | Sequential work (staged migrations, chained debugging) | No more than one | Parallelizing it slows you down | | Vague requirements, product-level design | Define it yourself first | Agents produce the wrong thing faster | | Final review and decisions | You | Accountability can't be delegated |
A checklist before you add an agent
- [ ] Can you define "done" in one sentence?
- [ ] Does each agent own a clear scope (which files/modules)?
- [ ] Are merge points and boundaries between agents explicit?
- [ ] Do you have a test or objective acceptance metric?
- [ ] Is the work actually parallelizable, or sequential?
- [ ] Who reviews the final output? (The answer shouldn't be "nobody")
Why this matters for small teams
If you're thinking "I'll add several AI assistants for sales, content, and support and everything speeds up" — remember Brooks' Law still holds: coordination and output quality are the bottleneck, not agent count. One agent with a clear brief and daily review beats five unsupervised agents. We've made a related point in AI and the software engineering middle class: human value is moving toward judgment and overall design, not raw generation.
Q: Does Brooks' Law still hold with agents?
Yes, but mutated. Coordination overhead moved from managing people to managing agents and reviewing output — and sequential work still can't be parallelized.
Q: How many parallel agents are reasonable?
As many as there are genuinely independent tasks with clear boundaries and tests. If two agents must touch the same file, you're buying coordination, not speed.
Q: How do I start without wasting budget?
Give one agent one small, testable task, review the output thoroughly, and only add parallel agents once reviewing stays lightweight.