Quite true! Having been fairly instrumental in a few areas that I'd eventually moved on from, it was always interesting to see some of my trademark accomplishments become The Old Thing We're Trying To Replace (or even just The Big Thing We Have To Maintain); gave me a lot of empathy for prior contributors of code I ended up inheriting.
I tend to assume that the old thing seems dumb because of the constraints when it was written and changing requirements over time; if a tool made by one person in a few weeks seems hopelessly naive to the medium sized team investing a few quarters in replacing it a few years later, that seems to be a rousing success for the original author.
Over the years I've come to say "design for deletion" when it comes to internal code. This means meaning more emphasis on making things straightforward to rip and out and replace, as opposed to stuff that is "configurable" or "extensible" etc.
As a junior developer, I know I spent too long on some things thinking that I could make a piece of Forever Art by adding ways for future developers to tweak its behavior.
The problem I often run into is people equating “we need to replace this” with “it never should have existed”.
Whether it needs to be replaced or not has absolutely nothing to do with how it got there in the first place. Yes, maybe the company avoiding bankruptcy due to your clever kludge. Thank you for your service. But today we are tripping over your kludge left, right, and center. So it gots ta go.
Somewhat awkward if you later see them in a meeting.