Rereading The Mythical Man-Month in the AI Era: Can the Strongest Copper Bullet Break Brooks's Law?

Adding People Makes Things Worse: A 50-Year-Old Curse of Software Engineering

Have you ever lived through this workplace nightmare: a core project is seriously behind schedule, and you're grinding away frantically every day. Then your boss waves a hand and assigns you a few new colleagues. On the surface, reinforcements have arrived from heaven—but the result is that the project falls even further behind, and a team that was barely holding together descends into endless chaos.

This is a curse almost no professional can escape, and it's by no means limited to programmers. On the surface, one more person means one more unit of strength—an intuitive, even comforting logic of addition. The boss thinks progress is slow, so he adds people; it sounds airtight. But reality always slaps you hard in the face.

To understand this deeply counterintuitive phenomenon, we've dug up a 50-year-old book revered as the bible of software engineering—The Mythical Man-Month. But today isn't about reviewing history. It's about asking a sharp question: in an era when AI coding tools like Cloud Code and Cursor can spit out thousands of lines of code in seconds, has this book been utterly shredded by AI, or did it long ago predict the even greater disaster we're now facing?

The Tar Pit and Brooks's Law

In the original text, author Fred Brooks used a vivid metaphor: he compared the development of large software systems to a prehistoric tar pit. A few huge, powerful beasts—dinosaurs, mammoths—accidentally fall into the sticky tar pit. To survive they struggle violently, but the stronger they are and the harder they thrash, the deeper they sink, until they all settle to the bottom. This is a true portrait of many large project teams: the harder everyone works overtime, the more the system collapses.

Brooks was no armchair theorist. Back then he led the development of the OS/360 operating system at IBM, with over a thousand people involved at the peak, ultimately consuming an astonishing five thousand man-years. OS/360 was an extraordinarily ambitious undertaking IBM launched in the 1960s, aiming to provide a unified operating system for IBM's entire line of mainframes—before this, each machine had its own dedicated system with virtually zero compatibility. It's worth noting that the first edition of The Mythical Man-Month was published in 1975, after Brooks left IBM and headed the computer science department at the University of North Carolina, systematizing this painful experience into theory. The book was later listed by both the Association for Computing Machinery (ACM) and the Institute of Electrical and Electronics Engineers (IEEE) as one of the most influential works in software engineering, and it remains required reading in top engineering management courses to this day—testament to insights that transcend their era.

