The author misapplies/misunderstands the mythical man month even in the first example. It does not apply for idea generation and also not to problem solving/ fixing things, only to software creation. Even then, it also does not apply when creation is cheap, if you can generate 100 solutions cheaply without coordination between them and pick the winner with a relatively fast eval, creation behaves way more like fixing / problem solving.
> generate 100 solutions cheaply without coordination between them and pick the winner with a relatively fast eval
While it might get workable results, this seems like a miserable way to work with code. You spend the vast majority of time thinking about the problem domain of working with agents instead of your project, and for mediocre output. You are transforming your role into a dumpster diver of code.
The approach that proves to be fastest in the long run is to stay close to the code. Lay out the base structure, and use an LLM to check your work and fill in the gaps. The beauty of this approach is that it scales very well with the size of the project. When the LLM has plenty of high quality examples to follow, they start to write the same code that you would. Where it diverges, create documentation.
Perhaps the single best property of LLMs is their ability to consume and apply examples and documentation.
Brooks covers this case himself in chapter 2. He says men and months are interchangeable only when a task can be partitioned among many workers with no communication among them, and his examples are reaping wheat and picking cotton. 100 independent attempts are exactly that kind of task. He would have agreed they scale.
But the work doesn't go away, it moves. Someone still has to judge the 100 results, pick one and integrate it with everything else. That part doesn't partition, and it's where Brooks put most of the schedule anyway: in the same chapter his rule of thumb gives a sixth to coding and half to testing.