[simonw]

That might be true in the short-term, but I'd be very surprised to see that hold for the long-term.

We've had plenty of technology trends in the past that have promised faster development but has later turned out to have problems. Organizations that stick around learn lessons about what works and what doesn't.

If in a year's time organizations aren't feeling severe downsides from all of the unreviewed vibe-coded junk they put into production then maybe the vibe-coders were right. I'll believe that when I see it.

[deadbabe]

The problem is downsides are random and not well understood. Sometimes by luck, an organization might not encounter any significant downsides. These kind of survivor case studies will perpetuate the myth that vibe coding is good enough.

The vibe coders aren’t “right”, they just get lucky.

[toastmaster11]

If the vibe coders are right I would give at least 90% of the credit to all the well made libraries, rules, and best practices that developers have built up over the decades. That’s what is embedded into LLMs and what might be the saving grace of slop code bases in the future.

[locknitpicker]

> (...) rules, and best practices that developers have built up over the decades.

It seems you are not understanding that the reason all these "rules, best practices" had to be created in the first place was the fact that your average old times developer was churning out shit code and weaving spaghetti just as hard as today's vibecoders.

Those "rules, best practices" spawned from the same evolutionary pressure as today's instruction files, skills, custom agents, etc.

Why do you think one of the first AI features rolled out by GitHub was the automatic code reviewer?

You guys are talking as if everyone working on software before 2020 was this immaculate developer with pristine sense of architecture and style. No, they were not.

[deadbabe]

They were not, but they were outputting code at a pace that was reasonable to review. Now they go straight to prod, 10x faster.

[toastmaster11]

All that stuff you mentioned is derived from a core set of principles established by decades of software best practices applied to a new means of generating code. Like quite literally those instruction files/skills essentially just reiterate the practices themselves.

To your last paragraph, I never say that nor do I imply it. I find that as a pretty disingenuous interpretation of what I said actually. The practices I mentioned were derived from hard learned lessons and designed as a means of mitigating the human tendency to write bad code.

[locknitpicker]

> All that stuff you mentioned is derived from a core set of principles established by decades of software best practices applied to a new means of generating code.

The whole point is that the problem was already here, and the solutions were developed over a decade ago because the old time way of developing software was exemplary in the volume of shit it generated and had to be reigned in.

It's disingenuous to blame AI for yesterday's problems.

> The practices I mentioned were derived from hard learned lessons and designed as a means of mitigating the human tendency to write bad code.

That's the whole point. It's silly to pretend that AI invented bad code. It was already here, and in high volume. Ironically, AI is contributing to greatly improve the quality of existing code, but as the same shit coders are at the helm of course you still get the result of the same level of oversight.