Tech debt has rules. You cut a corner to ship on time, you write a comment that says TODO fix this, and six months later someone pays it down. It is annoying but it is bounded. A senior engineer can look at a codebase with tech debt and draw a map of where the bodies are buried.
Yeah, I find it really tricky, because LLMs excel at adding yet another implementation to the side, whereas they will barely ever introduce an abstraction to cover both requirements.
And the humans often don’t really read the code anymore either. They ask the LLM to make a suggestion, then check the diff for plausibility and that’s it. They don’t have to solve it themselves, so they never properly dig into the surrounding context and therefore cannot notice the missing abstraction either.
And in the end, it’s not just that the humans don’t know the code, it’s also that it becomes near-impossible to refactor, because it’s just too much code to fit into a brain at a time.
You can’t anymore realize that one part of the codebase should’ve been solved by an already-existing abstraction.
Instead, you find five places in the codebase that really look like they should’ve been solved with a shared abstraction and then good luck figuring out what the common denominator is and how each of those places should be adjusted to fit this common abstraction, oh and also you didn’t see two more places that really should also be solved that way, but for them your chosen abstraction doesn’t make sense anymore, and then you ask the others and they tell you, oh man, that never made sense, we never really thought about it, because it was so easy to just tell the LLM to build it, and now that feature has to be removed in its entirety, so you just wasted two weeks trying to understand code that never made any sense in the first place.
Ask me how I know. 😑