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.
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.
"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 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
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.
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.”
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.
"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.
Mythical Man Month
(martinfowler.com)199 points by ingve 7 May 2026 | 137 comments
Comments
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
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.
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.
Vibe coded software is the Marvel green screen movie equivalent.
“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)
Fred 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.
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.