The Rsync thing was inevitable and it’s happening everywhere

Robert’s Substack

SubscribeSign in

The Rsync thing was inevitable and it’s happening everywhere

Robert Webb<br>Jun 01, 2026

Share

Lately there was an issue with ai commits to rsync: reddit, hacker news. This caused some bugs in rsync. Then people responded by opening issues and having nasty arguments.<br>There are many such packages

It’s not just happening to rsync, that is just the tip of the iceberg. This is somewhat obvious given the “it’s never just one rat” theorem1. If you can see one obvious rat, that means many more are hidden. Given that rsync, which is a beloved and famous package, has this problem, there are many more less famous packages that have this issue.2<br>If you are not pinning your dependencies, you are going to see bugs in production.<br>As a society, we have just cracked open the ability for AI to write code as competently as an engineer3, and it is also as flawed as an engineer. Every line of code written is a liability that needs to be well tested, at scale, often in production, before we can be sure that it does not have issues. This has always been true. AI has only enabled a much higher velocity of contributions.<br>Of course, you will still have to update dependencies sometimes, but if you’re on the bleeding edge of anything right now, you are willingly signing up for bugs, and you should not be complaining. Your favorite project will be a bug ridden mess. This is the era we now live in. It will quickly become a regular occurrence, just like NPM package worms or GitHub outages.<br>The Github backlash

The Github community reacted to this in an incredibly inappropriate way. We should not be using GitHub to harass maintainers. If someone wants to take their open source project and then ruin it, that’s their right. You can always fork. I know this is somewhat unsatisfying to the reddit mob, but as programmers, we should hold ourselves to a higher standard when communicating online. Open source maintainers are almost always working for free, or are highly underpaid. They tend to be highly accomplished programmers, and they deserve some respect.<br>I’m sure some people will say that suggesting to just fork the code is not the right thing to do. However, the alternative is pressuring a volunteer with harassment. I’m all for the diplomatic route, but when that has failed, you should walk away. I’m sure a lot of this is just due to the nature of social media, maybe Github has to start banning accounts that participate in social media mob brigades or something.<br>Will this be better in the future?

Given the breakneck speed of AI model intelligence improvements, we will possibly see that they have even better contributions to code. However, the nature of code will not change, and it will always introduce bugs, no matter how well written it is. Some maintainers may understand this and be somewhat limited on what kind of PRs they merge, and perhaps mitigate the issue by having canary releases, or other such well known methods of reducing releasing bugs to prod. Inevitably, some projects won’t, and people who update to their latest release will find nasty bugs written by ai.<br>And inevitably, each time it happens, people on social media will get very upset and start harassing the maintainer on Github (assuming it is not down). And there will be another blog post on it.<br>1I made this up. Or maybe I heard it from someone else and forgot.

2It’s possible that only famous packages actually get massive contributions from AI, so it may also be much less widespread.

3This is hyperbole, or completely true, depending on who you ask.

Share

Discussion about this post<br>CommentsRestacks

TopLatestDiscussions

No posts

Ready for more?

Subscribe

© 2026 Robert Webb · Privacy ∙ Terms ∙ Collection notice<br>Start your SubstackGet the app<br>Substack is the home for great culture

This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts