Live data from Hacker News

The problem with "vibe coding"

dylanbeattie.net

131–140 of 154 posts

Re: The problem with "vibe coding"

#131
post #63

Earlier quoted context omitted.

Dude, ask ChatGPT to explain the analogy for you. It understood well enough. It will save both of us some time. Maybe AI is useful for some things after all.

Not sure about the reason for the personal attack, but my comment wasn't a reply to you. Michelin star restaurant was not even your analogy. I guess you are right, though. AI is useful for some things. At least it reads the prompt before responding.

> Michelin star restaurant was not even your analogy

Precisely.

Re: The problem with "vibe coding"

#132
post #68

Earlier quoted context omitted.

Please, think about what you just said. How can I feed to it context about a DSL that does not exist yet?

> How can I feed to it context about a DSL that does not exist yet? My example referred to ARM templates. They do exist, don't they?

I guess they do. But if that's the case then your comment brings nothing new to the discussion.

Re: The problem with "vibe coding"

#133

Earlier quoted context omitted.

So can any human-based sources. A healthy learning experience with AI takes discipline, just as it does with humans.

The amount of errata in technical books is very small compare to the length of the book. I believe it ranges from none to a page or two.

I think that's an oversimplified metric when comparing the ability of an AI to analyze and describe code. Imaging you're reading a book on a challenging new topic. Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret. A book won't correct you, offer alternate explanations, or break down concepts any further than what was already written.

An LLM, for all its flaws, can do these things exceedingly well (provided it has good source material, of course). This gives you the ability to get answers to your questions and correct your mistakes. I'd argue that these benefits far outweigh the errors an LLM makes in breaking down and explaining material, and make an LLM better than a book in many (not all) cases.

Re: The problem with "vibe coding"

#134

'The problem' is this species prefers doing instead of thinking. 'Vibe coding' is merely an instance.

If you haven't already read it, you'd probably enjoy "How big things get done" by Brent Flyvbjerg and Dan Gardner - what you said is the central thesis of the book.

Reading books is an instance of doing instead of thinking in many cases :)

Re: The problem with "vibe coding"

#136

I wish there were no "software products" at all. They usually just come in the way. I favor open source, and not imposing unnecessary constraints on users. Every piece of software should be swappable, and tying it to a vendor makes it less so.

similar thought if you were running a sport franchise as a GM and saying imma make a team where every player is swappable except of course swapping lebron might not be all that feasible :)

This was precisely the dilemma you'd have playing Speedball 2.

Re: The problem with "vibe coding"

#137

This is about the problem with vibe coding your way to a product. But if the vibes are strong enough, maybe we don't need products at all? They do tend to complicate things, with all of their moats and such. I never wanted a product that did the thing, I really just wanted to do the thing. "Works on my machine" might be good enough if you're unlikely to want to repeat yourself on a different machine.

> I never wanted a product that did the thing, I really just wanted to do the thing.

Would you vibe code your daily driver car's ECU or a high-frequency trading application to use for your 401k? If you were to do these things (more power to you), I rather suspect you'd still do a whole lot of research and critical thinking beforehand, which sort of obviates the "vibes".

Re: The problem with "vibe coding"

#138
post #133

Earlier quoted context omitted.

The amount of errata in technical books is very small compare to the length of the book. I believe it ranges from none to a page or two.

I think that's an oversimplified metric when comparing the ability of an AI to analyze and describe code. Imaging you're reading a book on a challenging new topic. Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret. A book won't correct you, offer alternate explanations, or break down concepts any further than what was already written. An LLM, for all its flaws…

> Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret.

Which is why no one reads only one book on a particular subject, especially if one is new to the domain. Often you bring in an alternate, but correct perspective from another book. The risks of hallucination with LLMs' responses outweighs the advantage of multiple perspectives (even if a broken clock is right twice a day, you still want a working one)

Re: The problem with "vibe coding"

#139
This article starts to touch on an important distinction between software and products, but seems to miss the larger picture.

With the cost of developing software dropping to near zero, there are a whole class of product features that may not be relevant for most users.

> You haven’t considered encoding, internationalization, concurrency, authentication, telemetry, billing, branding, mobile devices, deployment.

Software, up until now, was only really viable if you could get millions (or billions) of users.

Development costs are high, and as a product developer you're forced to make software that covers as many edge cases as possible, so that it can meet the needs of the most people.

I like to think of this type of software as "average" -- average in the sense that it's tailored not to one specific user or group of users, but necessarily accommodating a larger more amalgamous "ideal" user.

We've all seen software we love get worse over time, as it tries to expand it's scope to more users.

Salesforce may be the quintessential example of this, with each org only using a small fraction of it's total capabilities.

Vibe coding thus enables users to create programs (rather than products) that do exactly what they want, how they want, when they want. Users are no longer forced into the confines of the average user, and can instead tailor software directly to their needs.

Is that software a product? Maybe one day. For now, it's a solution.

Re: The problem with "vibe coding"

#140
post #133

Earlier quoted context omitted.

I think that's an oversimplified metric when comparing the ability of an AI to analyze and describe code. Imaging you're reading a book on a challenging new topic. Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret. A book won't correct you, offer alternate explanations, or break down concepts any further than what was already written. An LLM, for all its flaws…

> Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret. Which is why no one reads only one book on a particular subject, especially if one is new to the domain. Often you bring in an alternate, but correct perspective from another book. The risks of hallucination with LLMs' responses outweighs the advantage of multiple perspectives (even if a broken clock is righ…

No one reads only one book on a subject? People act on mere headlines all the time. Reading one whole book would be a huge win over the status quo

> The risks of hallucination with LLMs' responses outweighs the advantage of multiple perspectives

You can ask a model a question multiple times. You can ask different models the same question. You can ask the same question different ways. You can do this automatically with agentic frameworks or reasoning models. "Multiple perspectives" are compatible with language models.

Post reply on HN