Just yesterday a coworker who knows little Rust vibe coded a new feature that “worked” but is actually horribly broken (lots of synchronous I/O/locks/channels in a tokio async context). On top of everything else, they created their own bad abstractions for things that already had safe async abstractions.
If they’d had to actually do this themselves they either would have asked for help sooner so they could be guided or they would have done research in the code which already had examples on how to do things.
Legacy code isn't a bad thing either. The majority of code that actually generates revenue right now is probably considered "legacy" by the devs working there.
The article's point is that if you are planning to maintain something, you've created instant legacy code. Which might be fine, depending!
I know zero about the code the LLM created, though. I've tried going through it, and it is all well-written, but it's all foreign. I wasn't there for any of its creation and I don't have any map in my head about the layout of the functions or the flow of the apps.
I've also, in pre-llm days, seen warnings to not show visually polished prototypes to non-technical customers/salespeople/managers because they have no way of judging the quality and will try to force you to use the prototype immediately because "look, it's done".