Code has an invisible attribute "confidence" associated with it. All code has it. So-called "battle-tested" codebases have a high value, newly-written stuff starts at low values, and the only two ways of increasing it are 1) rigorous testing and 2) actual usage in production scenarios at scale.

AI can generate "confidence" only in very limited amounts. It can help with testing, but that becomes very expensive and hard once we leave the realm of tests that can be simply written with code, like unit tests. At some point, the only way to increase the confidence in a codebase is actual testing with actual, real user interaction. And once that's maxed out, the only way to further generate more confidence is to get it into production and let real users (not test users, production users) find the remaining bugs no tester and no AI ever managed to hit.

This is the sole reason why AI doesn't make code "disposable" - yes, it can rewrite any codebase far more quickly than any human, but that new code will start at low confidence values - AI cannot transfer the confidence that the old codebase achieved simply due to being smashed against reality in production use to the new code it writes.

This is also the reason why it still makes sense to maintain libraries, even though AI could not just theoretically, but also practically write a lot of functionality from scratch that we usually import into projects via open-source libraries: the newly written stuff doesn't come with the same confidence as the already-battle-tested library does.

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.

_some_ code is disposable, but robust, proven solutions that fit the case of massive userbases will keep existing and get maintained. at a certain point it makes no sense to rebuild everything each time.