Report · j11g.com
The Mythical Man-Month in the Age of AI
j11g.com
Source published October 27, 2026
Summary: 1 min read
59/100
Summary
Frederick P. Brooks Jr.’s Brooks’s Law holds that adding manpower to a late software project makes it later. Brooks formulated the idea in his 1975 book, The Mythical Man-Month, drawing on his experience managing IBM’s OS/360 project. The principle reflects coordination and onboarding costs, as well as tasks that cannot be parallelized. AI agents and large language models can eliminate some traditional delays because they can begin work immediately and do not require human meetings or workplace management. However, sequential work remains sequential: multiple agents cannot compress a task with unavoidable dependencies into less time. Human oversight is still required to define completion criteria, review generated code, detect hallucinations, integrate separate outputs, and coordinate work across a shared codebase. Uncoordinated autonomous agents can overwrite or duplicate one another’s work when assigned to the same codebase. Jan van den Berg argues that a modern version of Brooks’s Law is that adding agents to a project with unclear requirements produces the wrong answer faster.
Key Takeaways
- Brooks’s Law states that adding manpower to a late software project makes it later, a principle Frederick P. Brooks Jr. presented in his 1975 book The Mythical Man-Month.
- AI agents can start work quickly, but they cannot remove dependencies in sequential tasks or eliminate the need for project coordination.
- Humans still need to specify requirements, define what counts as complete, review AI-generated work, catch hallucinations, and integrate outputs.
- Jan van den Berg argues that adding AI agents to projects with unclear requirements can accelerate incorrect results.
What the discussion said
The thread mostly treated AI coding agents as a force multiplier with a brutal caveat: they accelerate whatever judgment and coordination already exist. Several commenters see rapid, obviously flawed prototypes as valuable requirement-discovery tools. A cheap one-hour experiment can expose missing constraints more vividly than staring at a blank specification, and agents look especially useful for grind-heavy exploration, reverse engineering, and optimization where feedback arrives quickly. One experienced user even reported a personal tenfold productivity jump with recent frontier coding models. The pushback is that fast output is not the same as fast progress. Readers warned that a torrent of generated alternatives can swamp review capacity, while agents often lock themselves into overly detailed plans and optimize for the current codebase instead of asking what the system ought to become. Parallel agents still collide in shared repositories, contend for tests, and inherit the same communication and integration bottlenecks behind Brooks's Law. Some also reject the idea that developers should simply juggle many tasks: divided attention can trade apparent throughput for shallow understanding and lower-quality decisions. The emerging role is less passive delegation than active technical direction: define boundaries, challenge assumptions, inspect results, and shift effort toward architecture, product fit, usability, and QA. The debate is not whether agents can produce code quickly, but whether teams can evaluate and integrate that code quickly enough to create durable products.
Where opinion split
The sharp dispute is whether AI's speed makes wrong prototypes a productive route to clearer requirements. Supporters argue that many cheap, visibly broken implementations reveal the real problem faster than upfront planning; skeptics argue that without prior reasoning and rigorous review, the output avalanche merely hides mistakes and turns developers into managers of mediocre code.
Coverage & discussions
Hacker News · j11g.com
Community discussions
Community Sentiment
Positives
- Cheap, deliberately rough agent-built prototypes can surface missing requirements fast, making failure a practical design instrument rather than an expensive detour.
- Agents appear strongest on bounded, feedback-rich work such as reverse engineering and performance tuning, where rapid trial-and-error can beat painstaking manual exploration.
- Recent frontier coding models have delivered order-of-magnitude personal output gains for at least some experienced developers, challenging older assumptions about productivity ceilings.
- Delegating implementation can free developers to interrogate architecture, usability, product fit, and failure modes instead of treating code completion as the whole job.
Concerns
- Agent output arrives faster than humans can validate it, so dozens of plausible designs can create an evaluation bottleneck rather than genuine progress.
- LLM subagents tend to overconstrain their own plans and defend existing implementation choices, missing the higher-level question of what the software should actually do.
- Multiple agents in one repository still overwrite each other, wait on shared work, and contaminate concurrent tests; token-based coordination has not erased integration costs.
- Treating AI delegation as mental leisure risks weakening technical understanding, while frantic multitasking can substitute motion for careful engineering judgment.
