> Even ignoring the semantic drift that has happened since he coined the term (on which there have already been a few HN threads), the key part of Karpathy's definition is "...and forget that the code even exists." Which is why I was careful to phrase it thus:
The point of bringing up the exact definition is to draw a clear line on what defines "vibe-coding" in the first place. There is no "semantic drift" and, karpathy's entire tweet is used as the definition and I don't think you can separate any part of it at all.
In your first post, you mentioned "vibe coding" and by definition it includes not looking at the code and accepting all changes the AI agent suggests and copy pasting errors back to the agent until it is fixed without any understanding; exactly how karpathy first defined it.
> It is pretty clear that "giving in to the vibes" is simply "looking at the results."
Seems like you don't even understand what vibe coding is. "giving into the vibes" is not just looking at the results, it is not looking at the code and accepting all the agent's output without any understanding of the code.
> But I'm predicting that it is going to be an engineering discipline in itself. Note that I started with (emphasis added):
"Vibe coding" is not engineering anymore than "coding" is not software engineering.
> And then I went on to explain the engineering aspect as extensive technical validation. There is a role called Validation Engineers in many industries including semiconductors, and I posit that it's going to be everybody's primary role soon.
It already is, in the form of quality assurance. This was there for years alongside formal verification engineers and validation engineers for years and "vibe coding" is incompatible with all of this and breaks the software development lifecycle.
These roles were already a given at many companies, so there is nothing new that you actually said.