@aburka To be fair, they aren't welcoming slop PRs. They are welcoming AI contributions, but the PRs are still at the discretion of the developers. So the developers bear the responsibility. This gives them an incentive to properly vet the AI contributions.
The main goal here was to increase transparency around AI use among the developers. I suspect many of them had already been using AI before the policy. Now they are obligated to report when and where they used it. It's impossible to completely ban AI use, so there was really no better anti-AI alternative than to increase transparency.
I personally don't like it, and I think it's a slippery slope. But I see it less as a "pro-AI" move and more as a "monitor AI use" move. I think other projects should adopt a similar policy.
@hyperreal actually, it's quite possible to completely ban AI usage. Here is a sample policy:
"AI generated contributions are not allowed in this project. Undisclosed usage of AI will result in a ban."
Fedora chose a different route, which I believe will prove to be a mistake.
What you are saying is that it's impossible to completely *prevent* AI-generated contributions, because even against a clear policy like I outlined above, people can lie. That is true. But I reject the conflation of *prevention* with *banning*. It's also impossible to completely prevent contributions that are plagiarized from other people, or contributions containing backdoors. But nobody would write a policy saying those things are allowed.
It's always a choice, and Fedora (and so many other projects) chose.
Affinity: Explicitly made as an alternative to Adobe's rent-seeking middleman subscription grift & refusing to jump on the AI bandwaggon - and then bought this year by Canva, who immediately made it "free" ( = precursor to subscription) & added AI...
Arguably, Ruby on Rails itself because of DHH. Poor @Eugen Rochko must be probably considering how much of a rework would it take to move #Mastodon 's source code away from Ruby.
We are using keepassXC and your message is really scary. I mean, coding a password manager without leaving vulnerabilities is hard. Vibe coding a password manager is just... I don't even know what to say at this point. Are we doomed?
Max
in reply to Deborah Pickett • • •aburka 🫣
in reply to Deborah Pickett • • •hyperreal
in reply to aburka 🫣 • • •@aburka To be fair, they aren't welcoming slop PRs. They are welcoming AI contributions, but the PRs are still at the discretion of the developers. So the developers bear the responsibility. This gives them an incentive to properly vet the AI contributions.
The main goal here was to increase transparency around AI use among the developers. I suspect many of them had already been using AI before the policy. Now they are obligated to report when and where they used it. It's impossible to completely ban AI use, so there was really no better anti-AI alternative than to increase transparency.
I personally don't like it, and I think it's a slippery slope. But I see it less as a "pro-AI" move and more as a "monitor AI use" move. I think other projects should adopt a similar policy.
aburka 🫣
in reply to hyperreal • • •@hyperreal actually, it's quite possible to completely ban AI usage. Here is a sample policy:
"AI generated contributions are not allowed in this project. Undisclosed usage of AI will result in a ban."
Fedora chose a different route, which I believe will prove to be a mistake.
What you are saying is that it's impossible to completely *prevent* AI-generated contributions, because even against a clear policy like I outlined above, people can lie. That is true. But I reject the conflation of *prevention* with *banning*. It's also impossible to completely prevent contributions that are plagiarized from other people, or contributions containing backdoors. But nobody would write a policy saying those things are allowed.
It's always a choice, and Fedora (and so many other projects) chose.
JWcph, Radicalized By Decency
in reply to Deborah Pickett • • •Carlos Solís
in reply to Deborah Pickett • • •Eugen Rochko
in reply to Carlos Solís • • •Carlos Solís
in reply to Eugen Rochko • • •Felix Hlatky
in reply to Carlos Solís • • •Maubert Vincent
Unknown parent • • •@BitardMichael haaaaaaa
BitardMichael
in reply to Maubert Vincent • • •BitardMichael
Unknown parent • • •@2something @WanderingBeekeeper @vincentmaubert
We are using keepassXC and your message is really scary. I mean, coding a password manager without leaving vulnerabilities is hard. Vibe coding a password manager is just... I don't even know what to say at this point. Are we doomed?
2something
in reply to BitardMichael • • •