FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
67% Positive
Analyzed from 1655 words in the discussion.
Trending Topics
#code#software#don#vibe#should#coded#tool#every#used#program
Discussion (44 Comments)Read Original on HackerNews
Feature Request: BGP route lookup using looking glasses of your choice, and Peeringdb lookup for the ASN. https://www.peeringdb.com/apidocs/
https://pluswhois.com
If it provides value who cares?
I mean we could read the code to see if it does anything nefarious. Or have a bought do a check or checks.
But asking every time there’s a show HN is it vibe coded is such gatekeeping elitest nonsense it makes me angry.
It's ok for people to just hate things. I hate spinach for example. Listing all the reasons that my distaste for spinach is irrational won't change that.
Similarly, explaining to the new amish that AI with TDD writess better code than most of the devs I know isn't going to get you anywhere. They don't really care about code quality at all. It's a religious or political belief.
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.
Lots of infected programs provide value. It has nothing to do with being or not being infected.
If a project was vibecoded in a weekend - there are less chances that it will still be maintained in a, say, year or two.
I'm definitely not going to jump in on a vibe-coded project. I'd much rather start from scratch if I found the use-case to be relevant.
Not to say vibe-coded projects can't be alright. If the engineer behind it knows their stuff, it's fine to me. But we don't know that. So to get a general idea, I think it's fair to ask how this was done.
So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable.
Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.
These concerns were great valid even before vibecoding becoming a thing, but now the estimated probabilities of malicious code's presence have changed, simply because nowadays the cost/effort of writing software plummeted.
To make it really funny, that extension should be vibe coded.
Seriously though, it should just be against HN guidelines. It's annoying to see that 90% of the comments are just people fighting over vibe coding on a completely unrelated topic. On this submission? There's only 1 (one) on-topic comment.
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.
There's also a tiny little Amish bakery that I know of. They make all kinds of things there, but the most interesting to me are the loaves of plain white bread that they bake every day (except Sunday) in their wood-fired oven. It is not near to me and is also off the beaten path a good bit, but I try to make a point to go there when I'm in the area. I usually just get a loaf of that plain white bread along with a dozen eggs from the chickens that they have roaming around outside eating bugs.
I wouldn't call any aspect of it artisanal or anything like that, but it's definitely not made by machines.
And for reasons I can't really rationalize or explain, I enjoy having things from the Amish bakery in my kitchen more than I do the superficially similar things that I get from Kroger.
And yet: I usually eat the factory stuff from Kroger. On a strictly functional basis it's about the same to me.
---
Anyway: Software. Did a bot write it? Did a person? Was it a combined effort? Does it even matter?
I can accept that folks might prefer to have software in their library that is written by people. My acceptance of this does not require them to rationalize their preference, or for me to agree with it or even understand it.
It's fine when someone cares about that kind of thing. And it's fine if they don't care, too.
We're allowed to like what we like. It's good to have options, and it's OK to prefer one way over another.
I am trying to say that when people freely share software with the world, I do not think you are entitled to try to add conditions. People are free to share whatever they like, in the conditions they like - in this case the MIT license. Everybody else is free to take the code AS IS.
There is a difference between a commercial transaction and software which is shared without any expectations in return. With software shared without any expectations in return. I don’t believe that we should be trying to create normal practices on top of existing licences or trying to specify under what conditions somebody can share something
> It's fine when someone cares about that kind of thing. And it's fine if they don't care, too. > We're allowed to like what we like. It's good to have options, and it's OK to prefer one way over another.
I agree and never said anything different, but if somebody wants to share under different conditions, then their conditions will always trump yours
I have been using LLMs since August last year, and I know the output they can produce. And I know that the initial output requires refinement in most cases. And that's coming from someone experienced in Software development. LLMs in the hands of people who are not experienced lead to skip a proper review process.
Additionally, it's unreasonable to assume one can take a large codebase and will spend hours on examining the code before. It's not only unreasonable but downright ridiculous.
LLMs are a part of reality right now and they're not going away. Code should be labeled as such. Not doing that is inconsiderate.
> it's unreasonable to assume one can take a large codebase and will spend hours on examining the code before.
This seems to be an issue with your security posture that exists regardless of how the software was written. Do you think malicious or broken software was invented with the advent of LLMs?
People and organizations serious about security absolutely do evaluate unknown software before use. You don’t have to read the code, there are many other ways to evaluate software depending on your risk profile.
To put it another way, if you're enjoying eating sausages then what difference does it make how they're assembled?