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
> It's like a denial-of-service attack on the human mind.
I think this may be an example of deliberate hostile design, attempting to force users to adopt LLM based solutions to then summarise the vast output. Pushing back against AI contributions as such in this context makes sense, especially in software with an existing proven track record of great value delivery like Godot.
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.
"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.
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
And on top of that - no matter if you develop open-source or proprietary software, who is to guarantee the AI didn't get trained with GPL (or even worse, leaked proprietary) source code? Who is going to pay my lawyer when someone files a copyright lawsuit and all I have as an excuse is that I "AI-laundered" my code?
And some projects like WINE or ReactOS probably have to worry about that even more given they need to guarantee clean-room reverse engineering...
> 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.
The foundation points out something that has always been true, but AI has really brought to the forefront, that any contributor, including AI, could potentially not be relied on to maintain this patch in the future.
This is the core of the issue, not that someone uses AI, but that it’s just one of many smells a patch can have that indicates someone doesn’t understand what they’re submitting. You could be breaking variable naming conventions, changing APIs you shouldn’t, making amateur language mistakes, all indicate that yes, maybe the patch does work, but that there are other good reasons to reject it.
A way around this might be to mark a PR as rejected because of AI and then ask the author to point out some part of it they’re particularly proud of and explain in their own words, not a wall of AI text, what this does and why they like it. Just something where the author has to show that they have something an AI can’t, namely taste and an opinion.
AI accidentally found one of the most expensive resources in the industry: the free time of people who maintain open source in the evenings after their day job
I'm not sure I agree with the policy, but I'm glad we are seeing different project experimenting with different policies. So after a while we can probably see how things shake out in the end.
Definitely sympathetic to their policy, but AI tooling and quality are changing quite fast. In a year I'd expect a modification of this as AI agents get better in virtually every possible way.
If someone thinks they're building better open source with their AI, let them fork; their AI can maintain downstream. If it's really better, people will join the fork. Good luck.
In all likelihood anyone attempting this will realize the value that a maintainer provides. On the odd chance they discover a new working model and produce better software, all the better, everyone wins.
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.
The Godot maintainers do review based on the quality of contributor's past contributions. Those becoming especially proficient can even become maintainers.
Allowing AI use by 'trusted contributors' has been suggested and discussed, but there were enough reasons against it and not enough established benefit.
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; [...]
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.
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.
> what if code contributions objectively improve something?
If the contribution is complex enough, it is no longer an 'objective improvement' but rather a judgement call, and in the process becomes copyrightable. This is where the trouble lies, and why this kind of AI involvement is banned.
If it is not, for example by being a one-line fix that literally cannot be performed differently, it's a different story. Then it can be merged, viewed either as a menial change (exempt by the ban) or by transfer of ownership (the reviewer becomes the effective author) because it is not copyrightable.
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.
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.
reply