Nothing to add other than that I agree, and this is a easy to understand, correct way of framing the problem. But the framing probably won't convince exuberant AI folks. These tools are incredibly powerful, but they can only take you faster in the direction you were already going. Using them responsibly requires discipline, and not everyone has it, and we're about to undertake a grand social experiment in seeing how it plays out.
Unnecessary complexity was already a big problem in software prior to LLMs, and I think we're about to see it become, unbelievably, a much much bigger problem than before. My personal belief is that there are a lot of exponential harms that stack up as complexity increases:
1) Difficulty of understandinga codebase rises expontentially with code size. A 100kLOC codebase is more than 10x harder to understand than a 10kLOC codebase.
2) Large codebases get larger faster, classic snowball effect. Implementing a given feature against a larger codebase requires a larger change, even if it's the ideal, perfect change. Plus, ast shortcuts and bad abstractions make future shortcuts and bad abstractions much more likely.
3) Team size increases with codebase size, larger team size triggers Brooks law: number of communication paths grows quadratically with team size.
Prior to LLMs, the world already had large codebases that had essentially become emergent organisms that became so complex, the organizations that created them completely lost control of the ability to work in them effectively. Visual Studio and MSBuild, or Microsoft Teams come to mind. But historically, it was very expensive to get to this point. Now it's going to be much easier
Unnecessary complexity was already a big problem in software prior to LLMs, and I think we're about to see it become, unbelievably, a much much bigger problem than before. My personal belief is that there are a lot of exponential harms that stack up as complexity increases:
1) Difficulty of understandinga codebase rises expontentially with code size. A 100kLOC codebase is more than 10x harder to understand than a 10kLOC codebase. 2) Large codebases get larger faster, classic snowball effect. Implementing a given feature against a larger codebase requires a larger change, even if it's the ideal, perfect change. Plus, ast shortcuts and bad abstractions make future shortcuts and bad abstractions much more likely. 3) Team size increases with codebase size, larger team size triggers Brooks law: number of communication paths grows quadratically with team size.
Prior to LLMs, the world already had large codebases that had essentially become emergent organisms that became so complex, the organizations that created them completely lost control of the ability to work in them effectively. Visual Studio and MSBuild, or Microsoft Teams come to mind. But historically, it was very expensive to get to this point. Now it's going to be much easier