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?
Breaking the spell of vibe coding
251–260 of 375 posts
Re: Breaking the spell of vibe coding
#252She 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
#253Earlier 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.
Re: Breaking the spell of vibe coding
#254Earlier 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.
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
#255Earlier 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.
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
#256Earlier 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…
Re: Breaking the spell of vibe coding
#257Earlier 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.
Re: Breaking the spell of vibe coding
#258Earlier 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.
Re: Breaking the spell of vibe coding
#259Earlier 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…
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
#260Earlier 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…