It's a fair policy. Getting those verbose, AI-authored walls of text is very annoying, especially when you're expected to thoroughly review it. It's like a denial-of-service attack on the human mind. I can only imagine how frustrating this can get in open projects that get a lot of contributions.
However, I don't think this will discourage AI-based coding at all. In fact, I see two potential outcomes of these policies:
- Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
- Positive: Submitters actually provide to-the-point, no-bullshit commits and comments - "here's the code, here's why I made that change, here are the effects of that change". Even if AI-generated, these small contributions may become much easier to verify & validate. We may even see some standardization in terms of what qualifies as an appropriately sized contribution, what requires more thorough review (e.g., adding unverified dependencies), etc.
I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
> - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
> Positive: Submitters actually provide to-the-point, no-bullshit commits and comments
Contributors can have good intention but verbosity and number of automatically submitted issues kills it.
Few days ago, I have found a small json-based bug in one of popular software. So I submitted an issue that was written by Claude. But it was so verbose that explanation was longer than the bug itself :)
So I had to shorten the text manually.
The whole point of not-accepting AI authored code is because this line is not respected=>"Submitters actually provide to-the-point, no-bullshit commits and comments". You're putting way too much faith into the human minds ability to resist clout-chasing. AI isn't able to humanize code without human supervision.
Interesting initiative. What are the guiding reasons behind these lists?
I can't think of a functional reason for a no-AI policy: if it runs, it runs, regardless of who or what made it.
Also, even if you avoid AI-generated slop, you can't really avoid the human-generated or human+AI-generated slop that passes your filters.
Still, I can definitely think of good non-functional reasons: provenance, accountability, proof-of-work, encouraging people to write code themselves, empirically tracking how humans develop codebases, etc.
or, maybe, as a form of protest? many people are actively against AI for ethical/moral/personal reasons, so they want to avoid using software made with it
you can see it sort of like making a list of vegan restaurants. you might not see anything wrong with other restaurants (they might even have vegan dishes) but to some people it makes all the difference because they get to choose who they support
I think the main functional reason is that because a human hasn't written the code, its potentially more likely to have subtle hidden bugs that a human cant explain because they didn't write it, as well as large pull requests that have to be validated by a human when smaller human written ones would be better. But I think it's generally the non-functional reasons that projects are rejecting LLM-generated code. Some developers just find LLM generated code icky, and would prefer not to be associated with it
> Still, I can definitely think of good non-functional reasons
For many people that’s enough of a reason.
As for functional, you can see it all up and down this comment thread. People don’t check their work and leave these massive walls of text and codebases that someone else has to audit/cleanup. It’s exhausting. Too many people offload their work to AI and put zero effort into vetting the results, which punctually means they are just offloading the work downstream. So many maintainers are simply going “no I will not do your work for you,” which is a very functional decision.
To butcher a comment I read on HN that put it very succinctly months ago: everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work. It’s a seriously problematic dynamic on many levels. And that dynamic will not change until the vast majority of people start reliably vetting the results, which I don’t think is going to happen because babysitting a black box and trying to force it to output something a specific way (or constantly copy editing middling work) is not something that most of us enjoy.
"If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review," the Foundation said.
Because it's not about the tool or the quality of the past contributions, but the quality of the current contribution. It's not new either, it's "show me the code" - it doesn't matter who you are, what you say, what you claim to have achieved in the past, the only thing that matters right now is this particular merge request and code.
I don't think the problem is the (AI generated) code per se, but as the article mentions, it's the human interaction. A reviewer can spend hours on reviewing the code and leaving feedback to the author, but if the author just feeds it into an AI (or worse, it's automatically fed into it) and processes it within seconds, only to start with a blank slate for a next change, what's the point of putting in all that effort?
Humans can learn and adapt, AIs can... ingest more stuff into their context, I suppose, but it's been proven that things break down if they have too much stuff in said context, and said context is limited.
Because of lot of AI PRs come from first time contributors who just discovered the tools. Maybe their PR is amazing, maybe it is trash. You never know until you review it.
There is legally. Make sure they sign the DCO (Developer Certificate of Origin). They will fail at the first paragraph
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; [...]
It's far more time-consuming to judge the quality of someone's past contributions than to have the LLM redo the contribution with quality you can control far more.
In many ways this makes sense. I noticed other projects
struggle with this as well. AI slop spam kills time
available.
On the other hand ... it is a bit strange though, because
what if code contributions objectively improve something?
I dislike AI slop spam, but from a purely objective point
of view, I am not sure it should be forbidden based on
it intrinsically making a change, which COULD be an
improve. Now I am also aware of the AI slop spam worsening
things; ton of documentation is useless, look at what matz
produces with claude, this seems to be written purely by
an alien, aka AI. I don't understand anything that this
AI generates. But I think from an objective point of view,
I'd actually lean more towards not completely disallowing
AI slop contribution. The issue seems largely with:
a) the quality
b) the amount of text generated
Both these problems, in my opinion, could be solved. The
time required by a real human to look at it, though, will
always be a bottleneck, so perhaps the more honest answer
would be that humans don't have enough time for
contributions from skynet.
While I agree with the general message, and wish it will eventually radiate to cooperations as well, it is obviously a decision driven by feelings, not logic.
The idea that you can't trust code that was generated by heavy users of AI, because _they_ don't understand it enough to fix it, is false, because they can use AI to fix it.
In general, I have hard time understanding how one might even block other contributors from using ai.
Community management (which is an important part of PR/issue management for open source projects) should definitely take in account the human aspect, i.e. feelings.
It's a fair policy. Getting those verbose, AI-authored walls of text is very annoying, especially when you're expected to thoroughly review it. It's like a denial-of-service attack on the human mind. I can only imagine how frustrating this can get in open projects that get a lot of contributions.
However, I don't think this will discourage AI-based coding at all. In fact, I see two potential outcomes of these policies:
- Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
- Positive: Submitters actually provide to-the-point, no-bullshit commits and comments - "here's the code, here's why I made that change, here are the effects of that change". Even if AI-generated, these small contributions may become much easier to verify & validate. We may even see some standardization in terms of what qualifies as an appropriately sized contribution, what requires more thorough review (e.g., adding unverified dependencies), etc.
I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
> - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
> Positive: Submitters actually provide to-the-point, no-bullshit commits and comments
That would be a dream.
I completely agree.
Contributors can have good intention but verbosity and number of automatically submitted issues kills it.
Few days ago, I have found a small json-based bug in one of popular software. So I submitted an issue that was written by Claude. But it was so verbose that explanation was longer than the bug itself :) So I had to shorten the text manually.
Isn’t there a /skill for this?
The whole point of not-accepting AI authored code is because this line is not respected=>"Submitters actually provide to-the-point, no-bullshit commits and comments". You're putting way too much faith into the human minds ability to resist clout-chasing. AI isn't able to humanize code without human supervision.
There are some curated lists of no-AI software. Would be nice to have an index / plot of how that changes in time.
https://codeberg.org/brib/slopfree-software-index
https://noai.starlightnet.work/list.html
Interesting initiative. What are the guiding reasons behind these lists?
I can't think of a functional reason for a no-AI policy: if it runs, it runs, regardless of who or what made it.
Also, even if you avoid AI-generated slop, you can't really avoid the human-generated or human+AI-generated slop that passes your filters.
Still, I can definitely think of good non-functional reasons: provenance, accountability, proof-of-work, encouraging people to write code themselves, empirically tracking how humans develop codebases, etc.
or, maybe, as a form of protest? many people are actively against AI for ethical/moral/personal reasons, so they want to avoid using software made with it
you can see it sort of like making a list of vegan restaurants. you might not see anything wrong with other restaurants (they might even have vegan dishes) but to some people it makes all the difference because they get to choose who they support
There is a "why" a the end of the list
https://codeberg.org/brib/slopfree-software-index#why-care-a...
I think the main functional reason is that because a human hasn't written the code, its potentially more likely to have subtle hidden bugs that a human cant explain because they didn't write it, as well as large pull requests that have to be validated by a human when smaller human written ones would be better. But I think it's generally the non-functional reasons that projects are rejecting LLM-generated code. Some developers just find LLM generated code icky, and would prefer not to be associated with it
> Still, I can definitely think of good non-functional reasons
For many people that’s enough of a reason.
As for functional, you can see it all up and down this comment thread. People don’t check their work and leave these massive walls of text and codebases that someone else has to audit/cleanup. It’s exhausting. Too many people offload their work to AI and put zero effort into vetting the results, which punctually means they are just offloading the work downstream. So many maintainers are simply going “no I will not do your work for you,” which is a very functional decision.
To butcher a comment I read on HN that put it very succinctly months ago: everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work. It’s a seriously problematic dynamic on many levels. And that dynamic will not change until the vast majority of people start reliably vetting the results, which I don’t think is going to happen because babysitting a black box and trying to force it to output something a specific way (or constantly copy editing middling work) is not something that most of us enjoy.
"If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review," the Foundation said.
That is to the point!
Godot's new contribution policy: https://godotengine.org/article/contribution-policy-2026/
Why base the decision on what tools are used by the author and not on the quality of their past contributions?
Because it's not about the tool or the quality of the past contributions, but the quality of the current contribution. It's not new either, it's "show me the code" - it doesn't matter who you are, what you say, what you claim to have achieved in the past, the only thing that matters right now is this particular merge request and code.
I don't think the problem is the (AI generated) code per se, but as the article mentions, it's the human interaction. A reviewer can spend hours on reviewing the code and leaving feedback to the author, but if the author just feeds it into an AI (or worse, it's automatically fed into it) and processes it within seconds, only to start with a blank slate for a next change, what's the point of putting in all that effort?
Humans can learn and adapt, AIs can... ingest more stuff into their context, I suppose, but it's been proven that things break down if they have too much stuff in said context, and said context is limited.
Because of lot of AI PRs come from first time contributors who just discovered the tools. Maybe their PR is amazing, maybe it is trash. You never know until you review it.
If your contributions are genuinely indistinguishable from AI code, then this shouldn’t affect you. There would be no way to enforce it
There is legally. Make sure they sign the DCO (Developer Certificate of Origin). They will fail at the first paragraph
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; [...]
https://developercertificate.org/
I guess that means no IDEs doing refactoring or automating common code. Not linters altering code, etc... right ? Because that's the same thing.
How about if AI generates code in a file, then I copy/paste bits... like stack overflow ?
Because:
1. In the case of AI generated code, the tool is the author.
2. Its far easier to enforce.
3. The alternative gate keeps against new contributors.
You are not the author with ai.
It's far more time-consuming to judge the quality of someone's past contributions than to have the LLM redo the contribution with quality you can control far more.
oh shoot, anyway
In many ways this makes sense. I noticed other projects struggle with this as well. AI slop spam kills time available.
On the other hand ... it is a bit strange though, because what if code contributions objectively improve something? I dislike AI slop spam, but from a purely objective point of view, I am not sure it should be forbidden based on it intrinsically making a change, which COULD be an improve. Now I am also aware of the AI slop spam worsening things; ton of documentation is useless, look at what matz produces with claude, this seems to be written purely by an alien, aka AI. I don't understand anything that this AI generates. But I think from an objective point of view, I'd actually lean more towards not completely disallowing AI slop contribution. The issue seems largely with:
a) the quality
b) the amount of text generated
Both these problems, in my opinion, could be solved. The time required by a real human to look at it, though, will always be a bottleneck, so perhaps the more honest answer would be that humans don't have enough time for contributions from skynet.
Godot is one of the worst run open source projects with a crawling pace since 2014.
It’s been wildly successful. Poorly run projects tend to fail.
Care to give arguments?
While I agree with the general message, and wish it will eventually radiate to cooperations as well, it is obviously a decision driven by feelings, not logic.
The idea that you can't trust code that was generated by heavy users of AI, because _they_ don't understand it enough to fix it, is false, because they can use AI to fix it.
In general, I have hard time understanding how one might even block other contributors from using ai.
Community management (which is an important part of PR/issue management for open source projects) should definitely take in account the human aspect, i.e. feelings.