[see https://news.ycombinator.com/item?id=48416020 for how all this happened in the first place]
Did Claude increase bugs in rsync?
91–100 of 611 posts
Re: Did Claude increase bugs in rsync?
#92Earlier quoted context omitted.
Sorry to say but I'm absolutely certain I would've preferred to read your worst attempt at a write-up over the grating utter shite LLMs output. It's not even a question, this is unreadable.
I read it perfectly fine. I see content, not style.
Re: Did Claude increase bugs in rsync?
#93Earlier quoted context omitted.
I really struggle to believe you wrote text like: > A simple distributional analysis of every rsync release with bug data. No model. No assumptions. Just placement.
In general, it seems HN does not like to read llm-generated articles. I ran into this myself when using an llm to edit some stuff I wrote. At the time, I found this a bit irritating, but with a few weeks time I see the merit. The informational content tends to fall into “derivative” territory when LLM’s write stuff. And people are here for novelty and some socialization. Also LLM prose seems optimized for engagement…
Re: Did Claude increase bugs in rsync?
#94Re: Did Claude increase bugs in rsync?
#95- The release with the highest number of attributed bugs is the release _right before_ the first release with Claude-coauthored commits, released in January; is there a chance that unattributed LLM-authored commits made it into this release?
- The release attribution methodology is not great, since it will tend to attribute bugs introduced in a minor version update to the longest-lived patch release of that minor version. I doubt that 3.4.1 actually introduced a lot of bugs, but since it was released a day after 3.4.0, bugs that were introduced in that release get attributed to 3.4.1.
- Relatedly, more recent releases have had less time to have bugs filed against them, so there may be a bit of a bias toward evaluating recent releases as less buggy.
Re: Did Claude increase bugs in rsync?
#96> The analysis uses a single metric: bugs per 10 commits (bugs/10c). Bugs per commit as a metric papers over severity, both in terms of security severity as well as the effect on the user. A mislabeled button has the same weight as the entire app crashing in this framework.
IMO "bugs per commit" is even worse than that, because, in addition to what you say, it also hides the extraordinary spike of commit activity of a project that had previously been stable. [0] It is the exact metric you'd choose if you wanted to make the current situation of rsync look like not a big deal. [0] https://github.com/RsyncProject/rsync/graphs/commit-activity
Re: Did Claude increase bugs in rsync?
#97Re: Did Claude increase bugs in rsync?
#98Earlier quoted context omitted.
IMO "bugs per commit" is even worse than that, because, in addition to what you say, it also hides the extraordinary spike of commit activity of a project that had previously been stable. [0] It is the exact metric you'd choose if you wanted to make the current situation of rsync look like not a big deal. [0] https://github.com/RsyncProject/rsync/graphs/commit-activity
Yes, but we know why there was an "extraordinary spike," and it has nothing to do with rsync being "vibe coded." The maintained has directly addressed this.
Re: Did Claude increase bugs in rsync?
#99What followed was extraordinary: 329 comments and counting, ranging from thoughtful concern to outright harassment. The thread did not stop at words. One user posted My Little Pony drawings of themselves strangling the "project janitor that pushed vibecoded commits": It spread to Hacker News and Lobsters, generating hundreds more comments. This is false, it did not appear on Lobsters. Here is the function in the code…
> On Lobste.rs, in response to the Medium essay Tridge himself posted in response, finally some users like boramalper begin to actually ask for evidence one way or another:
Re: Did Claude increase bugs in rsync?
#100Unfortunately for the people mad about this, I predict the only thing they will accomplish by pressuring the rsync maintainers, is to discourage everyone else from responsibly disclosing their use of AI. You’re just going to make people disable Claude attribution on their commits to avoid drama.