Comment by TeMPOraL
3 days ago
Those stereotypes look more like misconceptions (to put it charitably). Vibe coding doesn't mean one doesn't care about software working correctly, it only means not caring about how the code looks.
So unless you're also happy about not reporting bugs to project managers and people using low-code tools, I urge you to reconsider the basis for your perspective.
This isn't remotely true. Vibe coding explicitly does not care about whether software works correctly because the fundamental tenet is not needing to understand how the software works (& by extension being unable to verify whether it works correctly).
That extension doesn't follow. It is possible to verify if software works without knowing how it works internally. This is true with many things. You don't need to know how a plane/car/elevator works to know that it works when you use it.
I would actually argue that only a small percentage of programmers know what happens in code on an instruction level, and near none on a micro-op or register level. Vibe-coding is just one more level of abstraction. The new "code" are the instructions to your LLM.
> You don't need to know how a plane/car/elevator works to know that it works when you use it.
I'm sure the 737 MAX seemed to work just fine to Boeing's test pilots. Observing the external behavior of a system is not a substitute for understanding its internal workings and the failure modes they carry.
No, vibe coding is about not reading the generated code but you have to check that it works, be it manually or using tests.
If you do not, why are you vibe coding?
Also there are ways to use a coding agent that are different from this and produce great results, like this:
https://friendlybit.com/python/writing-justhtml-with-coding-...
"fundamental tenet"? There's not an engineering pope speaking ex cathedra.
I mean it's new enough to essentially still be a neologism, so you're right - we can give any arbitrary definition to it if we like. I'm just describing my own observations.
1 reply →
Nobody cares how the code looks, this is not an art project. But we certainly care if the code looks totally unmaintainable, which vibe-coded slop absolutely does.
While true, the only anyone has to care that vibe coding* produces technical debt is that the LLM doesn't always properly clean up that technical debt without being prompted to do so, and that when you have too much technical debt your progress slows down regardless of if there's a human or an LLM doing the coding.
To put it another way, ask what code an LLM can maintain, not just what code a human (of whatever experience level) can maintain.
* in the original sense, no human feedback at any point
Proper vibe coding should involves tons of vibe refactoring.
I'd say spending at least a quarter of my vibe coding time on refactoring + documentation refresh to ensure the codebase looking impeccable is the only way my projects can work at all long term. We don't want to confuse the coding agent.
I'm using an LLM to write the code for my current project, but I iterate improvements in the code until it looks like code I wrote myself. I sign off on each git commit. I need to maintain and extend this code, it is to scratch my own itch.
LLMs are capable of producing junk, and they are capable of writing decent code. It is up to the operator to use them properly.
> I'm using an LLM to write the code for my current project, but I iterate improvements in the code until it looks like code I wrote myself.
The prevailing research suggests this is not quicker than just writing it in the first place.
5 replies →
The operator is incentivized not to use them property
2 replies →