Frankly, your screed comes off just as ridiculous as the people you're attempting to paint as "the new amish." Those people have valid concerns, which you disregard as irrational because your own irrational, religious/political beliefs don't allow you to consider them.
mapontosevenths2 days ago | | | parent | | on: 47741012
If the concerns were valid they would mention them. They don't.

Instead they pop up in every single thread to complain endlessly about anything that wasn't written using only their preferred tools. They never talk about actual issues with the code. Just the tooling used.

It adds nothing to the conversation, and frankly is boring now.

If you see a problem with the code say that. If the problem is that the author used vim and you prefer emacs, or they used AI and you prefer copy/pasting from stack overflow just go stick your head in a bucket and scream as loud as you like. You'll influence exactly as many people and the only headache you cause will be your own.

nozzlegear2 days ago | | | parent | | on: 47741315
Concerns have been mentioned, in this very thread that you were already replying to. One concern that I share with another user upthread is that vibecoded projects tend to be dumped out into the public and then abandoned, because the effort to produce them is practically zero – there's no investment, the "maintainer" has already moved on to the next ten shiny things.

https://news.ycombinator.com/item?id=47729572

> It adds nothing to the conversation, and frankly is boring now.

It seems to me the boring conversation could've been avoided if the project included a disclaimer that it was vibecoded. I suspect you'll continue to be bored by such trite conversations until that becomes commonplace.

> If you see a problem with the code say that.

Nobody is going to read the code, especially if it's shat out by an overly verbose LLM. @exorcist had a better take on this:

> Perhaps this is a matter of different perspectives? Every tool I use is an investment for me, it might be light if I only use it once, it might be heavy if I use it for years. That investment is all the time I take to learn the various concepts involved and how to think about problems to fit the tool. But it is also all the time needed to constantly keep in mind if that tool is affected by the latest security vulnerability, how changing trends in the industry affects my use of the tool, and what to do if the tool becomes abandonware.

> Reading code is hard. Writing can sometimes even be faster than reading, especially when there are many unknowns involved. So saying "you can just read it" doesn't really work for me. There's no "just" in reading. Taking in new tools is an investment, a burden, and I am perfectly entitled to avoid tools where that burden is harder than the expected outcome. It's impossible to know for sure, of course, but you can often guess pretty good very early.

https://news.ycombinator.com/item?id=47729329