> My way is to understand my own codebase and look at the output of the LLM.
Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
I don't think the OP was using the classic definition of vibe coding, it seemed to me they were using the looser definition where vibe coding means "using AI to write code".
I think this is my main confusion around vibe coding.
Is it a skill for the layman?
Or does it only work if you have the understanding you would need to manage a team of junior devs to build a project.
I feel like we need a different term for those two things.
That is the correct definition of vibe coding "fully giv[ing] in to the vibes, embrac[ing] exponentials, and forget[ting] that the code even exists."
I think we need another term for using an LLM to write code but absolutely not forgetting the code exists.
I often use LLMs to do refactoring and, by definition, refactoring cannot be vibe-coding because that's caring about the code.
I don't know anybody except the bleeding edge people (Steve Yegge) or non-engineers that are actually "vibe coding" to this definition.
I know what you mean but to look that black and white at it seems dismissive of the spectrum that's actually there (between vibecoding and software engineering). Looking at the whole spectrum is, I find, much more interesting.
Normally I'd know 100% of my codebase, now I understand 5% of it truly. The other 95% I'd need to read it more carefully before I daresay I understand it.
This seems to be a major source of confusion in these conversations. People do not seem to agree on the definition of vibe coding. A lot of debates seem to be between people who are using the term because it sounds cool and people who have defined it specifically to only include irresponsible tool use, then they get into a debate about if the person was being irresponsible or not. It’s not useful to have that debate based on the label rather than the particulars.