>If the resulting software is so poor you need to hire a human specialist software engineer to come in and rewrite the vibe coded software, it defeats the entire purpose.
I don't think this is entirely true. In a lot of cases vibe coding something can be a good way to prototype something and see how users respond. Obviously don't do it for something where security is a concern, but that vibe-coded skin cancer recognition quiz that was on the front page the other day is a good example.
Exactly… back in 1975 Fred Brooks was advising programmers to “plan to throw the first version away” (The Mythical Man-Month) and it’s still true today. Just the tools to build that rapid prototype that have changed. Once it was Ruby on Rails, once it was Visual Basic 6, very often it’s still Excel macros…
Wasn't part of throwing away the first version because of all the knowledge you gain while actually building it? So that you could build it much better the second time, with much better abstractions/design? If you had AI code it the first time, you don't gain that same knowledge.
You still do from operating the software. You see what problems users have using it, which types of problems they tackle with it. By the end of running the software for a month you will have typically learned a boat load.
But you and the parent are both ignoring that, in the real world, prototypes constantly (in fact, nearly always) get shipped straight to production and not updated or rewritten, precisely because they solve a pressing problem, and if they solve it well they get real users right away who start bringing up new feature requests and bugs before the prototype can ever be fixed.
This was a constant pattern in software engineering even before LLMs, but LLMs are making it much worse, and I think it's very head-in-the-sand behavior to ignore that. It's akin to going "well, you can't blame the Autopilot because the person should have been fully-attentive ready to react at any millisecond". That's not how humans work, and good engineering is supposed to take real-world human behavior into consideration
I've spent a good chunk of my career fixing or rewriting messes created by human developers. A majority of startups that succeed need this at some point, whether it's because of time and resource constraints during initial development, experience and competence issues, poor choices that got baked in, or whatever.
Right now, vibe coding just means there might be a lot more of this, assuming vibe coding succeeds well enough to compete with the situations I described.