rHXN - Godot will no longer accept AI-authored code contributions

TomasBM - 2 hours ago

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.

ivorius - 2 hours ago

> - 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.

QuantumNomad_ - 1 hour ago

> 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.

True. At least with a policy about it, the project maintainers can unilaterally close such PRs without further internal or external discussion on any case-by-case basis.

whateverboat - 1 hour ago

But now with AI, this should be "easier" for some definition of easy. In the sense that in the past, this might have taken 15 minutes to write, now with AI, this can take 5 minutes to write by first getting AI to produce a summary and then using human judgement to make it better. So, it's a good idea now to actually demand the dream.

ivorius - 58 minutes ago

If people knew how to get AI to write terse, focused summaries, sure, that might help. I haven't seen many that do (well, ignoring the toupee fallacy).

Though the most important aspect is that we need to know the motivation and thought process, and all AI can do is fabricate a 'plausible' one.

watwut - 1 hour ago

> 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.

The policy allows the reviewer to reject it on the "AI" grounds.

dspillett - 53 minutes ago

> allows the reviewer to reject it on the "AI" grounds

… but still unfortunately leaves reviewers having to spend time checking submissions and rejecting them.

jon-wood - 40 minutes ago

At least half the people firing off LLM generated PRs will have left the "Coauthored-by: Claude" line on it allowing automated rejections.

ivorius - 29 minutes ago

Unfortunately, only a single PR like this comes to mind. Most AI authors we've seen were identifiable mainly by overly verbose PR descriptions, meaningless code changes and copy-pasting more AI output when questioned.

fendy3002 - 41 minutes ago

oh but it'll be very2 helpful and the time spent will be short. It's easy to verify:

* new contributor?

* more than 10 files affected (higher count are more valid)?

* wall of text on description without screenshots, etc?

just close the PR as AI, and then the contributor can challenge it if they feel it should not.

captainbland - 2 hours ago

> 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.

someonebaggy - 1 hour ago

There's no chance that anyone saw that far ahead in the future and planned it. It's emergent behaviour.

dspillett - 55 minutes ago

> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.

The problem is that a lot of AI contributions are lazily produced without review. Those that have been properly reviewed for correctness (tested to ensure actually working with no obvious undesirable side effects, tweaked where needed to be readable and understandable, fitting the other guidelines of the project, etc) will be indiscernible from human-only contributions, but there are a lot of people who make no such effort so the majority are not nearly this good.

whateverboat - 1 hour ago

This was the original rule in linux kernel as well. No more than 200 loc per patch. We should also introduce this to git commits and pull request descriptions:

1. 400 chars/10 lines per commit

1b. Not more than 3 commits in the initial pull request

2. 20 lines of explanation for pull request

3. not more than 3 pull request open at any one time

peepee1982 - 37 minutes ago

If a commit is written by AI but reads as authored by a human, the developer has done their job and nothing will be flagged.

If commits written by AI wouldn't be substantially different, there would be no need to reject them.

So I agree with you that it won't discourage AI-based coding. But that's not even the intent.

blackoil - 30 minutes ago

Better way is to provide a Claude.md with strong stylistic guidelines and loc requirements. Else it will be a chicken and mouse game of what is from AI.

ivorius - 28 minutes ago

I made a PR like that, but it was rejected by the community (for some valid reasons and some not so valid). https://github.com/godotengine/godot/pull/118681

onesandofgrain - 2 hours ago

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.

sixtyj - 2 hours ago

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?

grey-area - 2 hours ago

If you understood the change, writing a short description of the problem and the fix yourself would be trivial.

sixtyj - 1 hour ago

Efficiency is the key. I haven’t written any issue before so LLM was much quicker than manual experiment. I have personally checked the result before submission.

So why the hate? :)

unfocso - 1 hour ago

You "personally checked" the result (generated by an LLM, a huge black box with extensive knowledge of all fields) to the best of your knowledge. There is a mismatch between what the machine knows (and has done as the result of it) and what you think you know.

Implementing a fix implies knowledge of the inner workings that brought you to it. A fix made by a LLM does not give you that.

cyclopeanutopia - 1 hour ago

Efficiency rarely is the key.

