I agree there is this problem, which is why I try to write software that is actually good (and use software that is actually good, if it is available). It is also one reason why I still use some DOS programs (even with emulation, which is slow, it is still better than the bad quality they have in newer computers).
I do not use any of the software mentioned in that article, and I also do not have that much RAM in my computer.
This is the core philosophical divide in modern software development.
The "vibe coding MVP" crowd treats code as disposable—ship fast, validate the idea, and discard it if it doesn't work.
The problem: most MVPs never get thrown away. They get customers, then funding, then "we'll refactor later" becomes "we can't afford downtime to refactor."
That's how you end up with production systems built on prototypes that were never meant to handle real load.
I'm with you: if you're not willing to build it properly, don't build it at all. Technical debt compounds faster than most founders realize.
The Twitter mob defends vibe coding because it worked once for someone. However, for every success story, there are thousands of companies struggling with unfixable codebases.
Do it right or don't do it. There's no "we'll fix it later" in production.