The Mythical Man Month at 50: Does Brooks’ Law Still Hold True and is AI Finally the Silver Bullet?
Jonathan W. Lartigue, PhD
June 2026
It is now 50 years since Frederick P. Brooks Jr. wrote the classic book “The Mythical Man-Month: Essays on Software Engineering”, stating the counter-intuitive maxim that adding more labor to a delayed project simply delays it further.10 In five decades, what has become known as “Brooks’ Law” has held up because Brooks, despite framing his argument around 1970s technology and tools, was really writing about the economics of conceptual, coordinated human work. The tools have changed radically; the human failure modes have not.
Brooks’ Law ran counter to the prevailing assumptions of the time that production could be scaled linearly. Based on his experiences at IBM, Brooks grounded his arguments in first-hand experiences leading System/360 and OS/360 development at the company. His fundamental argument is that adding labor also adds communication and complexity, which is as intrinsic to software development as is coding. Therefore, the prevailing managerial instinct at the time of adding labor to a late project simply makes it later.
“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.”
Frederick P. Brooks Jr.
Why Do Organizations Keep Making the Same Mistakes?
The “man-month” fiction is organizationally convenient. It lets leaders pretend schedule is a resource-allocation problem rather than a system-design, uncertainty, and learning problem.
There are deeper reasons:
Estimation bias persists. Most surveyed software projects encounter effort or schedule overruns, with no clear evidence that formal estimation models automatically produce more accurate estimates.13 Similarly, large IT efforts still average 45
Organizations measure the wrong thing. Developer productivity cannot be reduced to a single activity metric; it must include satisfaction, performance, activity, communication/collaboration, and flow. “More people”, “more commits”, and “more output” can mask degraded flow, quality, and coordination.5
Architecture and organization are coupled. System architecture tends to mirror organizational communication structures, and ignoring this relationship creates friction between how teams are organized and how the software must evolve.6
The incentives are wrong. When a project is late, cutting scope is politically painful, changing architecture is slow, and admitting estimation error is embarrassing. Adding people looks decisive. Brooks’ point survives because it describes not just software mechanics, but executive psychology.
Accidental versus Essential Complexity
Brooks divided software difficulty into accidental complexity – friction from tools, languages, environments, and representation – and essential complexity – the hard work of specifying, designing, validating, and evolving a precise conceptual structure. He argued that no single technology or management technique would produce an order-of-magnitude improvement in productivity, reliability, and simplicity because much of the hard part is essential.3 Engineers still have to define relationships, exceptions, state transitions, constraints, and verification strategy.12 Modern practices partially mitigate Brooks Law by changing coordination costs and work decomposition, but they can also introduce new coupling.
Systematic reviews of agile methods report benefits (e.g., responsiveness, stakeholder alignment) while emphasizing that results depend on context and study quality; agile does not remove coordination costs, and large-scale agile introduces its own coordination structures.16,17
Agile is not a refutation of Brooks; it is a re-optimization of feedback loops and work slicing. It can lower coordination overhead through standardization and by making failures visible earlier. Similarly, platform engineering can increase parallelism by decoupling systems into individually deployable units. But distributed agile teams and remote work add new challenges and overhead for coordination and communication.
These costs cannot be eliminated; software remains a socio-technical coordination problem.11,15 Fraser writes the reality is “that software systems are shaped as much by people, organisational structures, incentives, and decision-making as they are by code, tools, and architecture.”9
In the past decade, accidental complexity has been reduced by great improvements in IDE support, refactoring tools, build/dependency management, version control, collaboration workflows, cloud infrastructure, and containerization. But essential complexity has simultaneously increased: distributed systems, concurrency, network reliability, security, privacy, and compliance constraints. Modern systems must also align with organizational processes, governance and legal constraints, incentives, and human workflows. Additionally, systems are rarely “finished,” and long-term change increases complexity pressure.
Does “No Silver Bullet” still apply, or is AI finally it?
Ten years after The Mythical Man Month, Brooks would postulate another seminal concept that became known as the “No Silver Bullet” theory: the concept that no single advance in software development process or tools can provide more than a modest leap in improvement to the efficiency of a software team.4
Over the intervening years, there have been several potential “silver bullets”: OO, CASE tools, 4GLs, agile, the cloud, and now artificial intelligence.
AI clearly attacks accidental complexity. It can be especially strong in certain areas of software development: generating boilerplate, explaining APIs, creating test cases, translating and summarizing legacy code. But in
wider areas its benefits may be more of a placebo effect. A 2025 randomized controlled trial on experienced open-source developers working in mature repositories found AI usage increased completion time by 19
So the short answer is: No, AI is not yet Brooks’ silver bullet.
It may produce order-of-magnitude improvements for some tasks, teams, and contexts, but Brooks’ standard was broader: a single development that delivers a 10x improvement in productivity, reliability, and simplicity across software engineering. The evidence does not yet support that.
Joe Yoder famously referred to “silver buckshot,” and current AI might more accurately be thought of as that: many small-to-large improvements across coding, testing, documentation, analysis, and operations, but with new failure modes in correctness, security, maintainability, and accountability.7
AI still has a long way to go, and it may become the silver bullet sooner than we think. We must wait.
Dr. Jonathan W. Lartigue is an associate director for business and program management in the aerospace and defense industry. He is an engineering process expert and Advanced SAFe Practice Consultant with more than 17 years of experience in training and leading agile teams. He holds a master’s degree in software engineering and a PhD in computer science and software engineering from Auburn University.
© Copyright 2026. All rights reserved.
[1] Joel Becker, Nate Rush, Elizabeth Barnes, and David Rein. Measuring the impact of early-2025 ai on experienced open-source developer productivity, 2025. arXiv:2507.09089v2.
[2] Michael Bloch, Sven Blumberg, and Jurgen Laartz. Delivering large-scale it projects on time, on budget, and on value. McKinsey Digital / Business Technology Office report, October 2012. Accessed: 2026-06-
24.
[3] Frederick P. Brooks. No silver bullet—essence and accidents of software engineering. Computer, 20(4):10–19, 1987.
[4] Frederick P. Jr. Brooks. No silver bullet—essence and accidents of software engineering. In Proceedings of the IFIP Tenth World Computing Conference, North-Holland, 1986. Elsevier Science Publishers B.V.
[5] Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. The space of developer productivity: There’s more to it than you think. ACM Queue, 2021.
[6] Martin Fowler. Conway’s law. Martin Fowler’s Bliki, October 2022.
[7] Steven Fraser and Dennis Mancl. No silver bullet: Software engineering reloaded. IEEE Software, 25(1):91–94, 2008.
[8] Yujia Fu, Peng Liang, Amjed Tahir, Zengyang Li, Mojtaba Shahin, Jiaxin Yu, and Jinfu Chen. Security weaknesses of copilot-generated code in github projects: An empirical study. ACM Transactions on
Software Engineering and Methodology, 34(8):218:1–218:34, 2025.
[9] Shiven Govender. The socio-technical reality behind failing software systems, 2024. LinkedIn article.
[10] Frederick P. Brooks Jr. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, Reading, MA, USA, 1975.
[11] Charity Majors. The future of software is a sociotechnical problem, 2023. Blog post.
[12] Steve McConnell. Software engineering principles. IEEE Software, 16(2):6–8, mar ”/” apr 1999.
[13] Kjetil Moløkken and Magne Jørgensen. A review of software surveys on software effort estimation. In 2003 International Symposium on Empirical Software Engineering, pages 223–230, 2003.
[14] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. Asleep at the keyboard? assessing the security of github copilot’s code contributions. In IEEE Symposium on Security and Privacy, 2022.
[15] Jay Soeur. Software isn’t just a tech problem — it’s a people problem, February 2025.
[16] ToreDyb˚ aand Torgeir Dingsøyr. Empirical studies of agile software de- velopment: A systematic review. Information andSoftware Technology, 50(9–10):833–859, 2008.
[17] ToreDyb˚ aandTorgeir Dingsøyr. Agile project management: From self- managing teams to large-scale development. 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, 2:945–946, 2015.
Artificial intelligence was utilized in production of the images associated with this article.
