Meh, I'll concede that Fred Brooks was mostly writing about developing software within an organisation, and therefore writing about teams.
Coding time is important if it gates experiments and spikes. If you have to work out your architecture on paper because actually coding it up is a serious expense, then it becomes harder to experiment with different designs. In an LLM world where coding time is very cheap, it becomes easier to experiment and try things out. Developing an entire architecture and then abandoning it because it turned out that it didn't scale too well, or couldn't handle some edge cases, is not a major mistake or problem any more. There's no pressure to keep old code because it cost a lot of money to develop. You can spike an entire system, decide that it was a useful experiment, but didn't work, delete the repo, and go get lunch. This is new, and important.
I guess it's what you think the work of sw dev is.
> Developing an entire architecture and then abandoning it because it turned out that it didn't scale too well, or couldn't handle some edge cases, is not a major mistake or problem any more.
Cool, but I can count on one (two?) hands how many times in a 30yr career I had the opportunity to do this, except when I "made the opportunity" by coding the solution fast enough that the PHBs couldn't say no. LLMs should be even better for this of course.
But it's rare, and those times I forced the issue were good for my career but not always for the team. Most of the time, once an organization has a working product, you want to stay in the lanes, roughly, of that product, which is IMO where the coding time advantage vanishes.