5 ms·

> The problem is that a lot of AI contributions are lazily produced without review. That sounds like a contributor problem. Not an AI problem. I still don't u

> The problem is that a lot of AI contributions are lazily produced without review. That sounds like a contributor problem. Not an AI problem. I still don't understand a "no AI" policy whose only purpose is to weed out bad PRs. You should be weeding out bad PR's regardless of their source. I don't see why treating a purely human-authored, but bad, piece of code should be treated any differently than an AI-authored one. All they've accomplished is creaking an environment where good code can't be submitted unless the submitter lies.

krainboltgreene 4mo ago
Probably because a human authored contribution, no matter how bad, can be trained to make it good and also improves the community.
- mexicocitinluez 4mo ago
  > can be trained to make it good and also improves the community. AI can be trained. Also, AI can create code that improves the community. It's replies like this that leave me even more confused.
  - skydhash 4mo ago
    Human being trained is already proven (that’s how most maintainers came to be). Can you explain how AI can be trained in the above context?
    - mexicocitinluez 4mo ago
      lol Human beings are famously not already trained.
  - krainboltgreene 4mo ago
    > AI can be trained. I don't have access to a data center's worth of GPUs, unfortunately. You offering yours?
    - mexicocitinluez 4mo ago
      So when you said "AI cant be trained" you didn't mean "AI cant be trained" you meant that you personally can't? lol.
      - krainboltgreene 4mo ago
        I'm saying that most people, even most programmers, don't have the facilities or inclination to train new models man. I've done it plenty of times and I absolutely don't recommend it. Frankly I don't think you even know what the phrase entails.
        mexicocitinluez 4mo ago
        So again, you can train people but not AI? That's literally what you've said and now moving the goal posts in a way that makes no difference to what you said being patently wrong. It's wild having to argue with people who say demonstrably untrue things and then refuse to admit that what they said was wrong.
        krainboltgreene 4mo ago
        Yeah, real wild.
SpicyLemonZest 4mo ago
You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". So it can be both satisfying and worthwhile to spend your effort on cleaning it up, even if it starts to take as much or even more effort than doing it yourself would have. You're not the first person I've seen argue that authorship doesn't matter, so I don't want to blame you for it, but I really don't understand where that idea is coming from. To me it seems obviously wrong.
- KronisLV 4mo ago
  > You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". I think the difference in perspective might come from the fact that to many people the code and features matters more than any community or the idea of participating in it. If it works, it works. Or maybe they’re not even indifferent about the community, just upset at people throwing away working code.
  - SpicyLemonZest 4mo ago
    The Godot maintainers have decided they don't support that perspective. In their words, they value "being cautious about feature creep" and "dedicated to high code quality"; they don't accept that all working code should be merged. Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork. But then all of the stuff in their fork won't benefit from the participation of the community, which I suspect most such people do value even if they identify as a "code first" person.
    - KronisLV 4mo ago
      > they don't accept that all working code should be merged. That’s perfectly within their rights to do! > Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork. Too many of those do fragment the development effort and hurt any project. Here’s hoping that Godot doesn’t struggle too much with people who don’t care about their rules and spam PRs regardless and that the people who want to commit AI code regardless because it works and is good in their eyes at least demonstrate enough initiative to cheat convincingly (maybe actually read the code and make it their own). Godot is a pretty cool project! Wonder what the middle ground would look like - a project with super high test coverage and tooling, that also requires at least 20 USD in Opus tokens spent on review on the behalf of the author or something, before an actual human being is bothered with it? Heh.
