The Mythical Man-Month in the AI Era: Does Brooks' Law Still Hold?

When AI Becomes a New Teammate, Are Software Engineering's Old Laws Obsolete?

"Adding manpower to a late software project makes it later." Frederick Brooks wrote this line in The Mythical Man-Month more than forty years ago, and it has remained an iron law of software engineering management ever since. But as AI coding assistants take on more and more development work, does this law still hold? A discussion on Hacker News has brought this question back into the spotlight.

Although modest in scale (41 points, 28 comments), this discussion touches on a core contradiction that is widely avoided: AI boosts the output efficiency of individual developers, but that doesn't mean a project can be accelerated indefinitely. The underlying logic of Brooks' Law—that communication costs grow nonlinearly with team size—doesn't automatically disappear just because you've added an AI assistant.

What Brooks' Law Is Really Saying

The Man-Month Trap

The core insight of The Mythical Man-Month is that the man-month as a unit for measuring workload is itself dangerous. When a task cannot be decomposed, adding manpower doesn't shorten the schedule. More critically, new members need time to understand the system, get familiar with the context, and mesh with the team—during which they not only fail to produce output but also consume the time of existing members.

The "man-month" is a unit of measurement obtained by multiplying workload by time, with the implicit assumption that people and time are interchangeable—two people for one month equals one person for two months. Brooks pointed out that this assumption does not hold in software engineering, because tasks have indivisible dependencies and some work cannot be parallelized simply by adding more hands. This concept matters because it exposes a common fallacy in software project estimation: treating a schedule slip as a shortage of manpower and then trying to "recover" the time by adding people, which often backfires.

The Nonlinear Growth of Communication Costs

Brooks offered a frequently cited estimate: when team size is n, the number of communication paths is n(n-1)/2. This means that doubling the team roughly quadruples the communication cost. This mathematical relationship doesn't change just because AI tools are introduced. On the contrary, when AI-generated code requires human review, new communication links are actually introduced.

The number of communication paths n(n-1)/2 comes from pairwise counting in combinatorics: among n people, every pair needs a communication channel, so the total is the number of combinations of 2 from n. This formula shows that communication overhead grows quadratically—not linearly—with the number of people. In AI-assisted development scenarios, communication doesn't only happen between people but also between people and AI output—every piece of AI-generated code must be understood, verified, and integrated, which effectively adds new "communication nodes" and makes the calculation of coordination costs even more complex.

What AI Has Changed and What It Hasn't

What Has Changed: Improved Individual Output

AI coding assistants have indeed brought efficiency gains in scenarios such as code completion, boilerplate generation, and unit test writing. Developers can focus more energy on architecture design and business logic rather than spending time on repetitive labor. At the individual level, the amount of work one person can complete is increasing.

What Hasn't Changed: Coordination and Decision-Making

But software development has never been just about writing code. Requirements alignment, architecture decisions, code review, cross-module integration—the cost of these activities depends on team size and system complexity, not on coding speed. Some comments in the Hacker News discussion pointed out that AI makes writing code faster, but it doesn't make "ensuring the code written is correct" much faster.

Reviewing AI-generated code can sometimes be more laborious than reviewing a human colleague's code, because you need to judge whether the AI has missed edge cases or introduced implicit dependencies.

Implicit dependencies refer to coupling relationships between code modules that are not explicitly declared in interfaces or documentation but actually exist—for example, shared global state, implied call order, or undocumented data format conventions. Because AI-generated code lacks a complete understanding of the project's overall context, it is more prone to introducing such implicit dependencies, which often only surface during integration or at runtime. Reviewers therefore need to additionally infer the AI's "assumptions," which is precisely the technical reason why reviewing AI code can sometimes be more laborious than reviewing human code.

The Emergence of New Problems

AI also brings coordination challenges that Brooks did not foresee. When multiple developers each use AI to generate code, consistency of output style, identification of duplicate code, and the speed at which technical debt accumulates can all become new sources of problems.

Technical debt refers to the long-term maintenance costs accumulated from suboptimal technical decisions made for short-term delivery, including duplicate code, lack of test coverage, architectural inconsistency, and so on. AI coding assistants may accelerate the accumulation of technical debt: first, generation speed is fast, allowing problematic code to enter the codebase more quickly; second, different developers each generate similar but duplicate implementations, increasing redundancy; third, AI tends to generate code that "runs" rather than code that "conforms to project standards." Identifying and controlling the growth rate of technical debt has therefore become a quality assurance step that AI-assisted teams need to design specifically.

Consensus and Divergence Across Multiple Perspectives

Although the original Hacker News discussion thread offers limited information, some cross-verifiable judgments have already formed in the community around the topic of "AI and software engineering efficiency." According to the Hacker News thread and similar analyses in multiple technical communities, the following points enjoy relatively broad agreement:

• AI significantly reduces the burden of repetitive work for individual developers
• Team-level productivity gains are far smaller than individual-level gains
• Code review and integration are becoming new bottlenecks

Divergence centers on whether AI has fundamentally changed the optimal team size. Some discussants believe that AI allows small teams to take on larger project scopes, thereby bypassing Brooks' Law; others point out that the growth in project complexity offsets this advantage—when a small team uses AI to rapidly stack features, the system's cognitive burden also expands rapidly.

Practical Implications for Development Teams

If Brooks' Law still holds in the AI era, then the focus of team management should not be "using AI to make everyone write more code" but "using AI to reduce coordination friction." Specifically:

• Use AI to generate documentation and comments, lowering the cost for team members to acquire context
• Use AI-assisted code review for a first round of screening, focusing human attention on architecture and logic
• Control the size of individual AI-generated code changes to avoid introducing too many changes that need review at once

What these practices have in common is this: use AI to lower communication and coordination costs, rather than simply increasing the speed of code output.

An Old Law in a New Guise

Brooks' Law has not been overturned by AI; it has simply taken on a new face. What constrained project schedules in the past was the cost of human coordination, and that cost still exists today—only the battlefield has partly shifted from "human communication" to "human review and trust of AI output."

Understanding this is more practically valuable than arguing about "whether AI will make programmers unemployed." For technical teams, what really needs to be designed is not only the workflow for using AI tools but also the collaboration methods and quality assurance mechanisms that match them. The core warning of The Mythical Man-Month—do not reduce software engineering to manual labor—is, in fact, even more worth revisiting in the AI era.