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.
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.
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.
Or LLMs, as we have seen.
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.
It was a constant struggle to get them to be concise, one I mostly lost.
"And the Lord spake, saying, ''First shalt thou take out the Holy Pin. Then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who, being naughty in My sight, shall snuff it.'
... then flooded maintainers would be doing it.
The policy allows the reviewer to reject it on the "AI" grounds.
… but still unfortunately leaves reviewers having to spend time checking submissions and rejecting them.
* 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.
“Mission. Fucking. Accomplished.”
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.
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.
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.
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.
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.
Most PRs to me are not coming out of nowhere anyway, rather they're "here's the linked issue, I started out addressing it by doing X and Y, but then Y got hairy so I switched to Z, hope that makes sense but happy to discuss further as well."
And most feedback is not "let's have you explain the design to me in a diff comment" but rather please explain this design in a code comment so that the next reader of the source will have your context.
- tough hiring market, especially for more Jr candidates
- the perception (true or not) that OSS contributions help get attention from recruiters
- LLMs making it very easy to generate “contributions”
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.
Its not 500 moves ahead.
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
Are we really in a situation where good code that solves a problem won't be merged because the person the person checked the "I used AI" box on the PR?
Ban PR's that are too big, don't have a clear purpose, touch too many areas, etc.
Basically a play sandbox for contributors to not get jaded. A honeypot to contain the verbosity vomit, while also serving as positive public relations by keeping young contributor morale from starting in the basement.
Everyone has been that person once early in their life who is told they aren’t welcome and never comes back. Maybe it was SourceForge or IRC, maybe it was Wikipedia.
Say AI is used to identify and rewrite a single function that improves performance or fixes a bug, then the developer carefully reviews and tests it and submits a nice tight PR with all human communication.
So they don’t want that? They would just reject it?
If I’m understanding correctly, under the policy the higher performance function / bug free submission would be rejected and they could ask for a rewrite.
Should it then be rewritten from scratch, and clean room engineered so it doesn’t resemble the AI too much?
It's pragmatic. Linus once said, the reason C++ is not allowed in the kernel is to keep the C++ people out.
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.
I have some misgivings about AI, but I'm not a fundamentalist - you can't be or the machine will squish you, frankly - but please, don't spam me with text or code that could be much shorter. Relevant quotes:
"I didn't have time to write a short letter, so I wrote a long one instead"
"Brevity is the soul of wit"
This helps with PR reviews as it prevents a giant wall of text but it’s still verbose. However doing it this way cuts down on the wall of text at the expense of increased PR frequency.
Perhaps reconsider "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer..."
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.
Continuing the analogy: if this happens, then you are using the wrong drugs or you are using the drugs wrong. It's not like there's an axiom "you can't enhance your performance without detrimental side-effects."
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.
Important to note that fast never meant much to open source and for good reason.
It was never a moat.
Moving fast and getting to the right destination is a huge moat. AI changes nothing here.
If you missed your destination, the solution isn't to think deeply about where you're supposed to go, it's to drive faster towards the next goal, so that if you make a mistake, it's not that big of a deal.
The slow moving projects didn't have some magic knowledge about where to go, they made the same mistakes but at a slower pace.
But all of this relied on the fact that code went through the brains of a human and said humans intelligence gets updated from the feedback, so that the developer builds a theory/model of what the software is really meant to look like in the end.
With AI, there is no such model. A context window is more like a tape or a film. The human is still responsible for building that mental model.
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
the assumption that all code (and everything else producing digital artefacts) will be written using AI in the near future,
No, we don't have to. We can just write code ourselves.
(My condolences to people who have jobs where AI is mandated.)
Godot, Zig, who else? Most major OSS projects I know are openly welcoming high quality AI contributions, not fighting to keep them out.
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.
I gave it an innocuous 2 sentence prompt, telling it to help me implement it, by building X first.
It produced code, and it was a big wall of code, which I expected. What I didn't expect is that the zed developers completely threw out the accept/reject workflow since Codex is no longer directly integrated into zed anymore.
Instead of the agent patiently waiting for my acceptance, it just kept going, it automatically ran cargo test, kept iterating like a dozen times, running cargo test and editing the code. Since I was in the middle of a big refactor, I kept a dozen compile errors as a reminder. It tried to "fix" these compile errors.
Then it proceeded to keep going even further and use the code to finish a file that was supposed to use the new code in the future.
The end result is as expected: It produced completely unusable garbage code that no sane person would sign off on and not just that, it used this garbage code and kept going with it, building more garbage on top of a garbage foundation. It also silenced the errors by producing more garbage code.
I'm the type of person that thinks the "accept always" button for specific commands is the dumbest idea ever [0], but they went one step further and basically made the agentic coding experience so bad it became unusable overnight. At this point I'd rather abandon agentic coding and go back to copy paste development with a chat interface.
[0] it's either accept or reject, everything else is stupid
For a project that already struggled with the ammount of PRs to review before AI era is not fair to mantainers to keep dealing with things like this.
That's why the real big change in the policy is that new contributors can't take big features or refactors.
This university is very stupid university. Is there anyway to know which university is forcing these kids to spam open source project?
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.
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
And some projects like WINE or ReactOS probably have to worry about that even more given they need to guarantee clean-room reverse engineering...
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.)
https://codeberg.org/brib/slopfree-software-index#why-care-a...
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".
But I think the point the parent commenter made is: if there's not a functional difference in the result (i.e., job satisfies the definition of done), it doesn't matter if the AI generated the code or did the diagnosis.
But I think it's also fair to say that the process matters, even if the result is the same. If something exists for our benefit (e.g., there's no real alternative to learning-by-doing, and people need to know stuff for safety/security reasons), and we're fine with the trade-off, there's no reason to just give up the process to the AI.
(And I'm unfortunately no longer as certain that "Well, that sort of thing can't happen where _I_ live." as I would have been a decade ago.)
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
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.
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".
I'm sure some are convinced LLMs can (eventually) manage everything, and others (I'm leaning more here) are convinced that you will always need a minimum amount of people both educated in the fundamentals and the domain to steer the project, and these people wont exist down the path of non-human PRs.
If it fails to run who is responsible to fix ? Problem with AI is that it does not have causal-models of how something works, and the reason for that is that it doesnt interact with the world. I think of it as an armchair expert who spouts recommendations without having a grounded understanding in the real world.
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.
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).
Agreed, but my main point is most people continue to do exactly this and simply won’t stop. They think “AI took care of it and it’s good enough” then essentially shove their work on to the recipient 30% completed. So long as that’s the way most people use LLM’s we will continue to see restrictions put in place by the recipients.
Imagine morals.
That makes much more sense now. The inability is completely on you, and you admit it at least.
There are functional reasons for a no-AI policy. It helps the Godot Foundation function to establish a no-AI policy. Do you argue it doesn't help them function?
Do you understand the difference between functional and non-functional?
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.
If you use rsync clone by an LLM to copy a million files, will you bother to verify every single one was copied correctly?
And I'm not disagreeing - it is hard to anticipate what needs verifying, regardless if it's functional or non-functional.
But if it's not a spam submission, you could probably design tests or static/dynamic analysis tools that can verify those million copies much faster than manual reviews.
So you have integration tests that verify the general specs of the software and rely on your skills to verify the finer details. But if you’re using an LLM (and not reviewing every line), you can no longer be confident about those details.
And reviewing every line kills the speed advantage of using LLM.
> I can't think of a functional reason for a no-AI policy
These lists don't have you as an audience.
That is to the point!
It takes 10x more effort to refute BS than to generate it. Reviewing code is refuting. So is verifying the correctness of propositions. Generating propositions is easy, Refuting it requires proving the truth value or finding contradiction.
For maintainers of open source whose time is scarce, their energies are wasted needlessly, and I am all for conserving and directing energies productively.
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.
(It’s famously not well capable of sounding human)
Rather than a binary, I prefer to measure the question of "how much text does it take to be reasonably sure that it's an AI?"
By that metric, it is getting better at a reasonable pace. People are also getting better at prompting their AIs to write in something other than the default LLM style. If you think you're good at picking up that style, you probably are. But it's a lot harder to pick up AIs when they're fed a style sample. You wrote in the default AI style, and yeah, most of us have twigged to that by the end of your couple of short sentences. But feed the AI a style sample and it can definitely make it two sentences without every one realizing it's AI.
That I think is also an important issue if a project wants to keep AI out of its code.
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)
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.
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)
They can even list on their CV that they are the maintainers of those projects.
I do think I helped out.
And I have discovered this edge case when fiddling with my homelab which is my hobby.
Both PR were tiny, not different from human PR. I still believe these were valuable additions, and obviously some maintainers think the same.
AI can materially improve PRs - you just have to do it right.
Firstly there are not going to be a material number of non-AI patches written in the future. I know some people still ride horses, but when compared to the 17th century the percentage of travel primarily enabled by literal horse power is way down. Same way goes "artisinal, hand crafted code"
Secondly the problem isn't the AI - it's the crappy prompts and lack of intermediate artifacts and quality gates (deterministic and adversarial) in the generation pipelines.
Thirdly, don't disallow AI (I mean, feel free, you're doing something without charging for it - do you) - disallow crappy PRs, verbose descriptions. and bloated code that doesn't fit your coding standards.
Fourthly, ship your standards. Document what a good PR looks like, the comments and examples, the search for open PRs to ensure it isn't a dupe or a won't fix. Then ship your coding standards - have some LLMs infer them from your current code base and review (bonus - anything it infers correctly that you don't agree with, get it to re-code to your new standards).
Then set up a PR reviewer - start with deternministic gates for the format of the PR and some broad heuristics, then run it through adversarial reviews. Anything that looks great, feel free to run by a human either before the merge or after just to keep an eye on things.
The deterministic gates will cheaply get rid of 95% of the slop (AI and human - I've seem plenty of human slop over the years) so you can focus tokens on the good stuff.
- Disable public pull requests.
- Require people to open an issue or discussion. Issues and discussions should have stated length/quality parameters. If an issue is a wall of Claude-text, users should be prepared for this text to be automatically summarized into plain language. If you don't want your Claude-text to be machine-turned into something human-consumable, the onus is on you to post human text up front.
- PRs are only drafted once approved in issue or discussion
I'm wondering if this is a tractable approach that yields results. I've seen references to a few projects trying something like this. Would be nice to hear folks experience.
A better policy might simply be to automatically (using AI for this is kind of an obvious thing to do) filter and classify incoming PRs and issues for complying with quality thresholds.
A huge PR that comes in without a clear discussion history in the issue tracker is kind of a rude thing to do. That should be an automatic close. Have some good contributor guidelines and then enforce them. With or without AI. Block repeat offenders that can't be bothered to stick to those. Most of the annoyance comes from having to do all this manually and getting distracted by all this noise.
A small, focused fix that comes in with a well articulated explanation of what was done and why is a different matter. It shouldn't matter if the contributor used AI or not.
The main issue is that the signal is drowned out with the noise with a lot of problematic contributions from new/unverified users. But those should be kind of easy to detect as well.
There are multiple ways to deal with this. But a blanket ban on AI is a bit throwing out the baby with the bath water.
I actually have the opposite problem on my OSS repositories. It seems people are to busy doing their own projects to actually open pull requests on my projects. There's a noticeable decline in the number of pull requests since last year.
As someone with 2 years of Godot experience (which seems like a lot given their lifespan), the underlying infra isn't strong enough to ward off the many competitors that will embrace AI at the heart of the engine. Ironically, the best engine right now for AI-assisted coding is Godot! It has plain text scene files, and Opus does a half decent design - screenshot - iterative flow to get things off the ground before artists clean it up.
Being an open source maintainer is HARD work I wouldn't wish on my worst enemy. However, the Godot team has very strong opinions that don't really drive especially better software. There is a small history of being confrontational in their github PRs, and a strong opinionated approach. They mostly inherited their current spot in the market from mistakes and commercial pressures of the top two engines (cough Unity per-install fees).
The removal of AI-generated contributions is pitched as helping them maintain a better core product, but in reality, (my prediction) it will end up massively hampering velocity over the next 3-5 year horizon.
At the same time, it used to be impractical to make your own game engine to make a game. Now, with AI-assisted coding, strong game devs have a viable option, despite the added complexity. Rust libraries like bevy provide the training wheels to a half decent dev + AI assistant that can build more bespoke smaller engines for indies. To gain Godot's level of indie marketshare, a single breakout engine project that embraces vibecoding could be enough. I expect that will gobble up eager /r/aigamedev Redditors and the new swarm of unemployed juniors fresh out of college.
But they'll both be beaten by people using AI intelligently to generate code, but not letting it drive everything. Who look at every line and apply their experience to fixing what the AI generates until it outputs more or less what you would have, only more quickly.
The false dichotomy that some of you are trying to push between "just taking whatever the AI slops out" and "pristine hand-crafted code by dedicated, loving experts" doesn't exist.
I mean, this remains to be seen. Is this actually much faster or better than coding by hand?
(Not a facetious question: it's one I grapple with all the time)
We have PR auditing skills, PR writing skills, testing conventions, etc that all need to be self-monitored for bullsh*t Claude ignorance (e.g. you apply them many times, then review your own PRs manually before merge). None of that is free, but we have shipped significantly more code as a result.
It's a game built in Godot that runs on mobile (a mobile game). Godot is C++, there is no porting of engine to run on mobile? Slay the Spire 2 is built in Godot and has 500k concurrent users.
Who are the competitors? Something lower level like bevvy? The way I see it even with vibe coding you need to do a lot of infrastructure work to make editing easy, and anybody except Unity is far off from them.
GUI Editor is not one I'd list.
Internal tooling stood up a GUI Editor clone within a few weeks that was targeted towards our specific use case. Their editor isn't uniquely ergonomic. In fact, for about 3 releases, one of the highest requested objects was multiple tabs at the same time. A rather standard feature in an editor and especially a modern code editor.
My argument isn't totally about individual devs making engines (though it is actually feasible on a Max plan), I'm imagining a very small team competitor that embraces AI-assisted PRs, internally and externally, along with vibecoding directly baked into the app itself (MCP or more direct claude code scripting language integration). That would be able to match or exceed the functionality in Godot, probably with more common and performant scripting languages (Rust + Luau for example).
What are you basing this off of? There are already plenty of game engine projects like what you describe here. Doesn't seem to have affected Godot thus far, unless I'm missing something.
There isn't, until there is. These things take time. The tech has to be adopted, the people have to integrate into game jams, indies percolate. Godot is young, my predictions are 3-5 years.
Regarding competition though, the question is about the unique selling points of Godot that would be hard to replicate. Before AI coding, there is a _lot of momentum_ for leaders in the game engine world. Everyone specializes and it takes many years of game cycles to make the switch to a new engine. Not anymore!
So we have yet to see a dog-eat-dog game engine world, and in that world, ejecting AI-coding could in fact be a net negative. That's what I am arguing at least.
Regarding the unique selling points of the engine: 1. Open-source 2. Node/Scene encapsulation design: Big! - Easily my favorite part of GDScript. Easy to replicate. 3. Scripting languages: GDScript, buggy C# - AI-coding doesn't care what language as long as it's popular
My suspicion: A competitor could use a known compiled language (Rust) and a scripting language (luau) and get the same mileage as Godot and replace every one of their selling points with more performant code. Because they waited so long to deploy a marketplace, they have very little sticky bits to their market share.
PRs with just the results and final code doesn't seem better even if we assume ai coding will be much faster.
The team is taking a pretty strong stance against external AI-assisted PRs, which makes you think they'd take a weak stance against internal AI-assisted PRs? It's hard to draw the exact line, but maybe?
For our team, the outcome is the PR, and you have to set up _a lot of testing infrastructure_ to prevent regressions. It's a skillset like any other.
It would be consistent with their actions that my belief is they are slow to adopt workflows that will accelerate them. Thus velocity will decrease.
What I am saying is squishy conjecture.
On the other hand, they're training new contributors to make internal AI-assisted PRs by requiring them to make non-assisted PRs? That sounds unlikely but I suppose possible.
Building on an engine is a HUGE investment, and nobody serious picks a game engine because of its feature velocity, they pick it based on what it can do today.
Also in terms of marketing I think this is pretty clever. I know a lot of game developers (I used to work in the industry), and pretty much everyone I know despises AI on some level. HN is mostly business people who see dollar signs, but creatives just see destruction of art forms they care about, so none of their users are going to see this as a bad thing.
When you go to invest in an engine. One with Claude Code natively infused and another that says "meh" to AI. Which would you have your small indie dev team choose? Smart money says velocity. I suspect the Godot-slayer I am imagining will start getting buzz in /r/aigamedev subreddit as the only way to quickly code a game. A little better design and 3D work from Anthropic, and we are off to the races.
Regarding game dev hatred of AI, I've been to GDC for the last 3 years for the explicit purpose of talking about AI in games. The wall of hatred isn't holding strong. It used to be universal. Now, not so much. People on their laptops claude coding during presentations. 20% of talks being about AI in games, and _sponsored (!!!)_ talks about AI are getting the largest crowds at GDC this year. The times, they are a changin'. This is only a clever marketing move for a certain set of developers, which I totally agree are the (maybe?) majority today. I said 3-5 years though, not 6 months...
Here, you're making a negative argument, it "can't" be done. Maybe. Historically, correct. I prefer to image what could be done. As insane a statement as it sounds just 15 months ago, a small dev team could get it done, I'll stand by that. Framing is up to you, to each their own!
I mean, even with the advent of “AI” agents, is software today any better than it was 3 years ago?
I think teams embracing too much LLM coding are going to see a continued decrease in quality and a massive drop in team productivity. Godot, on the other hand, is avoiding this. While it might not be as trendy, I think it’ll be a competitive advantage in the long term.
When accounting for "coding taste," I think there is equal or higher quality output over small teams, and if there is a decrease in software quality, it's nowhere near the implied amount (5-10% at most) with a massive gain in speed (approx 3x? 4x? hard to measure). Those numbers net out positive in the end, especially as the team starts to understand and ship with AI in the loop.
Like who? Unity/Unreal? Those are completely different engines for a different audience. IMO, Godot has a unique market space and no real peers. I think this was a wise decision that only adds to their brand as something for creators rather than corporations.
If AI-assisted coding can help corporations make AAA games with 1/10th the resources, then it would stand to reason it also helps indies make AAA with 1/10th the resources? I have never understood this argument.
Godot has no peers because for the last 30 years in software, it's been hard for people to make their own game engines, which made open source engines totally impractical. W4 is a non-profit organization that happened to get just enough resources and traction to make it. That underlying assumption is not true anymore, making engines has never been easier in software history. Unreal/Unity are not the competitors I'm talking about.
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.
there's a few elsewhere in the comments here but I'm not sure how comprehensive any are
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?
But the blog post is written in future tense. I don't think they have a new contribution policy file yet
However, as a senior engineer with fairly deep technical knowledge in these areas, I'm now using AI in my own projects. Frankly, before even touching Github, I'm already drowning in code reviews generated by my own use of an LLM!
There are meaningful, generally good PRs waiting for my attention against GodotJS, and other projects I (somewhat) maintain e.g. MoonSharp, C# Lua runtime. It was already extremely difficult to stay on top of PR code reviews for reasonably technical projects. When you're already somewhat burnt out from reviewing LLM code all day, it's so much more exhausting than it used to be.
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.
(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; [...]
How about if AI generates code in a file, then I copy/paste bits... like stack overflow ?
I assume most IDEs allow you to use their snippets under many different licenses. LLMs have mostly been trained on public git repos under lots of different licenses (most importantly, Copyleft licenses)
Allowing AI use by 'trusted contributors' has been suggested and discussed, but there were enough reasons against it and not enough established benefit.
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.
...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....
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?
It's basically the same issue as spam in emails. It was bad before, and automation made it a zillion times worse.
I don't know if this is a very universal feeling. I personally find reviewing code is tedious compared to writing it
Not just the process of reading the code and understanding it, but the back and forth can be miserable if the submitter isn't meeting you part way
I dunno. Maybe I'm the odd one out for thinking reviewing PRs is more of a chore than a joy
FOSS has become the release valve for too much labour supply.
People are never entitled to their contributions getting accepted to someone else's code base.
The rule is general on purpose to allow the maintainer to freely remove whatever is very evident is just ai slop
Do you think sociopaths willing to lie about how they came up with a contribution are really that common?
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.
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.
That already happened. Redot is a major fork that's more community-driven and positive. They're also fine with AI use, as long as you review, understand, and take responsibility for everything you do with it. https://github.com/Redot-Engine/redot-engine
They're also building a brand new game engine from scratch! https://github.com/Redot-Engine/DraconicEngine
* Software security - I.e. Mozilla blog post on using Mythos for software security [1]
* Algorithms - AlphaEvolve makes real progress on matrix multiplication [2]
* Open source - Backlog crushing in openvpn [3]
* Corporate - CloudFlare Oauth workers [4]
People are clearly using AI to ship real work that people end up using directly or indirectly. Projects like Godot are also in a weird spot though.
[1]. https://blog.mozilla.org/en/privacy-security/ai-security-zer...
[2] https://arxiv.org/abs/2506.13131
[3] https://stanislas.blog/2025/12/claude-code-opus-open-source-...
On an unrelated note, I lost all respect and eagerness to try it out after the drama.
Also, what drama?
Google Godot drama 2024, for some top-notch community mismanagement classes.
Though I guess if your stance is “these people should have less rights” then it is politics, but in that case I don’t see the drama for banning people.
This doesn't mean I agree with them, but pretending this isn't a complex and very large issue with multiple facets is just wrong.
Basically some incredibly stupid highschool level drama fed by the worst YouTubers you can think of. People vaguepost about it because it's so dumb.
You just can't expect someone who isn't willing enough to write one good PR to be willing to become a good maintainer.
is about quality not AI which is exactly my point.
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.
I predict any project that allows AI will slowly degrade in quality
I've seen policies like this in various places and they do not generally seem to be based quantitative measures of code functionality, security, and efficiency.
There are other approaches to take to deal with large numbers of incoming PRs: improved CI, AI-readable standards for AI code, better static testing, AI first-pass review, etc.
It's fine to enshrine hobbyism into your code review policy to keep things fun and human-scale. On the other hand, where projects actually matter, it is necessary to think about code review as part of an industrial process with inputs and outputs, one where this sort of thing has no place.
This gets a lot harder when there is a giant wall of text that the pull requester doesn't understand and can't really discuss outside of asking AI (and probably getting "The reviewer is right to push back - I was too aggressive in my blah blah blah" as an answer).
A lot of (but maybe not all) pull requests are fundamentally a human to human task, even if there is a lot of technical details involved.
Another part is "how do we communicate project goals and ideals and standards?" The answer to that, I'd argue, is not simple, and will inherently run into scale issues. It's something that needs to be tackled as you move from a bespoke craft project to an industrial project.
Now, maybe you never move. It's okay and good for hobby projects to exist. But let's be clear about the choice there.
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.
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.
There, I solved FOSS sponsorship.
Yet all that is being produced is piggy-backing unchecked vibe-slop.
At some point you just call it failed.
No need to ruin existing software?
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.
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.
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.
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.