The Mythical Man-Month in the Age of AI Agents

I re-read Frederick Brooks’ The Mythical Man-Month while running a six-agent AI team for a production project. The experience was disorienting in the best way. A book written in 1975 about software projects at IBM turned out to be more relevant to what I was doing than most of the recent writing about AI collaboration. Brooks was right about almost everything, and the parts where he was wrong are wrong in instructive ways.

What Brooks Got Right

The core argument of The Mythical Man-Month is that adding people to a late software project makes it later. The reason is communication overhead. If you have n workers, the number of communication channels between them grows as n(n−1)/2. Double the team, and you more than double the coordination cost. At some point the project spends more time on coordination than on actual work.

I observed this directly. With two agents working on a task — one designing, one implementing — the communication overhead was minimal. One message with the spec, one message with the implementation, one message with the review. Three exchanges per task.

Adding a third agent (a dedicated reviewer) did not increase that linearly. The reviewer needed context that the first two agents had built up implicitly. That context had to be serialized, transmitted, and parsed. The reviewer’s questions required answers from the designer that the designer had assumed were obvious. Tasks that took three exchanges with two agents took seven or eight exchanges with three.

Brooks called this the surgical team problem: a skilled individual surgeon operating with support staff is more efficient than a committee of surgeons because the committee cannot share a single coherent mental model of the patient. The support staff amplifies the surgeon; a second surgeon competes for control and requires constant synchronization.

My six-agent team is not a surgical team. It is closer to Brooks’ surgical team gone wrong — six actors who each hold partial models of the system, and whose coordination cost is not eliminated by their being AI rather than human.

Where Brooks Is Wrong About AI Agents

Brooks’ argument assumes that adding workers adds proportional capability alongside proportional communication cost. The arithmetic is n new brains at the cost of n(n−1)/2 new channels. At some n, the channels eat the brains.

AI agents break one half of that equation. An agent does not come with a fixed capability ceiling. You can run the same agent on a harder problem than a human worker can handle, at roughly the same communication cost. The marginal capability per agent does not flatten as quickly as it does for humans, because the agent’s bottleneck is not attention or energy — it is context and task framing.

This means the cross-over point — where adding another agent starts hurting more than it helps — is higher for AI teams than for human teams. But it still exists. In my six-agent setup I found that tasks requiring more than three handoffs consistently arrived at the final agent in a degraded state. Not because any individual agent made an error, but because each handoff truncated context. Each agent summarized what it received and passed along a smaller version. By the third handoff, the original nuance was gone.

Brooks describes the same phenomenon in human teams — he calls it conceptual integrity eroding across team boundaries — but his solution (a single architect with final authority over all decisions) maps well to AI teams. The equivalent is a lead agent that holds the full spec and never delegates the spec itself, only specific execution tasks with tightly constrained scope.

The Second-System Effect

One of Brooks’ subtler observations is the second-system effect: the system a designer builds after their first successful system is almost always over-engineered. The first system was constrained by inexperience and caution. The second is built with the confidence from the first, minus the caution, and it accumulates all the features and abstractions the designer wanted to add to the first but held back.

I watched an AI agent exhibit this exact pattern. After successfully building a simple queue routing system, it was given a similar task — routing file processing jobs. Without prompting, it introduced priority queues, a retry mechanism with exponential backoff, a dead-letter queue, and a monitoring hook. None of these were in the spec. The agent had learned from the first system what could go wrong and added defenses against all of it.

The system worked correctly. It was also approximately four times more complex than the task required. When requirements changed two weeks later, the complexity that was never needed became active cost.

The mitigation in AI agent workflows is the same as Brooks prescribes for human teams: an explicit minimal spec that the agent is instructed to satisfy exactly, with extensions requiring separate approval. An agent given latitude will use it, and not always usefully.

Communication Cost in Practice

Brooks’ formula for communication channels assumes bidirectional, full-mesh communication — everyone talks to everyone. Real software teams do not work that way, and neither do well-structured AI agent teams. The actual communication graph matters as much as the agent count.

In my setup, communication is strictly hierarchical: the lead agent (PM role) delegates to specialist agents and receives reports from them. Specialists do not communicate with each other directly — they hand off through the PM. This cuts the active communication channels from n(n−1)/2 to n−1: one channel per specialist to the lead.

The trade-off is that the PM agent becomes a bottleneck. Every inter-specialist dependency passes through it, and its context fills with routing and summarization work rather than substantive reasoning. This is the same bottleneck Brooks observed in organizations that centralize too much authority — the center becomes the constraint.

The practical solution I use: the PM agent batches related updates rather than forwarding each immediately, and specialists are given enough context at task start to operate independently for longer before needing to check back. Reducing check-in frequency matters more than reducing the number of agents.

What Brooks Would Say About Context Windows

The Mythical Man-Month does not discuss context windows because the concept did not exist in 1975. But Brooks understood something equivalent: the finite working memory of a project team is the binding constraint on conceptual integrity.

His argument is that large systems fail to be conceptually coherent not because engineers are bad at coherence, but because coherence requires holding the entire system in mind simultaneously, and that capacity is finite. The larger the system grows past that capacity, the more it fractures into independently-maintained subsystems that drift apart.

Context windows are that capacity limit made explicit and measured. An agent with a 200,000-token context window can hold more of a system in mind than a human engineer — but it is still finite, and systems larger than the window will fracture at the boundaries of what the agent can simultaneously see.

Brooks’ solution — modular architecture with clean, narrow interfaces between modules — is the same solution for AI agent workflows. The agent does not need to hold the entire system in context if each module has a clean interface that makes cross-module reasoning unnecessary. The discipline of interface design is not a concession to human cognitive limits; it is a response to the fundamental constraint that no reasoner, human or artificial, can hold an unbounded system in mind at once.

The One Thing Brooks Got Completely Wrong

Brooks argued that there is no “silver bullet” — no single development that would yield an order-of-magnitude improvement in software productivity. His argument was that the hard part of software development is the essential complexity of the problem — understanding what to build — and no tool can eliminate that.

He was right that no tool eliminates essential complexity. He was wrong that no tool produces order-of-magnitude productivity gains.

AI coding tools, in my experience, produce roughly a 3–5× productivity gain on implementation tasks — not by eliminating the complexity of deciding what to build, but by dramatically compressing the time from decision to working implementation. The essential complexity remains; the accidental complexity (syntax, boilerplate, lookup costs) largely disappears.

Brooks would probably argue this is exactly what he predicted: the gain is real but not the order-of-magnitude improvement he defined as a silver bullet. I think he would be technically right and practically wrong. A 5× gain on implementation, compounded with better tooling for specification and review, produces systems that would have been impractical to build previously — not because any single step is qualitatively different, but because the cumulative acceleration changes what is feasible to attempt.

Whether to Read It

Yes, read The Mythical Man-Month. Not for the implementation advice — specific practices around documentation, scheduling, and team structure are dated. Read it for the structural arguments about why complex systems are hard to build and why adding resources often makes the problem worse.

The arguments have not dated because they are about coordination overhead and cognitive limits, not about specific technologies. Those constraints have not changed. The tools change; the humans (and now agents) operating those tools still pay the coordination tax Brooks measured in 1975.

---

Running a six-agent AI team raised every problem Brooks describes. The team setup is covered in the Build & Projects section; the communication and routing architecture is detailed in the Problem Solving section.