flexagoon - 1 hour ago

> Submitters just add stylistic markers to make their accounts and output seem human-generated

https://xkcd.com/810/

CamouflagedKiwi - 1 hour ago

Not quite accomplished, if it's creating text on the pull requests that looks sufficiently human-like, but you're still worried about the quality of the code and that the submitter doesn't understand it.

ThePhysicist - 1 hour ago

Interesting that on one hand the valuation of these AI providers is based on the assumption that all code (and everything else producing digital artefacts) will be written using AI in the near future, on the other hand almost all popular open source projects fight to keep AI contributions out. Hard to reconcile.

Personally I'm also experiencing a bit of AI hangover after using it a lot in my own open-source projects. I find it's a bit like taking drugs (not that I have much experience with that) in the sense that in the moment I'm using these tools I feel great and powerful, writing features in a span of hours that would've taken me weeks to write by hand. But inevitably some time later I will look at the code and notice all the subtle cracks and inconsistencies the tool introduced, and despair a bit at the mess.

I now plan to use these tools less for extensive feature development and more for planning, debugging and narrow refactoring where I can put very strict guardrails on them. I'd still say it accelerates my work but not by a factor of 10, more like 1.5-3 (which is still a lot) given the care you need to ensure what is being built is actually good. For what I really like these tools is that I need less mental focus to do coding, but on the other hand I have this new kind of fatigue of being in a constant chat loop with a machine and trying to get it to do stuff based on natural language, never knowing how it will interpret what I write and wrote before. In that sense, these tools don't feel satisfying, it's like operating a machine where you try to push some buttons to get it to do something but the internal wiring changes all the time so you never know exactly what a given button combination will do and you have to figure it out by watching the machine and constantly adapting.

michaelchisari - 59 minutes ago

Moving fast was a huge moat for a long time, but now moving fast is easy. Quality might be the new moat.

Important to note that fast never meant much to open source and for good reason.

otabdeveloper4 - 9 minutes ago

> Moving fast was a huge moat for a long time

It was never a moat.

Moving fast and getting to the right destination is a huge moat. AI changes nothing here.

Folcon - 34 minutes ago

I've very much come around to this perspective as well

Our current generation of AI tools still seems to be very much not there when you really try and use it's output

There's a problematic dopamine dynamic as well where it's far too easy to reach for an AI when doing some work or starting a new project

I'm currently trying to dopamine hack my brain back to preferring to handwriting the majority of my code as opposed to reaching for claude

Time will tell if this is just a phase and it will get better or we'll need some sort of LLMs-anonymous

d1sxeyes - 52 minutes ago

The key problem is that traditionally, OSS contributions were self-selecting. Basically, to create a PR, you had to be invested in the project. To create a contribution of value, you had to understand the codebase, the conventions, engage a little with the project, and generally the folks doing it are doing so because they like the project, or because they are scratching a specific itch they have etc.

What AI unlocks is contributions from folks who are not at all involved in the project, and creating a PR is no longer enough to clear the gate of “this person is at least somewhat interested in the success of the project”.

AI is a force multiplier when wielded properly, but as an OSS maintainer, it’s easy to drown in prolific, low value “contributions” from folks who don’t care about the project.

neonstatic - 1 hour ago

> the moment I'm using these tools I feel great and powerful, writing features in a span of hours that would've taken me weeks to write by hand. But inevitably some time later I will look at the code and notice all the subtle cracks and inconsistencies the tool introduced, and despair a bit at the mess.

Very relatable. I wasted 2 weeks of full time effort earlier this year building a helper library with Sonnet. It was the first (and the last) time I vibe coded something. Once I was satisfied with it, I began using the library and within 2 days I was certain it was all for nothing. I will never get those 2 weeks back, but a lesson has been learnt.

warpech - 1 hour ago

Totally! The feeling of using AI to create something not fully productive is similar to the "just one more turn..." effect when playing a Civilization game. Even when you realize it's a waste, it's hard to stop, because the next dopamine hit is just around the corner.

manvel_hn - 2 hours ago

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

TomasBM - 2 hours ago

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.

vazark - 1 hour ago

Because the goal is two-part

1. Accept quality contributions from someone who understands what they're doing

