I’d argue that code was always disposable. What was valuable was always the specifications and test cases, which more directly represent useful knowledge with lasting business utility.

The problem is that oftentimes code is the only real record of the system design and specification. That creates problems because it’s harder to replace obsolete code and modules. You can try to reverse engineer a spec from current behavior, but that always leaves uncertainty about what behavior is intentional and what behavior is accidental and changeable, and because when the system behaves in surprising ways there’s no clear source of truth on if it was supposed to do that.

What I see with LLM coding is that it makes it easy for people to “at of one” a project, and armies of one tend to produce few artifacts other than the code itself. This, ironically, makes code less disposable by eliminating any sort of thoughtful, detailed record of design intent. The code itself becomes the only record, so modifying or replacing the code needs to either replicate the original code as close as possible, warts and all, or take extra care in reverse engineering and analyzing the original code to try and understand if any simplifying changes can safely be made. Which doesn’t actually happen very often because it’s a lot of generally unenjoyable work.

Which, in turn, is why LLM codebases tend to accumulate bloat at a higher rate.