A laptop, four helpers, and a fifty-year-old law§
The argument starts small. In a post published at j11g.com, the author describes watching four people try to get a laptop to connect to a screen. When nudged to help, he declines, offering a one-line diagnosis: "My experience is that adding more people will not solve this problem any quicker." He notes the remark was an indirect citation of Brooks's Law — "Adding manpower to a late software project makes it later" — formulated by Frederick P. Brooks Jr. in his 1975 book The Mythical Man-Month, drawing on his experience managing the IBM OS/360 project.
The anecdote is a framing device, but it sets up the real question: does a law derived from 1960s mainframe systems management still describe software work when the "manpower" being added is AI agents?
Why agents look like the exception§
The case against Brooks is intuitive, and the source states it directly. The traditional bottlenecks that make late projects slower when staffed up — onboarding time, endless stand-ups, office politics — appear to evaporate. An AI agent is up to speed in milliseconds, and it does not demand a coffee break. If coordination cost were entirely a function of human socialization, adding agents would be nearly free.
That is the strongest version of the optimistic reading, and it is worth stating plainly because it is what most agent-deployment pitches quietly assume.
The Baby Problem doesn't care how fast the workers are§
The source's answer is that the law has not vanished; it has mutated. The first mechanism is what the post calls the "Baby Problem": nine agents still cannot deliver a baby in one month. Sequential tasks remain sequential. Any work whose steps have a genuine ordering dependency — schema migration before backfill, interface definition before implementation, deploy after test — sits on a critical path that extra parallelism cannot shorten. Latency per step improves; the number of steps does not.
This is the part of Brooks that transfers cleanly. Speed of individual execution was never the binding constraint the law described.
Overhead relocates to orchestration and review§
The second mechanism is where the argument gets more interesting for practitioners. Overhead has not disappeared — it has shifted. Instead of managing people, you are managing agents. Someone still has to define what "done" means, review the code, catch hallucinations, and stitch the pieces together. Those are human-bound activities that scale with the number of parallel workstreams, not with the throughput of any single agent.
The source is explicit about the failure mode: turn nine autonomous agents loose on a single codebase without crystal-clear orchestration, and they will rewrite each other's work in a high-speed loop. Notably, that loop runs at machine speed. Humans doing the same thing generate merge conflicts slowly and visibly; agents generate them quickly and, potentially, quietly — which raises the cost of the review layer rather than eliminating it.
What this means in practice§
Several implications follow directly from the source's framing, without requiring any claim about measured productivity:
- Define "done" before spawning agents. The specification work is the orchestration. If it is missing, the agents' speed is spent on divergence.
- Partition deliberately. Parallelism pays only where the work decomposes. Sequential chains should be treated as sequential, not handed to a fleet.
- Budget the review layer as a first-class cost. Code review, hallucination detection, and integration remain on the human side of the ledger.
- Don't staff up a late project — with people or agents. The Brooks trap reopens the moment additional workers arrive without a corresponding drop in coordination load.
What remains uncertain§
The excerpt is truncated mid-sentence ("Maybe the 20..."), so the post's closing argument and any proposed remedies are not visible. More substantively, the piece offers no measurements. There are no benchmarks for agent-team throughput, no data on how review cost scales with agent count, and no empirical test of whether coordination overhead in multi-agent systems follows the same curve Brooks observed in human teams. The claim that the law "mutated" is an argument from mechanism, not from measurement.
That gap matters. A plausible reading is that agents shift the constant factor in coordination cost rather than the exponent — a large efficiency gain that leaves the structural problem intact. Whether that is true, and at what team size the curve turns upward, is an open empirical question the source does not attempt to settle.