I was talking about it for a while with colleagues. AI besides other benefits, needs to be treated as great interface for discovery, you have your features baked in, AI uses it via your users and MCP, then you figure out what are actual flows of my users and then you build it
That depends on (A) verification being very low cost and (B) being able to infer the right answer based on wrong ones.
Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.
There is a difference between building a product and building a product that sells. So, which one are we talking about here? In my opinion MMM talks about the latter
If you can vibecode a product that sells, I can vibecode a free open source one just as easily, probably even easier since I can just ask the AI to copy the existing one. Software is trending towards being free and open source.
Right, the key being a fast feedback loop. I have full confidence that the same LLMs that can do these crazy math proofs could also do crazy biology, even cancer research, but they simply don’t have the cycle time low enough because they require actual physical experiments, often on living things, often over long time horizons. Even if you perfectly automated a lab, made thousands of them, you’d still be unable to match the speed of iteration that one gets with pure math and computing problems.
"You're absolutely right, that drug was lethal and that's on me. I'll add a note to check human toxicity for all compounds in the future. To verify the safe dosage, I'll administer a high dose and then check smaller doses until the patient survives — not guesswork, grounded load-bearing experiments."
There is a great turkish proverb about this "one hand is nothing,two hands make a sound" (i hope i translated it right).
So,adding people to a task isnt necessarily bad in every situation. Honestly, it depends on the nature of the job beacuse everyone approaches a problem from diffrent perspective
Here's a question, to people who delegate all their coding to AI agents now: What are you doing to keep your mind exercised in all this suddenly new free time you have? Personally I find talking with agents extremely tedious and unrewarding; I would rather just write the code, even if it's simply because it's more interesting than playing Sudoku or whatever the fuck you do when you have nothing to do with your brain.
And talking to AI agents is not the same as using your brain. It's frustrating, it seems to be intelligent, you think you're using reason with them, but it rapidly degrades your ability to reason. It encourages you to accept answers without checking them thoroughly. So much for the skills of accuracy and integrity you built up. It's a sugar rush.
OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"
Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.
Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.
If you use AI then that is not going to be your bottleneck. So if a project is late one of the options on the table is still to add manpower to "help".
So nothing has changed fundamentally, only perhaps superficially.
> nine agents still can’t deliver a baby in one month.
Very weird way to say this. Like it holds true for biological beings because pregnancy by default has a fixed timeline. But how does this apply to AI? Also what even is an "agent"? Are they distinct worker units on a program or the same worker unit split into multiple instances?
Why are we assuming agent = man when its a computer program?
It's a weird way to express that concept, in fact I don't think it ever appeared like this in the book (it has been a while).
It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".
The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.
I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)
The part of Brooks that still holds for me as a solo developer is that the cost sits in coordination and understanding, not typing. AI makes producing code cheaper, but reviewing it, keeping the design coherent, and remembering why things were done still takes the same attention. I have found small, well-bounded tasks with tests work well, while open-ended changes across many files create review work that cancels the speedup. So the useful question is how much of a change I can verify quickly.
I think it takes MORE attention and thought. I feel like a rope being pulled tight and fraying in the middle. Working with these things is very addictive and interesting but it is cognitively exhausting long term, even if invigorating in the short term.
It does require that the human driver knows what they are doing. It captures the pre-AI developer mindset of developing a mental model along side writing the code. This has always been iterative, in discovering the model that results in high cohesion and low coupling.
That doesn't work if the driver cannot steer properly. It's the main issue with vibe-coded one-shotted solutions, that might look impressive until you peek underneath and it's all a mess.
I get a feeling that the best way we currently know how to use these tools is to not read their code at all. Models code and models review. Humans just ask questions and guide. Claude Code has no code editor on purpose.
As long as you are accountable, you need to understand the code. There’s just no way “But I told the LLM to make the code secure” is an acceptable explanation for a security breach.
You might be surprised to learn that yes, regularly pointing a tool at the codebase and seeing it found no issues is indeed enough to claim compliance with cybersecurity regulations.
While we may use deterministic tools like static code analysis, dependency scanners and similar today, people are already replacing/augmenting them with LLMs.
While every breach will trigger a root cause analysis process in a compliant environment, the solution is never going to be "all code in a deployment was manually reviewed by someone at the company" because this would extend to tooling (like compilers, scanners but also packaging and deployment tools) and all dependencies.
So I am pretty sure your example is already used in a number of places especially with "LLMs are better at security than humans" marketing being pushed around — this really makes it easy to sell that excuse to the gullible management who wants to believe this.
The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.
1. A blank sheet of paper
2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.
And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.
Anything grindy. Reverse engineering. Performance optimizations.
That's where swarms shine I think. But that's a much much much smaller problem space than what these agents are being sold for.
"You're absolutely right, that drug was lethal and that's on me. I'll add a note to check human toxicity for all compounds in the future. To verify the safe dosage, I'll administer a high dose and then check smaller doses until the patient survives — not guesswork, grounded load-bearing experiments."
And talking to AI agents is not the same as using your brain. It's frustrating, it seems to be intelligent, you think you're using reason with them, but it rapidly degrades your ability to reason. It encourages you to accept answers without checking them thoroughly. So much for the skills of accuracy and integrity you built up. It's a sugar rush.
Who got more time thanks to AI ? I think a lot of us are working more instead
OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"
Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.
Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.
So nothing has changed fundamentally, only perhaps superficially.
Very weird way to say this. Like it holds true for biological beings because pregnancy by default has a fixed timeline. But how does this apply to AI? Also what even is an "agent"? Are they distinct worker units on a program or the same worker unit split into multiple instances?
Why are we assuming agent = man when its a computer program?
It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".
The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.
I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)
That doesn't work if the driver cannot steer properly. It's the main issue with vibe-coded one-shotted solutions, that might look impressive until you peek underneath and it's all a mess.
Is this sustainable? I've got no idea.
While we may use deterministic tools like static code analysis, dependency scanners and similar today, people are already replacing/augmenting them with LLMs.
While every breach will trigger a root cause analysis process in a compliant environment, the solution is never going to be "all code in a deployment was manually reviewed by someone at the company" because this would extend to tooling (like compilers, scanners but also packaging and deployment tools) and all dependencies.
So I am pretty sure your example is already used in a number of places especially with "LLMs are better at security than humans" marketing being pushed around — this really makes it easy to sell that excuse to the gullible management who wants to believe this.