{"id":19,"date":"2026-08-22T18:02:46","date_gmt":"2026-08-22T18:02:46","guid":{"rendered":"https:\/\/lartigue.us\/?p=19"},"modified":"2026-09-06T02:31:09","modified_gmt":"2026-09-06T02:31:09","slug":"the-mythical-man-month-at-50-does-brooks-law-still-hold-true-and-is-ai-finally-the-silver-bullet","status":"publish","type":"post","link":"https:\/\/lartigue.us\/?p=19","title":{"rendered":"The Mythical Man Month at 50"},"content":{"rendered":"\n

The Mythical Man Month at 50: Does Brooks\u2019 Law Still Hold True and is AI Finally the Silver Bullet?<\/h2>\n\n\n\n
\n

Jonathan W. Lartigue, PhD<\/strong>
June 2026<\/em><\/p>\n<\/div><\/div>\n\n\n\n

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<\/sup> In five decades, what has become known as “Brooks\u2019 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.<\/p>\n\n\n\n

Brooks\u2019 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.<\/p>\n\n\n\n

\u201cThere 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.\u201d<\/p>Frederick P. Brooks Jr.<\/cite><\/blockquote><\/figure>\n\n\n\n

Why Do Organizations Keep Making the Same Mistakes?<\/h2>\n\n\n\n

The \u201cman-month\u201d fiction is organizationally convenient. It lets leaders pretend schedule is a resource-allocation problem rather than a system-design, uncertainty, and learning problem.<\/p>\n\n\n\n

There are deeper reasons:<\/p>\n\n\n\n

Estimation bias persists<\/strong>. Most surveyed software projects encounter e\ufb00ort or schedule overruns, with no clear evidence that formal estimation models automatically produce more accurate estimates.13<\/sup> Similarly, large IT e\ufb00orts still average 45\n\n\n\n

Organizations measure the wrong thing<\/strong>. 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<\/sup><\/p>\n\n\n\n

Architecture and organization are coupled.<\/strong> 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<\/sup><\/p>\n\n\n\n

The incentives are wrong.<\/strong> 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\u2019 point survives because it describes not just software mechanics, but executive psychology.<\/p>\n\n\n\n

Accidental versus Essential Complexity<\/h2>\n\n\n\n

Brooks divided software di\ufb03culty 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<\/sup> Engineers still have to define relationships, exceptions, state transitions, constraints, and verification strategy.12<\/sup> Modern practices partially mitigate Brooks Law by changing coordination costs and work decomposition, but they can also introduce new coupling.<\/p>\n\n\n\n

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<\/sup><\/p>\n\n\n\n

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. <\/p>\n\n\n\n

These costs cannot be eliminated; software remains a socio-technical coordination problem.11,15<\/sup> 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<\/sup><\/p>\n\n\n\n

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 \u201cfinished,\u201d and long-term change increases complexity pressure.<\/p>\n\n\n\n

Does \u201cNo Silver Bullet\u201d still apply, or is AI finally it?<\/h2>\n\n\n\n

Ten years after The Mythical Man Month, Brooks would postulate another seminal concept that became known as the \u201cNo Silver Bullet\u201d theory: the concept that no single advance in software development process or tools can provide more than a modest leap in improvement to the e\ufb03ciency of a software team.4<\/sup><\/p>\n\n\n\n

Over the intervening years, there have been several potential \u201csilver bullets\u201d: OO, CASE tools, 4GLs, agile, the cloud, and now artificial intelligence.<\/p>\n\n\n\n

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 e\ufb00ect. A 2025 randomized controlled trial on experienced open-source developers working in mature repositories found AI usage increased completion time by 19\n\n\n\n

So the short answer is: No, AI is not yet Brooks\u2019 silver bullet.<\/p>\n\n\n\n

It may produce order-of-magnitude improvements for some tasks, teams, and contexts, but Brooks\u2019 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.<\/p>\n\n\n\n

Joe Yoder famously referred to \u201csilver buckshot,\u201d 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<\/sup><\/p>\n\n\n\n

AI still has a long way to go, and it may become the silver bullet sooner than we think. We must wait.<\/p>\n\n\n\n

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\u2019s degree in software engineering and a PhD in computer science and software engineering from Auburn University.<\/em><\/p>\n\n\n\n

\u00a9 Copyright 2026. All rights reserved.<\/p>\n\n\n\n

[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 O\ufb03ce report, October 2012. Accessed: 2026-06-
24.
[3] Frederick P. Brooks. No silver bullet\u2014essence and accidents of software engineering. Computer, 20(4):10\u201319, 1987.
[4] Frederick P. Jr. Brooks. No silver bullet\u2014essence 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\u2019s more to it than you think. ACM Queue, 2021.
[6] Martin Fowler. Conway\u2019s law. Martin Fowler\u2019s Bliki, October 2022.
[7] Steven Fraser and Dennis Mancl. No silver bullet: Software engineering reloaded. IEEE Software, 25(1):91\u201394, 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\u2013218: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\u20138, mar \u201d\/\u201d apr 1999.
[13] Kjetil Mol\u00f8kken and Magne J\u00f8rgensen. A review of software surveys on software e\ufb00ort estimation. In 2003 International Symposium on Empirical Software Engineering, pages 223\u2013230, 2003.
[14] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. Asleep at the keyboard? assessing the security of github copilot\u2019s code contributions. In IEEE Symposium on Security and Privacy, 2022.
[15] Jay Soeur. Software isn\u2019t just a tech problem \u2014 it\u2019s a people problem, February 2025.
[16] ToreDyb\u02da aand Torgeir Dings\u00f8yr. Empirical studies of agile software de- velopment: A systematic review. Information andSoftware Technology, 50(9\u201310):833\u2013859, 2008.
[17] ToreDyb\u02da aandTorgeir Dings\u00f8yr. Agile project management: From self- managing teams to large-scale development. 2015 IEEE\/ACM 37th IEEE International Conference on Software Engineering, 2:945\u2013946, 2015.<\/p>\n\n\n\n

Artificial intelligence was utilized in production of the images associated with this article.<\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

The Mythical Man Month at 50: Does Brooks\u2019 Law Still Hold True and is AI Finally the Silver Bullet? Jonathan W. Lartigue, PhDJune 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\u2019 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\u2019 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. \u201cThere 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.\u201d Frederick P. Brooks Jr. Why Do Organizations Keep Making the Same Mistakes? The \u201cman-month\u201d 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 e\ufb00ort or schedule overruns, with no clear evidence that formal estimation models automatically produce more accurate estimates.13 Similarly, large IT e\ufb00orts 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\u2019 point survives because it describes not just software mechanics, but executive psychology. Accidental versus Essential Complexity Brooks divided software di\ufb03culty 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 \u201cfinished,\u201d and long-term change increases complexity pressure. Does \u201cNo Silver Bullet\u201d 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 \u201cNo Silver Bullet\u201d theory: the concept that no single advance in software development process or tools can provide more than a modest leap in improvement to the e\ufb03ciency of a software team.4 Over the intervening years, there have been several potential \u201csilver bullets\u201d: 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 inwider areas its benefits may be more of a placebo e\ufb00ect. 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\u2019 silver bullet. It may produce order-of-magnitude improvements for some tasks, teams, and contexts, but Brooks\u2019 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 \u201csilver buckshot,\u201d 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\u2019s degree in software engineering and a PhD in computer science and software engineering from Auburn University. \u00a9 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 O\ufb03ce report, October 2012. Accessed: 2026-06-24.[3] Frederick P. Brooks. No silver bullet\u2014essence and accidents of software engineering. Computer, 20(4):10\u201319, 1987.[4] Frederick P. Jr. Brooks. No silver bullet\u2014essence 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\u2019s more to it than you think. ACM Queue, 2021.[6] Martin Fowler. Conway\u2019s law. Martin Fowler\u2019s Bliki, October 2022.[7] Steven Fraser and Dennis Mancl. No silver bullet: Software engineering reloaded. IEEE Software, 25(1):91\u201394, 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 onSoftware Engineering and Methodology, 34(8):218:1\u2013218: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\u20138, mar \u201d\/\u201d apr 1999.[13] Kjetil Mol\u00f8kken and Magne J\u00f8rgensen. A review of software surveys on software e\ufb00ort estimation. In 2003 International Symposium on Empirical Software Engineering, pages 223\u2013230, 2003.[14] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. Asleep at the keyboard? assessing the security of github copilot\u2019s code contributions. In IEEE Symposium on Security and Privacy, 2022.[15] Jay Soeur. Software isn\u2019t just a tech problem \u2014 it\u2019s a people problem, February 2025.[16] ToreDyb\u02da aand Torgeir Dings\u00f8yr. Empirical studies of agile software de- velopment: A systematic review. Information andSoftware Technology, 50(9\u201310):833\u2013859, 2008. [17] ToreDyb\u02da aandTorgeir Dings\u00f8yr. Agile project management: From self- managing teams to large-scale development. 2015 IEEE\/ACM 37th IEEE International Conference on Software Engineering, 2:945\u2013946, 2015. Artificial intelligence was utilized in production of the images associated with this article.<\/p>\n","protected":false},"author":1,"featured_media":40,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-19","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"yoast_head":"\nThe Mythical Man Month at 50 -<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/lartigue.us\/?p=19\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Mythical Man Month at 50 -\" \/>\n<meta property=\"og:description\" content=\"The Mythical Man Month at 50: Does Brooks\u2019 Law Still Hold True and is AI Finally the Silver Bullet? Jonathan W. Lartigue, PhDJune 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\u2019 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\u2019 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. \u201cThere 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.\u201d Frederick P. Brooks Jr. Why Do Organizations Keep Making the Same Mistakes? The \u201cman-month\u201d 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 e\ufb00ort or schedule overruns, with no clear evidence that formal estimation models automatically produce more accurate estimates.13 Similarly, large IT e\ufb00orts 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\u2019 point survives because it describes not just software mechanics, but executive psychology. Accidental versus Essential Complexity Brooks divided software di\ufb03culty 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 \u201cfinished,\u201d and long-term change increases complexity pressure. Does \u201cNo Silver Bullet\u201d 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 \u201cNo Silver Bullet\u201d theory: the concept that no single advance in software development process or tools can provide more than a modest leap in improvement to the e\ufb03ciency of a software team.4 Over the intervening years, there have been several potential \u201csilver bullets\u201d: 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 inwider areas its benefits may be more of a placebo e\ufb00ect. 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\u2019 silver bullet. It may produce order-of-magnitude improvements for some tasks, teams, and contexts, but Brooks\u2019 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 \u201csilver buckshot,\u201d 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\u2019s degree in software engineering and a PhD in computer science and software engineering from Auburn University. \u00a9 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 O\ufb03ce report, October 2012. Accessed: 2026-06-24.[3] Frederick P. Brooks. No silver bullet\u2014essence and accidents of software engineering. Computer, 20(4):10\u201319, 1987.[4] Frederick P. Jr. Brooks. No silver bullet\u2014essence 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\u2019s more to it than you think. ACM Queue, 2021.[6] Martin Fowler. Conway\u2019s law. Martin Fowler\u2019s Bliki, October 2022.[7] Steven Fraser and Dennis Mancl. No silver bullet: Software engineering reloaded. IEEE Software, 25(1):91\u201394, 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 onSoftware Engineering and Methodology, 34(8):218:1\u2013218: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\u20138, mar \u201d\/\u201d apr 1999.[13] Kjetil Mol\u00f8kken and Magne J\u00f8rgensen. A review of software surveys on software e\ufb00ort estimation. In 2003 International Symposium on Empirical Software Engineering, pages 223\u2013230, 2003.[14] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. Asleep at the keyboard? assessing the security of github copilot\u2019s code contributions. In IEEE Symposium on Security and Privacy, 2022.[15] Jay Soeur. Software isn\u2019t just a tech problem \u2014 it\u2019s a people problem, February 2025.[16] ToreDyb\u02da aand Torgeir Dings\u00f8yr. Empirical studies of agile software de- velopment: A systematic review. Information andSoftware Technology, 50(9\u201310):833\u2013859, 2008. [17] ToreDyb\u02da aandTorgeir Dings\u00f8yr. Agile project management: From self- managing teams to large-scale development. 2015 IEEE\/ACM 37th IEEE International Conference on Software Engineering, 2:945\u2013946, 2015. Artificial intelligence was utilized in production of the images associated with this article.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/lartigue.us\/?p=19\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-22T18:02:46+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-06T02:31:09+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1536\" \/>\n\t<meta property=\"og:image:height\" content=\"1024\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"admin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/lartigue.us\/?p=19\",\"url\":\"https:\/\/lartigue.us\/?p=19\",\"name\":\"The Mythical Man Month at 50 -\",\"isPartOf\":{\"@id\":\"https:\/\/lartigue.us\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/lartigue.us\/?p=19#primaryimage\"},\"image\":{\"@id\":\"https:\/\/lartigue.us\/?p=19#primaryimage\"},\"thumbnailUrl\":\"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png\",\"datePublished\":\"2026-08-22T18:02:46+00:00\",\"dateModified\":\"2026-09-06T02:31:09+00:00\",\"author\":{\"@id\":\"https:\/\/lartigue.us\/#\/schema\/person\/1154e1ea2f624f22847665cfff36ab24\"},\"breadcrumb\":{\"@id\":\"https:\/\/lartigue.us\/?p=19#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/lartigue.us\/?p=19\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/lartigue.us\/?p=19#primaryimage\",\"url\":\"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png\",\"contentUrl\":\"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png\",\"width\":1536,\"height\":1024,\"caption\":\"Brooks' Law: Is AI the Silver Bullet?\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/lartigue.us\/?p=19#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/lartigue.us\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Mythical Man Month at 50\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/lartigue.us\/#website\",\"url\":\"https:\/\/lartigue.us\/\",\"name\":\"\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/lartigue.us\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/lartigue.us\/#\/schema\/person\/1154e1ea2f624f22847665cfff36ab24\",\"name\":\"admin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/lartigue.us\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/aa24e98cf326e942f468ef5ad5ecff522a0b793420d96c17f3accc5af64f12ee?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/aa24e98cf326e942f468ef5ad5ecff522a0b793420d96c17f3accc5af64f12ee?s=96&d=mm&r=g\",\"caption\":\"admin\"},\"sameAs\":[\"https:\/\/lartigue.us\"],\"url\":\"https:\/\/lartigue.us\/?author=1\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"The Mythical Man Month at 50 -","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/lartigue.us\/?p=19","og_locale":"en_US","og_type":"article","og_title":"The Mythical Man Month at 50 -","og_description":"The Mythical Man Month at 50: Does Brooks\u2019 Law Still Hold True and is AI Finally the Silver Bullet? Jonathan W. Lartigue, PhDJune 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\u2019 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\u2019 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. \u201cThere 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.\u201d Frederick P. Brooks Jr. Why Do Organizations Keep Making the Same Mistakes? The \u201cman-month\u201d 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 e\ufb00ort or schedule overruns, with no clear evidence that formal estimation models automatically produce more accurate estimates.13 Similarly, large IT e\ufb00orts 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\u2019 point survives because it describes not just software mechanics, but executive psychology. Accidental versus Essential Complexity Brooks divided software di\ufb03culty 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 \u201cfinished,\u201d and long-term change increases complexity pressure. Does \u201cNo Silver Bullet\u201d 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 \u201cNo Silver Bullet\u201d theory: the concept that no single advance in software development process or tools can provide more than a modest leap in improvement to the e\ufb03ciency of a software team.4 Over the intervening years, there have been several potential \u201csilver bullets\u201d: 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 inwider areas its benefits may be more of a placebo e\ufb00ect. 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\u2019 silver bullet. It may produce order-of-magnitude improvements for some tasks, teams, and contexts, but Brooks\u2019 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 \u201csilver buckshot,\u201d 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\u2019s degree in software engineering and a PhD in computer science and software engineering from Auburn University. \u00a9 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 O\ufb03ce report, October 2012. Accessed: 2026-06-24.[3] Frederick P. Brooks. No silver bullet\u2014essence and accidents of software engineering. Computer, 20(4):10\u201319, 1987.[4] Frederick P. Jr. Brooks. No silver bullet\u2014essence 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\u2019s more to it than you think. ACM Queue, 2021.[6] Martin Fowler. Conway\u2019s law. Martin Fowler\u2019s Bliki, October 2022.[7] Steven Fraser and Dennis Mancl. No silver bullet: Software engineering reloaded. IEEE Software, 25(1):91\u201394, 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 onSoftware Engineering and Methodology, 34(8):218:1\u2013218: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\u20138, mar \u201d\/\u201d apr 1999.[13] Kjetil Mol\u00f8kken and Magne J\u00f8rgensen. A review of software surveys on software e\ufb00ort estimation. In 2003 International Symposium on Empirical Software Engineering, pages 223\u2013230, 2003.[14] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. Asleep at the keyboard? assessing the security of github copilot\u2019s code contributions. In IEEE Symposium on Security and Privacy, 2022.[15] Jay Soeur. Software isn\u2019t just a tech problem \u2014 it\u2019s a people problem, February 2025.[16] ToreDyb\u02da aand Torgeir Dings\u00f8yr. Empirical studies of agile software de- velopment: A systematic review. Information andSoftware Technology, 50(9\u201310):833\u2013859, 2008. [17] ToreDyb\u02da aandTorgeir Dings\u00f8yr. Agile project management: From self- managing teams to large-scale development. 2015 IEEE\/ACM 37th IEEE International Conference on Software Engineering, 2:945\u2013946, 2015. Artificial intelligence was utilized in production of the images associated with this article.","og_url":"https:\/\/lartigue.us\/?p=19","article_published_time":"2026-08-22T18:02:46+00:00","article_modified_time":"2026-09-06T02:31:09+00:00","og_image":[{"width":1536,"height":1024,"url":"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png","type":"image\/png"}],"author":"admin","twitter_card":"summary_large_image","twitter_misc":{"Written by":"admin","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/lartigue.us\/?p=19","url":"https:\/\/lartigue.us\/?p=19","name":"The Mythical Man Month at 50 -","isPartOf":{"@id":"https:\/\/lartigue.us\/#website"},"primaryImageOfPage":{"@id":"https:\/\/lartigue.us\/?p=19#primaryimage"},"image":{"@id":"https:\/\/lartigue.us\/?p=19#primaryimage"},"thumbnailUrl":"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png","datePublished":"2026-08-22T18:02:46+00:00","dateModified":"2026-09-06T02:31:09+00:00","author":{"@id":"https:\/\/lartigue.us\/#\/schema\/person\/1154e1ea2f624f22847665cfff36ab24"},"breadcrumb":{"@id":"https:\/\/lartigue.us\/?p=19#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/lartigue.us\/?p=19"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lartigue.us\/?p=19#primaryimage","url":"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png","contentUrl":"https:\/\/lartigue.us\/wp-content\/uploads\/2026\/08\/Mythical50SilverBullet.png","width":1536,"height":1024,"caption":"Brooks' Law: Is AI the Silver Bullet?"},{"@type":"BreadcrumbList","@id":"https:\/\/lartigue.us\/?p=19#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/lartigue.us\/"},{"@type":"ListItem","position":2,"name":"The Mythical Man Month at 50"}]},{"@type":"WebSite","@id":"https:\/\/lartigue.us\/#website","url":"https:\/\/lartigue.us\/","name":"","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/lartigue.us\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/lartigue.us\/#\/schema\/person\/1154e1ea2f624f22847665cfff36ab24","name":"admin","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lartigue.us\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/aa24e98cf326e942f468ef5ad5ecff522a0b793420d96c17f3accc5af64f12ee?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/aa24e98cf326e942f468ef5ad5ecff522a0b793420d96c17f3accc5af64f12ee?s=96&d=mm&r=g","caption":"admin"},"sameAs":["https:\/\/lartigue.us"],"url":"https:\/\/lartigue.us\/?author=1"}]}},"_links":{"self":[{"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/posts\/19","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lartigue.us\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=19"}],"version-history":[{"count":9,"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/posts\/19\/revisions"}],"predecessor-version":[{"id":60,"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/posts\/19\/revisions\/60"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lartigue.us\/index.php?rest_route=\/wp\/v2\/media\/40"}],"wp:attachment":[{"href":"https:\/\/lartigue.us\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=19"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lartigue.us\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=19"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lartigue.us\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=19"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}