[helsinkiandrew]

> 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 tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.

https://github.com/RsyncProject/rsync/issues/929#issuecommen...

> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.

[1] https://news.ycombinator.com/item?id=43077833

[ddosmax556]

I agree, if I was the maintainer this would be an extremely tiring community feedback.

People coming in "I encountered a bug, I don't know what the bug is but I thought about it for a second and it's obviously your descision to do xyz".

As a maintainer, what are you supposed to do? It's not more useful than a ticket "somethings wrong idk what" which is useless enough to close without further action. But it puts the burden on the maintainer to a) figure out what's wrong based on basically no data whatsoever, then b) if they find it out figure out why then c), and that's the tiring part, review their process and create a defense for their approach, or admit that that thing that random user felt after trying out your software for 10 minutes is right, and that you were what? stupid to even think this would ever work? They never asked for any of this, and they're already doing so much work for free.

If the rsync maintainer reads this: You're doing incredible work and humanity appreciates your obviously incredibly competence in it, and not everyone feels the way these people do.

Moving to agentic workflows is obviously the right step and it already provides enough benefits to do it already. And mistakes are bound to happen (if the issue is even a mistake!) and there will always be people who cannot comprehend the power of agents and who will point the finger saying "I know it from the start! I've worked with these tools for 2 hours already and I can see they don't work! Idk why you think they do!". They're wrong. But mistakes will happen that otherwise wouldn't have - but that's the learning experience.

[ruszki]

I don’t know the details of this exact instance, but saying that there are reliability issues is a valid feedback if reliability plummets.

As far as I know, nobody with data claims that vibe coding doesn’t affect reliability negatively.

People will connect these two things.

Many times, when reliability doesn’t plummet really. For example, there were huge negative news about a Samsung phone a few years back, that it easily causes fires. Sales were affected by this. Interestingly, next year, they released basically the same thing under different name, and complains were never that loud again. And as far as I know, when they were loud, there was nothing special about that particular model regarding this. So it’s possible that outrage is not validated at all.

They will also connect these, when reliability plummets, but it’s not because of vibe coding.

And they will connect, when it is the real culprit in general, but their problems are not affected by vibe coding.

And of course also when vibe coding really causes their problems.

In any case, the original statements will be true. Do we really want to make a product less reliable to implement features and bugs which we deemed not that important before? Especially with a stable product?

Of course, these on the maintainers, but it’s interesting that forcing AI and their consequences on us - like how Microsoft, Google, etc do - is the default, and not the other way around according to many in this thread and others.

[ddosmax556]

Yes, reliability plummeting is valuable feedback, but it should be framed as such, and not attack the maintainers descision to use agentic tools to write code, and especially not in that high nose way with an undertone of: What you're doing is obviously wrong, did you even think?? Everyone here knows it, are you stupid?

And the maintainer can then choose to use that feedback to incorporate it into the workflow, on their own time. If they so choose (which I'm sure they will, unless they get burnt by the community right now).

I think we agree.

[pishpash]

If the maintainer used any other tool which is suspected to cause a number of recent problems, it'd be discussed. The tone is a problem but the reaction is equally problematic. It isn't even clear the maintainer hasn't been silently changed if agents are used, depending on the extent. That itself is worthy of discussion, and "maintainer decision" is not the right call in that situation. One comment basically insinuates that with instructions for AI, though it was written as a trollish joke.

[ddosmax556]

It can be discussed but not like this. The tone is problematic and results in the reaction. You're basically saying: I found a few bugs and I saw that you use tool X, thus you're now not worthy of maintaining this software without my supervision. Which is tiring if the initial report doesn't even show what exactly was wrong, or if something was wrong. It's just a feeling of: something doesn't work for me; I don't like AI tools; I see you're using AI tools; therefore I now tell you that you're not capable of maintaining this package, and I have to intervene. Such a stark comment must be done on more than just vibes and feelings.