[AshleysBrain]

I'm sure there's a time and a place for "vibe coding", but a related point is with larger software projects, most work is maintenance (shameless plug: see my blog post on the subject[1]). It should be obvious that if there's a problem in a serious project, "just work around it or ask for random changes until it goes away" is probably not going to get you very far. I suspect perhaps "vibe coding" was just pointed out with the attitude of "hey this is kinda cool", but hype is blowing it out of proportion.

[1] https://www.construct.net/en/blogs/ashleys-blog-2/reality-lo...

[perrygeo]

Great point, this maps to my experience. Almost every "fix this existing code" problem posed to LLMs is a failure. The approach of simply spitting out the next probable token doesn't work if any complexity or design aesthetics is involved. We wouldn't trust a human that approached problems by stream of consciousness either.

But vibe coding does work reasonably well for solo greenfield/demo projects. When there is no external complexity, no inferred requirements, no consequences to getting it wrong, nothing to integrate with, nobody to collaborate with ... just you and a blank editor - vibe coding works.

While it can be nice living in a little self-contained fantasy world, on existing projects you'll find absolutely none of the same conditions. And a whole slew of other engineering challenges that aren't solved by throwing generated code at it. As the value of code trends to zero, the value of those other engineering skills increases.