The Mythical Man-Month in the Age of AI
j11g.com ·
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.
What people are saying
The thread mostly treated AI coding agents as a force multiplier with a brutal caveat: they accelerate whatever judgment and coordination already exist.
What readers liked
- Cheap, deliberately rough agent-built prototypes can surface missing requirements fast, making failure a practical design instrument rather than an…
- Agents appear strongest on bounded, feedback-rich work such as reverse engineering and performance tuning, where rapid trial-and-error can beat…
Concerns raised
- Agent output arrives faster than humans can validate it, so dozens of plausible designs can create an evaluation bottleneck rather than genuine…
- LLM subagents tend to overconstrain their own plans and defend existing implementation choices, missing the higher-level question of what the…
Read full discussion analysis
Source: Hacker News · Based on 15 sampled comments · Analyzed
Discussion overview
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.
Points of disagreement
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.
What readers liked
- 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 raised
- 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.
Keep reading
Sources and details
j11g.com · Published
The Mythical Man-Month in the Age of AI
Read report →
Community analysis available for 1 of 1 linked discussions.
Additional discussion searches are still incomplete.
Coverage details and dates
Latest available community analysis:
Summaries: 1 current · 0 awaiting update · 0 not verified
Latest summary update:
Hacker News · j11g.com