2. Cultivate a relationship with the contributor who might potentially become a core-team member. Maybe even the next maintainer

0xMalotru - 2 hours ago

There is a "why" a the end of the list

https://codeberg.org/brib/slopfree-software-index#why-care-a...

kjeksfjes - 11 minutes ago

> There is a study showing that doctors who use AI to help detect cancer become less skilled at detecting cancer without AI.

Not exactly an argument against using AI, is it? It's a bit like saying that GPS makes people worse at navigating by memory, which is true, but also not a strong argument for going back to paper maps. I feel the discourse is more about "stop using AI" and less about "how can we ensure our backup skills doesn't disappear".

croon - 45 minutes ago

The reasons are functional in aggregate, but not necessarily per specific PR.

You could get a perfectly adequate instance of a PR that is easily readable and verifiable while generated by an LLM, but generally they're not.

A policy pushes the aggregate to at least what looks and communicates as a human made PR that is functionally easier to approve. Whether they are created by an LLM or not is then secondary, but it likely pushes all PRs to be better.

TomasBM - 29 minutes ago

Good point. Even if you submit small, verifiable and readable changes, you can still overload the review process by submitting too many of them (e.g., 100s of PRs).

But I'd argue that some projects [1] could benefit from the speed (and sometimes, quality) of AI code generation without filtering by something that's difficult to identify (i.e., is it truly human-generated).

One way could be to constrain the size of each commit and PR, and invest more heavily into the review process (e.g., tests, static/dynamic analysis, sandbox deployments), so even if you get 100s of contributions, you can knock each out quickly.

Obviously, easier said than done. And at that point, you may as well use the AI to make the commits yourself, instead of relying on community contributions.

[1] Of course, this is only the case if the project's only purpose is to be a tool, and not also an educational reason for humans to learn how to code - in which case, it makes sense to invest more into identifying the "cheaters".

voidUpdate - 2 hours ago

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

drdaeman - 1 hour ago

This makes sense, but I'm not sure it's directed at the actual issue.

There are probably some subtle bugs I can't explain in the code I wrote all by myself. I sure had a few "what was I possibly thinking when I wrote this" moments working on some old code - and that's only the bits I know about. And I sure had countless times people pointing out "hey, you got this stinky here" in a code review (which is the whole point of it). Attention lapses and brain farts sure happen. Slop can be more frequent with LLMs but it's certainly not a LLM-specific issue. They're very productive, there's a literal outbreak, and by the sheer volume shadow any The Daily WTF stories.

