Notably, his essay “no silver bullet” states that there has never been a new technology or way of thinking or working that has led to a 10X increase in the speed of software development.
That was true for almost seventy years until roughly last year.
AI is the silver bullet - my output is genuinely 10X what it was before claude code existed.
> Notably, his essay “no silver bullet” states that there has never been a new technology or way of thinking or working that has led to a 10X increase in the speed of software development.
I think the statement is generally true, but I also think there are specific tools that do vastly increase dev time for something that follows that specific pattern.
Program templates and also code generation have been used forever to simplify and speed up specific types of programs, like all of the CRUD programs in an ERP system for maintaining the hundreds to thousands of different master data like Customers, etc.
Those approaches can speed a specific activity that follows a specific pattern by some multiplier (e.g. 4x or 10x).
But the trade-off is time to build the template or code gen vs number of instances it will be used.
I think where "no silver bullet" has the strongest case is for something completely new where the patterns and templates have not been established.
When I think about LLM's and compare to past templates and code gen, I wonder what exactly is the nature of the LLM trade-off in the broad sense. For a template, it's pretty clearly up front design+dev compared to number of instances of usage of the template.
LLM's are more general and more broadly applicable, but still not the same as a human. Is the trade-off purely cost that was sunk into the model and tool that now needs to be recouped by the AI company? (e.g. charging the actual $1,000 to $1,500 that it really costs instead of $200
Or are the big trade-offs and costs going to show up in the future: the dwindling of human expertise due to reliance on the tool and the loss of understanding of complex systems.
As a software engineering manager, I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can. If some things take longer than expected, then I already have a team of engineers with all the context since the project kicked off that can help each other with any longer running tasks. An engineer that has completed a smaller chunk of work can help out with the items on the critical path, for example.
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." -FB
Fortunate to be reminded of this right now, especially the pull-quote about conceptual integrity.
This is the reason why AI-assisted programming has not turned out to be the silver bullet we have been hoping for, at least yet. Muddled prompting by humans gets you the Homer Simpson car you wished for, that will eventually collapse under its own weight.
I've been thinking a lot about Programming as Theory Building [0] as the missing piece in AI-assisted engineering. Perhaps there are approaches which naturally focus on the essence while ignoring the accidents, but I'm still looking for them. Right now the state of the art I see ignores both accident and essence alike, and degrades the ability to make progress.
Please inform me if there are any approaches you know that work! And lest this sound pessimistic, far from it. This state of affairs is actually intoxicatingly motivating. Feels like we have found silver, and just need to start learning to mould bullets.
It's interesting to revisit Brooks' "surgical team" in light of AI. For example, I frequently have Claude act as a "toolsmith", creating bespoke project-specific tools on the fly, which are then documented in Skills that Claude can use going forward. What has changed is that a) One person (or rather, one person-AI hybrid) plays all the roles within the surgical team, and b) Internal frictions such as cost, development time, and communication overhead have all been dramatically slashed.
"The most influential." is relative, I read it when it came out, and I had been programming for more than 20 years, there were 2 professors on the facility who were there... and confirmed much of it. 10 years later, while dipping back into academia again, it was a recommend read, so I read it again. 20 years later, the same thing happened... it influenced multiple generations of programmers and managers world wide. I am willing to read it again, and yes, it really is that influential.
I re-read that book every 10 years and try to think carefully about whether what Brooks wrote still holds.
The last three times I read the book, everything held.
This time, I'm not so sure: AI does change things significantly. Perhaps not for all teams and not all scales of software, but in my case (solo developer, complex software system) I did measure a 12x productivity increase [1].
Also, some of the problems Brooks describes became much easier, if not borderline trivial with AI. For example, maintaining design documentation that stays consistent with the software being built. I do this and it is no longer a problem.
I still think most of what Brooks wrote is applicable today. I think the biggest difference is that AI enables smaller teams to work on larger systems, and the biggest benefit is for single-person teams (ahem) like me. I see it as another step that allows me to tackle larger systems: the previous one was Clojure which reduced incidental complexity so significantly that I was able to develop the system to the size it is today. AI is the next step: it allows me to build features that would have taken me years in a span of months. Not because of "vibe coding", but primarily because I can work on a set of design documents and turn my ideas into a coherent design.
[1] For the nitpickers: yes, measured, not guessed. Yes, the metric was reasonable. No, it wasn't "lines of code" or something equally silly, in fact one of my main goals is reducing code size as much as possible. Yes, I compared larger time periods: 2 months with AI to an average of 12 months of the previous year. No, the metric wasn't gamed: this is a solo business and I have no interest in gaming my own metrics. I earn a living from this work, so this is as objective as it gets.
"Conceptual integrity" is something I always try to adhere to when I design and build systems. I also use it also a bit of an indicator when gauging someone's experience. For example, mid-level devs will often try to introduce some form of "optimisation" somewhere in the codebase that results in the codeflow deviating from existing patterns. More often than not I will reject the PR, or the idea. For me, it's better than all flows follow similar paths. It makes it easier to reason and communicate ideas about, modularise and/or form logical groupings etc etc.
This is also why one of my instructions to coding agents is that they adhere to established coding and testing patterns, even where they appear to be sub-optimal.
The funny thing is that adding agents to an AI-first project has similar issues (today). Agents stepping on each others toes, needing to manage state, communicate with each other, and divide up work that is planned ahead centrally. Agents accelerate, but don't reinvent the fundamentals of building products.
Anytime I read an article about increasing software delivery times, I think of this quote:
“Through more vigorous computer programing and more sophisticated scheduling, it was possible to reduce the changeover period from two weeks to two days.”
Loved Brooks’ and feel like I must’ve internalized his model because that’s all I care about anymore in dev. Coherence among the components (people or software) to produce something good. I think of if 100 pianos are tuned to the same tuning fork then they all play well together.
AI accelerated iteration and undisciplined use seem to me the main risk lately. Drift from any prompting, accumulation of features, plausible looking patches that are actually slop. Wrote about this recently [0], it creates a dynamic where you aren’t just making the software less coherent, you’re paying more and more to make it so. Curious to hear others experience of this.
>He argues that conceptual integrity comes from both simplicity and straightforwardness
If you want to follow this advice, I think Leslie Lamport's formulation is the most concrete. His version is:
- Write down a small model of what you are about to build before building it.
- Try to see how that model could fail. If it still looks good, either make the spec/design doc/model clearer and more concrete, or start writing the code.
- If plain text gets too vague, use math. If you want tools to check it, use TLA+ with TLC or Apalache. Quint and stateright.rs are nearby tools in the same area.
When I first heard about the book I accidentally read it as “Mythical Man Moth” and was deeply intrigued how this was about software development and immeasurably disappointed when I found out it was “month” instead.
In agentic design, I keep coming back to the idea of “how easily we can compose elements”, along with Fowler’s OOP and refactoring principles.
It’s a new frontier, and there are no absolutes. But I suspect the most durable AI systems will be built around highly composable, well-orchestrated agents.
When it comes to Brooks's Law and AI, will trying to incorporate AI tools into a late project, make the project later? Probably. I'm glad I'm close to retiring. AI has been a mixed blessing for me. I don't have the desire at this stage to do all the wrangling necessary to incorporate AI tools effectively into my workflow.
29 comments
[ 0.18 ms ] story [ 41.2 ms ] threadFred Brooks wrote that book when they were programming IBM operating systems in assembly language.
Times have really, really changed - do not pay attention to the messages of this book unless for historical fun.
That was true for almost seventy years until roughly last year.
AI is the silver bullet - my output is genuinely 10X what it was before claude code existed.
I think the statement is generally true, but I also think there are specific tools that do vastly increase dev time for something that follows that specific pattern.
Program templates and also code generation have been used forever to simplify and speed up specific types of programs, like all of the CRUD programs in an ERP system for maintaining the hundreds to thousands of different master data like Customers, etc.
Those approaches can speed a specific activity that follows a specific pattern by some multiplier (e.g. 4x or 10x).
But the trade-off is time to build the template or code gen vs number of instances it will be used.
I think where "no silver bullet" has the strongest case is for something completely new where the patterns and templates have not been established.
When I think about LLM's and compare to past templates and code gen, I wonder what exactly is the nature of the LLM trade-off in the broad sense. For a template, it's pretty clearly up front design+dev compared to number of instances of usage of the template.
LLM's are more general and more broadly applicable, but still not the same as a human. Is the trade-off purely cost that was sunk into the model and tool that now needs to be recouped by the AI company? (e.g. charging the actual $1,000 to $1,500 that it really costs instead of $200
Or are the big trade-offs and costs going to show up in the future: the dwindling of human expertise due to reliance on the tool and the loss of understanding of complex systems.
Vibe coded software is the Marvel green screen movie equivalent.
This is the reason why AI-assisted programming has not turned out to be the silver bullet we have been hoping for, at least yet. Muddled prompting by humans gets you the Homer Simpson car you wished for, that will eventually collapse under its own weight.
I've been thinking a lot about Programming as Theory Building [0] as the missing piece in AI-assisted engineering. Perhaps there are approaches which naturally focus on the essence while ignoring the accidents, but I'm still looking for them. Right now the state of the art I see ignores both accident and essence alike, and degrades the ability to make progress.
Please inform me if there are any approaches you know that work! And lest this sound pessimistic, far from it. This state of affairs is actually intoxicatingly motivating. Feels like we have found silver, and just need to start learning to mould bullets.
[0] Another classic required reading of the industry https://pages.cs.wisc.edu/~remzi/Naur.pdf
The last three times I read the book, everything held.
This time, I'm not so sure: AI does change things significantly. Perhaps not for all teams and not all scales of software, but in my case (solo developer, complex software system) I did measure a 12x productivity increase [1].
Also, some of the problems Brooks describes became much easier, if not borderline trivial with AI. For example, maintaining design documentation that stays consistent with the software being built. I do this and it is no longer a problem.
I still think most of what Brooks wrote is applicable today. I think the biggest difference is that AI enables smaller teams to work on larger systems, and the biggest benefit is for single-person teams (ahem) like me. I see it as another step that allows me to tackle larger systems: the previous one was Clojure which reduced incidental complexity so significantly that I was able to develop the system to the size it is today. AI is the next step: it allows me to build features that would have taken me years in a span of months. Not because of "vibe coding", but primarily because I can work on a set of design documents and turn my ideas into a coherent design.
[1] For the nitpickers: yes, measured, not guessed. Yes, the metric was reasonable. No, it wasn't "lines of code" or something equally silly, in fact one of my main goals is reducing code size as much as possible. Yes, I compared larger time periods: 2 months with AI to an average of 12 months of the previous year. No, the metric wasn't gamed: this is a solo business and I have no interest in gaming my own metrics. I earn a living from this work, so this is as objective as it gets.
This is also why one of my instructions to coding agents is that they adhere to established coding and testing patterns, even where they appear to be sub-optimal.
“Through more vigorous computer programing and more sophisticated scheduling, it was possible to reduce the changeover period from two weeks to two days.”
- Lee Iacocca (in his autobiography)
AI accelerated iteration and undisciplined use seem to me the main risk lately. Drift from any prompting, accumulation of features, plausible looking patches that are actually slop. Wrote about this recently [0], it creates a dynamic where you aren’t just making the software less coherent, you’re paying more and more to make it so. Curious to hear others experience of this.
[0] https://charlesleifer.com/blog/tokens-and-dreams/
If you want to follow this advice, I think Leslie Lamport's formulation is the most concrete. His version is:
- Write down a small model of what you are about to build before building it.
- Try to see how that model could fail. If it still looks good, either make the spec/design doc/model clearer and more concrete, or start writing the code.
- If plain text gets too vague, use math. If you want tools to check it, use TLA+ with TLC or Apalache. Quint and stateright.rs are nearby tools in the same area.
---
Materials:
- TLA+ videocourse by Lamport: https://lamport.azurewebsites.net/video/videos.html
- How to win a Turing Award speech: https://www.youtube.com/watch?v=tw3gsBms-f8
- Thinking above the code: https://www.youtube.com/watch?v=-4Yp3j_jk8Q
It’s a new frontier, and there are no absolutes. But I suspect the most durable AI systems will be built around highly composable, well-orchestrated agents.
Exponentially? Quadratically I would say.