Live data from Hacker News

Please Do Not Vibe Fuck Up This Software

github.com

171–180 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#171

A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.

Describing the issue as “violent” is wild. Reading through a bit, it’s massive, it’s clear no one involved has the moral high ground here. The polite response is to close the issue if you believe it’s genuinely off topic.

Still not quite sure what you mean by obvious because to me “Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code.” Is much more violent than “please do not vibe fuckup this software”.

Re: Please Do Not Vibe Fuck Up This Software

#172
Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares?

If a maintainer just accepts any code, without review or control, humans, just as well as "AI:s" can submit crappy code.

I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.

Re: Please Do Not Vibe Fuck Up This Software

#173

Earlier quoted context omitted.

> Why do we need AI here? As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1] https://github.com/RsyncProject/rsync/issues/929#issuecommen... > The issue t…

[flagged]

The result might be closing bug trackers for the core open source projects. Or make them invite only. Even fundamental projects like Linux or LLVM accept AI contributions.

Re: Please Do Not Vibe Fuck Up This Software

#174
post #11

Earlier quoted context omitted.

When I look at the commits themselves, most of the ones generated by Claude are testsuite changes, or at least labelled as such. https://github.com/RsyncProject/rsync/commits/master/

Is that suppose to make this better? IME the most valuable tests are those that test specific regressions. It's the scaffolding we build for ourselves to enable feature development. Remove that scaffolding and you get accidents. Pray to your god of choice these accidents don't cause harm or loss of life. It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we…

> Is that suppose to make this better?

When I first saw the 26k changes statistic I was shocked. It made me think a large chunk of code running on people’s machines was AI-generated.

But the knowledge that a lot of the changes might be testsuite changes made me change my perspective. If for instance 25k of the changes were test changes and only 1k of the changes actually affected the .so and other artifacts used downstream, that would be a lot less dramatic.

I haven’t reviewed the code, only the messages, so I don’t know if these changes were removing or adding test cases. And there are a minority of Claude-assisted changes which are not listed as tests.

Re: Please Do Not Vibe Fuck Up This Software

#175
post #142

Earlier quoted context omitted.

“No warranty” isn’t the same as “no complaints”. Otherwise there wouldn’t be an issue tracker and a discussions section. The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.

An Issue tracker is to track issues regarding the behaviour of the program, not the behaviour of the maintainer.

And focusing on that after the fact does nothing to resolve the situation or advance the discussion, which should be the goal now.

During an emergency situation where an issue is running out of control, the priority is to evaluate and contain the problem then address it, it is not the time to assign blame and quote regulations which weren’t followed. That’s for later, when everything is stable, together with understanding why the rules weren’t followed and if you can improve that process for the future.

Re: Please Do Not Vibe Fuck Up This Software

#176

A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.

Describing the issue as “violent” is wild. Reading through a bit, it’s massive, it’s clear no one involved has the moral high ground here. The polite response is to close the issue if you believe it’s genuinely off topic. Still not quite sure what you mean by obvious because to me “Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code.” Is much more violent than “please do…

The "Stop. You know nothing." comment was apparently a reference to this tweet. https://x.com/CodyRhodes/status/980680154098757632

Embarassing nonetheless

Re: Please Do Not Vibe Fuck Up This Software

#177
post #139

Earlier quoted context omitted.

> It's not silly to have issues with something. I absolutely understand and agree. As I said, I understand the underlying reason. The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)

I'd argue there would be two lanes as well: one where the issues are addressed in code, the other being the discussion of why people think this is a bad idea and speak so openly about it. This topic is the second I guess. Looking at the flow there is quite a bit of flamebait by the LLM and non-LLM camps which only muddies the water and doesn't resolve anything. The better discussion (imo) would be to decide if the vi…

idk maybe LLM people should only commit what they actually understand, only in bite-size (maximum few lines in few files) and with at least 1~5 tests that shows the edge cases

drive-by 20-file pull-requests that ultimately end up costing maintainer's burden seems to hit hard here.

Re: Please Do Not Vibe Fuck Up This Software

#178

Earlier quoted context omitted.

> Why do we need AI here? As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1] https://github.com/RsyncProject/rsync/issues/929#issuecommen... > The issue t…

[flagged]

> But I think if people want to continue using LLM shit, they need to be ready to weather ALL criticism that comes with it.

And if they don't then too? Because why should they not have to weather ALL "criticism" that comes with writing open source software?

Apparently there are lots of people defending comments that "are obviously out of line and [...] ragebaiting". That sure makes being an open source developer enjoyable!

Re: Please Do Not Vibe Fuck Up This Software

#180
post #59
post #36

I truly don't get it You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes. Why do we need AI here? And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.…

wtf is this comment section? The author of these commits were tridge & claude. What does tridge have to do to convince the open source community that he might be a legit programmer & have a clue? Samba? Whats that? Rsync? Never heard of it. Tivo? No clue (maybe more Australian context here than others, but still). Even the comments on the github issue, are totally devoid of the context that this is a very senior open…

[flagged]
Post reply on HN