However, I can agree that LLM-generated code most likely has higher probability of slop. But then, a policy "a human contributor MUST fully know and understand all the contents of the submitted work, in fine detail, all the way down to every single line of contributed code and documentation" would probably address that in a more functional manner. And then the code can be from an LLM or monkeys with typewriters author had seen in his sleep. That stops to matter because author takes ownership and responsibility: "here's a recognized rational agent who swears by their work". Makes non-self-authored code require a lot more effort (unless it's a trivial change for obvious reason), but arguably even more robust than self-authored code.

That is, unless the PR authors tend lie about their knowledge - but that'll be a whole different story, where LLMs will be just a background detail.

(I'm not saying Godot should be done something different - their project, their rules, let's use that as an opportunity to watch how it goes. Just musing on the matter in general, if there's any rationally explainable merit in such policy.)

mschuster91 - 2 hours ago

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...

cyclotron3k - 45 minutes ago

I'm not disagreeing with you, but it's worth noting there were plenty of GPL violations before LLMs existed.

mschuster91 - 43 minutes ago

Sure, but at least when I write code by hand I can be fairly certain that I do not copy code without the appropriate license to do so.

voidUpdate - 1 hour ago

Given the amount of web scraping LLM providers have been doing, I'd say it's likely that any code that is publicly accessible on the internet has been incorporated into it's training data, whatever its license

nasso_dev - 2 hours ago

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

vips7L - 1 hour ago

> I can't think of a functional reason for a no-AI policy

Imagine morals.

degamad - 1 hour ago

That would be part of the non-functional reasons mentioned in the next paragraph.

seanclayton - 1 hour ago

> I can't

That makes much more sense now. The inability is completely on you, and you admit it at least.

alberto467 - 55 minutes ago

You can’t understand the difference between functional and non-functional.

dirkc - 1 hour ago

Please define "if it runs, it runs"?

TomasBM - 1 hour ago

If you have some requirements/specifications, and the piece of code fits them, then it runs.

Alternatively, if you have some vague idea [1] about what you expect to see/have, and the running code satisfies that idea, then it also runs.

Obviously, there are plenty of non-functional specs (e.g., security, cleanness, readability) that a code should probably fulfill before one finds it acceptable, but these are also not somehow impossible for state-of-the-art models to satisfy.

[1] Vibe, if you prefer, tho I dislike the term. Another related term is eyeball estimation.

qsera - 39 minutes ago

But it is hard to verify it, right?

If you use rsync clone by an LLM to copy a million files, will you bother to verify every single one was copied correctly?

Forgeties79 - 2 hours ago

> 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.

TomasBM - 40 minutes ago

I think that's completely fair.

There are also plenty of valid personal reasons for refusing to generate code with AI - learning-by-doing and ownership of the result being the main ones, IMO.

> everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work.

This is also true in my experience. But in my work, I found that I don't care how the code or comment was generated, as long as it doesn't try to overload my brain with irrelevant and obfuscated things, and as long as the person is not pretending that it's true, verified or their own creation (when it isn't).

timacles - 17 minutes ago

So you didn’t read the article?

gitowiec - 2 hours ago

"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!

qsera - 36 minutes ago

And the worse thing is that their feed back probably goes into the training of the next LLM. So more free labor for the AI companies.

signa11 - 40 minutes ago

zig's 'contributor poker' is sounding more and more prescient.

Mabusto - 2 hours ago

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.

ivorius - 2 hours ago

AI is well-capable of fabricating text that looks like an opinion in 2026. This would not help differentiate AI from human authors.

Mabusto - 1 hour ago

You’re absolutely right - AI is not just capable, it’s on the leading edge. It’s not about vibes, it’s about results.

(It’s famously not well capable of sounding human)

pigeonwarz - 35 minutes ago

This could easily be circumvented by having the AI generate an explanation of the chosen portion of code and have the human rewrite it in their own words. It is much easier, imo, to swap clauses and put synonyms in place of other words within existing writing then it is to synthesise new text.

ivorius - 1 hour ago

Right. Reviewers still have the advantage of being able to spot AI text because it's often overtly different. I just meant to say that, if you prompt ai "what would a human be proud of having written this code" you'll get an answer. They're not categorically incapable of fabricating an "opinion", they're just trained not to express one by default.

kriro - 16 minutes ago

Is there a list or overview of all open source projects that refuse to accept AI-code? It pops up every now and then but would be nice to have a good reference. Could also be interesting for quality analysis and so on in the future.

I can fully understand the reasoning for it and I also think it's by and large a good idea because one of the cool things about open source projects is that they are traditionally good places for younger developers to get started or hop in and learn. There's a lot more to be learned from writing everything yourself and thinking through it.

nemomarx - 5 minutes ago

https://noai.starlightnet.work/list.html

there's a few elsewhere in the comments here but I'm not sure how comprehensive any are

SwtCyber - 2 hours ago

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

Semkas - 1 hour ago

I'm getting the feeling that many people here are mostly reacting to the title instead of reading the actual policy: they state that an important part of the reason is that they use PR review to train new contributors and find possible future maintainers.

Irrespective of the quality of ai-contributions, that seems hard to argue with.

(unless you believe ai will make the whole concept of OS contributions / maintenance redundant. If that's your belief I don't think it makes much sense to submit PR's to Godot though, instead of just forking the engine and having your agents work on it)

flowerthoughts - 14 minutes ago

Is anyone using LLM on the other side, to vet incoming PRs for quality and whether it's worth reviewing?

brettermeier - 1 hour ago

Do those AI contributors really think they are helping out? Don't they get, that they are destroying such projects with their "work"? Why do they spend money for stuff nobody wants and gets rejected. I don't get it... Don't these people have any hobbies? Or are these free-roaming OpenClaw instances that have been forgotten by their creator and are now doing their own thing?

muvlon - 1 hour ago

We are no longer in the era of FOSS where contributions are purely motivated by either scratching your own itch, altruism or curiosity. Haven't been for over a decade, since that's how long companies have been checking out applicants' GitHub pages during hiring.

These people are farming contributions to major FOSS projects as a form of CV-padding. The same is happening with vulnerability reports. The sloppers may genuinely think they're helping out, or they may know their 'contributions' are a net negative for the projects, in the end it doesn't matter much. When you're motivated by direct economical incentives and your situation is precarious enough (in today's labor market, it is), externalities are not high on your list of concerns.

alberto467 - 45 minutes ago

Exactly. That’s the only real core issue. Wild AI usage is just a consequence.

Developers who have a nice job and career, and are making good money, might think of doing open source to “contribute to society” or something like that.

But new developers who are seeing those golden opportunities shut in front of their faces, they feel like they have to desperately fight for the last places on the lifeboat, so I don’t blame them for wanting to farm cv points and game the system of incompetent recruiters who make much more then they will do, instead of spending time and effort doing something nice for society hoping someone will notice (lol they will not, especially if you’re a nobody)

Archer6621 - 43 minutes ago

It's a sad state of affairs really. But I also think this high degree of slop everywhere will eventually shift what people and organizations deem valuable and how they scan or select for it, it's unsustainable otherwise. You're seeing it here already, and in other places as well.

maxgashkov - 43 minutes ago

There are degrees to "AI contributors". E.g. recently I have stumbled upon rare edge case in an OSS tool written in Rust. It would have taken me a week+ to be able to contribute a minor change in a clean and Rust-idiomatic way as this is not the language I'm proficient in, and Claude did that in 1 hour, with 3 or 4 rounds of tweaks from me to reduce the walls of text and make the contribution matching the of the original project. Alternative was just swiping it under the rug or opening an issue instead (thus placing the burden on the maintainer).

I do think I helped out.

And I have discovered this edge case when fiddling with my homelab which is my hobby.

HelloUsername - 1 hour ago

Perhaps move comments to source posted yesterday? 30-jun-2026 "Changes to Our Contribution Policies" https://news.ycombinator.com/item?id=48733236 9 comments

throwfaraway135 - 53 minutes ago

Wouldn't it make much more sense to just reject _low_ quality PR's?

On an unrelated note, I lost all respect and eagerness to try it out after the drama.

plst - 18 minutes ago

Another problem, AI allows many people submit PRs that may look viable with very low effort. So you get a lot more code to review, often submitted by people who are not actually familiar with the codebase. So they may not even be able to make requested changes to their patches. Combine that with AI's verbosity. The maintainers drown in noise.

nkrisc - 21 minutes ago

They want people who will be around to maintain the features as well. There have been several areas of the project that have languished at times because no current maintainer had the capacity or familiarity to move it forward.

Also, what drama?

koteelok - 47 minutes ago

No, it wouldn't. The goal of reviewing PRs is to mentor and find new maintainers who will eventually replace the current ones.

You just can't expect someone who isn't willing enough to write one good PR to be willing to become a good maintainer.

throwfaraway135 - 32 minutes ago

> write one good PR

is about quality not AI which is exactly my point.

Aachen - 56 minutes ago

Actual source: https://godotengine.org/article/contribution-policy-2026/

minraws - 55 minutes ago

As a former extensive Godot contributor(I haven't contributed much since post 4.1 era), I am sad to see people target a project like Godot with AI Slop PRs.

I am with the maintainers on this one, I am not quite sure how they plan to filter out AI slop, but atleast all slop PRs should stop now, I am sad to not have the free time to contribute to the project or maybe just not enough energy.

In generally, I am just sad that this is where the public contributions and open source has come down to, couldn't we all have been more fun working together, what makes someone think they can vibe code their way to a meaningful PR and not even mention that it's a vibe PR.

Why does this PR appear to add any value, and if it does provide some insights into solving a problem, why do you expect it to be merged and reviewed?

The best defense of these drive by vibe PRs can be I found a bug, tried to fix it, seems to work, here's my code, someone who has more time could take a look and see if it has any insights.

Also only works on PRs that are specifically bug fixes or address some issue specifically. Not your omega 10K+ line feature commits...

Why do some people feel compelled to make these PRs? I am genuinely curious, I don't hate these people but do these folks think that this is adding some value?

baq - 49 minutes ago

just when the models started to be actually good. these policies need quarterly revisions at the current dynamics.

thinkingemote - 2 hours ago

Godot's new contribution policy: https://godotengine.org/article/contribution-policy-2026/

Aachen - 49 minutes ago

This is the link for the actual contribution policy: https://contributing.godotengine.org/en/latest/pull_requests...

But the blog post is written in future tense. I don't think they have a new contribution policy file yet

bickov - 1 hour ago

Banning the PRs is the easy part. The funny bit is that "understands their own code" is now a filter worth writing down.

eru - 2 hours ago

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.

deftio - 2 hours ago

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.

avaer - 2 hours ago

Totally valid.

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.

prymitive - 52 minutes ago

Silicon Valley is working round the clock to make bad behaviour as cheap and easy as possible, while taking all the profits. PR floods are probably the most innocent of this. Imagine if you want to send someone abusive text, previously you’d have to spend time and energy writing insults, now the machine can text or even phone someone on your behalf and harass them all day all night. Being a pest to the society was never as easy as right now.

TekMol - 2 hours ago

Why base the decision on what tools are used by the author and not on the quality of their past contributions?

Cthulhu_ - 2 hours ago

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.

superb_dev - 2 hours ago

If your contributions are genuinely indistinguishable from AI code, then this shouldn’t affect you. There would be no way to enforce it

SwtCyber - 1 hour ago

I think they arent even trying to build an AI detector. This is more of a social signal like "dont send us an automatically generated flood of changes"

preisschild - 2 hours ago

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/

someonebaggy - 1 hour ago

Why will they fail? They will simply sign it and continue.

mobiuscog - 2 hours ago

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 ?

throwawayffffas - 2 hours ago

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.

ivorius - 2 hours ago

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.

kkapelon - 2 hours ago

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.

0x073 - 2 hours ago

You are not the author with ai.

stavros - 2 hours ago

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.

frb - 1 hour ago

  ...the influx of contributions authored or submitted by AI is sapping the projects' maintainers of their willingness to confront the "already tedious" work of reviewing pull requests....

To me this seems a core issue: PR reviews for most people feel tedious and this has been the case way before AI already.

Don't get me wrong, slop is slop, no matter if AI or entirely human-fabricated. But just like AI-assisted coding can actually be helpful, why can't AI-assisted PR reviews make it less tedious?

pferde - 1 hour ago

No, reviewing PRs in general is a delightful process. The tedious part is in the initial triage when the PR comes from a previously unknown submitter, and you cannot be sure what is the intention of the submitter, what is their technical level, whether they are talking out of their ass or not.

It's basically the same issue as spam in emails. It was bad before, and automation made it a zillion times worse.

Sharlin - 1 hour ago

It can, but using a technology just to work around problems caused (or at least exacerbated) by the very same technology is obviously not something we should be doing or encouraging.

JodieBenitez - 2 hours ago

And how will this be enforced ?

yulaow - 1 hour ago

How they enforce it in every other project with the same policy, if the reviewer/maintainer suspects the pr is ai slope he closes it. That's it, it works fantastically well, I do the same even in my job

JodieBenitez - 1 hour ago

"suspects".... that sounds error prone. And I read it like "we don't want AI generated stuff unless we can't tell the difference".

terminalbraid - 42 minutes ago

It's their project, they can run it how they like. If they lose out on valid contributions that's their loss.

People are never entitled to their contributions getting accepted to someone else's code base.

yulaow - 1 hour ago

exactly, I for example don't care usually about false positives, in the very uncommon case it happens the pr creator can discuss and prove he actually understood the problem, the codebase, the project policy and how to explain his solution actually could work.

LauraMedia - 1 hour ago

Any PR will get the same quality review. It's just that they now have a fast lane so they don't have to invest that much time to review a PR they won't fix properly and/or support.

eschaton - 1 hour ago

How do they enforce that contributions aren’t copied and pasted from AGPLv3 or proprietary codebases? The honor system and intuition and occasionally flat out asking people.

Do you think sociopaths willing to lie about how they came up with a contribution are really that common?

JodieBenitez - 35 minutes ago

Let me tell you a story: I use agents at work. Not to add more useless features, not in a let-loose way, not so that I can slack all day but to produce better output. Think performance optimizations, security fixes, better use of underlying frameworks, produce better documentation, get useful hints from the code base, that kind of thing. In a word, to produce objectively better software. that is my honor: giving the best I can.

Because AI is frowned upon where I work, I kept that under the radar. And I got nothing but praises for the good work, everybody loving it. Later I had the opportunity to port a piece of software from one language to another. LLMs are great for porting stuff when steered well. Again, nothing but praises for the amazing work done in a very short time. And this is where I tried to open a debate about AI by disclosing my tools and methods. And boom, suddenly I was evil. Praises gone. But still, none had the guts to throw the port to trash, because it's still very good. Hypocrisy.

So yes, call me sociopath if you like, but I will lie, produce better software and get the praises if I have to work in an environment that values tools and methods over results.

mellosouls - 1 hour ago

Underlying announcement might be a better link:

https://godotengine.org/article/contribution-policy-2026/

I predict this won't last long in any extreme version in any significant open source repo.

Banning AI-slop is one thing, but AI as a properly used co-programmer is becoming more and more capable and shutting out well-guided AI will enable competitors who don't to edge and then power ahead.

There are obviously problems to solve here, but blanket bans (while understandable in under-resourced maintenance environments) aren't anything more than a short-term buffer.

dude250711 - 1 hour ago

If AI is so good, there should be hundreds of new engines far exceeding Godot.

Yet all that is being produced is piggy-backing unchecked vibe-slop.

terminalbraid - 39 minutes ago

It's also telling with all the comments of "just wait a few months the models are getting so much better" which has been said for years and will continue to be said for years. It's the same with any other scam with tenuous value (see cryptocurrency).

At some point you just call it failed.

shevy-java - 2 hours ago

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.

ivorius - 2 hours ago

> 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.

villgax - 2 hours ago

Just put it behind a paywall for PR prioritization or consideration, more payment to jump the queue.

There, I solved FOSS sponsorship.

Fraterkes - 1 hour ago

I honestly think that a 1$ “deposit” to submit a pr for new contributors (to be returned if the pr is merged) could help with a lot of OSS problems

claud_ia - 1 hour ago

[flagged]

MagicMoonlight - 1 hour ago

[dead]

marsven_422 - 2 hours ago

[dead]

endre - 2 hours ago

oh shoot, anyway

taris2 - 2 hours ago

Godot is one of the worst run open source projects with a crawling pace since 2014.

tmountain - 2 hours ago

It’s been wildly successful. Poorly run projects tend to fail.

throwfaraway135 - 26 minutes ago

If Unity didn't commit hara-kiri I'm positive it would be much less successful.

JsonDemWitOster - 12 minutes ago

And if yomomma had balls, she'd be yopoppa.

Puh-lease. Unity's "hara-kiri" was in 2023 by which time Godot was NINE years old. Hara-kiri or no hara-kiri Godot has shown longevity and relevance. Anything gained from Unity's own-goals is just cherry on top.

Stevvo - 1 hour ago

This was true until a couple of years ago. Recently things really picked up. That said, there are still many years old open PRs unmerged that make great additions; maybe this policy will free up resources to move forward with those.

jokoon - 2 hours ago

Care to give arguments?

localhoster - 2 hours ago

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.

dgellow - 2 hours ago

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.

SwtCyber - 1 hour ago

And it just keeps looping like that until the context window bursts. In practice the model is great at writing new code, but when you feed it its own six month old spaghetti code with a floating bug in the state machine it just starts hallucinating and silently breaking neighboring features

eschaton - 1 hour ago

You block them from using AI by making sure they know your project doesn’t want contributions from people using AI. Either they’re a decent human being and they’ll comply with the project’s wishes, or they’re a sociopath who will violate the explicit request of the project and lie about the origin of their contribution and hopefully slip up and get caught doing so.