Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

251–260 of 375 posts

Re: Breaking the spell of vibe coding

#251
post #246

Earlier quoted context omitted.

>the failure mode is invisible Only if you are missing tests for what counts for you. And that's true for both dev-written code, and for vibed code.

Who writes the tests?

It doesn't seem obvious that it's a problem for LLM coders to write their own tests (if we assume that their coding/testing abilities are up to snuff), given human coders do so routinely.

Re: Breaking the spell of vibe coding

#252
> Vibe coding is the creation of large quantities of highly complex AI-generated code, often with the intention that the code will not be read by humans.

She unfortunately lost me at the first sentence. I cannot get business value out of that, so I don't do that at work.

What I can do is design a situation where I can get business value out of having the AI agent do one thing where the details are too annoying/boring for me to do. Then I read the PR and I decide if the parts about where the data comes from, how it is massaged, etc are right. Then I scan over the HTML and CSS templating garbage I have no interest in and then I post the PR for review.

This is exactly the opposite of what she's talking about, and it's working great for me and my colleagues.

Re: Breaking the spell of vibe coding

#253
post #75
post #21

Earlier quoted context omitted.

I think it's like the California gold rush. Anybody and their brother can go out and dig, but the real money is in selling the shovels.

More like they’re leasing away deeply discounted steam shovels at below market rates and somehow expecting to turn a profit doing so. The real profits are the companies selling them chips, fiber, and power.

If it's below market rates, the people using the shovels are the ones making a profit.

Re: Breaking the spell of vibe coding

#254
post #75
post #21

Earlier quoted context omitted.

I think it's like the California gold rush. Anybody and their brother can go out and dig, but the real money is in selling the shovels.

More like they’re leasing away deeply discounted steam shovels at below market rates and somehow expecting to turn a profit doing so. The real profits are the companies selling them chips, fiber, and power.

Impossible to say right now... consider just the idea of reactive agentic workflows: test fails, agent is instantly triggered and response is passed off for review, or whatever, something along those lines.

Thats staying power, suddenly that lease isnt a lease, its an ongoing cost for as long as that system exists. its gas.

Re: Breaking the spell of vibe coding

#255
post #246

Earlier quoted context omitted.

Who writes the tests?

It doesn't seem obvious that it's a problem for LLM coders to write their own tests (if we assume that their coding/testing abilities are up to snuff), given human coders do so routinely.

This thread is talking about vibe coding, not LLM-assisted human coding.

The defining feature of vibe coding is that the human prompter doesn't know or care what the actual code looks like. They don't even try to understand it.

You might instruct the LLM to add test cases, and even tell it what behavior to test. And it will very likely add something that passes, but you have to take the LLM's word that it properly tests what you want it to.

Re: Breaking the spell of vibe coding

#256
post #239

Earlier quoted context omitted.

A good analogy might be synthesized music. In the early days, the interfaces were so complex and technical, that only engineers could use them. Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently. A lot of others, not so much. They twiddled knob…

I have been a lead engineer for a few decades now, responsible for training teams and architecting projects. And I've been working heavily with AI. I know how to get Claude multi-agent mode to write 2,500 lines of deeply gnarly code in 40 minutes, and I know how to get that code solid . But doing this absolutely pulls on decades on engineering skill. I read all the core code. I design key architectural constraints. I…

What I've found out is that a lot of people don't actually care. They see it work and that's that. It's impossible to convince them otherwise. The code can be absolutely awful but it doesn't matter because it works today.

Re: Breaking the spell of vibe coding

#257

Earlier quoted context omitted.

With handwritten code, the humans know what they don’t know. If you want some constants or some formula, you don’t invent or guess it, you ask the domain expert.

> With handwritten code, the humans know what they don’t know. I find this often not to be the case at all.

Let's put it this way: the human author is capable of doing so. The LLM is not. You can cultivate the human to learn to think in this way. You can for a brief period coerce an LLM to do so.

Re: Breaking the spell of vibe coding

#258
post #246

Earlier quoted context omitted.

Who writes the tests?

It doesn't seem obvious that it's a problem for LLM coders to write their own tests (if we assume that their coding/testing abilities are up to snuff), given human coders do so routinely.

Maybe it’s just the people I’m around but assuming you write good tests is a big assumption. It’s very easy to just test what you know works. It’s the human version of context collapse, becoming myopic around just what you’re doing in the moment, so I’d expect LLMs to suffer from it as well.

Re: Breaking the spell of vibe coding

#259
post #53

Earlier quoted context omitted.

It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?

A good analogy might be synthesized music. In the early days, the interfaces were so complex and technical, that only engineers could use them. Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently. A lot of others, not so much. They twiddled knob…

I like the analogy but I think you are underestimating how much random knob twiddling there is in all art.

Francis Bacon and The Brutality of Fact is a wonderful documentary that goes over this. Bacon's process was that he painted every day for a long time, kept the stuff he liked and destroyed the crap. You are just not seeing the bad random knob twiddling he did.

Picasso is even better. Picasso had some 100,000 works. If you look at a book that really gets deep to the more obscure stuff, so much of Picasso is half finished random knob twiddling garbage. Stuff that would be hard to guess is even by Picasso. There is this myth of the genius artist with all the great works being this translation of the fully formed vision to the medium.

In contrast, even the best music from musical programming languages is not that great. The actual good stuff is so very thin because it is just so much effort involved in the creation.

I would take the analogy further that vibe coding in the long run probably develops into the modern DAW while writing c by hand is like playing Paganini on the violin. Seeing someone playing Paganini in person makes it laughable that the DAW can replace a human playing the violin at a high level. The problem though is the DAW over time changes music itself and people's relation to music to the point it makes playing Paganini in person on the violin a very niche art form with almost no audience.

I read the argument on here ad nauseam about how playing the violin won't be replaced and that argument is not wrong. It is just completely missing the forest for the trees.

Re: Breaking the spell of vibe coding

#260
post #239

Earlier quoted context omitted.

A good analogy might be synthesized music. In the early days, the interfaces were so complex and technical, that only engineers could use them. Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently. A lot of others, not so much. They twiddled knob…

I have been a lead engineer for a few decades now, responsible for training teams and architecting projects. And I've been working heavily with AI. I know how to get Claude multi-agent mode to write 2,500 lines of deeply gnarly code in 40 minutes, and I know how to get that code solid . But doing this absolutely pulls on decades on engineering skill. I read all the core code. I design key architectural constraints. I…

[dead]
Post reply on HN