Kent Beck has a framing of
Futures vs Features.
Every feature you implement you trade off future optionality, because you now have to keep it working.
As you implement more features, you're pulled closer to the heat death of your codebase, where all futures are precluded.
The only way to get more futures is to pay down debt.
For example, by primitive archeology.
"What is the design that I wish I had that would have made this easier to implement?"
"What are the core data models and invariants I can establish, at which layers?"
It used to take codebases decades to reach their heat death.
Now, it's possible to reach it in weeks with LLMs spraying code.
LLMs can do tech debt reduction… but only if asked to.
If you don't ask them to do it, then you'll get more and more functionality by destroying the optionality of the codebase.
The difference between well-implemented (not unnecessarily reducing the future possibility) and poorly implemented (constraining the future possibility unnecessarily) is visible only to people with engineering experience.
Just because you can vibecode doesn't mean you feel this in your bones.
The difference between a Gilded Turd codebase and a Grubby Truffle codebase will be invisible to non-technical people (e.g. management).