>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.
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.
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 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.
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.
I have a harness for Claude Code "hooks" (https://code.claude.com/docs/en/hooks) which in my case execute a Go tool in a separate project which runs changes made by claude through a validator with various rules that can be defined (regex, semgrep, etc.). They can warn claude or they can block changes outright.
When I find claude is using tools or approaches that I have replaced with more specific ones, I ask claude to add a hook to prevent doing this in the future and point it to the instructions of what to do instead.
And of course I wrapped all that up in a Skill so it knows what approaches to take to add things to hooks.
It becomes fairly trivial to incrementally stop it making repeated mistakes like this.
You may want to try out pi-agent and create custom extensions instead.
Then codify this behavior into a process which automatically gets run through.
I.e. $repo/origin as bare repo, then prompt to create a shell script which creates the worktree and cds into it, running the script you mentioned, instantiating pi in it.
Potentially define explicit phases for your workflow and show the phase in the UI - and quality gates for transitions. Eg force the implment to finalize phase to only happen if all tests succeeded. Potentially add multiple review phases here too, with different prompts. This progressively gets rid of more and more inconsistencies.
Still not a perfect solution, but on average I've had less and less to manually address with that workflow. Albeit at cost of tokens (multiple reviews phases obviously ingest all changes multiple time)
Pi-agents extensibility is just a lot better then the other harnesses, but you could obviously also just introduce a different orchestrator to do the same. For me, pi-agent was just the least amount of effort necessary to get it going.
So why not fetch the ticket deterministically yourself as part of "staging" all the information that Claude will need? I.e. if Claude can't be relied upon to do something the way you want it done, take that task away from it, perform it some other way, and feed the results back to Claude.
I don't use AI much so I don't know if this is reasonable.
I rebuilt an app I found in rust and extended it in a bunch of ways that I use everyday for this use case and it works flawlessly if this is any help: https://github.com/dchuk/jarkdown-rs
On a local model, with open code, when I wrote a specific javascript way to run sql queries because bash and psql were error prone, what I did was when I saw it make a mistake, I told it in passive agressive tones something like: "please edit AGENTS.md to detail how to use the query.js tool to run a query and to never use psql"; I did this two times until it stopped wanting to use psql.
It seems like if you write the docs yourself that's not leveraging the probability that the model itself knows the anti-context guard rail that best prevents it from grabbing its average tool use.
> 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.
I do something similar, but tell the agent to write a recipe into a justfile. Then it can run `just` and get a self-documenting list of all the tooling for the project (just build, just test, etc.)
I had a similar experience recently. I had a huge Swagger JSON file that would waste too many tokens if added directly to the context, so I told the agent in memory to use jq to retrieve what it needs when it wants to check this document. This saved a lot of cost.
"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?
10x what? 10x revenue? 10x features shipped? Whats the measure, is it 10x speed of dev like parent comment? Because an unqualified 10x could mean 10x SLOC which is trivial with an agent but has negative value.
Assuming 10x on the speed of dev, Is the vscode repo a decent example? Recently they've been all in on AI augmented development so i'm thinking they'd be a reasonable subject?
How do you isolate out what counts as the "development" part of their delivery cycle (is that the dev inner loop, does that show up in frequency of commits then?) to measure it and see if it's running 10x?
Guarantee it’s the same story I get from all my friends/co workers who are now 10x… they are 10 times faster at starting random projects that get to 80% done that they can’t finish, so they immediately move on to the next project because their velocity is so high
From a software quality or software engineering POV --> this is clearly not building durable value, not scalable, etc. So I'd agree with you there.
But from the POV of say, a young startup company looking for PMF and navigating the ambiguities involved with trying to figure out what is the "right thing" to build that will appeal/delight/convince-people-to-pay --> being 10X faster at shipping 80% done projects, is actually incredibly, unfathomably valuable of a superpower. And it is also rationally the "right thing" to do, to make lots of cheap bets and fail/learn fast.
I find that many folks on my team (I am a manager/leader of small-to-mid size eng org), struggle with accepting the nuances of knowing the difference between different projects (where same team may need to do both kinds of work, all the time and in parallel):
- "Hey, the company needs, and you and I both agree, that this situation calls for building/renovating a skyscraper --> please design a fucking strong/safe/reliable skyscraper and don't take any shortcuts, this requires 'real' engineering"
- Vs, "Hey, the company isn't sure what it needs, and neither you nor I know any better either, so let's try a bunch of different shacks/sheds/treehouses/whatever, until we find something that has traction / makes us money (and it's okay if the shed collapses -- so long as the business knows this too, that it wasn't meant to be a load-bearing, skyscraper-esque thing anyways)"
I won't get into the rabbit hole of talking about dealing with bad business leaders, who want a skyscraper but expect to pay the price of a shack/shed. Let's assume that we are talking about the type of companies (maybe the minority) that are reasonable enough to know and acknowledge the difference. Then what is the game-theoretic/rational thing for them to do, and how does this 10X idea express itself? That's where my argument is coming from.
Its 10x code generation with .5x quality at best and all other parts of the SDLC are at 1.x or worse.
AI is not delivering 10x shareholder value, anywhere. Software developers have quite the level of hubris about how important they are to companies. Yes our work is very complex and takes a certain mindset to do it well. It takes a lot of other roles to have a successful business, many of those roles will use AI to help draft slide decks, emails, etc. and that's the limit for them.
Look at recent companies doing layoffs claiming its because of AI, like CloudFlare and Coinbase, do their reported financials paint the picture that they are crushing it with AI? No, its net losses into the $100's of millions.
It's more like ∞x (or N/Ax if you prefer) because the majority of the projects I did with LLM agents wouldn't have existed without them, because I would've never found enough time to work on them.
One of the latest things I made with Claude was a tool that allowed me to move a bunch of very low traffic Cloud Run services to a single VPS without losing any of the Cloud Run benefits such as easy Docker-based deployment and automatic certificate provisioning. I thought about making something like that for quite some time, and Claude finally made it possible, which makes me quite happy.
The fun thing here is that no other soul genuinely cares about it, or any other code I might publish. The code, especially AI generated, is so cheap that if anyone wants to repeat my steps to get rid of Cloud Run services, they will probably vibe-code their own tool instead of figuring out how to use mine, just like I did that instead of spending time on learning Dokku or similar solutions.
So, yes, 10x and more, but no one cares about the result, which makes the whole 10x measurement less useful.
There have been plenty of libraries/tools that got people from "I would like to do foo" to "oh, this tool makes foo possible in under 10 hours, I should start working on foo" in the past. LLMs have done this for many foos, which is great.
But I'm with hansvm - I haven't actually seen anyone plausibly maintain 10x. 10x is different from getting people past their activation cost.
The incredulity at 10x claims is often unearned because how much do these skeptics actually notice and appreciate the depth of work of ten developers collaborating on something (if not their own org)? Dev output slips by quietly. There are reams of unnoticed projects even at the scale of a life’s work.
I'm assuming the devs are seeing 10x code generation and equating that to the improvement.
It's when they practically ignore the rabbit holes where it's suspect. I'm definitely seeing speed ups. I troubleshot a linux system yesterday with minimal effort using a local llm. It likely would have taken me a few hours to locate all the docs & testing procedures. the llm did it with only a few prompts. To ensure it did it correctly, I had to interrogate it a few times before letting it proceed.
Humans make really bad scientists, and it takes a lot of effort to properly catalog and provide statistics for these things.
There is an improvement, but I doubt any random dev can give a real estimate since before LLMs they couldnt really give you a real estimate anyway. I do know when I encounter a bug now, debugging is almost immediately possible.
My small organization is noticing output increasing. We're excited about it. I’m not sure about 10x… Like others have mentioned, it’s difficult because you have to measure different workloads.
I build things I never would have. My tooling is better and more robust than ever. I verify and test my work better than ever. I fix more bugs than I used to simply because no one needs to care if it fits into a cycle. I explore and solve more problems in more parts of the application, even if I don’t write code. I take better care of our infrastructure. Performance goes up, bugs go down, AWS resources scale back, costs go down. I’ve paid for my AI usage in scaled back resources several times over at this point.
It might not be 10x but it’s a significant multiple.
1. I would not have attempted this without AI assistance because it's a big project.
2. I have built a functional program that I am able to use for real work in a handful of weeks, working part time on this (like literally a few hours per day prompting Claude and Kimi).
3. Had I decided to do this without AI assistance it would have been months of work.
I suspect that the goalposts for AI-assisted coding will be moved the same way they've been moved for the Turing Test.
The Turing Test used to matter until it didn't (does anyone even talk about it? was there a big news conference when it was solved?). Likewise every time it becomes easier to ship software, the bar will be pushed higher by sceptics. Ultimately the gatekeeping is going to become meaningless as software becomes "too cheap to meter".
It took me 2 years ago around 2k hours to build a cross platform FUSE vault, without using AI assisted tools.
The pain was debugging through logs and system traces. And understanding how things work.
Now managed to ship this one much faster, as an after hours project. Started it in may 2025, and around end of November 2025 started using claude on it.
Just by dumping logs into claude, and explaining the attack vector for the problems, saved me the FML moments of grindings walls of syscalls on 3 platforms.
I would say much easier to progress, and ship with the same rigour, minimize my time, focus and brain power involvement such that I can put the energy somewhere else.
Yep, the real strength of AI is less in replacing engineering skills, it's more in slashing all the time we spend not using those skills and doing low level research and data correlation tasks instead. Which isn't to say that those tasks aren't valuable in their own way, but in terms of raw output...
Just create a skill for it -> I call mine `babysit`. It spins up a subagent that polls it every x minutes and auto-fixes it until it's green. I already continue with the next task while it does that in the background
About 30% of our AI PR review checks are flawed at a fundamental level, based on poor comprehension of the whole. If I told the AI "fix everything and keep going until it's green" I would be terrified of the result.
I disbelieve this works in anything other than a toy codebase (or an incredibly fine-grained microservice).
The 70% is amazing! But a 30% failure rate requires intense supervision.
It is possible. I tell to use cli app, and for the agent to ad timer and check the status once in a while. Especially if there is something with a long wait. Also if it can run some validators/ same tools locally, would be much faster.
Might tend to deviate and waste time, needs guiding once in a while, and to check what is it spewing out, point it in the correct direction.
I treat the low level tasks as building blocks. You need a grasp and understanding of what is possible with them, but you do not need to remember the exact byte order and syntax. I think the idea is you should structure your workflow in a deterministic way, and just use Claude/ LLM as the interface. It is much easier and enjoyable to use high level language, where you give pointers to building blocks/ directions/ say hard no when you understand things deviate.
If I had to output the code myself, would take around 8 hours of constant writing to get around 1k LoC of code. For FUSE level tricky stuff, I might need to spend 3 weeks for 10 LoC. Very easy to burnout and build pain.
My friend who has never taken a programming class (or even touched an IDE before AFAIK) has now put a small app into production.
Complete frontend + backend + database.
Yes, it is an internal app, but it works and everyone loves it.
Does that count as an example?
(Also I absolutely expect him to need help at some point, but so far it has taken his project from absolutely impossible to 3 weeks of work in between work, renovating his house and being a dad for the first time so I was very impressed.)
These kind of things (internal tools created out of band of normal engineering practices by non-engineers) were amazing back when I did pentesting because the security was always the last consideration. That got harder when SaaS became preferable to rolling your own stuff for everything. Guess things are gonna get fun again for red teams lol
The danger is not however that only that people write their own tools for calculations and capacity planning etc.
The danger is people make useful stuff that is very fine as long it is just an internal tool, but then someone add credentials to other systems so it can access and maybe even update stuff and it gets exposed to third parties etc and all of a sudden we have a major data breach going on.
Obviously it was not the same s since models that could write programs were not available 10 years ago.
And if you just mean your friend taught himself programming on his own, well that is actually very cool, I did too back in the 90ies and so did many others here.
My point is that it is now possible to vibe code a full application from frontend to backend today and still not be able to understand a line of TypeScript or anything else.
20 years ago we had cpanel where people without programming knowledge can instantly deploy their own apps. Many people got millionaire doing that, I'd say proportionally probably way more than the people vibecoding solutions. This is not as revolutionary as we thought.
I'm building an open source Google Photos alternative. Have a look at my project and tell me if you think you could do all this at the same speed without an LLM: https://opennoodle.de
It doesn't completely blow away your argument, but you forked Immich and gave it to a LLM. Which is arguably slightly easier than starting from scratch.
Sounds like you're nitpicking on whether or not LLMs make you faster by saying that working on existing code is easier than starting from scratch? I think you've missed the point.
No, they're saying that it was misleading. OP said "I'm building an open source Google Photos alternative" and surprisingly didn't say "based on Immich". This dramatically changes the evaluation of "open-noodle".
We're now in an era where LoC is easy and design is hard[1]. Starting with an existing project means using an existing design, where someone else has already made many/most of the difficult decisions.
10Xing code without caring about design/UX/DX is trivial. Literally anybody with a token budget can do it. But they probably won't ship a good project. Not with current frontier models.
[1]: design has always been hard. But now it's even more difficult because of code veloocity and because LLMs are happier to work with bad code than humans. It's never been easier to go deep into rabbit holes without noticing a single issue.
Pretty much every example in this thread is "I forked some existing project and made changes I like".
The main thing they dont realize is:
1. These are mostly superficial changes.
2. The only thing they 10xed is their ability to "start" on something.
3. They have not produced actual value. Their project/fork is just a version they think they prefer. But It is less maintainable, and less robust/useful for others due to its specificity.
My observations is that consistently these arguments are made by: inexperienced devs who simply dont understand what it takes to produce value in the real world.
LLMs CAN 10x you (in very specific areas like prototyping), IF you understand how to deliver this value, but that is the hard part. It has always been the hard part.
I have a programming language project: lone lisp. It's on GitHub. I asked Claude to analyze the commit history before and after AI and the result was: with AI I'm committing around 8x faster than before. Lone experienced a literal explosion of features, improvements and fixes after I subscribed to Claude.
And this is the project I care most about. I review every single line of code the AI outputs. I push back on everything it does. I reword every commit message. I make every effort to understand how everything works before committing it to master. I cook branches for days and I don't merge until I think it's perfect.
Still gave me an ~8x improvement.
The latest development: shaped objects, like Self and V8. I asked Claude about it and it just implemented it in like 10 minutes. Boom, instant ~20% speed improvement. I read the code and it turned out to be almost obnoxiously simple. It basically converts hash tables into arrays internally, and deoptimizes back to a hash table if anyone deletes keys from it. I'm still reeling from the sheer absurdity of it.
I can describe private efforts about a couple recent projects that made me finally believe that Claude Code can actually be a 10x multiplier on certain work.
We decided to integrate our SaaS into Microsoft Business Central and NetSuite as plugins into those systems. BC has its own programming language, called AL, that has a lot of idiosyncrasies from any other language I've worked with. And NetSuite plugins are written in SuiteScript, which is a custom JS runtime with a ton of APIs to learn.
In the "before", it would've taken 5 developers a year or more to build those integrations. I did both by myself in well under a year. Thank you Claude.
I can state one thing that I'm sure a lot of people connect with, and I don't know if this is 10x, probably not.
I've always been a backend engineer, never front end. And almost every team I've been on has lacked any front end skills at all, so all our tools end up being a mash of scripts, maybe sometimes an API.
Now we are all front end engineers creating UIs for things we could never do before, and this starts API first development, so the CLI + UI are just calling APIs. Nothing new here, but this used to be what teams do, now a single person does it.
It would not have taken you long to learn frontend if you wanted to. Now you can use AI to generate it but you don't understand any of the generated code.
It's often much more than 10x, because AI makes things so much faster and easier that we are now doing many things we wouldn't have bothered to do at all before. And there's no reason to believe we're near the finish line yet as to how good LLMs can get.
It's a 10x in areas where I'm not very good/experimented at. Or perhaps even more. For example I'm mostly a backend developer, I used to be a full stack dev a long time ago so I know how to make front-end but my knowledge there is outdated, I've forgotten half of it, it takes me time to get back to it. I'm also not good at creating a web UI so in the past I was using frameworks like Bootstrap or Foundation, leading to sites that looked good but very generic.
Now with AI, I can easily create a nice looking front-heavy web app.
> 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.
It's always worth remembering that code is a liability while software is the asset. Wiring 10x more code is accumulating 10x the liability, with the often unjustified belief that the software is 10x as valuable. It might be, but that's what the market is for.
I highly doubt that, unless you are talking about something much more specific like test cases.
There is certainly no sign of these companies becoming more productive.
Most of the software that "billions" of humans are relying from any of these companies are things like Microsoft Windows, Microsoft Office, Google Search, FaceBook, that were not written, or rewritten, in last 1-2 years, so were certainly not written by AI.
Well, not exactly productivity, but yes there are some symptoms of a reduction in quality from some companies. I was about to say not the three mentioned, but GitHub (owned by Microsoft) is certainly one, and Amazon seems to be having an uptick in outages that are anecdotally linked to use of AI. Anthropic, who we know are using AI a lot internally also have reliability problems.
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.
I'm not sure those are great examples. Why not just consider normal apps?
I don't think we'll see AAA game velocity change until asset generation progresses quite a bit, not to mention stuff like rigging. Even then, there's still a layer between code and engine where you have to wire everything together which an LLM will struggle with.
Replacing some old COBOL is probably more of a management decision based on appetite for change and politics rather than development speed.
Aren't there some measurable things like github repo creation, PRs, app store additions, etc. that can be correlated to LLM adoption? Didn't Show HN have to get throttled after LLMs arrived?
I think your answer is the reason why. LLM performance is fine when applied to everything they can do.
Take LLM out that safe space and suddenly they are no silver bullet, in fact they are unless.
So of course those making the 10x claim mean in the safe space where LLM can handle all activities required. You can’t have it both ways 10x and difficult and confusing tasks for LLMs.
Right, I get that. I'm just saying it seems wrong to throw up minority examples. Nobody is pumping out AAA games at speed with LLMs, nor is anyone claiming to do so. There will likely always be some areas where LLMs are bad or useless.
How many people are writing crud apps using mainstream languages vs COBOL though? You don't need 100% silver bullet 1-shot everything, just to recognize the signals that for many use cases, there's a significant shift happening. The safe space is expanding and velocity is increasing.
Definitely the safe space is expanding but how fragile and expensive is this expansion?
AI requires a larger amount of fragile resources to work as opposed to an editor, keyboard and a human.
It some sense it’s a bit like the bitcoin revolution that slowed down once transaction times ballooned out. And blockchains didn’t replace databases as expected. Probably for very good reasons: resources required v. results delivered.
I personally agree that AI is great technology for some great new tools. But we still haven’t found its limits: cost v. results. That happened with bitcoins and blockchains is still outstanding for AIs.
The resources are definitely an issue. I'm still sucking from the corporate teat, but my hope is that by the time the frontier race slows down and they tighten the screws too much, the local models will be good enough. It sounds like recent local models are already getting pretty good for normal duties, but honestly, if it all goes away tomorrow, that's fine too. I'll go back to the old ways. I'd miss the informational capabilities more than the coding capabilities, but I'm no stranger to man pages.
As an aside, I still think there's a place for blockchains. They're not a good replacement for a typical database, but I think some of the concepts are useful. The idea of distributed ledgers and smart contracts have a lot of applications IMHO, particularly in government. The traceability of transactions seems like a great fit to enable transparency of government spending. Of course, governments are allergic to that idea for the usual reasons, but it's still a nice idea. Distributed computing is hard, and it's a shame that blockchains were usurped by crypto bro scams. I'm still rooting for the folks who are trying to push distributed technology forward though.
I feel like that’s tied to the hardware the companies are using. All the banks I’ve worked at run z/OS mainframes, can they even deploy modern run of the mill Go/Python/Rust code or is getting off COBOL reliant on hardware changes?
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.
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.
I agree with this sentiment but I think LLMs are really close to the Brooks idea of a silver bullet.
I don't know if, overall, it's a 10x improvement or 6x or 14x but it's a serious contender. Part of it is the LLMs are very uneven in their performance across domains. If all I build is simple landing pages, it might be a 100x improvement. If I work on more complex, proprietary work where there aren't great examples in the training data then it might be a 10% improvement (it helps me write better comments or something)
All available evidence points to it being an incremental improvement at best. Higher claims are attributable to the psychological effect of the AI sycophancy problem which erases the Dunning-Kruger effect and makes even experts extremely overconfident.
You still have to read the output of your LLM. Learning by reading alone and not doing is not nearly as effective.
"claude, connect to a k8s pod in prod and grab a 30s cpu profile, analyze and create a performance test locally for the top outlier, verify your fix and create a PR"
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.
90% of my my experience has always been dealing with large-ish corporate systems.
I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
>90% of my my experience has always been dealing with large-ish corporate systems. I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
>In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
>So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
I've always been in small-to-midsized US corporate where Oracle etc were generally "no way are we gonna spend that much" but if someone can hack a decent thing together and run it on a spare server... that got traction 10-20 years ago.
I'm curious if those large corporations are more homegrown-code-by-AI-friendly than they would've been towards homegrown-Rails-app? A lot of the same potential problems exist.
In particular if that steady-state requires 4 to 40GB blob of binary code to be installed or an internet connection to an AI SaaS provider and a credit card.
I remember when coding was free as in beer and freedom!
It's okay. In the near future people will not own a computer of significant capability at all, so it's not like they'd even be able to develop without a cloud connection in the first place.
And, for the most part, they will be okay with this. Gen Alpha or Beta will tell each other how morally wrong it is to expect for everyone to own a computer or even a smartphone, citing the environmental impacts, slaves mining coltan, and the toxic emotional effects upon people who grew up in the Social Media Dark Ages. Much like present-day Hackernews feels about personal automobile ownership.
Ah, Fails. "Before we made x improvement, the app had to restart 400x a day, now it's only 10x!"
For all the complaining we do about "enshittification", we (Hackernews, the broader industry, whatever), are perfectly willing to pay the price of stability and performance to get a little development speed. That's one prong of how enshittification happens. "I can make compromises in the quality of my product because time to market is the one thing, the only thing that matters in this move-fast-break-things economy—and pass my savings on to the customer (in the form of hidden costs)!"
Most of my work has been in core infra at large companies. Having the code written faster does not change rollout velocity all that much... It does help with signals and idiot proofing on bugs but when things break and cost real (very real) dollars AI is not an explanation. In that instance, its not even close. Development might be 10-20 percent of the actual work to get a change out.
To an extent it can help reduce wasteful steps. But there's nothing AI can do that can make it less irresponsible to reduce soak times, stagger the release across many environments, etc.
Code is always easy to multiply fruitlessly, always has been.
Features are harder to show the limits of, but have you ever had a client or boss who didn't know what they wanted, they just kept asking for stuff? 100 sequential tickets to change the contrast of some button can be closed in record time, but the final impact is still just the final one of the sequence.
Or have you experienced bike-shedding* from coworkers in meetings? It doesn't matter what metaphorical colour the metaphorical bike shed gets painted.
Or, as a user, had a mandatory update that either didn't seem to do anything at all, or worse moved things in the UX around so you couldn't find features you actually did use? Something I get with many apps and operating systems; I'd say MacOS's UX peaked back when versions were named after cats. Non-UX stuff got better since then, but the UX (even the creation of SwiftUI as an attempt to replace UIKit and AppKit) feels like it was CV-driven development, not something that benefits me as a user.
You can add a lot of features and close a lot of tickets while adding zero-to-negative business value. When code was expensive, that cost could be used directly as a reason to say "let's delay this"; now you have to explain more directly to the boss or the client why they're asking for an actively bad thing instead of it being a replacement of an expensive gamble with a cheap gamble. This is not something most of us are trained to do well, I think. Worse, even those of us who are skilled at that kind of client interactions, the fact of code suddenly being cheap means that many of us have mis-trained instincts on what's actually important, in exactly the way that those customers and bosses should be suspicious of.
>Or, as a user, had a mandatory update that either didn't seem to do anything at all, or worse moved things in the UX around so you couldn't find features you actually did use? Something I get with many apps and operating systems; I'd say MacOS's UX peaked back when versions were named after cats. Non-UX stuff got better since then, but the UX (even the creation of SwiftUI as an attempt to replace UIKit and AppKit) feels like it was CV-driven development, not something that benefits me as a user.
I can't name a single new feature Android has gained since version 13, or at least one that I am aware I use. I have a large handful of performance issues, feature removals, and UI annoyances that have been introduced, though.
At Microsoft I wrote a feature to support customer setting a preferred AZ for their database. Took a couple weeks as a side project. Nearly 2 years later it reached customers
Writing code is a part (sometimes a big part, sometimes not) of delivering software to production. The overall system throughput is the interesting thing to look at.
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.
> 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.
One of the most important graphs in economics shows a divergence between increases in labor productivity and worker take home share since at least the 1970s
> If you’re 10x more productive, someone is willing to pay you 10x as much as they were last year, because you’re producing 10x as much value as before.
Has your salary increased 10x?
That's too simplistic because the rest of the economy isn't static. Everyone is getting access to AI tooling, if the whole field gets a productivity increase then the baseline changes, you don't just become 10x more valuable. The previous work is now way less valuable than it was before. It's also not clear to me that the productivity gains from AI convert 1:1 into profit gains
Salary stays the same. A bunch of others are fired. You’re expected to produce their level of output as well as your own. After all, you’re 10x more productive now?
AI is certainly able to increase coding speed, especially for experienced engineers who can design the analytical parts themselves (data structures, interfaces, invariants, and process), but in large projects and/or organizations, queuing theory (especially as understood by lean development practitioners like Don Reinertsen) is going to be nasty.
Lean development theory teaches us that in a multi-workstream, multi-stage development process, developers should be kept at roughly 65-75% utilization. Otherwise, contra-intuitively, work queue lengths increase exponentially the closer utilization gets to 100%. The reason is that slack in the system absorbs and smooths perturbations and variability, which are inevitable.
Furthermore, underutilization is also highly comparable to stock market options: their value increases as variability increases. Slack enables quick pivots with less advance notice. It builds continuous responsiveness into the system. And as the Agile Manifesto tells us, excellent software development is more characterized by the ability to respond to change than the mere ability to follow a plan. Customers appreciate responsiveness from software vendors; it builds trust, which is increasing in value all the more with the rise of AI.
But AI-driven development threatens to increase, not decrease individual engineer utilization. More is expected, more is possible, and frankly, once you learn how to guardrail the AI and give it no trust to design well analytically, the speed a senior engineer can achieve while writing great code with AI assistance often feels intoxicating.
I think we're going to go through a whole new spat of hard, counterintuitive lessons similar to those many 1960s and 70s developers like Fred Brooks and his IBM team learned the hard way.
Oh spare me! Anyone can "output" 10x more code. Fred knew you could slap 10x more people on a team and "output" 10x more code.
What this article explains is why despite your feelings of untouchable success, on average the experience of using software just keeps getting worse and worse and worse, making this the worst era for software quality that I've ever lived through
Didn't we already do this with every company looking to hire "rockstar programmers"? I don't recall that that ended well.
This seems like somewhat of a mischaracterization. He contrasted improvements in software with improvements in hardware, saying we'd never have something like a Moore's law for software where performance doubled or cost halved equally rapidly. Churning out software faster doesn't mean it's any better.
We also seem to fall into these ruts of not understanding what is meant by labor productivity. When an economist is presenting the common outputs / inputs measure, they don't mean raw quantity of output. They're talking about the value added by outputs divided by the value of inputs. Churning out software faster that doesn't earn anybody additional revenue is not making us more productive. It's disheartening that even c-suites with business education don't seem to understand this. That's not to say there is no productivity gain. Plenty of AI-adjacent hyperscalers are seeing ridiculous growth right now, but no non-startup is seeing revenue 10x what it was the year before, not even NVIDIA.
A lot of this is just basic diminishing marginal utility. There is only so much value to be added. Software is usually either a semi-automated controller or human decision making augmenter to some kind of physical manufacturing process, or entertainment, when we talk about ultimately delivering value. Everything else is an intermediate input. We can only be so entertained. For physical goods, we have food, space, clothing seemingly at a sufficient level to satisfy just about everyone, with the reasons for value not being maximized having to do with distribution. Unless your software manages to solve borders, bigotry, cultural incompatibility, poverty, mental illess, physical illness, violence, I'm not sure what the other big rocks are. Software can absolutely be a key part of infrastructure to facilitate distribution. That's exactly what the Internet is, along with all the backend business and logistics systems out there in existence. But without hitting the true big rocks, where is the 10x value supposed to come from? We're talking incremental gains simply because we're not in the dark ages any more and incremental gains are all that's there. Short of Star Trek style replicators and transporters, I'm not sure what could realistically multiply global value by 10.
Without the value, then sure, you may be churning out 10 times as many discrete projects used by at least one person, or 10 times as many lines of code, but that was never the point. Your personalized notes and grocery ordering apps you share with your wife might excite you for a few weeks, but I can assure you they aren't going to revolutionize your life.
I've been thinking about this and have wanted to discuss it with people.
I think the 10x thing has been broken, but I don't think it's because the premise of "No Silver Bullet" was false - I think it's because LLMs have the ability to navigate some of the _essential_ complexity of problems.
I don't think anyone has really wrestled with the implications of that yet - we've started talking about "deskilling" and "congnitive debt" but mostly in the context of "programmers are going to forget how to structure code - how to use the syntax of their languages, etc et etc)." I'm not worried about that as it's the same sort of thing we've seen for decades - compilers, higher-order languages, better abstracts, etc etc etc.
The fact that LLMs are able to wrestle with essential complexity means that using them is going to push us further and further from the actual problems we're trying to solve. Right now, it's the wrestling with problems that helps us understand what those problems are. As our organizations adopt LLMs that are able to take on _those_ problems - that is, customer problems, not problems of data, scaling, and so forth - will we hit a brick wall where we lose that understanding? Where we keep shipping stuff but it gets further and further from what our customers need? How do we avoid that?
It's mostly slop. And sometimes slop is good enough. But Fred Brooks was talking about actual software systems, not a shop front for an amateur wine importer.
The premise of "no silver bullet" is wrong (LLM just made it clear, but it has always been wrong).
The premise is that the software development had been mostly "essential complexity" rather than "accidental complexity." But I think anyone who worked as SE in the past decade would have found the opposite is true.
It's not only that software development is full of accidental complexity. Programmers (and the decision makers above them) have always been actively creating accidental complexity. Making a GUI program hasn't gotten easier since Visual Basic. In fact for each JavaScript framework and technique that wraps around DOM render engine, it has got harder over years. Until LLMs made it easier again (by creating a permanent dependency on LLMs. If you intend to edit the code manually afterwards, it became even harder!)
A weaker claim is that maybe there's no single silver bullet but there have been many bronze bullets that add up to more than a single silver bullet. I readily endorse at least that and think it's rather easy to justify.
"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
When I was young, in my teens, I already knew a bit about programming but of course nothing about the industry.
These beautiful metaphors by Brooks, from books like inmates running the asylum, etc - they made me romanticize the industry I had no idea about.
Now, about 20 years later, I wonder to which extent they influenced me to take the path I've taken. Because when I began, it wasn't lucrative or cool in the slightest.
It's funny, I also read the book as a teen, and I came away from it amazed that IBM was dedicating entire team members to inter-/extra-team communication.
Before that I hadn't even considered how necessary a product manager or project manager were in software development.
But it was the "No Silver Bullet" essay added as a bonus in my copy that I think about the most. "Never again will we see a 10x productivity increase in a decade", this is self-evident now but must have been crushing to people who had experienced the first compilers, the first high-level languages, the first interactive terminals, and waited for the next incredible leap.
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 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.
Ah, maybe this is what you think he would take issue with? Fair enough. Perhaps I should have said:
>I always look to staff up as much as is economically and organizationally optimal, to exploit all genuine parallelism opportunities, being careful not to overstaff.
You mileage may vary but in my (unfortunate) experience, stuffing up by any other reason than grassroots "we need more hands" raised by engineers themselves typically backfires. Teams that are constrained by people resources often find creative ways to work smarter. Teams that have an abundance of labor, often end up working unnecessarily harder, duplicating work, reinventing the wheel, not solving the right problems, etc. See also intensive vs extensive development.
"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.
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.
Same, I always misread the title like this when it comes up and it amuses me for a while, since it sounds like it could be a book written by Franz Kafka.
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.
Dario Amodei said in the most recent interview with Dwarkesh that Anthropic currently gets achieves an increase of around 20-30% coding productivity, which tracks with my experience. What do you do to reap orders of magnitude more?
Also, how much more money do you make? Or are you working less?
I can clearly see, and feel, Dario's associates' "increased productivity" in their Claude Code/Chat/Cowork desktop product...
So many updates, pretty much daily, so many tweaks to the interface. Sometimes the tweaks are a bit dumb, sometimes completely trivial, and other times they just undo what they did previously.
My favorite examples of their newfound velocity:
1. When there is a nice feature that was easily discovered, and then it was gone...
2. When the "customize" section moves around to random places in settings, or entirely out of it
Special mention to their scatterbrained keyboard shortcuts strategy
> What do you do to reap orders of magnitude more?
I don't know what Dario Amodei says, does, how Anthropic is run or structured, or what kind of people work there, so I can't comment on that.
I do know about myself, though. The increase is very real, measured by the number of (Linear) issues resolved. No, I haven't changed how I open or close those issues, I've been using the system for years. During the first three months of 2026 I went through 12x more issues per month than during past years.
But I guess I am not an "average programmer": 35 years of experience means I can work with AI as I would with a small (but very skilled) team. I can architect systems, notice unnecessary complexity, and intuitively choose solutions that are more maintainable. And I am a single-person company, with no managers to report to, KPIs to achieve, presentations to make, etc.
I do not make "more money". It's a mature SaaS. Changes in revenue are over the long term, on a scale of years more than months, and implementing features is no longer enough: marketing is needed for more growth.
But, to be honest, I am tired of defending myself this way. It's not the first time I post this metric, I thought people would find it an interesting data point. Instead, I get downvoted (see my comment above which currently sits at -1 in spite of being objective and factual), and then get plenty of responses asking me to defend my statements.
Come to think of it, I'd rather not convince people about AI increasing productivity so much. I'm not really sure why I bother to post here anymore. I'd rather have everyone (including my competition) believe whatever they want to believe and not use AI.
Sounds like a blog post on your experience would be very interesting.
Like a sibling comment - I'm also curious about what that 12x means for you and your business - same revenue at fewer hours? More revenue, fewer hours? Etc.
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.”
Nine women can already have babies in parallel. That is, nine women cannot have a baby in one month, but nine women can have nine babies in nine months.
14,000 women will produce a baby in a month, because that is how many, in average, it would take for one of them to be 8 months pregnant. Of course, if you need one tomorrow, you can go over to the maternity ward and steal someone's that was just delivered.
It would probably be more practical to make old age less expensive than to inject more people into the bottom of the demographic pyramid. Those young people eventually get old too. I am looking forward to my sentient robot caretaker:
Oddly from your comment I can't quite tell which end of the political spectrum you're on. I think I agree with you, but I'm not sure until I know which team you're on.
Life was becoming increasingly more affordable, but that stopped being the case years ago. It is now declining. I would like it to either stay the same as it was years ago or start increasing again.
Sure but it’s still more affordable than it was for the vast majority of our ancestors, and they still had kids, so it’s not an explanation for declining TFR in developed countries.
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.
Indeed a lot of things have changed. A worthwhile exercise is to read the book, contemplate how things have changed, and try to map lessons from the book onto modern technology and organizational practices. A LOT of the core principles are still relevant IMO, even if many of the implementation details are not.
You should tell these AI companies and we could have AGI tomorrow if only they would throw a few thousand more men on the project.
Or perhaps today's men are coding agents? You can spin up as many agents as you care to, so asymptotically any project should be completable in zero time, regardless of complexity.
>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.
If only it wasn't a dichotomy!
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.
This is the kind of practice I was going to get an insight into.
For your conceptual-model.md, do you find natural language is sufficient? Do you use pseudo code, Entity Relationship modeling, or anything like that?
And how do you go about round-tripping it from the source code, keeping it up to say with any changes, and yet at the right later of abstraction?
> 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.
[flagged]
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.
I have a harness for Claude Code "hooks" (https://code.claude.com/docs/en/hooks) which in my case execute a Go tool in a separate project which runs changes made by claude through a validator with various rules that can be defined (regex, semgrep, etc.). They can warn claude or they can block changes outright.
When I find claude is using tools or approaches that I have replaced with more specific ones, I ask claude to add a hook to prevent doing this in the future and point it to the instructions of what to do instead.
And of course I wrapped all that up in a Skill so it knows what approaches to take to add things to hooks.
It becomes fairly trivial to incrementally stop it making repeated mistakes like this.
Is it open-source/ can you share it?
You may want to try out pi-agent and create custom extensions instead.
Then codify this behavior into a process which automatically gets run through.
I.e. $repo/origin as bare repo, then prompt to create a shell script which creates the worktree and cds into it, running the script you mentioned, instantiating pi in it. Potentially define explicit phases for your workflow and show the phase in the UI - and quality gates for transitions. Eg force the implment to finalize phase to only happen if all tests succeeded. Potentially add multiple review phases here too, with different prompts. This progressively gets rid of more and more inconsistencies.
Still not a perfect solution, but on average I've had less and less to manually address with that workflow. Albeit at cost of tokens (multiple reviews phases obviously ingest all changes multiple time)
Pi-agents extensibility is just a lot better then the other harnesses, but you could obviously also just introduce a different orchestrator to do the same. For me, pi-agent was just the least amount of effort necessary to get it going.
I've had that happen before too, and I just added a line to CLAUDE.md or AGENTS.md something like (adapted to your example):
Claude has gotten better about following CLAUDE.md over the last year (it was pretty laughably bad at it previously).I have that both in the skill and in CLAUDE.md but it's not reliable - and polluting CLAUDE.md with task specific instructions kind of sucks.
I have the same issue too, 99% of the it's for two reasons
1) It tried the tool, but for some reason it worked unexpectedly and Claude is VERY good at working around problems, it won't just stop.
2) Context got too long so those rules were "forgotten"
So why not fetch the ticket deterministically yourself as part of "staging" all the information that Claude will need? I.e. if Claude can't be relied upon to do something the way you want it done, take that task away from it, perform it some other way, and feed the results back to Claude.
I don't use AI much so I don't know if this is reasonable.
It only released just over a year ago…
I rebuilt an app I found in rust and extended it in a bunch of ways that I use everyday for this use case and it works flawlessly if this is any help: https://github.com/dchuk/jarkdown-rs
Use Codex. It benchmarks much better at instruction following.
On a local model, with open code, when I wrote a specific javascript way to run sql queries because bash and psql were error prone, what I did was when I saw it make a mistake, I told it in passive agressive tones something like: "please edit AGENTS.md to detail how to use the query.js tool to run a query and to never use psql"; I did this two times until it stopped wanting to use psql.
It seems like if you write the docs yourself that's not leveraging the probability that the model itself knows the anti-context guard rail that best prevents it from grabbing its average tool use.
> 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.
I do something similar, but tell the agent to write a recipe into a justfile. Then it can run `just` and get a self-documenting list of all the tooling for the project (just build, just test, etc.)
I do exactly the same thing
I had a similar experience recently. I had a huge Swagger JSON file that would waste too many tokens if added directly to the context, so I told the agent in memory to use jq to retrieve what it needs when it wants to check this document. This saved a lot of cost.
"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?
10x what? 10x revenue? 10x features shipped? Whats the measure, is it 10x speed of dev like parent comment? Because an unqualified 10x could mean 10x SLOC which is trivial with an agent but has negative value.
Assuming 10x on the speed of dev, Is the vscode repo a decent example? Recently they've been all in on AI augmented development so i'm thinking they'd be a reasonable subject?
How do you isolate out what counts as the "development" part of their delivery cycle (is that the dev inner loop, does that show up in frequency of commits then?) to measure it and see if it's running 10x?
https://github.com/microsoft/vscode/graphs/contributors?from...
Guarantee it’s the same story I get from all my friends/co workers who are now 10x… they are 10 times faster at starting random projects that get to 80% done that they can’t finish, so they immediately move on to the next project because their velocity is so high
From a software quality or software engineering POV --> this is clearly not building durable value, not scalable, etc. So I'd agree with you there.
But from the POV of say, a young startup company looking for PMF and navigating the ambiguities involved with trying to figure out what is the "right thing" to build that will appeal/delight/convince-people-to-pay --> being 10X faster at shipping 80% done projects, is actually incredibly, unfathomably valuable of a superpower. And it is also rationally the "right thing" to do, to make lots of cheap bets and fail/learn fast.
I find that many folks on my team (I am a manager/leader of small-to-mid size eng org), struggle with accepting the nuances of knowing the difference between different projects (where same team may need to do both kinds of work, all the time and in parallel):
- "Hey, the company needs, and you and I both agree, that this situation calls for building/renovating a skyscraper --> please design a fucking strong/safe/reliable skyscraper and don't take any shortcuts, this requires 'real' engineering"
- Vs, "Hey, the company isn't sure what it needs, and neither you nor I know any better either, so let's try a bunch of different shacks/sheds/treehouses/whatever, until we find something that has traction / makes us money (and it's okay if the shed collapses -- so long as the business knows this too, that it wasn't meant to be a load-bearing, skyscraper-esque thing anyways)"
I won't get into the rabbit hole of talking about dealing with bad business leaders, who want a skyscraper but expect to pay the price of a shack/shed. Let's assume that we are talking about the type of companies (maybe the minority) that are reasonable enough to know and acknowledge the difference. Then what is the game-theoretic/rational thing for them to do, and how does this 10X idea express itself? That's where my argument is coming from.
Its 10x code generation with .5x quality at best and all other parts of the SDLC are at 1.x or worse.
AI is not delivering 10x shareholder value, anywhere. Software developers have quite the level of hubris about how important they are to companies. Yes our work is very complex and takes a certain mindset to do it well. It takes a lot of other roles to have a successful business, many of those roles will use AI to help draft slide decks, emails, etc. and that's the limit for them.
Look at recent companies doing layoffs claiming its because of AI, like CloudFlare and Coinbase, do their reported financials paint the picture that they are crushing it with AI? No, its net losses into the $100's of millions.
> AI is not delivering 10x shareholder value, anywhere.
A bit facetious, but I'd expect Nvidia and the like providing the "AI equipment" to have a 10× share value at least…
As always, the real money in a gold rush goes to the people selling shovels.
It's more like ∞x (or N/Ax if you prefer) because the majority of the projects I did with LLM agents wouldn't have existed without them, because I would've never found enough time to work on them.
One of the latest things I made with Claude was a tool that allowed me to move a bunch of very low traffic Cloud Run services to a single VPS without losing any of the Cloud Run benefits such as easy Docker-based deployment and automatic certificate provisioning. I thought about making something like that for quite some time, and Claude finally made it possible, which makes me quite happy.
The fun thing here is that no other soul genuinely cares about it, or any other code I might publish. The code, especially AI generated, is so cheap that if anyone wants to repeat my steps to get rid of Cloud Run services, they will probably vibe-code their own tool instead of figuring out how to use mine, just like I did that instead of spending time on learning Dokku or similar solutions.
So, yes, 10x and more, but no one cares about the result, which makes the whole 10x measurement less useful.
There have been plenty of libraries/tools that got people from "I would like to do foo" to "oh, this tool makes foo possible in under 10 hours, I should start working on foo" in the past. LLMs have done this for many foos, which is great.
But I'm with hansvm - I haven't actually seen anyone plausibly maintain 10x. 10x is different from getting people past their activation cost.
>or N/Ax if you prefer
It's not a matter of preference
The incredulity at 10x claims is often unearned because how much do these skeptics actually notice and appreciate the depth of work of ten developers collaborating on something (if not their own org)? Dev output slips by quietly. There are reams of unnoticed projects even at the scale of a life’s work.
This doesn't pass a sniff test at any small organization. And wouldn't these devs see this 10x claim themselves?
I'm assuming the devs are seeing 10x code generation and equating that to the improvement.
It's when they practically ignore the rabbit holes where it's suspect. I'm definitely seeing speed ups. I troubleshot a linux system yesterday with minimal effort using a local llm. It likely would have taken me a few hours to locate all the docs & testing procedures. the llm did it with only a few prompts. To ensure it did it correctly, I had to interrogate it a few times before letting it proceed.
Humans make really bad scientists, and it takes a lot of effort to properly catalog and provide statistics for these things.
There is an improvement, but I doubt any random dev can give a real estimate since before LLMs they couldnt really give you a real estimate anyway. I do know when I encounter a bug now, debugging is almost immediately possible.
My small organization is noticing output increasing. We're excited about it. I’m not sure about 10x… Like others have mentioned, it’s difficult because you have to measure different workloads.
I build things I never would have. My tooling is better and more robust than ever. I verify and test my work better than ever. I fix more bugs than I used to simply because no one needs to care if it fits into a cycle. I explore and solve more problems in more parts of the application, even if I don’t write code. I take better care of our infrastructure. Performance goes up, bugs go down, AWS resources scale back, costs go down. I’ve paid for my AI usage in scaled back resources several times over at this point.
It might not be 10x but it’s a significant multiple.
I am building a better interface for managing KNX systems than the ETS6 software. Code is here: https://github.com/jgrahamc/koolenex
1. I would not have attempted this without AI assistance because it's a big project.
2. I have built a functional program that I am able to use for real work in a handful of weeks, working part time on this (like literally a few hours per day prompting Claude and Kimi).
3. Had I decided to do this without AI assistance it would have been months of work.
I suspect that the goalposts for AI-assisted coding will be moved the same way they've been moved for the Turing Test.
The Turing Test used to matter until it didn't (does anyone even talk about it? was there a big news conference when it was solved?). Likewise every time it becomes easier to ship software, the bar will be pushed higher by sceptics. Ultimately the gatekeeping is going to become meaningless as software becomes "too cheap to meter".
Here is a public project.
https://github.com/KeibiSoft/KeibiDrop
It took me 2 years ago around 2k hours to build a cross platform FUSE vault, without using AI assisted tools.
The pain was debugging through logs and system traces. And understanding how things work.
Now managed to ship this one much faster, as an after hours project. Started it in may 2025, and around end of November 2025 started using claude on it.
Just by dumping logs into claude, and explaining the attack vector for the problems, saved me the FML moments of grindings walls of syscalls on 3 platforms.
I would say much easier to progress, and ship with the same rigour, minimize my time, focus and brain power involvement such that I can put the energy somewhere else.
Yep, the real strength of AI is less in replacing engineering skills, it's more in slashing all the time we spend not using those skills and doing low level research and data correlation tasks instead. Which isn't to say that those tasks aren't valuable in their own way, but in terms of raw output...
I long for the day when they will supervise CI/CD systems.
Trying to fix syntax errors in strong interpolation on a 5-minute-delay loop is hell.
Just create a skill for it -> I call mine `babysit`. It spins up a subagent that polls it every x minutes and auto-fixes it until it's green. I already continue with the next task while it does that in the background
I do this with our AI PR review checks. We have AI review every PR and commits to PRs... which can cause long running loops of commit<>fix.
So my agent just listens for green checks and no PR comments and loops until those conditions are met.
About 30% of our AI PR review checks are flawed at a fundamental level, based on poor comprehension of the whole. If I told the AI "fix everything and keep going until it's green" I would be terrified of the result.
I disbelieve this works in anything other than a toy codebase (or an incredibly fine-grained microservice).
The 70% is amazing! But a 30% failure rate requires intense supervision.
It is possible. I tell to use cli app, and for the agent to ad timer and check the status once in a while. Especially if there is something with a long wait. Also if it can run some validators/ same tools locally, would be much faster.
Might tend to deviate and waste time, needs guiding once in a while, and to check what is it spewing out, point it in the correct direction.
I treat the low level tasks as building blocks. You need a grasp and understanding of what is possible with them, but you do not need to remember the exact byte order and syntax. I think the idea is you should structure your workflow in a deterministic way, and just use Claude/ LLM as the interface. It is much easier and enjoyable to use high level language, where you give pointers to building blocks/ directions/ say hard no when you understand things deviate.
If I had to output the code myself, would take around 8 hours of constant writing to get around 1k LoC of code. For FUSE level tricky stuff, I might need to spend 3 weeks for 10 LoC. Very easy to burnout and build pain.
My friend who has never taken a programming class (or even touched an IDE before AFAIK) has now put a small app into production.
Complete frontend + backend + database.
Yes, it is an internal app, but it works and everyone loves it.
Does that count as an example?
(Also I absolutely expect him to need help at some point, but so far it has taken his project from absolutely impossible to 3 weeks of work in between work, renovating his house and being a dad for the first time so I was very impressed.)
These kind of things (internal tools created out of band of normal engineering practices by non-engineers) were amazing back when I did pentesting because the security was always the last consideration. That got harder when SaaS became preferable to rolling your own stuff for everything. Guess things are gonna get fun again for red teams lol
I agree with you.
The danger is not however that only that people write their own tools for calculations and capacity planning etc.
The danger is people make useful stuff that is very fine as long it is just an internal tool, but then someone add credentials to other systems so it can access and maybe even update stuff and it gets exposed to third parties etc and all of a sudden we have a major data breach going on.
My friend who has never taken a programming class did the same 10 years ago.
Obviously it was not the same s since models that could write programs were not available 10 years ago.
And if you just mean your friend taught himself programming on his own, well that is actually very cool, I did too back in the 90ies and so did many others here.
My point is that it is now possible to vibe code a full application from frontend to backend today and still not be able to understand a line of TypeScript or anything else.
20 years ago we had cpanel where people without programming knowledge can instantly deploy their own apps. Many people got millionaire doing that, I'd say proportionally probably way more than the people vibecoding solutions. This is not as revolutionary as we thought.
I'm building an open source Google Photos alternative. Have a look at my project and tell me if you think you could do all this at the same speed without an LLM: https://opennoodle.de
Direct github link: https://github.com/open-noodle/gallery
It doesn't completely blow away your argument, but you forked Immich and gave it to a LLM. Which is arguably slightly easier than starting from scratch.
Nothing wrong with forks though.
Sounds like you're nitpicking on whether or not LLMs make you faster by saying that working on existing code is easier than starting from scratch? I think you've missed the point.
No, they're saying that it was misleading. OP said "I'm building an open source Google Photos alternative" and surprisingly didn't say "based on Immich". This dramatically changes the evaluation of "open-noodle".
We're now in an era where LoC is easy and design is hard[1]. Starting with an existing project means using an existing design, where someone else has already made many/most of the difficult decisions.
10Xing code without caring about design/UX/DX is trivial. Literally anybody with a token budget can do it. But they probably won't ship a good project. Not with current frontier models.
[1]: design has always been hard. But now it's even more difficult because of code veloocity and because LLMs are happier to work with bad code than humans. It's never been easier to go deep into rabbit holes without noticing a single issue.
Pretty much every example in this thread is "I forked some existing project and made changes I like".
The main thing they dont realize is: 1. These are mostly superficial changes. 2. The only thing they 10xed is their ability to "start" on something. 3. They have not produced actual value. Their project/fork is just a version they think they prefer. But It is less maintainable, and less robust/useful for others due to its specificity.
My observations is that consistently these arguments are made by: inexperienced devs who simply dont understand what it takes to produce value in the real world.
LLMs CAN 10x you (in very specific areas like prototyping), IF you understand how to deliver this value, but that is the hard part. It has always been the hard part.
What are you debating here? I replied to a comment asking for examples of public work displaying that LLMs can 10x a human's output.
https://opennoodle.de/roadmap/
Look at what I built, these are not all simple designs.
Just that you're treating LoC and complexity as useful metrics, when these days those come for free. Or for $3 per Mtok, almost free.
I have a programming language project: lone lisp. It's on GitHub. I asked Claude to analyze the commit history before and after AI and the result was: with AI I'm committing around 8x faster than before. Lone experienced a literal explosion of features, improvements and fixes after I subscribed to Claude.
And this is the project I care most about. I review every single line of code the AI outputs. I push back on everything it does. I reword every commit message. I make every effort to understand how everything works before committing it to master. I cook branches for days and I don't merge until I think it's perfect.
Still gave me an ~8x improvement.
The latest development: shaped objects, like Self and V8. I asked Claude about it and it just implemented it in like 10 minutes. Boom, instant ~20% speed improvement. I read the code and it turned out to be almost obnoxiously simple. It basically converts hash tables into arrays internally, and deoptimizes back to a hash table if anyone deletes keys from it. I'm still reeling from the sheer absurdity of it.
It is worth to have a detailed look into the original essay and its arguments. My interpretation is https://smartmic.bearblog.dev/no-ai-silver-bullet/
I can describe private efforts about a couple recent projects that made me finally believe that Claude Code can actually be a 10x multiplier on certain work.
We decided to integrate our SaaS into Microsoft Business Central and NetSuite as plugins into those systems. BC has its own programming language, called AL, that has a lot of idiosyncrasies from any other language I've worked with. And NetSuite plugins are written in SuiteScript, which is a custom JS runtime with a ton of APIs to learn.
In the "before", it would've taken 5 developers a year or more to build those integrations. I did both by myself in well under a year. Thank you Claude.
I can state one thing that I'm sure a lot of people connect with, and I don't know if this is 10x, probably not.
I've always been a backend engineer, never front end. And almost every team I've been on has lacked any front end skills at all, so all our tools end up being a mash of scripts, maybe sometimes an API.
Now we are all front end engineers creating UIs for things we could never do before, and this starts API first development, so the CLI + UI are just calling APIs. Nothing new here, but this used to be what teams do, now a single person does it.
It would not have taken you long to learn frontend if you wanted to. Now you can use AI to generate it but you don't understand any of the generated code.
It's often much more than 10x, because AI makes things so much faster and easier that we are now doing many things we wouldn't have bothered to do at all before. And there's no reason to believe we're near the finish line yet as to how good LLMs can get.
It's a 10x in areas where I'm not very good/experimented at. Or perhaps even more. For example I'm mostly a backend developer, I used to be a full stack dev a long time ago so I know how to make front-end but my knowledge there is outdated, I've forgotten half of it, it takes me time to get back to it. I'm also not good at creating a web UI so in the past I was using frameworks like Bootstrap or Foundation, leading to sites that looked good but very generic.
Now with AI, I can easily create a nice looking front-heavy web app.
See this for example: https://github.com/erwan/sovereign-cards-database
I would never have bothered doing that without AI.
In areas I'm more familiar with, like back-end software, it's maybe more of the 2x or 3x.
There are some things around the corner. The best engineers aren't going 10x on Claude to build the next goofy SaaS app.
There is verifiably a flood of new projects. The selfhosted subreddit had to put in checks coz too many people were complaining about vibecoded slop.
iOS submissions are way up.
What I havent seen is existing open source people develop 10x faster.
Or, anything vibe coded get popular which wasnt just a gimmick.
Just a tsunami of slop.
> 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...
>https://techtrenches.dev/p/the-snake-that-ate-itself-what-cl...
Ugh, I've started having a visceral reaction to that typeface+card-layout+color-scheme combo; is the author using it ironically?
I browse on my desktop and all these mobile-optimized blog sites look like crap regardless of color schemes etc, so I try to ignore that.
It's always worth remembering that code is a liability while software is the asset. Wiring 10x more code is accumulating 10x the liability, with the often unjustified belief that the software is 10x as valuable. It might be, but that's what the market is for.
Software written in Big tech companies is probably written at 90% with AI.
Now you could claim that software from Google/Meta/Microsoft is useless, but billions of humans rely on it every day.
I highly doubt that, unless you are talking about something much more specific like test cases.
There is certainly no sign of these companies becoming more productive.
Most of the software that "billions" of humans are relying from any of these companies are things like Microsoft Windows, Microsoft Office, Google Search, FaceBook, that were not written, or rewritten, in last 1-2 years, so were certainly not written by AI.
> There is certainly no sign of these companies becoming more productive.
Oh, if you look at real signs, like uptime and number of bugs, they are becoming very clear.
But it's not clear how much of it is caused by the layoffs and how much is because of LLMs.
Well, not exactly productivity, but yes there are some symptoms of a reduction in quality from some companies. I was about to say not the three mentioned, but GitHub (owned by Microsoft) is certainly one, and Amazon seems to be having an uptick in outages that are anecdotally linked to use of AI. Anthropic, who we know are using AI a lot internally also have reliability problems.
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.
I'm not sure those are great examples. Why not just consider normal apps?
I don't think we'll see AAA game velocity change until asset generation progresses quite a bit, not to mention stuff like rigging. Even then, there's still a layer between code and engine where you have to wire everything together which an LLM will struggle with.
Replacing some old COBOL is probably more of a management decision based on appetite for change and politics rather than development speed.
Aren't there some measurable things like github repo creation, PRs, app store additions, etc. that can be correlated to LLM adoption? Didn't Show HN have to get throttled after LLMs arrived?
I think your answer is the reason why. LLM performance is fine when applied to everything they can do.
Take LLM out that safe space and suddenly they are no silver bullet, in fact they are unless.
So of course those making the 10x claim mean in the safe space where LLM can handle all activities required. You can’t have it both ways 10x and difficult and confusing tasks for LLMs.
Right, I get that. I'm just saying it seems wrong to throw up minority examples. Nobody is pumping out AAA games at speed with LLMs, nor is anyone claiming to do so. There will likely always be some areas where LLMs are bad or useless.
How many people are writing crud apps using mainstream languages vs COBOL though? You don't need 100% silver bullet 1-shot everything, just to recognize the signals that for many use cases, there's a significant shift happening. The safe space is expanding and velocity is increasing.
Definitely the safe space is expanding but how fragile and expensive is this expansion?
AI requires a larger amount of fragile resources to work as opposed to an editor, keyboard and a human.
It some sense it’s a bit like the bitcoin revolution that slowed down once transaction times ballooned out. And blockchains didn’t replace databases as expected. Probably for very good reasons: resources required v. results delivered.
I personally agree that AI is great technology for some great new tools. But we still haven’t found its limits: cost v. results. That happened with bitcoins and blockchains is still outstanding for AIs.
The resources are definitely an issue. I'm still sucking from the corporate teat, but my hope is that by the time the frontier race slows down and they tighten the screws too much, the local models will be good enough. It sounds like recent local models are already getting pretty good for normal duties, but honestly, if it all goes away tomorrow, that's fine too. I'll go back to the old ways. I'd miss the informational capabilities more than the coding capabilities, but I'm no stranger to man pages.
As an aside, I still think there's a place for blockchains. They're not a good replacement for a typical database, but I think some of the concepts are useful. The idea of distributed ledgers and smart contracts have a lot of applications IMHO, particularly in government. The traceability of transactions seems like a great fit to enable transparency of government spending. Of course, governments are allergic to that idea for the usual reasons, but it's still a nice idea. Distributed computing is hard, and it's a shame that blockchains were usurped by crypto bro scams. I'm still rooting for the folks who are trying to push distributed technology forward though.
I feel like that’s tied to the hardware the companies are using. All the banks I’ve worked at run z/OS mainframes, can they even deploy modern run of the mill Go/Python/Rust code or is getting off COBOL reliant on hardware changes?
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.
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.
> 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.
I agree with this sentiment but I think LLMs are really close to the Brooks idea of a silver bullet.
I don't know if, overall, it's a 10x improvement or 6x or 14x but it's a serious contender. Part of it is the LLMs are very uneven in their performance across domains. If all I build is simple landing pages, it might be a 100x improvement. If I work on more complex, proprietary work where there aren't great examples in the training data then it might be a 10% improvement (it helps me write better comments or something)
All available evidence points to it being an incremental improvement at best. Higher claims are attributable to the psychological effect of the AI sycophancy problem which erases the Dunning-Kruger effect and makes even experts extremely overconfident.
You still have to read the output of your LLM. Learning by reading alone and not doing is not nearly as effective.
"claude, connect to a k8s pod in prod and grab a 30s cpu profile, analyze and create a performance test locally for the top outlier, verify your fix and create a PR"
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.
90% of my my experience has always been dealing with large-ish corporate systems. I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
>90% of my my experience has always been dealing with large-ish corporate systems. I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
>In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
>So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
I've always been in small-to-midsized US corporate where Oracle etc were generally "no way are we gonna spend that much" but if someone can hack a decent thing together and run it on a spare server... that got traction 10-20 years ago.
I'm curious if those large corporations are more homegrown-code-by-AI-friendly than they would've been towards homegrown-Rails-app? A lot of the same potential problems exist.
In particular if that steady-state requires 4 to 40GB blob of binary code to be installed or an internet connection to an AI SaaS provider and a credit card.
I remember when coding was free as in beer and freedom!
It's okay. In the near future people will not own a computer of significant capability at all, so it's not like they'd even be able to develop without a cloud connection in the first place.
And, for the most part, they will be okay with this. Gen Alpha or Beta will tell each other how morally wrong it is to expect for everyone to own a computer or even a smartphone, citing the environmental impacts, slaves mining coltan, and the toxic emotional effects upon people who grew up in the Social Media Dark Ages. Much like present-day Hackernews feels about personal automobile ownership.
Ah, Fails. "Before we made x improvement, the app had to restart 400x a day, now it's only 10x!"
For all the complaining we do about "enshittification", we (Hackernews, the broader industry, whatever), are perfectly willing to pay the price of stability and performance to get a little development speed. That's one prong of how enshittification happens. "I can make compromises in the quality of my product because time to market is the one thing, the only thing that matters in this move-fast-break-things economy—and pass my savings on to the customer (in the form of hidden costs)!"
10x the amount of code or features =/= 10x the speed of software development.
And 20x the bugs.
I too can vastly increase my speed of development when I stop caring about the quality.
There are sizes of projects where it's true, and that size is growing.
Doesn’t necessarily but does sometimes unless you have a concrete alternative
How are you defining speed of software development?
How is that not the same thing?
Most of my work has been in core infra at large companies. Having the code written faster does not change rollout velocity all that much... It does help with signals and idiot proofing on bugs but when things break and cost real (very real) dollars AI is not an explanation. In that instance, its not even close. Development might be 10-20 percent of the actual work to get a change out.
AI can also speed up the release processes
To an extent it can help reduce wasteful steps. But there's nothing AI can do that can make it less irresponsible to reduce soak times, stagger the release across many environments, etc.
Code is always easy to multiply fruitlessly, always has been.
Features are harder to show the limits of, but have you ever had a client or boss who didn't know what they wanted, they just kept asking for stuff? 100 sequential tickets to change the contrast of some button can be closed in record time, but the final impact is still just the final one of the sequence.
Or have you experienced bike-shedding* from coworkers in meetings? It doesn't matter what metaphorical colour the metaphorical bike shed gets painted.
Or, as a user, had a mandatory update that either didn't seem to do anything at all, or worse moved things in the UX around so you couldn't find features you actually did use? Something I get with many apps and operating systems; I'd say MacOS's UX peaked back when versions were named after cats. Non-UX stuff got better since then, but the UX (even the creation of SwiftUI as an attempt to replace UIKit and AppKit) feels like it was CV-driven development, not something that benefits me as a user.
You can add a lot of features and close a lot of tickets while adding zero-to-negative business value. When code was expensive, that cost could be used directly as a reason to say "let's delay this"; now you have to explain more directly to the boss or the client why they're asking for an actively bad thing instead of it being a replacement of an expensive gamble with a cheap gamble. This is not something most of us are trained to do well, I think. Worse, even those of us who are skilled at that kind of client interactions, the fact of code suddenly being cheap means that many of us have mis-trained instincts on what's actually important, in exactly the way that those customers and bosses should be suspicious of.
* https://en.wikipedia.org/wiki/Law_of_triviality
>Or, as a user, had a mandatory update that either didn't seem to do anything at all, or worse moved things in the UX around so you couldn't find features you actually did use? Something I get with many apps and operating systems; I'd say MacOS's UX peaked back when versions were named after cats. Non-UX stuff got better since then, but the UX (even the creation of SwiftUI as an attempt to replace UIKit and AppKit) feels like it was CV-driven development, not something that benefits me as a user.
I can't name a single new feature Android has gained since version 13, or at least one that I am aware I use. I have a large handful of performance issues, feature removals, and UI annoyances that have been introduced, though.
"nine women can't have a baby in a month". Speed of software development is not pure output.
for certain monkeys, they think it is tho
there are entire C corps of monkeys out there
At Microsoft I wrote a feature to support customer setting a preferred AZ for their database. Took a couple weeks as a side project. Nearly 2 years later it reached customers
Extreme example, but exemplifies point
Writing code is a part (sometimes a big part, sometimes not) of delivering software to production. The overall system throughput is the interesting thing to look at.
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.
You mean the price of software, as well as the cost. The value (to the user) is the same if not more.
Unless the user just vibe-codes their own version.
Which is what I’m seeing at my job. All of these “afternoon vibe code” projects never actually get users because everyone just vibe-codes their own.
But GP statement is still true. You just cut out a middleman.
But “your software” isn’t bringing value anymore if people don’t use it.
The things that the software does might have value, but the marginal utility of your software is effectively 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.
> 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.
You’re describing output while the essay is discussing productivity.
If you’re 10x more productive, someone is willing to pay you 10x as much as they were last year, because you’re producing 10x as much value as before.
Has your salary increased 10x?
I don't believe the 10x claims, but since when has salary been any indication of productivity?
Productivity is a value measured in dollars. So if you’re 10x more productive, someone somewhere is making 10x the $ value from your output.
You should expect this to be reflected in the labour market somewhere. Maybe not your own salary, but in somebody’s salary.
One of the most important graphs in economics shows a divergence between increases in labor productivity and worker take home share since at least the 1970s
maybe you are thinking ceos or shareholders
In economics productivity is generally the outputs divided by the inputs used for production. Are you talking specifically about capital productivity?
> If you’re 10x more productive, someone is willing to pay you 10x as much as they were last year, because you’re producing 10x as much value as before. Has your salary increased 10x?
That's too simplistic because the rest of the economy isn't static. Everyone is getting access to AI tooling, if the whole field gets a productivity increase then the baseline changes, you don't just become 10x more valuable. The previous work is now way less valuable than it was before. It's also not clear to me that the productivity gains from AI convert 1:1 into profit gains
Salary stays the same. A bunch of others are fired. You’re expected to produce their level of output as well as your own. After all, you’re 10x more productive now?
I guess the follow up question to this is “have nine of your colleagues been fired?”
They are paying Anthropic instead of you, because you aren't producing that value, Claude is.
Salary has had weak correlation to productivity gains since last century.
AI is certainly able to increase coding speed, especially for experienced engineers who can design the analytical parts themselves (data structures, interfaces, invariants, and process), but in large projects and/or organizations, queuing theory (especially as understood by lean development practitioners like Don Reinertsen) is going to be nasty.
Lean development theory teaches us that in a multi-workstream, multi-stage development process, developers should be kept at roughly 65-75% utilization. Otherwise, contra-intuitively, work queue lengths increase exponentially the closer utilization gets to 100%. The reason is that slack in the system absorbs and smooths perturbations and variability, which are inevitable.
Furthermore, underutilization is also highly comparable to stock market options: their value increases as variability increases. Slack enables quick pivots with less advance notice. It builds continuous responsiveness into the system. And as the Agile Manifesto tells us, excellent software development is more characterized by the ability to respond to change than the mere ability to follow a plan. Customers appreciate responsiveness from software vendors; it builds trust, which is increasing in value all the more with the rise of AI.
But AI-driven development threatens to increase, not decrease individual engineer utilization. More is expected, more is possible, and frankly, once you learn how to guardrail the AI and give it no trust to design well analytically, the speed a senior engineer can achieve while writing great code with AI assistance often feels intoxicating.
I think we're going to go through a whole new spat of hard, counterintuitive lessons similar to those many 1960s and 70s developers like Fred Brooks and his IBM team learned the hard way.
For your sake I hope that your pay is determined by your “output”, and not your long-term usefulness.
Oh spare me! Anyone can "output" 10x more code. Fred knew you could slap 10x more people on a team and "output" 10x more code.
What this article explains is why despite your feelings of untouchable success, on average the experience of using software just keeps getting worse and worse and worse, making this the worst era for software quality that I've ever lived through
Didn't we already do this with every company looking to hire "rockstar programmers"? I don't recall that that ended well.
This seems like somewhat of a mischaracterization. He contrasted improvements in software with improvements in hardware, saying we'd never have something like a Moore's law for software where performance doubled or cost halved equally rapidly. Churning out software faster doesn't mean it's any better.
We also seem to fall into these ruts of not understanding what is meant by labor productivity. When an economist is presenting the common outputs / inputs measure, they don't mean raw quantity of output. They're talking about the value added by outputs divided by the value of inputs. Churning out software faster that doesn't earn anybody additional revenue is not making us more productive. It's disheartening that even c-suites with business education don't seem to understand this. That's not to say there is no productivity gain. Plenty of AI-adjacent hyperscalers are seeing ridiculous growth right now, but no non-startup is seeing revenue 10x what it was the year before, not even NVIDIA.
A lot of this is just basic diminishing marginal utility. There is only so much value to be added. Software is usually either a semi-automated controller or human decision making augmenter to some kind of physical manufacturing process, or entertainment, when we talk about ultimately delivering value. Everything else is an intermediate input. We can only be so entertained. For physical goods, we have food, space, clothing seemingly at a sufficient level to satisfy just about everyone, with the reasons for value not being maximized having to do with distribution. Unless your software manages to solve borders, bigotry, cultural incompatibility, poverty, mental illess, physical illness, violence, I'm not sure what the other big rocks are. Software can absolutely be a key part of infrastructure to facilitate distribution. That's exactly what the Internet is, along with all the backend business and logistics systems out there in existence. But without hitting the true big rocks, where is the 10x value supposed to come from? We're talking incremental gains simply because we're not in the dark ages any more and incremental gains are all that's there. Short of Star Trek style replicators and transporters, I'm not sure what could realistically multiply global value by 10.
Without the value, then sure, you may be churning out 10 times as many discrete projects used by at least one person, or 10 times as many lines of code, but that was never the point. Your personalized notes and grocery ordering apps you share with your wife might excite you for a few weeks, but I can assure you they aren't going to revolutionize your life.
I've been thinking about this and have wanted to discuss it with people. I think the 10x thing has been broken, but I don't think it's because the premise of "No Silver Bullet" was false - I think it's because LLMs have the ability to navigate some of the _essential_ complexity of problems.
I don't think anyone has really wrestled with the implications of that yet - we've started talking about "deskilling" and "congnitive debt" but mostly in the context of "programmers are going to forget how to structure code - how to use the syntax of their languages, etc et etc)." I'm not worried about that as it's the same sort of thing we've seen for decades - compilers, higher-order languages, better abstracts, etc etc etc.
The fact that LLMs are able to wrestle with essential complexity means that using them is going to push us further and further from the actual problems we're trying to solve. Right now, it's the wrestling with problems that helps us understand what those problems are. As our organizations adopt LLMs that are able to take on _those_ problems - that is, customer problems, not problems of data, scaling, and so forth - will we hit a brick wall where we lose that understanding? Where we keep shipping stuff but it gets further and further from what our customers need? How do we avoid that?
Even assuming you are correct, does your "output" being 10x actually mean "a 10x increase in the speed of software development"?
Just because code has been put out does not mean the software is “developed”.
10x would only be possible if your output was low before Claude Code
I've found that I can have 10x output, so long as I don't expect anyone to review your code...
I can get 100x output, if we're counting lines of code!
I bet get I could hit 1000x output of random characters produced by smashing my hand against the keyboard.
your output !!
but is the industry output over 10X ?
It's mostly slop. And sometimes slop is good enough. But Fred Brooks was talking about actual software systems, not a shop front for an amateur wine importer.
[flagged]
Horses weren't replaced overnight.
Also, I know that there will be a lot of boilerplate applications that just don't look good or seem to have been well thought out early on.
Folks will use that as a cope mechanism, but huge changes are coming.
The premise of "no silver bullet" is wrong (LLM just made it clear, but it has always been wrong).
The premise is that the software development had been mostly "essential complexity" rather than "accidental complexity." But I think anyone who worked as SE in the past decade would have found the opposite is true.
It's not only that software development is full of accidental complexity. Programmers (and the decision makers above them) have always been actively creating accidental complexity. Making a GUI program hasn't gotten easier since Visual Basic. In fact for each JavaScript framework and technique that wraps around DOM render engine, it has got harder over years. Until LLMs made it easier again (by creating a permanent dependency on LLMs. If you intend to edit the code manually afterwards, it became even harder!)
I think the fuller version of the "'no silver bullet' is wrong" claim is at: https://blog.ploeh.dk/2019/07/01/yes-silver-bullet/
A weaker claim is that maybe there's no single silver bullet but there have been many bronze bullets that add up to more than a single silver bullet. I readily endorse at least that and think it's rather easy to justify.
"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
When I was young, in my teens, I already knew a bit about programming but of course nothing about the industry.
These beautiful metaphors by Brooks, from books like inmates running the asylum, etc - they made me romanticize the industry I had no idea about.
Now, about 20 years later, I wonder to which extent they influenced me to take the path I've taken. Because when I began, it wasn't lucrative or cool in the slightest.
It's funny, I also read the book as a teen, and I came away from it amazed that IBM was dedicating entire team members to inter-/extra-team communication.
Before that I hadn't even considered how necessary a product manager or project manager were in software development.
But it was the "No Silver Bullet" essay added as a bonus in my copy that I think about the most. "Never again will we see a 10x productivity increase in a decade", this is self-evident now but must have been crushing to people who had experienced the first compilers, the first high-level languages, the first interactive terminals, and waited for the next incredible leap.
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.
Fred brooks would not necessarily endorse this.
Please, say more!
>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.
Ah, maybe this is what you think he would take issue with? Fair enough. Perhaps I should have said:
>I always look to staff up as much as is economically and organizationally optimal, to exploit all genuine parallelism opportunities, being careful not to overstaff.
You mileage may vary but in my (unfortunate) experience, stuffing up by any other reason than grassroots "we need more hands" raised by engineers themselves typically backfires. Teams that are constrained by people resources often find creative ways to work smarter. Teams that have an abundance of labor, often end up working unnecessarily harder, duplicating work, reinventing the wheel, not solving the right problems, etc. See also intensive vs extensive development.
I agree with that
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.
Best advice I ever got was to let management fail on their unrealistic deadlines. You do this enough times and they'll start to get more realistic.
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.
Same, I always misread the title like this when it comes up and it amuses me for a while, since it sounds like it could be a book written by Franz Kafka.
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.
[0] https://charlesleifer.com/blog/tokens-and-dreams/
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.
What is that? Does he let openclaw post for him? Wikipedia article on the same topic is more informative
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.
Dario Amodei said in the most recent interview with Dwarkesh that Anthropic currently gets achieves an increase of around 20-30% coding productivity, which tracks with my experience. What do you do to reap orders of magnitude more?
Also, how much more money do you make? Or are you working less?
I can clearly see, and feel, Dario's associates' "increased productivity" in their Claude Code/Chat/Cowork desktop product...
So many updates, pretty much daily, so many tweaks to the interface. Sometimes the tweaks are a bit dumb, sometimes completely trivial, and other times they just undo what they did previously.
My favorite examples of their newfound velocity:
1. When there is a nice feature that was easily discovered, and then it was gone...
2. When the "customize" section moves around to random places in settings, or entirely out of it
Special mention to their scatterbrained keyboard shortcuts strategy
I think if you build out simple sites it is 10x. That number tends to 1x as the project gets more complex.
Side projects where you try an idea are you not finding 1h now to do what was 10h work?
Simple sites :-)
https://partsbox.com/ — it's an ERP/MRP for companies building electronics. Around 170k lines of Clojure and ClojureScript.
> What do you do to reap orders of magnitude more?
I don't know what Dario Amodei says, does, how Anthropic is run or structured, or what kind of people work there, so I can't comment on that.
I do know about myself, though. The increase is very real, measured by the number of (Linear) issues resolved. No, I haven't changed how I open or close those issues, I've been using the system for years. During the first three months of 2026 I went through 12x more issues per month than during past years.
But I guess I am not an "average programmer": 35 years of experience means I can work with AI as I would with a small (but very skilled) team. I can architect systems, notice unnecessary complexity, and intuitively choose solutions that are more maintainable. And I am a single-person company, with no managers to report to, KPIs to achieve, presentations to make, etc.
I do not make "more money". It's a mature SaaS. Changes in revenue are over the long term, on a scale of years more than months, and implementing features is no longer enough: marketing is needed for more growth.
But, to be honest, I am tired of defending myself this way. It's not the first time I post this metric, I thought people would find it an interesting data point. Instead, I get downvoted (see my comment above which currently sits at -1 in spite of being objective and factual), and then get plenty of responses asking me to defend my statements.
Come to think of it, I'd rather not convince people about AI increasing productivity so much. I'm not really sure why I bother to post here anymore. I'd rather have everyone (including my competition) believe whatever they want to believe and not use AI.
Sounds like a blog post on your experience would be very interesting.
Like a sibling comment - I'm also curious about what that 12x means for you and your business - same revenue at fewer hours? More revenue, fewer hours? Etc.
Mostly faster progress with same working hours, as I'm trying to improve my app and beat the competitors.
In a mature SaaS features do not map into more revenue quickly, so the effect on revenue can't be measured easily.
What did you measure? It’s a famously difficult problem, so I’m genuinely curious.
Maybe I’m misunderstanding but that sounds like a 6x improvement not 12x.
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
Are you confusing him with Robert C Martin?
"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
[flagged]
[flagged]
Nine women can already have babies in parallel. That is, nine women cannot have a baby in one month, but nine women can have nine babies in nine months.
14,000 women will produce a baby in a month, because that is how many, in average, it would take for one of them to be 8 months pregnant. Of course, if you need one tomorrow, you can go over to the maternity ward and steal someone's that was just delivered.
Moreover if you need 1 baby a month you can absolutely stagger your initial startup period to reliably produce 1 baby a month.
It would probably be more practical to make old age less expensive than to inject more people into the bottom of the demographic pyramid. Those young people eventually get old too. I am looking forward to my sentient robot caretaker:
“Open the refrigerator door, HAL”
“I can’t do that right now”
If he had saved enough money to subscribe to the Pro tier, HAL might have opened it.
Once we ditch our centrally controlled economies perhaps life can be affordable enough to not prevent willing parents from having children.
Oddly from your comment I can't quite tell which end of the political spectrum you're on. I think I agree with you, but I'm not sure until I know which team you're on.
I bet depending on the questions you ask me I could be on either side :)
Life has never been more affordable than it is now. Virtually all of your ancestors were impoverished to a degree you can't even imagine.
Life was becoming increasingly more affordable, but that stopped being the case years ago. It is now declining. I would like it to either stay the same as it was years ago or start increasing again.
Sure but it’s still more affordable than it was for the vast majority of our ancestors, and they still had kids, so it’s not an explanation for declining TFR in developed countries.
I think Brooks would call that an optimistic schedule estimate.
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.
The lessons in that book have broadly held true for nearly every single one of my employers throughout the entirety of my career.
Our field is full of vague, terrible opinions and useless advice. Arrogant people that think they're better than others.
That book isn't, it's built from humility and a rare bright light in this god forsaken field.
The book is good. As you say, the author, Fred Brooks, is not at all arrogant.
Martin Fowler, the author of the blog, may be a bit different than that.
Indeed a lot of things have changed. A worthwhile exercise is to read the book, contemplate how things have changed, and try to map lessons from the book onto modern technology and organizational practices. A LOT of the core principles are still relevant IMO, even if many of the implementation details are not.
Your comment and the OP both mention some things that are outdated about the book. What are those things?
So men and months have suddenly become fungible ?
You should tell these AI companies and we could have AGI tomorrow if only they would throw a few thousand more men on the project.
Or perhaps today's men are coding agents? You can spin up as many agents as you care to, so asymptotically any project should be completable in zero time, regardless of complexity.
IMHO, Brooks's Law applies more today than ever.
I was half expecting Fowler to tie it in to right-sizing agent teams.