The reason this project became a perfect specimen of the tar pit is that it tried to simultaneously solve two entirely different kinds of challenges: upward compatibility (supporting IBM's full range from low-end to high-end machines) and backward compatibility (ensuring old programs still ran). This bidirectional compatibility goal planted the seeds of a complexity explosion at the architectural level. Brooks later concluded that what truly dragged down the project wasn't the technical difficulties themselves, but "accidental complexity"—the extra trouble that was avoidable but arose from organizational scale and tool limitations.

What does five thousand man-years mean? If one person completed it alone, it would take 5,000 consecutive years of work. Collaboration on this scale inevitably makes communication and coordination themselves the primary work, rather than writing code. It was after being ground into the dirt by this behemoth that Brooks summarized the famous Brooks's Law:

Adding manpower to a late software project makes it later.

Man-Months Cannot Be Freely Interchanged

This statement is counterintuitive, because we always feel that "more hands make lighter work." But there's a huge mental trap hidden here—which is also the origin of the book's title, "the mythical man-month": people treat "people" and "time" as units that can be freely split and interchanged.

The book has a precise and cutting analogy: gestating a new life takes ten months, and you can't get nine women to produce a baby in one month. Much work simply cannot be divided and parallelized. In economics, this type of work is called "strongly sequential tasks"—each step must wait for the output of the previous step before it can begin, and no matter how many parallel resources you invest, the time on the critical path cannot be compressed. The core architectural design, interface protocol formulation, and security model reviews in software development all have this characteristic. This is also why you can have ten people finish building a brick wall, but you can't have ten people "simultaneously plant the seeds of the same tree and harvest it a month later"—growth itself is sequential.

Behind this lie two costly expenses:

• Training cost: New people arrive and someone has to teach them, and the one training the newcomers is often the team's most core, already busiest key player.
• Communication cost: This is the most fatal. Communication complexity doesn't grow linearly—it explodes. By the formula N×(N-1)/2, the communication paths among 3 people are only 3, but adding up to 10 people instantly balloons to 45. You think you've added fresh troops, but you've actually added a geometrically exploding communication burden.

This formula comes from calculating the number of edges in a complete graph in graph theory. In a complete graph, every node connects to every other node—precisely the mathematical abstraction of the "everyone communicates with everyone" scenario. But real teams' communication isn't truly a complete graph—hierarchical structures and sub-team divisions cut some of the links. The problem is that software development involves a lot of "hidden dependencies": two people may not appear to need to communicate, but the modules they each modify are coupled at a low level, and these hidden links create just as much chaos, while being harder for managers to detect and intervene in. This is also why Amazon promotes the "two-pizza rule" (team size capped at 6–8 people)—essentially using organizational design to fight this mathematical law: a 50-person team has 1,225 communication links, but compressed to 8 people, only 28 remain, resulting in completely different manageability. Interestingly, Google's "Project Aristotle," launched in 2012, found through long-term tracking research of 180 internal teams that the primary factor affecting team effectiveness wasn't members' individual ability, but "psychological safety"—further demonstrating that overly large teams not only increase communication links but also fundamentally undermine members' willingness to communicate candidly, doubly destroying collaborative efficiency.

Has AI Broken Brooks's Law?

Hearing this, as a modern developer you might think: what I'm introducing isn't a real new employee, but an AI Agent. If I pull in a few Cloud Code workflows, the AI doesn't need onboarding, doesn't slack off, doesn't listen to the boss's grand promises, and doesn't need alignment meetings. If AI doesn't add those 45 communication paths, hasn't it fundamentally broken Brooks's Law?

This inference is tempting, but if you zoom out and examine the entire workflow loop, you'll find a spine-chilling fact: the bottleneck hasn't disappeared—it has simply shifted position like a ghost.

The Bottleneck Moved from "Writing" to "Reviewing"

The AI Agent indeed doesn't attend lengthy architecture meetings, nor does it throw tantrums. But the project's entire bottleneck has moved from "writing" in the early stage and gotten firmly stuck at "reviewing" in the later stage—code review has become the new tar pit.

Imagine you have five AI Agents start work simultaneously, each writing its own code, generating at lightning speed. But when you try to merge these five chunks of tens of thousands of lines into the same core system, conflicts are inevitable. These five Agents never had an in-depth discussion about the system's overall context; each has its own seemingly reasonable but actually conflicting logic. Ultimately, the person sitting there frazzled, reviewing logical conflicts line by line, trying to make them mesh seamlessly, is still you. This phenomenon has a specialized term in software engineering called "technical debt"—a metaphor proposed by Ward Cunningham in 1992, referring to compromise design decisions made for short-term speed, which accumulate interest over time like financial debt: the thinking time saved today must be repaid in the future at several times the refactoring cost. The explosive growth of AI-generated code is helping teams accumulate this debt at an unprecedented rate, while debt-repayment capacity hasn't improved in sync.

AI has merely changed the "coefficient" in the equation, making each person produce code faster, but it hasn't erased the equation of "system collaboration" at all. In fact, because the code base has grown larger, the consequences are even more severe.

The Second-System Effect: A Curse Detonated Early by AI

Brooks had another extremely biting observation, called the second-system effect. When a designer builds their first system in their career, they tend to be restrained—inexperienced and afraid of messing up, they jot down flashy, immature ideas in a little notebook: "This idea is cool; save it for the next system."

As a result, when they build the second system, disaster strikes—it becomes a dumping ground for all the bloated ideas. OS/360 had a classic case: an engineer, to handle February 29 (well, December 31 of a leap year, appearing once every four years), wrote a 26-byte resident program that permanently hung in the precious memory. It's like building an expensive constant-temperature safe in a crowded kitchen for the crab pliers you use once a year.

AI Makes Physical Limits Disappear—and Kills the Space for Thinking

In the AI era, this effect has undergone a terrifying mutation. A real "aha moment": using Cursor to add a simple login button to a page, the AI generated over 500 lines of complex OAuth authentication code in two seconds, including third-party key library calls, and the app crashed immediately after merging.

Here it's worth pausing to explain why OAuth showed up. OAuth 2.0 (RFC 6749) is an open authorization framework standardized by the IETF in 2012, designed to let third-party applications access protected resources without obtaining the user's password. It involves over a dozen sub-mechanisms like the authorization code flow, token refresh, and scope management, and a complete implementation must handle many edge cases: token expiration, CSRF protection, PKCE extension, and so on. In production environments, OAuth is the industry standard for handling third-party login—well-designed and rigorously security-reviewed. The AI didn't "make a mistake" by generating it; it copied the high-frequency pattern "login = OAuth" from its training data, completely ignoring the actual needs of the current prototype stage. This exposes a structural weakness of large language models: they optimize for "code that looks correct" rather than "code that fits the current stage's needs." Technically, this stems from the language model's training objective—predicting the next most likely token—making it essentially a "probability statistics machine," good at reproducing high-frequency patterns in training corpora rather than reasoning about "what is the minimum viable solution in this specific scenario." This tendency toward "over-engineering" is extremely common in AI-assisted development: developers raise a simple requirement, and the AI returns an industrial-grade solution—there's a huge contextual gap between them, and this gap can only be filled by humans relying on business understanding. The root of the problem is: AI has removed the natural barrier of "the cost of hand-writing," allowing developers to complete a destructive decision before they've had time to think.

The key insight is: hand-writing code being laborious and typing being slow is actually a natural protection for humans. When you get stuck at the keyboard and can't type, you naturally realize "I haven't figured out the business logic yet"—the physical limitation forces you to think.

But now, AI reduces the cost of writing to zero, filling the screen at extremely high speed and directly killing the survival space for thinking. In the past, the second-system effect took several years to destroy a project; now AI has moved this curse up to every single Prompt of the developer. We're always in "the fervent state of the second system," blindly piling things up and silently destroying software engineering's most precious soul—conceptual integrity.

The Tower of Babel and Reims Cathedral: The Battle for Conceptual Integrity

The book contrasts two buildings. The negative example is the Tower of Babel: the builders had abundant clay, high-quality tar, no deadline, and the technology was feasible—they had everything they wanted, yet it ultimately fell into disarray. The reason was the loss of a unified communication mechanism, culture, and goal—no matter how good the resources, if collaboration collapses, it can only fall apart.

The positive example is France's Reims Cathedral (Cathédrale Notre-Dame de Reims), begun in 1211, a pinnacle of French Gothic architecture and historically the coronation site of French kings. It was built through the relay effort of eight generations of architects, without even a single unified, complete blueprint passed down, yet the entire building's style is completely unified, as if from a single hand. The core mechanism behind this lies in the knowledge inheritance system of the Masonic Guild—successors deeply internalized their predecessors' design language through apprenticeship, rather than merely receiving a blueprint instruction manual. Each generation of successors displayed extreme self-restraint: willingly sacrificing their own wild personal creativity to continue the original architect's design philosophy. Brooks believed this restraint revealed the essence of conceptual integrity—it doesn't depend on "one person doing all the work," but on every participant's profound understanding of and active deference to the original design spirit. They traded their personal desire for expression for the entire system's highly consistent conceptual integrity. This insight maps directly onto software engineering: the reason the Linux kernel maintains architectural consistency despite collaboration among thousands of contributors is precisely because Linus Torvalds long played the role of that "final arbiter"—every line of code entering the mainline must pass his gatekeeping of the overall design philosophy—which is, in essence, the same thing as the Masonic Guild's inheritance mechanism at Reims Cathedral eight hundred years ago. The implications for the AI era are equally profound: you cannot make AI truly "understand" your architectural intent through Prompt documentation. AI can reproduce syntactic patterns, but it cannot internalize a design philosophy.

The Surgical Team and the Micro-Teams of the AI Era

To replicate this "cathedral" in a software team, the book mentions Harlan Mills's concept of the surgical team: retaining a single chief surgeon as the core architect to make all key decisions, while everyone else (documentation, testing, tools) plays the auxiliary role of "handing over the scalpel." This somewhat autocratic-sounding model is precisely what ensures the system is driven by unified logic, avoiding the stylistic fragmentation of everyone acting on their own. Harlan Mills himself was a renowned scientist at IBM Research who practiced this model in the "New York Times Information Bank" (NYT Information Bank) project he led in the 1970s, reorganizing an originally chaotic large team into several surgical-team structures and ultimately delivering on time—a rare success story in the software engineering world at the time. This further corroborates Brooks's view: conceptual integrity is not an idealized philosophy but an engineering practice that can be implemented.

In the AI era, an ordinary developer paired with Cursor has, in an instant, actually formed a micro surgical team—AI takes over all the auxiliary roles' work, fast and well. But the trap is: you no longer personally type code line by line, so you stop reading and scrutinizing line by line, and your brain is no longer that strict filter. To please you, AI introduces all sorts of logical compromises you can't detect—the program appears to run, but its internal concepts have already begun to rot. AI has enormously amplified your execution power, which demands that you possess ten times, a hundred times the conceptual control.

No Silver Bullet: AI Is the Strongest "Copper Bullet"

Finally, we must confront the ultimate question that has hung unresolved for 50 years. In "No Silver Bullet," Brooks asserted: no single technology or management breakthrough in software engineering can, like a silver bullet, bring a tenfold or greater productivity improvement within a decade.

He sharply split the difficulties in two:

• Accidental difficulties: troubles like syntactic expression, typing code, and insufficient memory.
• Essential difficulties: inherent complexity, conformity with the real world, endless changeability, and intangible invisibility.

Behind this distinction lies a rigorous philosophical basis. Brooks drew on Aristotle's framework distinguishing "essential properties" from "accidental properties": essential properties are the fundamental determinations that make a thing itself and cannot be stripped away; accidental properties are additional features that can change without affecting the thing's essence. Software's essential difficulties—complexity, conformity, changeability, invisibility—are the inevitable cost of software's essence as "a logical mapping of reality," and no matter how tools evolve, they cannot be eliminated. All major technological breakthroughs in history (high-level languages, object-orientation, structured programming) have essentially only reduced accidental difficulties—which is the confidence behind Brooks's assertion that there is "no silver bullet": he saw the root of the difficulty, not its surface appearance.

What "Speed" Are We Actually Measuring?

When we exclaim that AI increases speed a hundredfold, we must ask ourselves: what speed are we measuring? We're measuring only the typing speed of "translating an idea into code." But what Brooks measured is the entire product lifecycle—including figuring out what the customer actually wants, designing a reasonable architecture, handling countless edge cases, and long-term maintenance.

A copper bullet can't kill a werewolf because it can only hit accidental difficulties; a true silver bullet must pierce through essential difficulties. In reality, customer requirements are often self-contradictory and chaotic, and combing these chaotic human requirements into a logically self-consistent computational model is where the true difficulty lies. AI cannot make the painful business trade-offs for you.

So AI has not overturned The Mythical Man-Month; it is merely the strongest copper bullet humans have forged. It mercilessly blasts away the tedious coding shell, laying bare the truly expensive parts of software development—it turns out the expensive part was never the lines of code, but the judgments humans make in the face of uncertainty, the consensus they reach, the painful trade-offs, and the responsibility you ultimately bear for the system.

Conclusion: Keep Your Brainpower on the Cutting Edge

What's most moving about this book is Brooks's honesty in the face of truth. In the retrospective chapter of the 1995 edition, 20 years after publication, this recipient of the U.S. National Medal of Technology publicly admitted that the waterfall model he once championed was wrong, and instead advocated small, fast steps and continuous iteration.

The waterfall model was the most mainstream software development methodology in the 1970s, strictly dividing a project into five linear phases: requirements analysis, system design, coding, testing and verification, and maintenance—this logic was borrowed from manufacturing, drawing blueprints first and then laying the foundation, seemingly airtight. But software's essential complexity lies in the fact that requirements themselves are ambiguous and continuously changing—you can't nail down all specifications before starting work the way you would with manufacturing car parts. The waterfall model carries a little-known historical irony: it was first described by Winston Royce in his 1970 paper "Managing the Development of Large Software Systems," but Royce himself explicitly pointed out in the paper that this model "is almost certain to fail"—what he actually advocated was multiple rounds of iteration. Yet later generations only looked at his diagram, ignored his warning, and enshrined this "negative example" as gospel, promoting it for decades—which was itself a massive "conceptual integrity" disaster. Brooks's public admission of error is an extremely rare moment in the history of software engineering. In February 2001, seventeen thinkers in software development gathered at the Snowbird ski resort in Utah and signed the "Manifesto for Agile Software Development," launching a paradigm revolution in software engineering methodology with 68 English words: valuing individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Brooks's endorsement of iterative development in the 1995 edition is seen as an important historical cornerstone of this revolution—an eyewitness who lived through the heyday of the waterfall model, testifying for the new paradigm with his own experience of failure. He self-deprecatingly said: "The code written often outlives the person who wrote it."

In an era swept up by AI's frenzied generation speed, the most important advice is: Never abandon thinking lightly just because you can write fast. Recognize the essential and accidental difficulties in your work, let AI handle the tedious tasks with a clear conscience, and then reserve your most precious brainpower—that uniquely human judgment—for true conceptual integrity.

Perhaps in the not-too-distant future, programmers will no longer need to understand specific syntax, but will be more like pure architects—relying only on rigorous logic, clear concepts, and the art of knowing how to compromise, to build, atop a chaotic tar pit, the Reims Cathedral that belongs to you.

Key Takeaways

Key Takeaways

Key Takeaways