Yet I have to say that if you are correct, the term is no different than eating tide pods or dry swallowing cinnamon. Why tf would anyone impose such an absurd artificial constraint on themselves, on the tool, or on whatever they are trying to build? Good faith question, I promise.
Constructing detailed prompts to ultimately pair program impressive, complex outcomes is what I assumed vibe coding was. After 35 years of not being able to tell a computer to write the code for me, even getting an 80% coherent first pass of a sophisticated refactor was already radical enough.
If that's what vibe coding is, then nobody should be using that term because it might be the perfect example of "just because you can, doesn't mean you should".
IDK! I don't think Vibe Coding, with the definition that I understand, is a good idea.
But the term comes from here: https://x.com/karpathy/status/1886192184808149383
And the key parts are:
> "forget that the code even exists"
> "I don't read the diffs anymore"
I myself am unclear on what the "vibes" that one is giving into actually are. But terms should have meanings and my understanding from reading the original tweet is that "Vibe Coding" means something distinct from "coding using some AI to help".
I appreciate the explanation. Off to get some cinnamon, I suppose.
It's the behaviorism of programming. (Pay no attention to the man behind the curtain).
Personally I use the term "agentic coding" if you are high leveling describing the specs to the LLM agent but still taking some minimal amount of time to review the diffs.
Maybe this is pedantic, but I thought that the core point of "Vibe Coding" is that you do not look at the code. You "give in to the 'vibes'".
I don't know how to translate it into a physical hardware product exactly, but I think it would be manufacturing it without looking at it, plugging it in for your use-case and seeing if it works, then going back to the model, saying it didn't work, rinse, repeat.