Comment by daveguy
9 hours ago
nullsanity got downvoted into oblivion, but they are correct. This is one of the many reasons why vibe coding produces worse software. The code that is generated and the best practice recommendations are completely separate. They both come from a distribution of "most common", and best practice is rarely common. Especially when a practice is first established, or in a specific niche.
Unless you are referencing some existing non vibe coded app, complaints the project being vibe coded may be just too generic at this point.
A hand coded electron project would have a discussion about electron vs native. Relevant in general but off topic in the context of this particular app.
idk about that. The big labs and their data providers are spending millions of dollars building up expert datasets. I was offered $120/hr to critique outputs and provide my own designs. Thats clean and high quality data, not the average internet word distribution
Maybe the real question is: who cares?
What’s the downside risk of having "worse software" when you’re just ideating and putting things out there to see how people like it.
Your idea can be great, but if the implementing is bad, people still may not like it, and you’ll never know that’s the cause.
Worst case:
- release vibe coded tool
- on HN, someone says, d'oh, you should be using Y, not X
- give that comment to your LLM
- LLM: "The commenter on Hacker News is absolutely right, my mistake. I can easily replace X with Y if you want"
- release a new, better version of vibe coded tool
Iteration, in one afternoon.
And manager types in software still haven't figured out that prototypes should not be the final product. In engineering it's common knowledge and only rarely do you take a proof of concept directly to production.
Kind of like "history is written by the victors"
Isn’t that why you use a plan mode? Or better, use a plan mode, revise and critique the plan, and then let it proceed to build?
On the flipside, it also leads to better software.