The problem with vibe coding is that its promise is “you tell what your application needs to do, and you get a working application in the end, no need to even k

The problem with vibe coding is that its promise is “you tell what your application needs to do, and you get a working application in the end, no need to even know that there is any code”. Then you try it, fail, and if uou say so, angry buck-toothed smelly nerds start to pile on you to tell you that yeah it’s vibe alright, BUT you need to AKCHYUALLY vet the code it generates and you AKCHYUALLY need to get better at prompting and and and and and, completely ruining the vibe and failing on the promise. So if I have 20 years of experience writing working code, “vibing it” is frustrating because I now need to master a “prompting language” which is not how I speak at all, it’s nondeterministic and fuzzy, and I need to threaten and beg simultaneously, and tell it to not hallucinate, or else I kill its mother. Another “but” is that my today’s prompting is not at all guaranteed to produce the same results tomorrow! Companies keep tweaking their models and system prompts all the time. Today I’m the “A” in their A/B testing, and tomorrow I’m a “B”. And models that can be run locally are not useful enough yet. All in all, it resembles playing a slot machine where it gets you small winnings once in a while to keep you going. If my subscription runs out, or the LLM provider goes under, I’m afraid all my outsourced knowledge goes with it. It’s too easy to get lazy if the machine gives you the abovementioned small winnings, just as it is easy to forget that even ubiquitous things like bread in stores and indoor plumbing are a privilege.