> I was waiting for the "so I tried coding something with an LLM myself, and I found..."
Why? Most of the article was about the productivity of teams.
> This is a very academic approach to the subject - read what other people have written about it
Meta-studies have tremendous value. He's asking a simple question: if LLMs are changing the world, let's look at what studies are showing.
> My experience has been remarkable, and, like others, I'm finding real joy in being able to move past the code to actually design and play with whole systems and architectures
Great! What does that have to do with the age-old problem that software development doesn't scale to teams well? It is indeed a "50 year old problem", so please tell us how LLMs solve it.
I had to go re-read the article to make sure, but it doesn't address teams or scaling to teams at all, so I'm not sure why you're asking about that?
The article is talking about inherent vs accidental complexity, amongst other points, and if the author had actually tried developing with an LLM, they might have worked out how LLM coding does address some of this.
- The DORA report is about organizations not individuals
- Mythical man-month is about organizations not individuals
- No Silver Bullet: "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation." Clearly he's NOT talking about the 10x dev building the whole thing themselves, which everybody knows is faster, better, probably doesn't even need a spec. Organizations are who need specs -- they have clients, business people etc. An organization with a single developer moves at light speed -- but this doesn't scale.
Nobody's disputing that LLMs give multiples for certain development tasks. The main thrust of the argument centers on how unimportant coding time is ... for organizations. Coding time is a HUGE lever if you're the one dev building everything, but that's not a repeatable pattern.
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.