I think I calculated the half-life of my code written at my first stint of Google (15 years ago) as 1 year. Within 1 year, half of the code I'd written was deprecated, deleted, or replaced, and it continued to decay exponentially like that throughout my 6-year tenure there.

Interestingly, I still have some code in the codebase, which I guess makes sense because I submitted about 680K LOC (note: not all hand-authored, there was a lot of output from automated tools in that) and 2^15 is 32768, so I'd expect to have about 20 lines left, which is actually surprisingly close to accurate (I didn't precisely count, but a quick glance at what I recognized suggested about 200 non-deprecated lines remain in prod). It is not at all the code that I thought would still be there 15 years later, or that I was most proud of. The most durable change appears to be renaming some attributes in a custom templating language that is now deeply embedded in the Search stack, as well as some C++ code that handles how various search options are selected and persisted between queries.

I think this both proves and disproves the original point. Most of your code is temporary. You have no idea which parts of your code is temporary. It's probably not the parts that you wish were temporary, which will almost certainly be made permanent.

I come into work and work on a 20 year old codebase every day, working on slowly modernizing it while preserving the good parts. In my experience, and I've been experimenting with both a lot, LLM-based tools are far worse at this than they are at starting new greenfield projects.

How can you possibly know which type of repo you're in ahead of time? My experience is that "temporary" code frequently becomes permanent and I've also been on the other side of those decisions 40 years later.

Unless you’re producing demos for sales presentation (internally or externally), it’s always worth it to produce something good. Bad code will quickly slow you down and it will be a never ending parade of bug tickets.