That was the theory, but it ran straight into the reality that most of the time “throwaway prototyping code” gets shipped straight to production and never updated, because it’s addressing real needs right now and there’s no time to fix it because a dozen other feature requests and support issues have arrived in the meantime.

The quip that “there’s nothing more permanent than a temporary solution” has been a truism of software engineering since long before AI arrived on the scene, vibe coding is just making the problem much worse.

The dirty secret of a huge amount of "production code", i.e. code that is in production right now servicing enterprise needs, is that it's written with the care and understanding of typical throwaway code. It's not a new problem. Ball of mud architectures are everywhere, prototypes becoming permanent are common, understanding is low (especially if the original author has left or switched teams), but teams muddle through with the super powers of being able to ship ongoing patch fixes, code review, automated testing, and sometimes even writing code with professional care and forming little oases of quality.

I'm mildly optimistic that vibe coding won't make the problems that much worse and can actually lift the standards of quality in some cases. In my own personal careless / throwaway bash scripts, I've been using AI for them more and more, but I also notice that it puts more care into them than I otherwise would have with respect to things like error checking, friendlier help and other options, progress echos, and comments. AI tools still have a ways to go on larger projects though, and hallucinations seem particularly bad when it comes to foreign library bindings...

Let's see how many forget how to write and think through their own code while primarily vibe coding.