Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

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.

View on HN

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.

the abstractions around this stuff are still a jenga stack with round pieces... I think it will tighten up over the next year or so for real world use cases. Right now it's great if one is a "build your own tools" kinda person.

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.

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.

The operator is incentivized not to use them property

I want to be able extend the code so I'd say I am incentivized to use it 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.

“Take this CSV of survey data and create a web visualization and create a chloropleth map with panning, zooming, and tooltips” I bypass permissions and it’s done in 10 minutes while I go do some laundry. If I did it myself I would not even be done researching a usable library and I would have zero lines of code. Those studies are total nonsense.

I could see it in cases.

LLMs excel at tasks that are fresh. LLMs are wonderful at getting the first 80% of the way there. -- LLMs are phenomenally good for a first draft or so.

I've had worse experiences for getting LLMs / agents to refactor code. I would believe in many cases it could be quicker to just manually go through and make refinements compared to merely getting the LLM to keep trying.

That seems very intuitive to me. If you want extremely specific changes made at extremely specific locations in an extremely specific way then you probably need to do that yourself because a language model can’t read your mind. I think there are very large set of problems where implementation details do not actually matter and cheap, disposable code is not a problem. I don’t think vibecoding is a good idea for missile guidance. Probably OK for a dashboard a manager isn’t really going to use anyway.

It may not be quicker, but it is often more thorough and less stressful on my old joints. It is also far less tiring.

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.

Reply on news.ycombinator.com