> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.
That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.
It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more.
Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes.
In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
What's even more surprising is that it can be given a grafana API key and reason about bugs from the hints of patterns in the logs even with pretty sketchy and inconsistent logging in places.
It can then raise, investigate and resolve those problems while also patching up and rationalising logging to improve future work.
The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting?
One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.
Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.
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.
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
Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also). They tend to overspecify. If I had a copy of myself I would tell him "do the thing", but agents say "do the thing like this and this, it must be such and such, use X and put it together that way". The subagent is just as intelligent but now it's constrained, sometimes as you start developing something you discover some things are better organized in a different way etc. So it spends much time figuring out how to deliver exactly what was asked even if it's not optimal because that's the task.
Basically a company where you can't ever question decisions of the higher ups, not even ask for clarification, but they force implementation choices on you. I mean, it definitely does happen, but the results are usually not great. Not alawys. For some tasks it works.
> Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also).
Isn't this odd? This seems to be the #1 task that the major labs should be optimizing, since it makes agent so much more effective.
> They tend to overspecify. If I had a copy of myself I would tell him "do the thing", but agents say "do the thing like this and this, it must be such and such, use X and put it together that way". The subagent is just as intelligent but now it's constrained, sometimes as you start developing something you discover some things are better organized in a different way etc. So it spends much time figuring out how to deliver exactly what was asked even if it's not optimal because that's the task.
Isn't this just the planning pattern, common for agentic work? (first plan then implement.. with things like /plan, or a planning skill, with or without creating a PLAN.md). If this methodology is wrong when an agent prompt another agent, it's also wrong when the human runs /plan manually..
And Indeed, I always thought it was odd to constrain the implementing agent like that, because common sense is that we discover things as we implement. Perhaps we should prompt the agent to communicate back, as they implement, any shortcomings in the plan itself - such as things they learned while implementing that contradicts the plan.
Does this actually work for anybody? In my experience, when you use cheaper models as subagents, the more expensive parent agent ends up reading all of the subagent's work and surrounding code into context anyway to review it. So you end up paying more, not less.
When I am making agents do a hard thing, I use Opus as both parent and child. I make the child review its code extensively, and then still make the parent read the work and review once again. It is much faster and cheaper than just rolling with no extra reviews, and then in a day I have fifty subtle bugs.
Plus the subagent's work is often subpar and the parent ends up requesting multiple revisions. Each back and forth burn unnecessary tokens as well as my time.
Where it might work well is for separate task categories like image generation - get the parent to ask for an image from another model that is better at this aspect
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.
Half of the value in open source was that it was used by lots of people and all of the nasty edge cases and bugs have been ironed out.
If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.
Unclear if this is that. If someone makes their own FOSS Photoshop, that's not piracy, it's GIMP. Training a AI on things that one otherwise has lawful access to (and not, e.g., pirating the material which Meta is being sued over and Anthropic settled over) has been ruled lawful.
Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?
We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.
And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.
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.
What gives you full confidence? The human body/biology has basically nothing to do with math or writing code. This doesnt translate in any way. There isnt a single biotech expert on earth that agrees with you.
"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."
i think of the mythical man-month at least once a day.
if i would know EXACTLY what and how I had to build stuff, it would probably not apply. But at least for me and my projects, that is not the case. Planning and building in parallel has given me too many headaches.
If you are building something stable, secure - well thought through and executed, you hardly get around sequential building.
In my experience, you choose the key difficult parts first, and build a small toy version. From that action, you learn which parts of the interfaces are common, and may undergo modularization with a clean design pattern.
Ultimately with sanity checking, sanitized marshaling, and constraint programming... the underlying security model is naturally enforced within the pattern itself.
The deceptively simple systems are more like an ant colony or bee hive. =3
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
Reminds me of my wife chatting with this guy at a party and we were complaining about money problems and she says this proverb she had learned recently and said, "a man is rich if he has two hands".
Turns out the other person was Albie Sachs who was a hero and had his hand blown off during the apartheid era and took both arms out of his pockets and raised them up and said "I guess I'm not rich then" - that was some serious gallows humor :-)
I can't believe I'm nitpicking proverbs, but making a sound with one hand isn't witchcraft.
To the core message of it, if we really need to stick to one liners, "go alone to go fast, go together to go far" would be an easier philosophy to adhere to perhaps.
How we've ended up cornered in this spot as an industry? From human craft to onboarding and baby sitting agents?? That sounds just stupid. I won't be surprise to learn, after ai companies go public, that those who pushed hard for agentic coding just disappear o will push for something else. What we have produced so far of extraordinary or even just good value? Please no math conjectures or advancements, there is no field benefit in brute forcing problems
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.
I don’t „talk” to my agents. I tell them what to do. If I need to „talk” it means something is going wrong and we need to figure out why agents are doing bad work - and this is intellectually challenging.
The effect you describe I had at times but with older/dumber models where you could spend a ton of time and the model was either too dumb to do it, or had a model dementia later in the context. Or when I didn’t really understand why it did a bad job and tried to stumble around in the dark - very mentally numbing.
Nowadays the model usually just had some bad tools or information required to do the job.
You need to switch into a product manager/QA/UI,UX mindset.
Is what is being built the right thing?
Does it work?
Is it usable?
Has it been built in an appropriate way? (Note this is not a code thing, it’s an architectural question)
Traditionally developers have outsourced these things to other people.
There’s a further thing you should be doing - if the questions above didn’t pass - why not? What went wrong in your process?
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.
Running 20 agents at the same time means a lot more task switching, its closer to team management, you may have one agent doing basic grunt work, so can be let alone, another one may be planning and designing, so needs a little bit more q&a, and others may be problem solving, and that does take a lot more supervision. But I have never felt like I have any free time, or down time, at the end of the day I feel far more mentily exhausted (in a good way) than any day before agentic development.
>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?
If you have a lot more free time you're not taking full advantage of agents. The time saved coding allows working on 4-6 projects simultaneously, and the majority of work is the hard design/product decisions that the agents can't do well themselves. Working on the hard parts of half a dozen projects simultaneously is far more mentally taxing than just hand-coding a single project, and with that many agents there'll usually always be one with a question for you so you won't have much extra free time.
Most people have no view on that, or dismiss it either as a cultish/outlandish topic or something so far into the future it's not worth discussing. The author most likely falls into these categories otherwise his point would be mute.
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?
To whit, 13,000 women can make a baby in one month. If you hire that many women, by the statistics, that's how many it takes for one of them to be 8 months pregnant.
Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.
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.)
I always thought it meant 9 women would take 9 months to create 9 babies because a baby takes 9 months to grow with the bottleneck being biology. And yes what you said applies to people but I don't get the whole "throw 9 agents into it" when it is possible to just see it as 1 agent doing 9 things? With people, yes everyone has a distinct way of doing things etc but all agents can be homogenious fully and completely sync up without any overload theoritically no?
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.
> "Adding agents to a project with unclear requirements gets you the wrong answer faster."
The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.
What's easier to use as inspiration for coming up with a list of 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?
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.
That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.
It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more.
What's the most soul crushing?
The latter, clearly? It is far more valuable to have a (badly) working system you can prod and probe than work from fantasy.
People are much better than saying what they don’t like than what they do.
Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes.
In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
Theyre also inclined to jump into talking about solutions rather than their actual problem which inhibits analysis of the problem.
"Oh no problem, I'll just run it again telling the LLM to not do those 20 things, and then we'll have the right answer." /s-mostly
It was pretty surprising to me when I realised I could put 5 different bug reports into the same message and it would fix all of them.
Not quite as shocking as the original InstructGPT video, but surprising.
What's even more surprising is that it can be given a grafana API key and reason about bugs from the hints of patterns in the logs even with pretty sketchy and inconsistent logging in places.
It can then raise, investigate and resolve those problems while also patching up and rationalising logging to improve future work.
The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting?
One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.
Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.
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.
Good points. This is after all why LLMs are so much better at maths and software than the economy in general.
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
> erm, Claude, do it again but leave out the bad stuff and make it good this time, mmkay?
Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also). They tend to overspecify. If I had a copy of myself I would tell him "do the thing", but agents say "do the thing like this and this, it must be such and such, use X and put it together that way". The subagent is just as intelligent but now it's constrained, sometimes as you start developing something you discover some things are better organized in a different way etc. So it spends much time figuring out how to deliver exactly what was asked even if it's not optimal because that's the task.
Basically a company where you can't ever question decisions of the higher ups, not even ask for clarification, but they force implementation choices on you. I mean, it definitely does happen, but the results are usually not great. Not alawys. For some tasks it works.
> Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also).
Isn't this odd? This seems to be the #1 task that the major labs should be optimizing, since it makes agent so much more effective.
> They tend to overspecify. If I had a copy of myself I would tell him "do the thing", but agents say "do the thing like this and this, it must be such and such, use X and put it together that way". The subagent is just as intelligent but now it's constrained, sometimes as you start developing something you discover some things are better organized in a different way etc. So it spends much time figuring out how to deliver exactly what was asked even if it's not optimal because that's the task.
Isn't this just the planning pattern, common for agentic work? (first plan then implement.. with things like /plan, or a planning skill, with or without creating a PLAN.md). If this methodology is wrong when an agent prompt another agent, it's also wrong when the human runs /plan manually..
And Indeed, I always thought it was odd to constrain the implementing agent like that, because common sense is that we discover things as we implement. Perhaps we should prompt the agent to communicate back, as they implement, any shortcomings in the plan itself - such as things they learned while implementing that contradicts the plan.
> The subagent is just as intelligent
Isn't it a common practice to use cheaper models to do the grunt work?
Does this actually work for anybody? In my experience, when you use cheaper models as subagents, the more expensive parent agent ends up reading all of the subagent's work and surrounding code into context anyway to review it. So you end up paying more, not less.
When I am making agents do a hard thing, I use Opus as both parent and child. I make the child review its code extensively, and then still make the parent read the work and review once again. It is much faster and cheaper than just rolling with no extra reviews, and then in a day I have fifty subtle bugs.
Plus the subagent's work is often subpar and the parent ends up requesting multiple revisions. Each back and forth burn unnecessary tokens as well as my time.
Where it might work well is for separate task categories like image generation - get the parent to ask for an image from another model that is better at this aspect
But it’s not a man-month anymore. It’s like half a day.
And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.
> Claude Code can build that application in an unprecedentedly short period
Yes, with the caveat that the application doesn't actually work.
P.S. If you wrote non-working applications even before the age of AI, then this is an upgrade, I guess.
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've got 9 coders, you've at least got a business idea and some financial backing.
Get it out quickly, market it, iterate it. That hasn't changed. Just the speed of iteration before you go from product to product that sells.
Once you know what sells, then again, it takes far less time to rebuild it well if you need to.
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.
Yeah, and then who maintains it?
Maintaining vibe coded software is going to become hours spent with Claude not your users.
That's going to be the difference. It takes nothing to rebuild the software, but listening to users, iterating, handling issues. That's boring.
The ones that win will be the ones that stay the course, not the ones that were built the quickest.
Half of the value in open source was that it was used by lots of people and all of the nasty edge cases and bugs have been ironed out.
If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.
In the good old days that was called 'piracy'.
Unclear if this is that. If someone makes their own FOSS Photoshop, that's not piracy, it's GIMP. Training a AI on things that one otherwise has lawful access to (and not, e.g., pirating the material which Meta is being sued over and Anthropic settled over) has been ruled lawful.
Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?
We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.
And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.
Agents seem to be useful for quickly mapping a problem space through trial&error + throwing stuff at the wall and seeing what sticks.
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.
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.
What gives you full confidence? The human body/biology has basically nothing to do with math or writing code. This doesnt translate in any way. There isnt a single biotech expert on earth that agrees with you.
Plus you'd kill a lot of people.
"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."
That's exactly what Sidney Farber did in Boston Children's Hospital btw in late 1940. One of his tests fast forwarded cancer.
I think its practical to solve cancer on a war footing where we would expect people to die.
And Farber's methods were pretty fast for his time - lol Farber would be a perfect name for this AI that wants to solve cancer knowing what's at risk.
i think of the mythical man-month at least once a day.
if i would know EXACTLY what and how I had to build stuff, it would probably not apply. But at least for me and my projects, that is not the case. Planning and building in parallel has given me too many headaches.
If you are building something stable, secure - well thought through and executed, you hardly get around sequential building.
In my experience, you choose the key difficult parts first, and build a small toy version. From that action, you learn which parts of the interfaces are common, and may undergo modularization with a clean design pattern.
Ultimately with sanity checking, sanitized marshaling, and constraint programming... the underlying security model is naturally enforced within the pattern itself.
The deceptively simple systems are more like an ant colony or bee hive. =3
From my last month's clauding experience, these agents now understand what needs to remain sequential and just wait for the other agents to get done.
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
Reminds me of my wife chatting with this guy at a party and we were complaining about money problems and she says this proverb she had learned recently and said, "a man is rich if he has two hands".
Turns out the other person was Albie Sachs who was a hero and had his hand blown off during the apartheid era and took both arms out of his pockets and raised them up and said "I guess I'm not rich then" - that was some serious gallows humor :-)
I can't believe I'm nitpicking proverbs, but making a sound with one hand isn't witchcraft.
To the core message of it, if we really need to stick to one liners, "go alone to go fast, go together to go far" would be an easier philosophy to adhere to perhaps.
Your proverb holds up talking about complementary work.
I think the Mythical Man Month specifically refers to piling on workers of the same skill set (i.e. engineers)
Don't forget to tell the agent to never generate buggy code.
How we've ended up cornered in this spot as an industry? From human craft to onboarding and baby sitting agents?? That sounds just stupid. I won't be surprise to learn, after ai companies go public, that those who pushed hard for agentic coding just disappear o will push for something else. What we have produced so far of extraordinary or even just good value? Please no math conjectures or advancements, there is no field benefit in brute forcing problems
The Mythical Token-Minute.
Would an unlimited context window enable you to solve all requests instantly ? No
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.
I don’t „talk” to my agents. I tell them what to do. If I need to „talk” it means something is going wrong and we need to figure out why agents are doing bad work - and this is intellectually challenging.
The effect you describe I had at times but with older/dumber models where you could spend a ton of time and the model was either too dumb to do it, or had a model dementia later in the context. Or when I didn’t really understand why it did a bad job and tried to stumble around in the dark - very mentally numbing.
Nowadays the model usually just had some bad tools or information required to do the job.
> I don’t „talk” to my agents.
Though, if you're still typing, you might want to try recent STT software.
You need to switch into a product manager/QA/UI,UX mindset.
Is what is being built the right thing? Does it work? Is it usable? Has it been built in an appropriate way? (Note this is not a code thing, it’s an architectural question)
Traditionally developers have outsourced these things to other people.
There’s a further thing you should be doing - if the questions above didn’t pass - why not? What went wrong in your process?
Doing more, understanding more the tech of the project, exploring more ideas, the list is infinite
Who got more time thanks to AI ? I think a lot of us are working more instead
> keep your mind exercised
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.
Running 20 agents at the same time means a lot more task switching, its closer to team management, you may have one agent doing basic grunt work, so can be let alone, another one may be planning and designing, so needs a little bit more q&a, and others may be problem solving, and that does take a lot more supervision. But I have never felt like I have any free time, or down time, at the end of the day I feel far more mentily exhausted (in a good way) than any day before agentic development.
>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?
If you have a lot more free time you're not taking full advantage of agents. The time saved coding allows working on 4-6 projects simultaneously, and the majority of work is the hard design/product decisions that the agents can't do well themselves. Working on the hard parts of half a dozen projects simultaneously is far more mentally taxing than just hand-coding a single project, and with that many agents there'll usually always be one with a question for you so you won't have much extra free time.
How about RSI? Recursive Self Improvement? I wonder the author's view on that.
Most people have no view on that, or dismiss it either as a cultish/outlandish topic or something so far into the future it's not worth discussing. The author most likely falls into these categories otherwise his point would be mute.
Is it just me or is this article itself AI? Or is everyone just adopting the AI tone and writing style now?
Not only that but there is limited number of good prompts/design decisions per employee per day.
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?
To whit, 13,000 women can make a baby in one month. If you hire that many women, by the statistics, that's how many it takes for one of them to be 8 months pregnant.
Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.
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.)
I always thought it meant 9 women would take 9 months to create 9 babies because a baby takes 9 months to grow with the bottleneck being biology. And yes what you said applies to people but I don't get the whole "throw 9 agents into it" when it is possible to just see it as 1 agent doing 9 things? With people, yes everyone has a distinct way of doing things etc but all agents can be homogenious fully and completely sync up without any overload theoritically no?
Are you aware of the original saying?
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.
Is this sustainable? I've got no idea.
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.