+1 for any mention of Fred Brooks. I like your point about software as a whole not being a bottleneck. In the 1970s the hardware was co-evolving with business uses (it still is, but constraints were much more severe) leading to large headcounts on software projects that _absolutely_ had to work and _absolutely_ required uncommon expertise. Most people had no concept of a computer's capabilities, computer science was not as widely distributed.

One thing that I would point to today to show that the landscape is different - the average programmer/engineer/developer today has no actual admin staff. Fred Brooks' example team setup of "The Surgical Team" has more support staff than programmers. Anyone who responds to the questions like "who manages the calendar" and "who manages the documentation" will state that the engineers doing it themselves offer the best results. Same goes for designing test cases, performing rollbacks, etc.

The fact of the matter is that any self respecting engineer today works in an environment where pro-activity and self-sufficiency are prerequisites. Managing your calendar and workload, communicating to leadership and users, these are all common tasks that would have been another person a generation ago.

So when discussing writing code more efficiently and aiding in software development, what I am essentially seeing is more people trying everything they can to offload work that used to be another person's job anyway. If you care about communication - you offload coding standards. If you care about security - you offload feature refactors, and so on.

In my opinion, I think that at some point we'll either realize that we need highly competent people _and also_ regular people to help us ensure the work gets done to a good standard. Or, we will each eventually survive by working alone in a room with a suite of AI tools, and wonder why we're still making software in the first place.

[dead]