Live data from Hacker News

Please Do Not Vibe Fuck Up This Software

github.com

261–270 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#261
post #42

Earlier quoted context omitted.

> is almost completely context free on what the drama is beyond "Claude" As soon as it happened their rsync based backup system that was working before started to fail. It says right there.

The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working. A users bald assertion that something is "broken" with no details should be regarded with suspic…

> Nothing but dripping contempt for their betters.

I didn't see this.

Re: Please Do Not Vibe Fuck Up This Software

#262
post #188
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.…

I feel really bad for the sense of entitlement a lot of open source devs have to deal with. Imagine building something for free as a hobby then having to deal a mob of angry people who have never paid you whenever you do something they don’t like. Surely your first thought would be to tell them to foxtrot oscar somewhere else.

That's not my experience. Users naturally get frustrated when I break the software that they rely upon, and sometimes they use strong words, but the resulting conversation is almost always friendly and productive. (There are exceptions, of course, but that's life, right?)

Here's a recent sample, paraphrased for brevity:

Them: this is broken.

Me: no, it's not broken.

Them (a few days later): "I think I must not have tried all the combinations", followed with two pages of transcripts.

Me: "I've just checked the code, and you're right [...] I'm extremely sorry I wasted your time."

Them: "Heh, it's all good. I'm am chuffed you're taking the time to give thoughtful responses with me"

Source: https://github.com/jech/galene/issues/309

Re: Please Do Not Vibe Fuck Up This Software

#263

Earlier quoted context omitted.

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

That doesn't make it any better. At all.

Re: Please Do Not Vibe Fuck Up This Software

#264

I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence. The actual Claude "churn" is mainly test suite enhancement.

One of the most reliable OSS sync/backup tools on the planet for 2+ decades broke under people's daily backup use of it because of a large pile of LLM-driven changes basically out of nowhere from the project maintainer in a minor point release. I think they're right to be annoyed and to complain about it. Whilst a lot of the Claude changes are test related, there were still other changes that obviously broke things f…

I wonder if the maintainer got jumpy because of all the llm generated valid bug reports lately?

Re: Please Do Not Vibe Fuck Up This Software

#265

Earlier quoted context omitted.

As HN consists of more than two people, it is home to multiple contradictory opinions. Furthermore, both points may be valid. As a user you might want working software, and as an open source maintainer, you aren't beholden to what the users want.

Sure, but you cannot deny the hypocritical swarm behavior, which is the point.

> the hypocritical swarm behavior, which is the point.

That's exactly why that "point" is inherently nonsense. It's right there, you just wrote it yourself. If you lump people together "as a group", and some of them have different opinions on something, that doesn't make any of them a hypocrite. And the group can't be hypocritical either, because it's just your abstraction, not an actual group that communicates and coordinates and decides what "official" stance to take on certain issues.

Re: Please Do Not Vibe Fuck Up This Software

#266

Earlier quoted context omitted.

You have to keep an eye on them, but they don't just make tests pass.

Claude sonnet 4 (this time last year) did do this. It once made simulation if a test script passing. Literally a script that just echoed test names and then said pass.

Change happens fast, a year old model is pretty outdated.

I'm sure it can happen, hence why I said to keep an eye out. Its main mode of operation is not to cook the tests however.

Re: Please Do Not Vibe Fuck Up This Software

#267
post #231

Earlier quoted context omitted.

Spamming an open source developer with angry comments because they decided to use a new tool for the code they write and publish freely is not normal.

This is rsync we are talking about. A bug in rsync basically means lost data and/or unreliable backups. I think it's normal to be pissed at lost data. Maybe it's not socially acceptable to spit in the face of a volunteer but it's 100% human to feel annoyed by an obvious drop in code quality.

The thing is, showing the annoyance to the volunteer, who is already doing their best, has two possible outcomes:

1) they stop volunteering

2) they will ignore you

In neither of that is your issue solved. So maybe it's better to deal with the frustration on your own and then file a bug report.

Re: Please Do Not Vibe Fuck Up This Software

#268
post #240

Earlier quoted context omitted.

Regressions are bad and need to not happen.

Would you hold off on fixing a security vulnerability if it caused a limited regression? Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.

Which part of security fixing demands thoughtless generation of code slop without regression testing though?

I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.

Re: Please Do Not Vibe Fuck Up This Software

#269
post #125

Earlier quoted context omitted.

> I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural referen…

> and grasp at every straw to combat it, which is a sane response Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response". What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such beh…

[flagged]

Re: Please Do Not Vibe Fuck Up This Software

#270
post #254

Earlier quoted context omitted.

Regressions are bad and need to not happen.

Regressions are bad and they should be avoided. Still, software engineering is a complex thing and regressions happened long time before coding agents were a thing. Unless one can pinpoint regression to changes that were more sloppy than the human-written rsync commits were I don't think coding agents are to blame.

Seems like that it's not that coding agents are to blame, its that the people who are ultimately responsible for committing and merging the offending code are to blame, regardless of its origin.
Post reply on HN