▲ 400 points
back
209 comments
>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.
---
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
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.
[0] Another classic required reading of the industry https://pages.cs.wisc.edu/~remzi/Naur.pdf
We've found pyrite thinking it gold. Then we bought the whole saloon drinks and hookers.
The hangover tomorrow morning will not be pleasant. And the bar tab even less so.
This is a good way of putting it. I ship individual features faster, but the end to end process of shipping software has remained the roughly same because the vast majority of my time is building the “theory”.
I love that Naur paper! Also love this essay that extends it: https://hiringengineersbook.com/post/autonomy/
I literally maintain a conceptual-model.md that describes the “things” in our entire system, how they relate to each other, and some bits about how that maps to the code (the DB schema maps sort of closely to it but sometimes not that close, and so does the API, and that’s ok). I wrote most of the doc myself, but plan to coauthor with LLMs going forward.
So far it’s saved me tons of typing as I add features. I don’t have enough data yet on how well it will guide myself and others when adding stuff that really stretches the model, but I’m also optimistic that it’s a valuable approach.
> Muddled prompting by humans gets you the Homer Simpson car you wished for
Well put! Now that we have a magic tool that can generate tokens on demand, the quality of the underlying idea gains enormous importance relative to the code. Tokens are cheap. Good ideas are not.
I would like to hope that some people take advantage of this newfound agentic power to create better theories. But there's a sizable population that seems intent on generating more and more code, regardless of quality.
Imo the main benefit of AI is allowing faster experimentation and more parallelism, as well as faster iteration.
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.
How well does that work for you ? It's annoyingly inconsistent for me - I give it instructions on how to fetch JIRA ticket with a script that renders everything relevant to a .md and half of the time it will still default to reading it via ACLI. I have instructions on how to do a full build with warnaserror before commit but I still get pipeline errors regularly because it will skip the noincremental part, etc.
> 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.
I also do this.
e.g. after watching Claude burn tokens building and then deploying a docker image multiple times (and it taking extra time), I asked it to just create a build.and.deploy.sh script. I also then have a test.deploy.sh script that Claude can use to confirm everything worked.
Saves a ton of time/tokens AND has the added benefit of being usable by me or other humans when doing manual tests or debugging outages etc.
"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.
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.
I haven't yet seen anyone with a concrete example project (public ideally, but even describing private efforts in enough detail to enable potential criticism would be fine) making a claim as strong as 10x. Are you willing to break the mould and show us what we're all missing?
I'm curious to check how faster AAA games will hit the market in the next years compared to the pre-LLM era. Or how much of the aging COBOL code base out there will disappear in the next decade.
When concrete things like that start to happen, then I will start to believe in the 10x claim.
> AI is the silver bullet - my output is genuinely 10X what it was before claude code existed.
This reminds me of ThePrimeagen noting that Dario was right about 90% of all software being written by AI. 90%+ of all useful software is still being written by humans, but now we've also got non-programmers like Gary Tan pushing the button to generate garbage piles of AI generated code at 10x the volume of what humans are generating.
Or look at Claude Code itself, the poster child for what AI generated code looks like, especially when you're operating in YOLO "never mind the quality, count the LOC" mode. Over a half million lines of bug ridden crap when 10-50K could have done the job.
https://techtrenches.dev/p/the-snake-that-ate-itself-what-cl...
The main point of mythical man month was that communication cost across people was the main cost as project grow in complexity.
So increasing individual output by itself is not enough to affect the argument. It could, if you also reduce the size of people needed for a project, where people are everyone included in the project, not just SWE. But there are strong forces in large orgs to pull toward larger project sizes: budgeting overhead and other similar large orgs optimize for legibility kind of arguments.
IMO the only way this will change is when new companies will challenge existing big guys. I think AI will help achieve this (e.g. agentic e-commerce challenging the existing players), but it will take time.
That is far from proven, 'far' being the keyword here in another understanding.
At _this_ moment, AI is in the state of producing things - if you like with factor 10 or more. But what will come afterwards, when all this mush of code shall create _reliable_ results. This means not man month then, rather man years or decades to fix this billion and maybe trillions lines of opaque probabilistic LOC. You have to take the mean of these two stages, if nothing qualitative happens to the models.
> that has led to a 10X increase in the speed of software development.
> AI is the silver bullet - my output is genuinely 10X what it was before claude code existed.
Those are not the same.
You can add 5 different features to a project and still provide less value that the 5 lines diff that resolves a performance bottleneck.
So there's input (prompts/requests/tokens), then there's outputs (lines of code) and there's outcomes. How much have the outcomes improved? Not just yours, but I'm more curious on the outcomes with regards to the actual need your projects are solving.
This was true as programming languages evolved too. It was so much easier to write scripting languages than C. You could crap out scripts like crazy - no cc refusing to give you a binary to get in your way.
Clearly..it still wasn't a silver bullet. Because output as a metric is a bad one. I thought it was only one managers valued..but apparently Anthropic has convinced devs to value it finally? i guess it def hits that dopamine receptor hard.
First counterexample that comes to mind: Rails vs 90s networked/shared line-of-business crud app development was a 10x factor. It also enabled a lot of internal tools that wouldn't have been worth doing without it.
But after people's expectations adjusted it was just back on the treadmill.
I don't think we've found a new steady-state yet, but I have some gut feeling guesses about where it's going to be.
10x the amount of code or features =/= 10x the speed of software development.
Conversely, the value of software has dropped to 1/10 of what it was before Claude code existed.
I’m being glib, but there’s a whole class of software (eg simple crud apps) that just don’t have any marginal value anymore. So it doesn’t matter if it’s 10X faster or 100X faster. 100 x $0 is still 0.
The disconnect here is a lack of proof that your increase in personal output actually increases the speed of software development. Considering: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule as a joking, but true fact of how software projects go, does AI skip that 2nd 90%? Or do we add a whole new bottleneck of review and corrections, and still need to code that last 90%?
When I measure software dev, delivery of code isn't even a metric I care about. It is a key part of the process, to be sure, but I care about results - Did we ship? Did it work? Do we have happier customers and a smaller bug list?
In my experience, while I can answer "yes" to those questions on people who use AI assistance surgically, applying it where its strengths lie... I can answer an emphatic "No" for the teams I've worked with who are "AI-first", making the AI usage itself part of their goals.
"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
It’s easy to see the conceptual integrity in good software, architecture, design and movies — or the lack of this quality in the bad ones.
Vibe coded software is the Marvel green screen movie equivalent.
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.
I love this book, and I often recommend it to new folks on my team. I used to carry a few extra paperback copies to give away, just in case.
"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'm living this hell right now.
Management just keep hiring developers. Coordination and communication between them and product managers gets more difficult.
Management keep agreeing to unrealistic timelines on new projects, yet haven't completed the old projects yet.
The architecture of the codebase is so convoluted and confusing that new devs take a very long time to get anywhere close to productive and self sufficient. Time to develop and release acceptable features gets longer and longer.
On top of all that, senior devs and tech leads are very up tight about code quality and 'how to write your code' yet can't even agree with each other on 'how to write your code' leading to Pull Request hell for devs and occasional whole week rewrites.
I'd buy a copy of this book and put it on my bosses desk, but he won't read it.
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.
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.
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.
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.
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.
What is that? Does he let openclaw post for him? Wikipedia article on the same topic is more informative
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.”
- Lee Iacocca (in his autobiography)
"Simple made Easy" is a nice add-on, the first half is the philosophical part and a classic. https://m.youtube.com/watch?v=SxdOUGdseq4
> The issue here is communication, as the number of people grows, the number of communication paths between those people grows exponentially.
Exponentially? Quadratically I would say.
so much bad software was written because of this guy (Martin) selling snakeoil
"Adding tokens to a late software project makes it bigger and still late."
I wonder if there's going to be a mythical AI month.
Adding AI to something makes it later/worse/slop
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.
Look, I read it and loved it 25 hyears ago.
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.