lokar 4mo ago
It’s just a social thing. Two identically bad submissions have different social contexts.
dspillett 4mo ago
> > The problem is that a lot of AI contributions are lazily produced without review. That sounds like a contributor problem. Not an AI problem. Ish. The tool is not doing the job fully, the contributor is not doing their task properly, checking for that, and fixing the issues. > I still don't understand a "no AI" policy whose only purpose is to weed out bad PRs. You should be weeding out bad PR's regardless of their source. Think of it like offering a job, and getting 100s of CVs. You don't have time to review each in detail, so you weed out a chunk of them using superficial cues that have been indicators of issues in the past. They are filtering the other contributions too, the no AI rule is just part initial triage to save a lot of time. You have missed a key point in what I wrote: "Those that have been properly reviewed for correctness [before being submitted] will be indiscernible from human-only contributions". It is like a Turing test: if you take the effort to make your AI aided contributions good enough to be indiscernible from good human-only contributions then the no-AI filter won't bother you because the people or automations enforcing it won't be able to discern that your contribution was assisted. > where good code can't be submitted unless the submitter lies. No. Unless it looks like a good contribution looks. The problem a lot of projects are facing right now is being inundated by bad PRs from people using AI without the effort to, or likely the knowledge of how to, properly understand and explain & document the change. People have a limited amount of time and if the filter saves a lot of time then maybe losing one or two good contributions due to the filter is worth it - better that than the project stalling under the weight of managing all the PRs. This is one of the reasons, even pre-AI, some projects declared themselves "open source but not open contribution".
- mexicocitinluez 4mo ago
  Saying you didn't use AI when you did, regardless of the end product, is lying. What definition of the word lie wouldn't cover that?
  - dspillett 4mo ago
    If they are simply filtering out based on signs of AI, then there is no lie. If they are explicitly asking “was AI used” then yes, there is a direct lie involved. If there is no explicit question but you are including “lies by omission”, then be aware that there are many things people choose not to say that they would be unfairly judged for if they did state (gender details, certain parts of their history, etc) so that might not be a line we want to draw. I'm not exactly pro-AI, in fact I'm avoiding it in DayJob to the point where I expect at some point I'll be given the choice “get with the program or leave” (I plan to leave at that point, preferably by my own choice though we'll see how heated the discussion gets!), but if there is a at least one human at the end of the process that is properly testing and cleaning everything up so there can be nothing problematic in the AI output that survives, is that really practically any different to a fully human created contribution? The problem with AI contributions in the vast majority of cases is the lazy ones, especially considering the sheer number of them. Using signs of AI as a code/documentation smell when it comes to filtering contributions is fine, especially if you have up-front requested no such contributions be sent. Permanently blocking people who have sent obviously AI-generated contributions previously despite you asking them not to, is also fine just as blocking people who have sent in entirely human made contributions that break your other requests/rules is. But banning all AI use when if you can't tell if a good contribution did or didn't use AI aid somewhere in the process, is both a daft extreme and actually impossible (if you can't tell, how do you tell?!).
banannaise 4mo ago
A tool that encourages bad behavior at scale is a bad tool. Blaming individuals for a collective problem leads to no improvements.

krainboltgreene 4mo ago

Probably because a human authored contribution, no matter how bad, can be trained to make it good and also improves the community.

mexicocitinluez 4mo ago
> can be trained to make it good and also improves the community. AI can be trained. Also, AI can create code that improves the community. It's replies like this that leave me even more confused.
- skydhash 4mo ago
  Human being trained is already proven (that’s how most maintainers came to be). Can you explain how AI can be trained in the above context?
  - mexicocitinluez 4mo ago
    lol Human beings are famously not already trained.
- krainboltgreene 4mo ago
  > AI can be trained. I don't have access to a data center's worth of GPUs, unfortunately. You offering yours?
  - mexicocitinluez 4mo ago
    So when you said "AI cant be trained" you didn't mean "AI cant be trained" you meant that you personally can't? lol.
    - krainboltgreene 4mo ago
      I'm saying that most people, even most programmers, don't have the facilities or inclination to train new models man. I've done it plenty of times and I absolutely don't recommend it. Frankly I don't think you even know what the phrase entails.
      - mexicocitinluez 4mo ago
        So again, you can train people but not AI? That's literally what you've said and now moving the goal posts in a way that makes no difference to what you said being patently wrong. It's wild having to argue with people who say demonstrably untrue things and then refuse to admit that what they said was wrong.
        krainboltgreene 4mo ago
        Yeah, real wild.

SpicyLemonZest 4mo ago

You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". So it can be both satisfying and worthwhile to spend your effort on cleaning it up, even if it starts to take as much or even more effort than doing it yourself would have. You're not the first person I've seen argue that authorship doesn't matter, so I don't want to blame you for it, but I really don't understand where that idea is coming from. To me it seems obviously wrong.

KronisLV 4mo ago
> You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". I think the difference in perspective might come from the fact that to many people the code and features matters more than any community or the idea of participating in it. If it works, it works. Or maybe they’re not even indifferent about the community, just upset at people throwing away working code.
- SpicyLemonZest 4mo ago
  The Godot maintainers have decided they don't support that perspective. In their words, they value "being cautious about feature creep" and "dedicated to high code quality"; they don't accept that all working code should be merged. Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork. But then all of the stuff in their fork won't benefit from the participation of the community, which I suspect most such people do value even if they identify as a "code first" person.
  - KronisLV 4mo ago
    > they don't accept that all working code should be merged. That’s perfectly within their rights to do! > Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork. Too many of those do fragment the development effort and hurt any project. Here’s hoping that Godot doesn’t struggle too much with people who don’t care about their rules and spam PRs regardless and that the people who want to commit AI code regardless because it works and is good in their eyes at least demonstrate enough initiative to cheat convincingly (maybe actually read the code and make it their own). Godot is a pretty cool project! Wonder what the middle ground would look like - a project with super high test coverage and tooling, that also requires at least 20 USD in Opus tokens spent on review on the behalf of the author or something, before an actual human being is bothered with it? Heh.

lokar 4mo ago

It’s just a social thing. Two identically bad submissions have different social contexts.

dspillett 4mo ago

> > The problem is that a lot of AI contributions are lazily produced without review. That sounds like a contributor problem. Not an AI problem. Ish. The tool is not doing the job fully, the contributor is not doing their task properly, checking for that, and fixing the issues. > I still don't understand a "no AI" policy whose only purpose is to weed out bad PRs. You should be weeding out bad PR's regardless of their source. Think of it like offering a job, and getting 100s of CVs. You don't have time to review each in detail, so you weed out a chunk of them using superficial cues that have been indicators of issues in the past. They are filtering the other contributions too, the no AI rule is just part initial triage to save a lot of time. You have missed a key point in what I wrote: "Those that have been properly reviewed for correctness [before being submitted] will be indiscernible from human-only contributions". It is like a Turing test: if you take the effort to make your AI aided contributions good enough to be indiscernible from good human-only contributions then the no-AI filter won't bother you because the people or automations enforcing it won't be able to discern that your contribution was assisted. > where good code can't be submitted unless the submitter lies. No. Unless it looks like a good contribution looks. The problem a lot of projects are facing right now is being inundated by bad PRs from people using AI without the effort to, or likely the knowledge of how to, properly understand and explain & document the change. People have a limited amount of time and if the filter saves a lot of time then maybe losing one or two good contributions due to the filter is worth it - better that than the project stalling under the weight of managing all the PRs. This is one of the reasons, even pre-AI, some projects declared themselves "open source but not open contribution".

mexicocitinluez 4mo ago
Saying you didn't use AI when you did, regardless of the end product, is lying. What definition of the word lie wouldn't cover that?
- dspillett 4mo ago
  If they are simply filtering out based on signs of AI, then there is no lie. If they are explicitly asking “was AI used” then yes, there is a direct lie involved. If there is no explicit question but you are including “lies by omission”, then be aware that there are many things people choose not to say that they would be unfairly judged for if they did state (gender details, certain parts of their history, etc) so that might not be a line we want to draw. I'm not exactly pro-AI, in fact I'm avoiding it in DayJob to the point where I expect at some point I'll be given the choice “get with the program or leave” (I plan to leave at that point, preferably by my own choice though we'll see how heated the discussion gets!), but if there is a at least one human at the end of the process that is properly testing and cleaning everything up so there can be nothing problematic in the AI output that survives, is that really practically any different to a fully human created contribution? The problem with AI contributions in the vast majority of cases is the lazy ones, especially considering the sheer number of them. Using signs of AI as a code/documentation smell when it comes to filtering contributions is fine, especially if you have up-front requested no such contributions be sent. Permanently blocking people who have sent obviously AI-generated contributions previously despite you asking them not to, is also fine just as blocking people who have sent in entirely human made contributions that break your other requests/rules is. But banning all AI use when if you can't tell if a good contribution did or didn't use AI aid somewhere in the process, is both a daft extreme and actually impossible (if you can't tell, how do you tell?!).

banannaise 4mo ago

A tool that encourages bad behavior at scale is a bad tool. Blaming individuals for a collective problem leads to no improvements.