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.

It's a guideline, the maintainers won't collectively explode if generated but unmarked code happens to pass review.

The problem with "they can just have the AI fix what's wrong" is explained a bit more in the contribution policy itself - https://godotengine.org/article/contribution-policy-2026/ - nice-to-have features often require design decisions which aren't obvious to outside contributors, but which can create a lot of work for maintainers, especially in game engines where backwards compatibility is a must.

A good example is their ongoing effort to restore C# support to web builds - https://github.com/godotengine/godot/pull/106125 - in Godot 3.x .NET integration was done through Mono, so web games could just bundle the Mono interpreter, but for 4.x which uses mainline .NET, the original plan of instead building WASM bundles (https://godotengine.org/article/platform-state-in-csharp-for...) was blocked by .NET WASM bundles not supporting dynamic linking, not by Godot itself.

The modal person asking "When is C# going to be supported for web games?" or prompting a fix likely won't know to ask "Does my fix need SharedArrayBuffer support?" and "Does my fix rely on patching the .NET runtime?", or why those questions matter, and will get frustrated when the fix that works on their machine then can't be merged into the main project.

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.

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

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.

> they can use AI to fix it

AI isn't some all powerful programming oracle that can do anything. Sometimes it doesn't do things right and if you're just blindly copying and pasting its mistakes to some poor reviewer that's going to piss them off.

Also what's the point? If you're just relaying messages to an AI what do you add?

I'm guessing you've never been on the receiving end of this behaviour.