Comment by mettamage
9 hours ago
> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not.
Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM.
LLMs allow me to write code faster and it also gives a lot of discoverability of programming concepts I didn't know much about. For example, it plugged in a lot of Tailwind CSS, which I've never used before. With that said, it does not absolve me from not knowing my own codebase, unless I'm (temporarily) fine with my codebase being fractured conceptually in wonky ways.
I think vibecoding is amazing for creating quick high fidelity prototypes for a green field project. You create it, you vibe code it all the way until your app is just how you want it to feel. Then you refactor it and scale it.
I'm currently looking at 4009 lines of JS/JSX combined. I'm still vibecoding my prototype. I recently looked at the codebase and saw some ready made improvements so I did them. But I think I'll start to need to actually engineer anything once I reach the 10K line mark.
> 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.
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.
The original use of the word "vibe code" was very clear.
You don't even look at the diffs. You just yolo the code.
https://x.com/i/status/1886192184808149383
That's a fair point.
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.
"Vibe coding" isn't a "skill", is a meme or a experiment, something you do for fun, not for writing serious code where you have a stake in the results.
Programming together with AI however, is a skill, mostly based on how well you can communicate (with machines or other humans) and how well your high-level software engineering skills are. You need to learn what it can and cannot do, before you can be effective with it.
I use "vibe coding" for when you prompt without even looking at the code - increasingly that means non-programmers are building code for themselves with zero understanding of how it actually works.
I call the act of using AI to help write code that you review, or managing a team of coding agents "AI-assisted programming", but that's not a snappy name at all. I've also skirted around the idea of calling it "vibe engineering" but I can't quite bring myself to commit to that: https://simonwillison.net/2025/Oct/7/vibe-engineering/
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".
The blog appears to imply that the author only opened the codebase after a significant period of time.
> It’s not until I opened up the full codebase and read its latest state cover to cover that I began to see what we theorized and hoped was only a diminishing artifact of earlier models: slop.
This is true vibe coding, they exclusively interacted with the project through the LLM, and only looked at its proposed diffs in a vacuum.
If they had been monitoring the code in aggregate the entire time they likely would have seen this duplicative property immediately.
1 reply →
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.
Agent-assisted coding (AAC) is what I call it. Everyone else around me just calls it vibe-coding. I think this is going to be like "cyber" that we tried to refuse for so long.
1 reply →
> I think we need another term for using an LLM to write code but absolutely not forgetting the code exists.
That is now what software engineering is.
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.
Call it "AI programming" or "AI pairing" or "Pair programming with AI" or whatever else, "vibe coding" was "coined" with the explicit meaning of "I'm going by the vibes, I don't even look at the code". If "vibe coding" suddenly mean "LLM was involved somehow", then what is the "vibe" even for anymore?
I agree there is a spectrum, and all the way to the left you have "vibe coding" and all the way to the right you have "manual programming without AI", of course it's fine to be somewhere in the middle, but you're not doing "vibe coding" in the way Karpathy first meant it.