It's a fair policy. Getting those verbose, AI-authored walls of text is very annoying, especially when you're expected to thoroughly review it. It's like a denial-of-service attack on the human mind. I can only imagine how frustrating this can get in open projects that get a lot of contributions.
However, I don't think this will discourage AI-based coding at all. In fact, I see two potential outcomes of these policies:
- Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
- Positive: Submitters actually provide to-the-point, no-bullshit commits and comments - "here's the code, here's why I made that change, here are the effects of that change". Even if AI-generated, these small contributions may become much easier to verify & validate. We may even see some standardization in terms of what qualifies as an appropriately sized contribution, what requires more thorough review (e.g., adding unverified dependencies), etc.
I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
> - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
> Positive: Submitters actually provide to-the-point, no-bullshit commits and comments
> 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.
Dingdingding, we have a winner. The main use of such a policy is to be able to just close those giant wall-of-text PRs and have something to point to when people start to scream it's not fair.
Why is a policy necessary. you were never entitled to have your pr merged in the first place? If pr wasn't reviewable pre AI I'd expect it to be closed or ignored too
The policy isn't necessary to close the PR. The policy just helps to shut down the ensuing discussion after closing the PR. It helps in quickly dealing with well-meaning onlookers asking for clarification when you block PRs from the account.
Before AI a large pull request was enough effort to make that you could assume good faith work on the part of everyone. Likely even if it is bad for architectural reasons it is solving an itch other users have and it is reasonable for them to want an explanation why you refused someone who made this much effort. And since the effort required meant it didn't happen often it wasn't a big deal to provide that.
These days large PRs are easy to create and so humans need to shut them down.
Whether or not someone is entitled to something has very little bearing on whether someone believes they are entitled to something (and are willing to waste everyone's time to make a stink about it). Having clear rules to point to, even after the fact, is surprisingly effective in mitigating that.
Or, put more bluntly, your belief in what people ought to feel entitled to has no bearing on what they do believe, and policy needs to address the latter, not the former.
Prior to AI making a PR involved considerable effort from a human. So the default position for many open source projects was that it deserved some level of attention for the effort. Even if many projects in practice would struggle to review every PR. But with AI tools this dynamic has shifted dramatically - many PRs have basically zero effort been put into it. Additionally there are many more of them, and often way bigger also.
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.
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.
Reading AI PRs reminds me of Monty Python's holy grenade:
"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.'
I wouldn't mind reading that and having a good chuckle while processing an MR, as long as the comment had been crafted by a person. But now I think writing in grunts is gonna become the thing. "pete? you good boy? we won't hire you/ paper you gave HR girl with older gigs? remember it pete my boy? too many words/ words were too long/ dots you used dots/ you scratched long dash with knife, but baby saw scratch/we don't ai pete/ask if they have job in next cave/good luck."
I've found that the instructions "be extremely concise" gets me much closer to output that's actually sensible/helpful rather than another wall of text.
> 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.
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.
A contributor in good faith is going to accept criticism and resubmit an improved change: less files modified, more explanation, more focus, references to actual tickets and discussion with actual developers.
They could allow AI PRs, but then have another AI PR reviewer reject them if they do not match the definitions for `to-the-point` `no-bullshit` commits.
Please provide 3 examples where layering on MORE of the offending technology has solved the problem. Spam? Malware & Viruses? Customer Service? Hiring & Recruitment?
We just recently started that policy so we'll see how it goes. If anything, having it stated as policy lets us filter out these requests without spending brain tokens on them.
I've always instructed Claude to check the policies first, frankly I'm surprised it's not smart enough to do that already. Would be easy to add to a system prompt. But usually it doesn't matter because many projects have no policies, or maybe they exist but only in hidden forum posts issues or something.
> 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.
> The problem is that a lot of AI contributions are lazily produced without review.
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 should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". So it can be both satisfying and worthwhile to spend your effort on cleaning it up, even if it starts to take as much or even more effort than doing it yourself would have.
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.
> You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community".
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.
The Godot maintainers have decided they don't support that perspective. In their words, they value "being cautious about feature creep" and "dedicated to high code quality"; they don't accept that all working code should be merged.
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.
> they don't accept that all working code should be merged.
That’s perfectly within their rights to do!
> Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork.
Too many of those do fragment the development effort and hurt any project.
Here’s hoping that Godot doesn’t struggle too much with people who don’t care about their rules and spam PRs regardless and that the people who want to commit AI code regardless because it works and is good in their eyes at least demonstrate enough initiative to cheat convincingly (maybe actually read the code and make it their own). Godot is a pretty cool project!
Wonder what the middle ground would look like - a project with super high test coverage and tooling, that also requires at least 20 USD in Opus tokens spent on review on the behalf of the author or something, before an actual human being is bothered with it? Heh.
Says the definition? I don't really understand your response. A pull request is a request from Alice (the author) that one of Barbara, Chris, Daniel (the maintainers) should pull her code into a particular branch.
Many communities do have a norm that all authors are to be presumed equal, as long as they're prepared to take advice and learn from it. (That's where all experts start, after all.) That's the norm that Godot are trying to protect here. If they don't stop accepting AI-authored contributions, they worry, reviewers will start to implicitly load-shed by not reading PRs from people they don't recognize.
I was explaining why the Godot maintainers have chosen to enact the policy described in the source article, in response to a comment saying that they should not have enacted it. I don't understand why you think I'm dictating or arbitrating anything.
I'm saying that most people, even most programmers, don't have the facilities or inclination to train new models man. I've done it plenty of times and I absolutely don't recommend it.
Frankly I don't think you even know what the phrase entails.
So again, you can train people but not AI? That's literally what you've said and now moving the goal posts in a way that makes no difference to what you said being patently wrong.
It's wild having to argue with people who say demonstrably untrue things and then refuse to admit that what they said was wrong.
> > The problem is that a lot of AI contributions are lazily produced without review.
That sounds like a contributor problem. Not an AI problem.
Ish. The tool is not doing the job fully, the contributor is not doing their task properly, checking for that, and fixing the issues.
> 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.
Think of it like offering a job, and getting 100s of CVs. You don't have time to review each in detail, so you weed out a chunk of them using superficial cues that have been indicators of issues in the past. They are filtering the other contributions too, the no AI rule is just part initial triage to save a lot of time.
You have missed a key point in what I wrote: "Those that have been properly reviewed for correctness [before being submitted] will be indiscernible from human-only contributions". It is like a Turing test: if you take the effort to make your AI aided contributions good enough to be indiscernible from good human-only contributions then the no-AI filter won't bother you because the people or automations enforcing it won't be able to discern that your contribution was assisted.
> where good code can't be submitted unless the submitter lies.
No. Unless it looks like a good contribution looks.
The problem a lot of projects are facing right now is being inundated by bad PRs from people using AI without the effort to, or likely the knowledge of how to, properly understand and explain & document the change. People have a limited amount of time and if the filter saves a lot of time then maybe losing one or two good contributions due to the filter is worth it - better that than the project stalling under the weight of managing all the PRs.
This is one of the reasons, even pre-AI, some projects declared themselves "open source but not open contribution".
If they are simply filtering out based on signs of AI, then there is no lie.
If they are explicitly asking “was AI used” then yes, there is a direct lie involved.
If there is no explicit question but you are including “lies by omission”, then be aware that there are many things people choose not to say that they would be unfairly judged for if they did state (gender details, certain parts of their history, etc) so that might not be a line we want to draw.
I'm not exactly pro-AI, in fact I'm avoiding it in DayJob to the point where I expect at some point I'll be given the choice “get with the program or leave” (I plan to leave at that point, preferably by my own choice though we'll see how heated the discussion gets!), but if there is a at least one human at the end of the process that is properly testing and cleaning everything up so there can be nothing problematic in the AI output that survives, is that really practically any different to a fully human created contribution?
The problem with AI contributions in the vast majority of cases is the lazy ones, especially considering the sheer number of them. Using signs of AI as a code/documentation smell when it comes to filtering contributions is fine, especially if you have up-front requested no such contributions be sent. Permanently blocking people who have sent obviously AI-generated contributions previously despite you asking them not to, is also fine just as blocking people who have sent in entirely human made contributions that break your other requests/rules is. But banning all AI use when if you can't tell if a good contribution did or didn't use AI aid somewhere in the process, is both a daft extreme and actually impossible (if you can't tell, how do you tell?!).
> 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.
Who says anything about „this far in the future“? It’s enough for Anthropic et al to realize this one or two model versions ago, see it as a strategic advantage and push for that behavior.
Literally some of the first advertised uses for LLMs were both "You can feed it bullet points and it will compose an entire email" and "You can take long emails and condense them into bullet points!" They've been doing this since day 1.
While it certainly didn't enter a mind of any director making decisions (because they can't comprehend not defecting in a prisoner's dilemma, being sociopaths), it was plainly obvious to every person even remotely connected to IT in the past two decades. If one makes a better and faster spam generator and the same unchanged program also works in reverse, by sifting through spam and condensing it to a readable summary, that it will be immediately co-opted in a spam arms race by all sides of the war and become essentially mandatory.
AI also works better with concise, focused, high information density text. So AI-spam text hurts both humans and AIs, but humans more so than AIs. It is always a negative, except for the "competition" between (human with) AI and human without AI.
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
YES! "No AI" policies that are purely based on technical grounds make no sense to me. Bad PR's are bad PR's regardless of their source.
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.
It's really a question of how much time you're willing to spend sorting through spam. "No AI" might be a blunt hammer, but the people submitting slop aren't reading guidelines anyway, and it's easier just to reject it early. Frankly, I'm sure if people wanted to sneak in an AI generated code by carefully reviewing it and making sure it's targeted and well tested... I'm sure they could, but those people aren't the problem.
> Frankly, I'm sure if people wanted to sneak in an AI generated code by carefully reviewing it and making sure it's targeted and well tested
But this is exactly the point I'm making. If the code is carefully reviewed, targeted, and tested, then why make people have to lie in order to submit PRs?
Why not just say "Irresponsible use or agentic-based PR's will be auto-rejected"?
And that's not even mentioning that tools like Github Copilot can just act like fancy autocomplete. There are dozens (if not hundreds) of different ways to use these tools.
I guess I'm just really not sure how you can unequivocally forbid these insanely powerful tools when they are almost certainly going to be a large part of developer's workflows going forward?
more that, most C++ developers aren't "C++ people", the ones that are are a very vocal, but very small minority, though they're disruptive enough that some projects (re: the aforementioned linux kernel) elect to abandon C++ entirely just to avoid them
> Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."
In my day job, I do a lot of AI coding but almost never have Claude actually create the PR titles or descriptions for me. It produces too much content, and the justification/background sections are often not quite right.
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.
Yeah I think this is a good approach. I’m pretty AI-optimistic when it comes to making code changes. But reading AI generated descriptions (including pull requests) is absolutely the worst. That content really needs to be human written. Not just for the benefit of the reader, but it also helps the writer exercise their understanding.
i want to figure out some extra practice - get a step of claude sending me a PR, then me accepting it after review, and then rewriting the merge to be a new PR for general review
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.
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?
> The Foundation says we can expect Godot's contributing policy to soon include explicit rejections of AI-authored code, noting that contributors should only use AI assistance for "menial things" and must disclose its use. Additionally, the Foundation will reject any AI-generated text in human-to-human communications, saying it's "a basic principle of respect"—though it says machine translations "are still acceptable" if the original text was human-authored.
As long as your bots aren't contributing low-effort garbage in a push to give their operator some of those tasty internet brownie points you should be fine
All these projects should seamlessly run a fork in parallel that accepts AI and has AI for review and approval. Both camps are happy.
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.
What's the point of this fork if it's just a landing spot for stuff that's not really wanted? Wouldn't that just be more condescending then telling people what's actually required for a contribution? Besides, the nature of forking is you can just do it yourself anyway. If people love their AI changes they can just make their own fork.
Plus I don't know how you could do this "seamlessly" -- someone has to manage merge conflicts, and as the codebases diverge it's just going to get more and more gnarly. (this is the reason most people don't maintain their own forks in the first place)
I mean, not sure if everyone wants that for their project, and there will surely be plenty of trade-offs.
But it would be a very good compromise: You (the maintainer) get only human-generated PRs in the canonical project, and they (pro-AI contributors) get a lower-threshold sandbox to play with. Best case scenario, you cherrypick the pre-filtered golden nuggets to bring back to the canonical project.
Yes - if I can tell that you used AI (except maybe because of an unnaturally high work rate, or obviously an AI declaration, which is good!), you fail. Keep up the quality and I don't care too much.
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"
My agents operate on their own branch for a feature, they commit code changes after each step or phase with a description of what was changed, why, and what’s left.
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.
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.
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.
Right but as they mentioned, at least then they are communicating with a human about it, not going back and forth with a machine which they clearly do not enjoy.
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.
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.
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.
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.
I think drugs are actually a great analogy. An initial feeling of "oh my god I have superhuman capabilities" followed by a hangover of "ohno I have created a mess". Especially with AI sycophancy where it's like "Great idea!" all the time. (I am well aware most my ideas are not great, thanks). Honestly, even the way people talk about like vibe coding on their phones while they're with their kids or something, it almost sounds like a compulsion.
> An initial feeling of "oh my god I have superhuman capabilities" followed by a hangover of "ohno I have created a mess".
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."
Yes. It is not true that anything that makes our lives better or work easier is bad. In fact that's the story of all progress - making peoples lives better and work easier.
> 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.
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.
They have much in common with slot machines, yes. It's no accident, many of the lessons from exploitative mobile games are being reused in LLM UIs. Rename "tokens" to "gems" and the situation looks very familiar.
The modern software development ethos is based around the idea that you don't know to what destination you're ultimately going.
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.
> 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.
Oh, it's not hard to reconcile at all.
On one side, you have people trying to sell you a product claiming that the product is the most amazing, indispensable thing ever.
On the other, you have the people dealing with the product's actual use evaluating it and finding it wanting.
The only reason this even looks hard to reconcile is because the people trying to sell you the product have been given more money than God (partly by people who think the product will become God).
Ignore the hype. Pay attention to the actual results.
the assumption that all code (and everything else producing digital artefacts) will be written using AI in the near future,
This is what AI providers wanted you to believe in because they have a couple of shovels to sell to you. Once you realize that the assumption is delusional, it's no longer hard to reconcile.
There's this crazy narrative that everyone starts parroting, saying the days of writing code yourself are over, now we have to use agents for everything.
No, we don't have to. We can just write code ourselves.
(My condolences to people who have jobs where AI is mandated.)
I'm in that boat - my current employer recently announced that they are tracking AI usage across the company and if you're not using enough AI you will be "replaced by someone who does".
> 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.
My suggestion would be that instead of sometime later, review incrementally as part of your process. Treat AI as just the tool for writing, just as if you handed it off to a junior. Replace "junior" with "AI" in the SDLC and keep everything else the same.
I don't think it's that hard to reconcile. The tools are being massively oversold and we are in a bubble. I think things will settle down to a reasonable middle ground in ~2 years as the checks being written right now start coming due and we are forced to figure out what they actually are and aren't good at. Infinite money distorts markets, it's currently not a good time to be judging these things for the long term perspective.
I have recently updated zed to the latest version which has parallel agents and all the other brainrot.
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
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.
> 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.
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).
>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.
I think the main functional reason is that because a human hasn't written the code, its potentially more likely to have subtle hidden bugs that a human cant explain because they didn't write it, as well as large pull requests that have to be validated by a human when smaller human written ones would be better. But I think it's generally the non-functional reasons that projects are rejecting LLM-generated code. Some developers just find LLM generated code icky, and would prefer not to be associated with it
And on top of that - no matter if you develop open-source or proprietary software, who is to guarantee the AI didn't get trained with GPL (or even worse, leaked proprietary) source code? Who is going to pay my lawyer when someone files a copyright lawsuit and all I have as an excuse is that I "AI-laundered" my code?
And some projects like WINE or ReactOS probably have to worry about that even more given they need to guarantee clean-room reverse engineering...
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
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.)
> 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".
We should keep some people around who can read paper maps (and keep paper maps around too). We need to keep doctors around who can keep working without a computer. It's a civilization threatening issue not to. There might be plenty reasons, from natural disasters, to self-inflicted "geopolitics", when we suddenly have to take a technological step back, and it's in our interest to maintain "30-50 years ago" level of tech possible, so that we don't have to start all over from something resembling a bronze age.
Definite agree on having human-based redundant systems.
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.
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
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.
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".
I agree, both in theory and that it's easier said than done, but I don't necessarily think that education is a primary reason, but merely a long term prerequisite of the project surviving.
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.
> 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.
AI-written code is far less likely to run than human-written code. Even worse, it often gives the appearance that it will be fine, only blowing up down the line. That is an extremely strong functional reason to reject AI code.
That depends on the model and the toolkit it uses. In my experience from using Claude Code (Max, Opus 4.5+) intensely for the past six months, I maybe had 3 instances where the implementation broke functionally. And all of these breaking changes were resolved by Claude.
Obviously, this won't apply to every context: I work primarily with well-known langs (e.g., Python, JS), small to medium codebases (<500k LoC, for sure), and relatively few co-developers.
> I can't think of a functional reason for a no-AI policy
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?
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.
Well, unless you needed those million copies for whatever reason, that is an example of spam or denial-of-service, regardless of how it's generated.
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.
There’s a reason most project don’t have a lot of unit tests. Because a specification, even when fully documented, doesn’t stay static enough to have time to write tests. And if it’s fluid enough, maintaining those tests will hamper velocity.
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.
> if it runs, it runs, regardless of who or what made it.
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.
"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.
Yeah the entire community telling devs for the last 15 years that open source contributions is how you get a job. Stupid statements get stupid incentives.
It’s not even a rarity / one-off thing. From my personal heuristics and anecdata, this happens with regularity, near semester end times.
Telltale marks: authors with university emails in github profile, often coming in pairs, with no prior interaction with the project, often trying to add features nobody wanted. Not even a CONTRIBUTING.md read-through, usually.
The first example is not just that it was AI-driven, but that he is young.
There was enough info in his repos to find his aliases and social media accounts. He is a preteen and simply doesn't yet have the foundational understanding needed to begin to grasp the problem or the social constructs involved.
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
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.
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.
I’m teasing a bit, yes your point is well made, you could just prompt around it. I think the bigger picture is there isn’t going to be some magical panacea that fixes this, we’ll just have to accept some sort of Swiss cheese model, like in the world of aviation safety. This “test” could be just be another layer in the stack.
"(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.
I think you first need to make an assumption of good faith on the submitter’s part. Yes, someone actively hostile to a repo and trying to sneak in changes will be successful, they can just prompt around the challenge.
I think the bigger picture is there won’t be one catch-all solution and we’ll need to embrace the Swiss cheese model from the world of aviation safety, this is just a suggestion for one layer.
It raises the stakes though. Getting challenged for an AI slop PR isn’t great, but ok, try and redeem yourself. Getting caught trying to cheat that challenge, you might as well just close down your account, like what is the point of even spending tokens to do this? These slop PRs are just people trying to pad their GitHub profiles.
I mean, yeah, you can give it style guidelines, but if someone's goal is "mislead people into thinking a person wrote this" then they should really be reevaluating their values.
One of the early selling points of LLMs was their ability to mimic styles. I haven't heard about that for a while though. Wouldn't that at least obscure the classic tells, if not eliminate them? I think the reason most (obvious) AI output is obvious is because people don't bother to hide it.
It's funny how identifiable AI text is. I usually know within like 10 seconds of watching a youtube video if the script is AI generated and it's a huge turnoff.
Plus the video generation, you basically know from the thumbnail. (Why do so many AI generated videos have a weird unnecessary film grain?!)
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.
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.
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)
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?
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.
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)
Yes, this was a huge problem even before AI. You had people spamming open source repos with 2 line "documentation cleanup" PRs that just capitalized some word or something. Totally pointless, but someone, somewhere is telling these people that it will help them get a job so they're all spamming. AI just let the spamming happen at scale.
Who the hell is looking at someone's "documentation cleanup" GitHub PRs and using them to boost their job application? I've served as an interviewer at every job I've worked and none of them tell you to even look at the candidate's GitHub, let alone allow its existence or nonexistence to influence your appraisal.
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.
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.
this is like ai use in arts to some degree, people don't want to write, they want to 'have written' and collect the social status that they think it confers. People don't want to code or make products better (or even understand the details) they want 'lines of code' or 'commit' or a pretty github green profile.
I wonder what people think about addressing this with process. For example, on GH:
- 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.
Generally creating a lot of friction around contributing to a project defeats the whole purpose of open sourcing it.
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.
> Generally creating a lot of friction around contributing to a project defeats the whole purpose of open sourcing it.
Is this friction? I think it's quality standards, and a flow that's relevant to a time when code is more of a commodity than before.
And contributing code isn't all that's valuable in OSS. Bug/UX reports and feature ideas are really valuable, more valuable now than code IMO.
Even before LLMs, I was much more likely to report an issue to an project if it was open source and I could go look at the code and confirm what's happening. Reporting a bug w/o this feels like wasting my time. Without source visibility, I'm usually inclined to just stop using the software (e.g. Microsoft products, or even "freeware"). With code viz, I can confidently report a bug with some sense of what the fix might entail, how long it might take, what my expectations for a fix might be.
A point of wild speculation. This is likely to be the slow decline of Godot.
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.
The people who hand write code for a game engine will beat the people who try to vibe code a game engine.
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'd put my estimates at 3x speed improvements. The amount of infra required upfront? 5x one time cost. These are estimates from Godot mobile app work. We have been trying out: no reviews under specific file sizes, except at design bottlenecks or large refactors. Number of PRs is probably up 3x with maybe 20% increase in regressions? Number of tests in our CI is up 500% (again, approximate), but this is absolutely required or we'd be awash in uncaught regressions with the velocity of code changes.
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.
Hearing about a Godot mobile app is hilarious to me. If there was ever a signal that Godot is not a serious tool to create releasable games, but rather a toy for beginners to mess around with, spending a bunch of resources on porting the engine to phones is it. Wowza
Seeing what y'all write in the child comments here, I think there is a massive misconception. Games made with Godot can be deployed to mobile fairly easily. The recent "breakthrough" about Godot working on Android was about making the Godot editor (which itself is made with Godot) fully work on Android in the sense that it can actually build project there which is more about getting build tooling to work on an Android device than actually running the Godot engine on Android. Totally different things. For quite some time you can quite easily deploy your Godot game to mobile, it's not a real problem.
I am struggling to understand the exact content of your message. I believe it's that Godot is unserious. Okay? Game engines serve a niche much smaller than broad consumer apps or SaaS platforms. Seems like a dunk I don't quite understand.
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.
I interpreted your comment "Godot mobile app work" to mean you worked on porting Godot itself to mobile, which I then checked and found that it did actually happen https://godotengine.org/article/gabe-stable-release/
If Godot for Android is unrelated to you then I misread. But I still find it hilarious conceptually, unrelated to you, that Godot is spending resources on porting itself to phones while it has so many serious outstanding issues. As though game devs are going to be coding on their phones in any meaningful way.
An important compilation target for Godot is mobile, since it's obviously a very large games market.
And, since the Godot IDE is, itself, an app written in Godot, porting to mobile is almost free. More a question of tweaking than rewriting. That's the same reason there's a version of Godot runnable in a browser... it's a consequence of Godot allowing webapps as build targets.
How does this square with the blog post I linked, that sounds like a lot of work, and its ending blurb, "It’s been a long road to bring full build support to the Godot editor on Android and XR devices, and we are excited to see what you build entirely on device!"?
A long road does not sound like something almost free
Thank you for clarifying! That totally changed my interpretation.
There is a surprising number of projects dedicated to making Godot work on mobile, and I am equally confused by that focus. I guess it's more possible with AI coding though, but couch game dev doesn't feel like a real thing.
By all accounts, with the current curve of model improvement, I don't see strong evidence that aligns with that belief. Perhaps with a plateau in model improvement or a saturation of the tech (a la iPhone 2020s), one could argue the lack of growth. But right now with evidence at hand? I wouldn't take that bet.
> To gain Godot's level of indie marketshare, a single breakout engine project that embraces vibecoding could be enough.
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.
That's basically the same argument Unity made a few years ago.
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.
A serious competitor wouldn't use Rust because it immediately disqualifies your engine from being shipped to consoles. At least at the moment. I know it's less of a technical limitation and more of a political one, but if you are serious about shipping your game to various platforms, you cannot use Rust. But things might be about to change, see https://akaganite.com
But honestly, as of today, you're probably having a better time taking a few days to work out clean C++23 guidelines for your AI agents by letting them churn through all the changes and deprecations that happened to C++ over the years, figure out good clang-tidy and clang-format rules, turn on all the compiler warnings and tell them to regularly use UBSAN, ASAN and TSAN and you're getting really close to a clean workflow similar to what Rust would give you but with the rich platform support of C++. It's just kinda sad that one has to go through so much ceremony while the Rust ecosystem gives you those things for free. But imo a well-crafted AI agent workflow gets really close here.
Mean edit: I was reading more of your comments in this post and I start to think you're a bit of bullshitter who's quite overconfident because you think AI makes you so much more productive. I say this because any seasoned game engine dev wouldn't have suggested Rust for a game engine that is supposed to compete with Godot, Unity, Unreal or whatever due to missing consoles support, but you just did, which makes me suspect that you have really shallow understanding and really, AI won't help here. You could have at least mentioned that if you only target dektop and mobile then Rust is a good choice, but you didn't. But don't get me wrong, I'm quite AI pilled as well, but I still know that some things require expert knowledge to properly steer the AI agents.
> the underlying infra isn't strong enough to ward off the many competitors that will embrace AI at the heart of the engine
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.
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).
>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.
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.
AI-assisted coding is good for creators. It happens to be good for corporations because it reduces costs, but it's actually much more powerful for creators with imagination. I don't know where that argument comes from.
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.
You can use AI assisted coding in Godot though with addons and an MCP server. That's completely separate from AI pr's in the engine itself.
Also, slight tangent but I'm just going to point out that the new MCP server in Unreal Engine 5.8 totally sucks, so it's not like other engines are that far ahead there. The very first task I gave it was to cache a couple of values in a map, and it couldn't do it because it couldn't figure out how to set the key type to FName (basic stuff). But honestly, I'm not surprised, the surface area of Unreal Engine is HUGE and trying to explain it all to a general purpose agent through tool calls is going to hit limits.
I have never found an MCP server that really crushed it. Totally agree. I think there's something required at a deeper level of integration to get AI coding working inside of engines. MCP is not it.
Yes, it's true, this is not a ban on AI coding with Godot. I didn't mean to conflate those, whoops. It stands to reason that there may be a small anti-AI perspective taking shape inside of the Godot engine team. This is one sign, but not confirmation of that suspicion.
>AI-assisted coding is good for creators. It happens to be good for corporations because it reduces costs, but it's actually much more powerful for creators with imagination. I don't know where that argument comes from.
>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.
We're talking about banning AI coding in the game engine itself, not game creators banning the use of AI to create actual games on top of the platform.
> adds to their brand as something for creators rather than corporations
I'm responding to the idea that banning AI contributions is on brand for being "for creators."
What about their action is creator friendly? Yes, they reject all low quality AI slop, which has some indirect positive benefit. They also won't accept high quality PRs unless they are hand crafted. How does that benefit creators? Most arguments it's "for creators" likely conflate the idea that AI-coding is inherently slop. If so, then we can say that directly instead of implicitly.
Funny enough, I see it the exact opposite. LLM slop code degrades software quality. While one person may appear to move quickly, the software quality suffers dramatically. It takes them (or other team members) more time to fix the issues than it would have to just do it right the first time.
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.
I don't know about large teams or companies. I feel more confident with the conjecture: Conditioned on small teams, a team of seniors with AI coding beats a team of junior with AI coding by a wide margin, in my experience.
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.
Integrating AI-assisted PRs into an existing team is a skillset all in itself.
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.
> Integrating AI-assisted PRs into an existing team is a skillset all in itself.
What exactly is this skillset? Why should AI created PR's be any different from other PRs?
To me this seems like a very sensible move.. they don't want to deal with bad code from uninvested contributors. I can't possibly see how that would harm them. If they want to use AI themselves, given their track record I trust they would do it tastefully.
Quite simply, volume. Detailed human review is a serious bottleneck on code merging. Skillset includes how to make sure you can get quality code at speed without 100% in-depth human review. I wouldn't recommend merges without human eyes, but there is a spectrum of depth in review.
but their stated reasoning is that they do open PRs to train up new contributors and eventually get them into the community where they'll be more trusted. That doesn't suggest a hardline stance against the tools to me necessarily at least.
On one hand, you could be right! I am making inferences on low data, judging the Godot team based on some of their _strong_ design choices. I would have a better argument if I spent the time tracking the Github issues that seemed quite wild that we encountered while building in Godot. Top of mind (low evidence, sorry) GDScript as a base scripting language (later reversed by C#), refusal to add async/await for GDScript, others that have escaped me.
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.
Any resources for getting better at that skillset (high-velocity but largely stable ai-enhanced coding, if I understand you correctly)? I’m always pretty skeptical of these claims but I wouldn’t mind being proven wrong
You have to consider the market for Godot: indie developers. They don't need cutting edge features; they need a good workflow, ease of use, a good community, stability, etc. Unity is actually really annoying in this regard, because they're _constantly_ deprecating features in favor of new features that are half baked and poorly documented. It feels like a really unstable platform to build on because by the time you're done with a project most of the things you built now need to be thrown away because the underlying engine changed so much, or you're halfway through a feature and you have to decide if you want to rewrite a huge chunk of code to support something new that came out. Unreal Engine is also going through this at the moment (although they're better about backwards compatibility). Hearing that they're dropping blueprints in favor of verse has a lot of people stuck in "uh, should I bother learning the current engine right now". I don't think it'll hurt UE in the long run, but I could easily see them losing some short term adoption. Stability in a platform is a very important feature!
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.
For many years, it's been difficult to build game engines. It's never been easier today. A half-decently funded startup team could get to Godot feature parity within 6-12 months. There's no VC in games anymore (especially not middleware), so it's less unlikely, but they don't have a moat on features.
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...
Oh god. If you really believe you can vibe code an engine in 6 months I challenge you to do it. I think you'll find you've wildly underestimated what goes into an engine.
Well, this is fundamentally where we end up disagreeing. Within the timeframe of a single mobile app development cycle, the entire coding infrastructure of the world changed. Our collective day-to-day coding experience has morphed within 15 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!
Even getting through the discussions and negotiations with the 3 big game console companies to support their platforms can eat up so much of your time window. You can't really vibecode your way out of that - though I suppose you could generate your email responses or an AI meeting participant and risk blowing up the business relationship.
As a professional developer that's using these tools professionally and worked on multiple game engines and even written a few of my own... nope. Sorry, just, that's so much hype not grounded in anything. I'm guessing your job is to promote this stuff based on that being your purpose of going to GDC?
Also, you're really misunderstanding why people use Godot in the first place. They've always been way behind Unreal Engine and Unity on flashy features, that's not their value proposition. A lot of churn on half baked slop features would be counter to why people want to use it. Developers in a stressful industry want tools they can trust, not buggy unstable things that are constantly changing out from under their feet (a lot of teams freeze their engine version per-project for this very reason).
Not grounded in anything? Really, anything? There's no evidence you've seen in the last three years that has had any impact on what you think is possible with AI coding?
I'm not a game dev by trade, I am AI researcher turned AI engineer (not the "AI engineer" of the modern era, like getting ML deployed in prod). That being said, I have tried and failed to make plenty of games over the years. Every mistake in the book. Making my own engine, trying to do 3D game as first approach, making mobile apps 2010, using Unity for personal projects, switching to Godot. I'm not at your level in game dev, but I've seen plenty at scale.
> I'm guessing your job is to promote this stuff based on that being your purpose of going to GDC
I'm not an AI hype maker, I'm a stunned observer. A person who has said "no way" AI will impact coding for the last 10 years. I am watching evidence in front of my very eyes and my workflow and simply adapting to the reality on the ground along with reasonable projection of capabilities into the future (based on velocity and reasonable assumptions). I don't need to convince you of anything, but I'm confident your beliefs won't hold up against the stockpile of evidence gathering now and in the near future.
Since you took a swing and miss on who I am, I'm going to guess that you are reluctant to incorporate these tools into your own workflow (perhaps having cast them off quickly after some frustrated probing) and have a deep-seated skepticism of the tech that doesn't really matter what I say.
Where's my inference coming from? The idea that you've conflated that AI coding by its very nature needs to be buggy and unstable. I wish you luck on holding the line as it slips past us on an exponential curve.
> Since you took a swing and miss on who I am, I'm going to guess that you are reluctant to incorporate these tools into your own workflow (perhaps having cast them off quickly after some frustrated probing) and have a deep-seated skepticism of the tech that doesn't really matter what I say.
I actually do use them (daily), and I do find them to be useful. I even bought a couple books about how to implement them, and my own current app has an MCP server I've built. I also find them to be overhyped and not particularly essential (if I had to choose one to take to a desert island, I would take a good IDE over a good AI, for example). The way I currently see them is they make things more convenient, but it doesn't really expand what's possible for me, and that convenience can come at a profound cost (some of which we're just now starting to see). I already enjoy coding, so the convenience of not having to code is not that big of a win for me, and when you factor in the extra factors I don't even think it makes me go that much faster. (I either have to correct its outputs, or spend extra time understanding them, or the codebases become unwieldy and I've DEFINITELY seen that. On average AI code seems to be about 2-3x more verbose than what I would write). I can see why someone that can't code (or doesn't want to) would find them to be amazing, but I also think those people are not in a great position to judge the outputs, which is still pretty necessary and probably will be for the foreseeable future.
I think a common thread with AI use is it seems amazing when you're asking it questions about fields you're not an expert in (I like to ask ChatGPT questions about biology for instance), but it seems very much not amazing when you ask it questions about fields you actually are an expert in.
> Where's my inference coming from? The idea that you've conflated that AI coding by its very nature needs to be buggy and unstable. I wish you luck on holding the line as it slips past us on an exponential curve.
See, but that's what bothers me about these conversations in general, people just go "look at number go up!" like you can take any trend and just keep growing it forever. Or people make really bold claims with no evidence like your "you can vibecode an engine in 6 months" claim. It's hard to even _learn_ all the features of a mature game engine like Unreal Engine over _multiple_ years, and to do so would require at least being partially fluent in multiple different very different domains (art, animation, level design, shaders, workflows, about a trillion 3rd party tools, etc.) How could you vibe code something that quickly when even experts probably know about 15-25% of the feature set? Like how can you prompt an AI to build features you don't even understand? Also these engines evolved over a long period of time, so there are so many micro decisions and customer feedback loops that are completely opaque but important and are embedded in the code. The code in many engines contains decades of important knowledge!
I'm not swayed by the "exponentials" argument because past results do not guarantee future performance. I'm basing my opinions on what I've seen in my job and my personal work, and what I've seen is they're a boost, but not to the degree being sold and I'm kind of sick of people telling me that I need to be on board with the hype train or get "left behind". AI is not that hard to prompt, I don't view that as a real skillset, so to me I can either continue to bet on my own skills and intellect and hope they still hold value, or I can just get out of the industry entirely because my role would be entirely pointless. I would rather bet on myself even if I'm wrong, because all becoming dependent on it is going to do is degrade my skillset and my intellect, and if I'm right, well, honestly it's not particularly hard to train up on current AI harnesses or whatever compared to learning a skill (my computer science degree took 4 years -- learning Claude took a day. In what universe is knowing how to use Claude a marketable skill?)
https://github.com/charlesrw1/MultiplayerFps, its pretty easy. And this is just my hobbyist engine Ive been solo orchestrating agents with. If you had a team of ~10 AI-enabled devs, you could easily reach feature parity with Unity in a month or 2.
I'm sorry for going off on a random hobby project, but doing this in a C++ project - even if it is a standard Visual Studio solution - is "putting your whole mouth into the salsa dip"-level rude IMO, agent access should not be a prerequisite to build code!
If you really believe this, I highly encourage you to do it! Unity makes a lot of money, spread that among just 10 people and you'll be doing quite well, especially for a month of two of time spent. And more importantly you'll have the bragging rights of telling an internet commentator they're wrong!
The weird thing though is I see comments like this all the time, and I've yet to see anyone come back a month later as a billionaire so.. I'm going to keep my skepticism for the moment.
As an aside, bragging about lines of code as the first thing in your repo is a very weird flex. Lines of code are a cost, not an achievement, you (or your AI) has to maintain them and the more you have the more it costs.
FWIW good on you for making a thing, my goal isn't to trash your project, but from my perspective this does not look like a serious competitor to any game engine; it reminds me of projects I've seen from college students before AI (I don't meant that as an insult, I just don't find this as compelling evidence for your argument)
You're missing that an AI ban is actually just a poor quality AI ban. No one can tell if you used AI in a quality way and write the description in quality English. All this ban does is filter out the worst slop that would never have worked. People can and will still submit quality PRs that used AI, but no one will know it used AI, because the author was conscientious.
I don't know, once you ban AI-assisted coding outright, it's much higher likelihood this ban will cause the Godot team to spend time and energy being AI detectives, especially if they don't agree with the intent of the contribution.
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?
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.
This makes sense in the short term, but we really need the industry as a whole to learn how to code with AI in a safe sustainable way. Open Source has a particular problem of taking a really long time to make changes, fix bugs, etc. A lot of design decisions are due to "we don't have time for this". AI can speed those things up and drastically increase the utility we can get out of open source. We just need to figure out how to do it without creating a mess.
It's a bad tool how? In that it doesn't automatically do everything perfectly from a 0-shot prompt?
We don't have to do anything. We could continue with the status quo and all the problems that entails. Or we could embrace progress and try to use technology to make our lives easier and better.
Simply choking them up is probably sufficient; if you limit how many commits and changes per commit can be made, limit how many PRs one can have open (or even just not closed) at a time, and limit the length of content in those PRs to a couple paragraphs, and autoclose everything that doesn't fit with a message putting the blame on AI garbage, the signal eventually gets big enough that they will start producing adequate content.
It's a really tricky one, but I think it's the right call for Godot, but probably not for other projects. I'm the current maintainer of GodotJS (TypeScript bindings for Godot). LLMs can generate genuinely useful solutions for Godot e.g. a functional WebGPU implementation for Godot — https://github.com/godotengine/godot-proposals/issues/6646.
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.
...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?
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.
That, not being sure if the submitter is willing to meet you part way, is exactly the miserable part I am talking about. Basically, you go in risking it's just a waste of your time. After some trust is established, or when the PR is from someone you already have some trust relationship, the dynamics are very different.
Yes, it can still be a slog to review someone else's code, but you usually have the feeling of "hey, this is probably something good".
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.
>why can't AI-assisted PR reviews make it less tedious?
Godot is a performance critical system in the realm of a million lines of code (?).
Keeping your system both correct AND performant, requires people understand how it works. This kind of technical knowledge is slow to develop, so it's one of the most valuable skills to possess.
I don't see how you continue to understand your system when people are both generating code with AI and using AI to review it's output.
I'm referring to any policy actually; it cuts both ways. I'd actually suggest a per-model policy - e.g. personally I'd have much less doubts accepting Fable/Mythos patches than Sonnet ones. this is obviously unworkable, impossible to validate and excludes mixed-model workflows, but in spirit the 'smart' models/model mixes should be treated differently than the dumb ones. another case is one-liner (approximately) fixes - I wouldn't even bother to self-report these as AI generated.
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.
Weird that AI is supposed to be able to enable all this and yet all we get is news about how it's really just burning out projects that have limited resources making them more expensive and companies having to hire back devs they laid off.
There is a saying in the services industry, one unhappy person will tell 10 people and it takes 10 happy people to tell one. The quantity of what you read online is not an actual representation. Best not to treat all Ai use and users as one group either.
> If it's really better, people will join the fork.
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
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.
I think "no-AI" policies are really just ways of gatekeeping low effort contributions from people who have no idea what they're doing. This is a good thing!
To use the current example of Godot--game engine development is really, really, __really__ hard. Building on your engine in a way that doesn't lead to performance regressions, introduce subtle bugs, etc. takes a lot of know how.
If you care about quality and performance, then rejecting work from people who aren't capable of understanding how their contributions impact the greater engine as a whole is a logical choice.
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.
I'm not sure I agree with the policy, but I'm glad we are seeing different project experimenting with different policies. So after a while we can probably see how things shake out in the end.
Definitely sympathetic to their policy, but AI tooling and quality are changing quite fast. In a year I'd expect a modification of this as AI agents get better in virtually every possible way.
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
These things are done not to block pr done with the help of ai, but to block the ai slops pr, aka those never reviewed, fully vibecoded, and with the submitter that didn't understand anything about the problem or the code, just trusted claude.
The rule is general on purpose to allow the maintainer to freely remove whatever is very evident is just ai slop
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.
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.
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?
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.
Don't compromise your professional integrity by lying about how you work. Rather find a job where you don't need to lie about your use of AI if you can.
25 years ago I had to lie about using free software since it was also frowned upon. I even lied to my CTO at the time who wanted me to work completely in a Microsoft environment, with ASP and what not. Being kinda stubborn I did not comply and used only free software. When boss saw the result and the cost I got promoted. My integrity is fine.
You should have been fired for cause, because the way you chose to work exposed your employer to substantial liability due to the “copyright laundering” nature of LLMs. But you prioritized feeling good over everything else. You’re a sociopath and you should be treated as one—a bad-faith actor only out for themselves, who cannot be trusted to collaborate within agreed-upon limits because you don’t think rules apply to you.
There are no agreed-upon limits, everything is new there. And I don't prioritize feeling good over everything else, otherwise I just wouldn't even start the debate. Far from being fired, I was promoted, because the real world is not your fantasy, results matter more than theorical threats. Also keep your name-calling to yourself.
You literally said as much, and I am not calling you names, I am accurately describing your behavior in a way you yourself appear to recognize:
> 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.
You specifically said you would lie about how you work to get accolades if your employer attempted to set rules against working the way you prefer.
The appropriate reaction to your employer setting rules you don’t agree with is to try to convince them to change those rules, engage in a labor action alongside your coworkers to force them to change those rules, or to leave.
I understand the struggle, but I feel like so many of these projects are going to ban AI contributions right before it starts getting undeniably better than humans.
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.
Then those 'competitors' can fork Godot and make their own AI version of it. Will they? No, no they wont. But they sure will complain about the rules while doing nothing about it.
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.
I get that, but again this seems like a quality problem. As for commitment a simple sorting algorithm which prioritizes repeat contributors should solve that.
Google Godot drama 2024, for some top-notch community mismanagement classes.
As far as I can remember. There was a pro LGBT tweet that some people didn't like. And the moderator decided to blanket ban everyone who disagreed with the tweet. Some of the banned people had reasonable objections like: regardless if they agree with something or not politics and OS should be separated, and were still banned, including on GitHub. Others had objections also shared with the Godot founder and were still banned. There were some other things also but can't remember the details.
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.
The drama is in a nutshell someone made a really stupid post claiming only the woke use game engines. Godot community manager said guess that makes us woke (paraphrased), conservatives went batshit, got blocked on Twitter or elsewhere for going insane and a few innocent tweets got caught in the crossfire. Someone went off and made a fork of Godot as a 'non-political version' which went in the only obvious direction it could go.
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.
The fork also had its own drama, resulting in one of the more active developers of the fork, plus the guy who helped kick off the original drama, splitting off to create yet another fork. Both forks are still active, I believe. It was all very silly
From what I recall, based on what a Godot developer wrote at the time, nobody got banned from GitHub for "a reasonable objection". The only people who got banned from GitHub were those who posted abuse there, after a few people had gotten blocked by the Godot Twitter account
The problem here is the definition of abuse. And I don't mean to say that I'm 100% sure Godot overstepped in the github ban cases, but if they can ban people for criticizing them I wouldn't be surprised if they overstepped there too.
Another problem, AI allows many people to 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.
A global labour crisis and broken reputation signaling in FOSS has produced a deluge of software production that has basically nothing to do with low quality submissions and everything to do with capitalism.
FOSS has become the release valve for too much labour supply.
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.
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"
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; [...]
> I guess that means no IDEs doing refactoring or automating common code. Not linters altering code, etc... right ? Because that's the same thing.
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)
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.
Because of lot of AI PRs come from first time contributors who just discovered the tools. Maybe their PR is amazing, maybe it is trash. You never know until you review it.
It's far more time-consuming to judge the quality of someone's past contributions than to have the LLM redo the contribution with quality you can control far more.
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).
They have consistently been proven right. The only thing failing has been the plateau claimers. If anything, it has improved much faster than the optimistic predictions.
Why are you directing the question at me? Obnoxious behavior, and your initial "gotcha" is just nonsense on a similar level as "why don't AI companies just clone all SaaS if the models are so good".
In many ways this makes sense. I noticed other projects
struggle with this as well. AI slop spam kills time
available.
On the other hand ... it is a bit strange though, because
what if code contributions objectively improve something?
I dislike AI slop spam, but from a purely objective point
of view, I am not sure it should be forbidden based on
it intrinsically making a change, which COULD be an
improve. Now I am also aware of the AI slop spam worsening
things; ton of documentation is useless, look at what matz
produces with claude, this seems to be written purely by
an alien, aka AI. I don't understand anything that this
AI generates. But I think from an objective point of view,
I'd actually lean more towards not completely disallowing
AI slop contribution. The issue seems largely with:
a) the quality
b) the amount of text generated
Both these problems, in my opinion, could be solved. The
time required by a real human to look at it, though, will
always be a bottleneck, so perhaps the more honest answer
would be that humans don't have enough time for
contributions from skynet.
> what if code contributions objectively improve something?
If the contribution is complex enough, it is no longer an 'objective improvement' but rather a judgement call, and in the process becomes copyrightable. This is where the trouble lies, and why this kind of AI involvement is banned.
If it is not, for example by being a one-line fix that literally cannot be performed differently, it's a different story. Then it can be merged, viewed either as a menial change (exempt by the ban) or by transfer of ownership (the reviewer becomes the effective author) because it is not copyrightable.
Are they gatekeeping to protect against AI "slop" or are they gatekeeping to protect an inefficient and non-scalable review process against velocity?
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.
In my experience success in a project isn't about the amount of code that can be produced, it's more about the thoughtfulness behind features and fixes. A lot of the work going into reviewing pull requests is understanding it in the context of the project's broader goals.
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.
Part of this is an argument for size limits on PRs.
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.
Doesn’t even have to be merged, it’s for the privilege of even being considered to be merged into a popular library, one can always fork but to put stuff in a popular repo should be pay-walled henceforth
I'm curious how they would know - can't someone just tell Claude not to use excessive comments and write code that matches the style and conventions of the codebase it's being used against?
Most LLM users wants to do less work, not more. Shaping LLM output to be human like is a lot of work, and that assumes you know what the human version looks like.
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.
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.
While I agree with the general message, and wish it will eventually radiate to cooperations as well, it is obviously a decision driven by feelings, not logic.
The idea that you can't trust code that was generated by heavy users of AI, because _they_ don't understand it enough to fix it, is false, because they can use AI to fix it.
In general, I have hard time understanding how one might even block other contributors from using ai.
Community management (which is an important part of PR/issue management for open source projects) should definitely take in account the human aspect, i.e. feelings.
It's a 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.
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
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.
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.
It's a fair policy. Getting those verbose, AI-authored walls of text is very annoying, especially when you're expected to thoroughly review it. It's like a denial-of-service attack on the human mind. I can only imagine how frustrating this can get in open projects that get a lot of contributions.
However, I don't think this will discourage AI-based coding at all. In fact, I see two potential outcomes of these policies:
- Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
- Positive: Submitters actually provide to-the-point, no-bullshit commits and comments - "here's the code, here's why I made that change, here are the effects of that change". Even if AI-generated, these small contributions may become much easier to verify & validate. We may even see some standardization in terms of what qualifies as an appropriately sized contribution, what requires more thorough review (e.g., adding unverified dependencies), etc.
I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
> - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
> Positive: Submitters actually provide to-the-point, no-bullshit commits and comments
That would be a dream.
> 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.
Dingdingding, we have a winner. The main use of such a policy is to be able to just close those giant wall-of-text PRs and have something to point to when people start to scream it's not fair.
> when people start to scream it's not fair
Or LLMs, as we have seen.
Or, who knows, the "AI" might gain sufficient intelligence to read the policy...
Then we'll amend the policy to instruct LLMs to author PRs as Fred Flintstone, yabba dabba doo!
Why is a policy necessary. you were never entitled to have your pr merged in the first place? If pr wasn't reviewable pre AI I'd expect it to be closed or ignored too
The policy isn't necessary to close the PR. The policy just helps to shut down the ensuing discussion after closing the PR. It helps in quickly dealing with well-meaning onlookers asking for clarification when you block PRs from the account.
Still, your not even entitled to a discussion though.
Before AI a large pull request was enough effort to make that you could assume good faith work on the part of everyone. Likely even if it is bad for architectural reasons it is solving an itch other users have and it is reasonable for them to want an explanation why you refused someone who made this much effort. And since the effort required meant it didn't happen often it wasn't a big deal to provide that.
These days large PRs are easy to create and so humans need to shut them down.
Whether or not someone is entitled to something has very little bearing on whether someone believes they are entitled to something (and are willing to waste everyone's time to make a stink about it). Having clear rules to point to, even after the fact, is surprisingly effective in mitigating that.
Or, put more bluntly, your belief in what people ought to feel entitled to has no bearing on what they do believe, and policy needs to address the latter, not the former.
Prior to AI making a PR involved considerable effort from a human. So the default position for many open source projects was that it deserved some level of attention for the effort. Even if many projects in practice would struggle to review every PR. But with AI tools this dynamic has shifted dramatically - many PRs have basically zero effort been put into it. Additionally there are many more of them, and often way bigger also.
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.
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.
Reading AI PRs reminds me of Monty Python's holy grenade:
"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.'
I wouldn't mind reading that and having a good chuckle while processing an MR, as long as the comment had been crafted by a person. But now I think writing in grunts is gonna become the thing. "pete? you good boy? we won't hire you/ paper you gave HR girl with older gigs? remember it pete my boy? too many words/ words were too long/ dots you used dots/ you scratched long dash with knife, but baby saw scratch/we don't ai pete/ask if they have job in next cave/good luck."
I have spent many years reviewing and editing design and product documentation from more Jr engineers and product managers.
It was a constant struggle to get them to be concise, one I mostly lost.
> If people knew how to get AI to write terse, focused summaries...
... then flooded maintainers would be doing it.
I've found that the instructions "be extremely concise" gets me much closer to output that's actually sensible/helpful rather than another wall of text.
> 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.
> allows the reviewer to reject it on the "AI" grounds
… but still unfortunately leaves reviewers having to spend time checking submissions and rejecting them.
At least half the people firing off LLM generated PRs will have left the "Coauthored-by: Claude" line on it allowing automated rejections.
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.
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.
A contributor in good faith is going to accept criticism and resubmit an improved change: less files modified, more explanation, more focus, references to actual tickets and discussion with actual developers.
They could allow AI PRs, but then have another AI PR reviewer reject them if they do not match the definitions for `to-the-point` `no-bullshit` commits.
Please provide 3 examples where layering on MORE of the offending technology has solved the problem. Spam? Malware & Viruses? Customer Service? Hiring & Recruitment?
And who pays for the (likely significant, and controllable by everyone) tokens such a system would use?
A small 4-9B model would be able to run cheaply for this sort of work.
What question do you think you're answering?
The Godot Foundation pays for it if it furthers their mission.
Does it?
> That would be a dream.
We just recently started that policy so we'll see how it goes. If anything, having it stated as policy lets us filter out these requests without spending brain tokens on them.
I've always instructed Claude to check the policies first, frankly I'm surprised it's not smart enough to do that already. Would be easy to add to a system prompt. But usually it doesn't matter because many projects have no policies, or maybe they exist but only in hidden forum posts issues or something.
> That would be a dream.
“Mission. Fucking. Accomplished.”
https://xkcd.com/810/
> 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.
> The problem is that a lot of AI contributions are lazily produced without review.
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 should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". So it can be both satisfying and worthwhile to spend your effort on cleaning it up, even if it starts to take as much or even more effort than doing it yourself would have.
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.
> You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community".
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.
The Godot maintainers have decided they don't support that perspective. In their words, they value "being cautious about feature creep" and "dedicated to high code quality"; they don't accept that all working code should be merged.
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.
> they don't accept that all working code should be merged.
That’s perfectly within their rights to do!
> Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork.
Too many of those do fragment the development effort and hurt any project.
Here’s hoping that Godot doesn’t struggle too much with people who don’t care about their rules and spam PRs regardless and that the people who want to commit AI code regardless because it works and is good in their eyes at least demonstrate enough initiative to cheat convincingly (maybe actually read the code and make it their own). Godot is a pretty cool project!
Wonder what the middle ground would look like - a project with super high test coverage and tooling, that also requires at least 20 USD in Opus tokens spent on review on the behalf of the author or something, before an actual human being is bothered with it? Heh.
> A pull request is a social artifact whose value and meaning is dependent on its author;
Says who? How can you say I'm categorically wrong when your entire point rests upon an opinion?
Says the definition? I don't really understand your response. A pull request is a request from Alice (the author) that one of Barbara, Chris, Daniel (the maintainers) should pull her code into a particular branch.
Many communities do have a norm that all authors are to be presumed equal, as long as they're prepared to take advice and learn from it. (That's where all experts start, after all.) That's the norm that Godot are trying to protect here. If they don't stop accepting AI-authored contributions, they worry, reviewers will start to implicitly load-shed by not reading PRs from people they don't recognize.
A social contract? You invented that out of thin air. They're a means to an end not some discussion on philosophy.
So you can run your project that way.
You don't get to dictate that other people run their projects that way.
> A pull request is a social artifact whose value and meaning is dependent on its author
...and the project to which it is submitted.
SpicyLemonZest is not the sole arbiter of what PRs mean and stand for.
I was explaining why the Godot maintainers have chosen to enact the policy described in the source article, in response to a comment saying that they should not have enacted it. I don't understand why you think I'm dictating or arbitrating anything.
A tool that encourages bad behavior at scale is a bad tool. Blaming individuals for a collective problem leads to no improvements.
It’s just a social thing. Two identically bad submissions have different social contexts.
Probably because a human authored contribution, no matter how bad, can be trained to make it good and also improves the community.
> can be trained to make it good and also improves the community.
AI can be trained. Also, AI can create code that improves the community. It's replies like this that leave me even more confused.
Human being trained is already proven (that’s how most maintainers came to be). Can you explain how AI can be trained in the above context?
lol Human beings are famously not already trained.
> AI can be trained.
I don't have access to a data center's worth of GPUs, unfortunately. You offering yours?
So when you said "AI cant be trained" you didn't mean "AI cant be trained" you meant that you personally can't? lol.
I'm saying that most people, even most programmers, don't have the facilities or inclination to train new models man. I've done it plenty of times and I absolutely don't recommend it.
Frankly I don't think you even know what the phrase entails.
So again, you can train people but not AI? That's literally what you've said and now moving the goal posts in a way that makes no difference to what you said being patently wrong.
It's wild having to argue with people who say demonstrably untrue things and then refuse to admit that what they said was wrong.
Yeah, real wild.
> > The problem is that a lot of AI contributions are lazily produced without review.
That sounds like a contributor problem. Not an AI problem.
Ish. The tool is not doing the job fully, the contributor is not doing their task properly, checking for that, and fixing the issues.
> 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.
Think of it like offering a job, and getting 100s of CVs. You don't have time to review each in detail, so you weed out a chunk of them using superficial cues that have been indicators of issues in the past. They are filtering the other contributions too, the no AI rule is just part initial triage to save a lot of time.
You have missed a key point in what I wrote: "Those that have been properly reviewed for correctness [before being submitted] will be indiscernible from human-only contributions". It is like a Turing test: if you take the effort to make your AI aided contributions good enough to be indiscernible from good human-only contributions then the no-AI filter won't bother you because the people or automations enforcing it won't be able to discern that your contribution was assisted.
> where good code can't be submitted unless the submitter lies.
No. Unless it looks like a good contribution looks.
The problem a lot of projects are facing right now is being inundated by bad PRs from people using AI without the effort to, or likely the knowledge of how to, properly understand and explain & document the change. People have a limited amount of time and if the filter saves a lot of time then maybe losing one or two good contributions due to the filter is worth it - better that than the project stalling under the weight of managing all the PRs.
This is one of the reasons, even pre-AI, some projects declared themselves "open source but not open contribution".
Saying you didn't use AI when you did, regardless of the end product, is lying. What definition of the word lie wouldn't cover that?
If they are simply filtering out based on signs of AI, then there is no lie.
If they are explicitly asking “was AI used” then yes, there is a direct lie involved.
If there is no explicit question but you are including “lies by omission”, then be aware that there are many things people choose not to say that they would be unfairly judged for if they did state (gender details, certain parts of their history, etc) so that might not be a line we want to draw.
I'm not exactly pro-AI, in fact I'm avoiding it in DayJob to the point where I expect at some point I'll be given the choice “get with the program or leave” (I plan to leave at that point, preferably by my own choice though we'll see how heated the discussion gets!), but if there is a at least one human at the end of the process that is properly testing and cleaning everything up so there can be nothing problematic in the AI output that survives, is that really practically any different to a fully human created contribution?
The problem with AI contributions in the vast majority of cases is the lazy ones, especially considering the sheer number of them. Using signs of AI as a code/documentation smell when it comes to filtering contributions is fine, especially if you have up-front requested no such contributions be sent. Permanently blocking people who have sent obviously AI-generated contributions previously despite you asking them not to, is also fine just as blocking people who have sent in entirely human made contributions that break your other requests/rules is. But banning all AI use when if you can't tell if a good contribution did or didn't use AI aid somewhere in the process, is both a daft extreme and actually impossible (if you can't tell, how do you tell?!).
> 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.
There's no chance that anyone saw that far ahead in the future and planned it. It's emergent behaviour.
Who says anything about „this far in the future“? It’s enough for Anthropic et al to realize this one or two model versions ago, see it as a strategic advantage and push for that behavior.
Literally some of the first advertised uses for LLMs were both "You can feed it bullet points and it will compose an entire email" and "You can take long emails and condense them into bullet points!" They've been doing this since day 1.
Big tech: "Should we add any functionality at all to filter AI slop in any of our platforms?" "...nah"
Its not 500 moves ahead.
While it certainly didn't enter a mind of any director making decisions (because they can't comprehend not defecting in a prisoner's dilemma, being sociopaths), it was plainly obvious to every person even remotely connected to IT in the past two decades. If one makes a better and faster spam generator and the same unchanged program also works in reverse, by sifting through spam and condensing it to a readable summary, that it will be immediately co-opted in a spam arms race by all sides of the war and become essentially mandatory.
AI also works better with concise, focused, high information density text. So AI-spam text hurts both humans and AIs, but humans more so than AIs. It is always a negative, except for the "competition" between (human with) AI and human without AI.
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
Seems like this policy would apply pretty well regardless of who/what generated the code.
YES! "No AI" policies that are purely based on technical grounds make no sense to me. Bad PR's are bad PR's regardless of their source.
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.
It's really a question of how much time you're willing to spend sorting through spam. "No AI" might be a blunt hammer, but the people submitting slop aren't reading guidelines anyway, and it's easier just to reject it early. Frankly, I'm sure if people wanted to sneak in an AI generated code by carefully reviewing it and making sure it's targeted and well tested... I'm sure they could, but those people aren't the problem.
> Frankly, I'm sure if people wanted to sneak in an AI generated code by carefully reviewing it and making sure it's targeted and well tested
But this is exactly the point I'm making. If the code is carefully reviewed, targeted, and tested, then why make people have to lie in order to submit PRs?
Why not just say "Irresponsible use or agentic-based PR's will be auto-rejected"?
And that's not even mentioning that tools like Github Copilot can just act like fancy autocomplete. There are dozens (if not hundreds) of different ways to use these tools.
I guess I'm just really not sure how you can unequivocally forbid these insanely powerful tools when they are almost certainly going to be a large part of developer's workflows going forward?
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.
> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
It's pragmatic. Linus once said, the reason C++ is not allowed in the kernel is to keep the C++ people out.
Joke's on him, many Rust people are current or former C++ people.
just because someone writes or wrote C++ doesn't make them a "C++ person", and "C++ people" are very much against rust
Only true Scots... err C++ people are against Rust, I see :>
more that, most C++ developers aren't "C++ people", the ones that are are a very vocal, but very small minority, though they're disruptive enough that some projects (re: the aforementioned linux kernel) elect to abandon C++ entirely just to avoid them
> Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."
https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-a...
In my day job, I do a lot of AI coding but almost never have Claude actually create the PR titles or descriptions for me. It produces too much content, and the justification/background sections are often not quite right.
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.
I think OSS maintainers are in the middle of intersecting trends:
- 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”
Yeah I think this is a good approach. I’m pretty AI-optimistic when it comes to making code changes. But reading AI generated descriptions (including pull requests) is absolutely the worst. That content really needs to be human written. Not just for the benefit of the reader, but it also helps the writer exercise their understanding.
i want to figure out some extra practice - get a step of claude sending me a PR, then me accepting it after review, and then rewriting the merge to be a new PR for general review
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.
How strict is this no AI policy?
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?
from TFA:
> The Foundation says we can expect Godot's contributing policy to soon include explicit rejections of AI-authored code, noting that contributors should only use AI assistance for "menial things" and must disclose its use. Additionally, the Foundation will reject any AI-generated text in human-to-human communications, saying it's "a basic principle of respect"—though it says machine translations "are still acceptable" if the original text was human-authored.
As long as your bots aren't contributing low-effort garbage in a push to give their operator some of those tasty internet brownie points you should be fine
All these projects should seamlessly run a fork in parallel that accepts AI and has AI for review and approval. Both camps are happy.
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.
What's the point of this fork if it's just a landing spot for stuff that's not really wanted? Wouldn't that just be more condescending then telling people what's actually required for a contribution? Besides, the nature of forking is you can just do it yourself anyway. If people love their AI changes they can just make their own fork.
Plus I don't know how you could do this "seamlessly" -- someone has to manage merge conflicts, and as the codebases diverge it's just going to get more and more gnarly. (this is the reason most people don't maintain their own forks in the first place)
>you can just do it yourself anyway.
But not with official branding.
> manage merge conflicts, and as the codebases diverge
not if you dont care if the sandbox diverges, and you just let the slop be slop.
Do you volunteer to maintain the sloppy fork?
I think most pro-AI people would be happy to let an AI maintain the sloppy fork. What reason would they have to complain, after all?
This is actually a good idea.
I mean, not sure if everyone wants that for their project, and there will surely be plenty of trade-offs.
But it would be a very good compromise: You (the maintainer) get only human-generated PRs in the canonical project, and they (pro-AI contributors) get a lower-threshold sandbox to play with. Best case scenario, you cherrypick the pre-filtered golden nuggets to bring back to the canonical project.
Precisely. Cherrypick nuggets from poo. It's there if you care to wade into it. May occasionally strike gold.
Yes - if I can tell that you used AI (except maybe because of an unnaturally high work rate, or obviously an AI declaration, which is good!), you fail. Keep up the quality and I don't care too much.
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"
> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
Perhaps reconsider "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer..."
I recently wrote a tool to help me read AI generated PRs and it’s pretty sad that it’s got to this point.
My agents operate on their own branch for a feature, they commit code changes after each step or phase with a description of what was changed, why, and what’s left.
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.
DoS attack is exactly what I describe an AI generated PR!!
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.
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
Which goes to show that despite all of the rationalization both here and in the comments of that PR, the push to ban AI is religious not reasoned.
> Submitters just add stylistic markers to make their accounts and output seem human-generated
https://xkcd.com/810/
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.
No different than a human written PR
Right but as they mentioned, at least then they are communicating with a human about it, not going back and forth with a machine which they clearly do not enjoy.
[flagged]
[flagged]
If you understood the change, writing a short description of the problem and the fix yourself would be trivial.
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? :)
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.
Why do I argue here anyway? :)
Before sending it I have tried the patch locally. It worked.
So I sent the proposal. And it was accepted by the author.
Efficiency rarely is the key.
> Efficiency is the key.
... and includes the reviewer efficiency disrespected by your verbose bot.
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.
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.
Exactly. People rediscover that gatekeeping and barriers-to-entry had positive aspects to them.
I think drugs are actually a great analogy. An initial feeling of "oh my god I have superhuman capabilities" followed by a hangover of "ohno I have created a mess". Especially with AI sycophancy where it's like "Great idea!" all the time. (I am well aware most my ideas are not great, thanks). Honestly, even the way people talk about like vibe coding on their phones while they're with their kids or something, it almost sounds like a compulsion.
> An initial feeling of "oh my god I have superhuman capabilities" followed by a hangover of "ohno I have created a mess".
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."
Yes. It is not true that anything that makes our lives better or work easier is bad. In fact that's the story of all progress - making peoples lives better and work easier.
What about "what goes up, must come down"?
...unless it goes hyperbolic.
Maybe we just need stronger drugs!
> 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.
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.
They have much in common with slot machines, yes. It's no accident, many of the lessons from exploitative mobile games are being reused in LLM UIs. Rename "tokens" to "gems" and the situation looks very familiar.
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.
> 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.
The modern software development ethos is based around the idea that you don't know to what destination you're ultimately going.
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.
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
> 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.
Oh, it's not hard to reconcile at all.
On one side, you have people trying to sell you a product claiming that the product is the most amazing, indispensable thing ever.
On the other, you have the people dealing with the product's actual use evaluating it and finding it wanting.
The only reason this even looks hard to reconcile is because the people trying to sell you the product have been given more money than God (partly by people who think the product will become God).
Ignore the hype. Pay attention to the actual results.
There's this crazy narrative that everyone starts parroting, saying the days of writing code yourself are over, now we have to use agents for everything.
No, we don't have to. We can just write code ourselves.
(My condolences to people who have jobs where AI is mandated.)
I'm in that boat - my current employer recently announced that they are tracking AI usage across the company and if you're not using enough AI you will be "replaced by someone who does".
Your employee is very late on this one. Other companies have tried that and have already been burned by people tokenmaxxing.
This seems like an awesome opportunity to sneak in some work on side projects to keep your token counts looking good.
It's only crazy if your goal isn't maximizing token purchases.
> 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.
My suggestion would be that instead of sometime later, review incrementally as part of your process. Treat AI as just the tool for writing, just as if you handed it off to a junior. Replace "junior" with "AI" in the SDLC and keep everything else the same.
> almost all popular open source projects fight to keep AI contributions out
Godot, Zig, who else? Most major OSS projects I know are openly welcoming high quality AI contributions, not fighting to keep them out.
Yes. Godot and Zig are the exceptions, and therefore newsworthy.
I don't think it's that hard to reconcile. The tools are being massively oversold and we are in a bubble. I think things will settle down to a reasonable middle ground in ~2 years as the checks being written right now start coming due and we are forced to figure out what they actually are and aren't good at. Infinite money distorts markets, it's currently not a good time to be judging these things for the long term perspective.
I have recently updated zed to the latest version which has parallel agents and all the other brainrot.
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
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
I made a filter that shows github repos posted to hacker news that do not have evidence of AI authorship:
https://hcker.news/?ai=exclude&include_domains=github.com
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.
> 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.
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).
>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.
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
I think the main functional reason is that because a human hasn't written the code, its potentially more likely to have subtle hidden bugs that a human cant explain because they didn't write it, as well as large pull requests that have to be validated by a human when smaller human written ones would be better. But I think it's generally the non-functional reasons that projects are rejecting LLM-generated code. Some developers just find LLM generated code icky, and would prefer not to be associated with it
And on top of that - no matter if you develop open-source or proprietary software, who is to guarantee the AI didn't get trained with GPL (or even worse, leaked proprietary) source code? Who is going to pay my lawyer when someone files a copyright lawsuit and all I have as an excuse is that I "AI-laundered" my code?
And some projects like WINE or ReactOS probably have to worry about that even more given they need to guarantee clean-room reverse engineering...
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
I'm not disagreeing with you, but it's worth noting there were plenty of GPL violations before LLMs existed.
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.
From godot's pov though, banning AI won't guarantee some arbitrary contributor's PR doesn't include GPL code.
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.)
There is a "why" a the end of the list
https://codeberg.org/brib/slopfree-software-index#why-care-a...
> 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".
We should keep some people around who can read paper maps (and keep paper maps around too). We need to keep doctors around who can keep working without a computer. It's a civilization threatening issue not to. There might be plenty reasons, from natural disasters, to self-inflicted "geopolitics", when we suddenly have to take a technological step back, and it's in our interest to maintain "30-50 years ago" level of tech possible, so that we don't have to start all over from something resembling a bronze age.
Definite agree on having human-based redundant systems.
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.
The people under GNSS jamming in war zones might disagree with you about the value of being able to read a map.
(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.)
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
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.
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".
I agree, both in theory and that it's easier said than done, but I don't necessarily think that education is a primary reason, but merely a long term prerequisite of the project surviving.
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.
> 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.
AI-written code is far less likely to run than human-written code. Even worse, it often gives the appearance that it will be fine, only blowing up down the line. That is an extremely strong functional reason to reject AI code.
That depends on the model and the toolkit it uses. In my experience from using Claude Code (Max, Opus 4.5+) intensely for the past six months, I maybe had 3 instances where the implementation broke functionally. And all of these breaking changes were resolved by Claude.
Obviously, this won't apply to every context: I work primarily with well-known langs (e.g., Python, JS), small to medium codebases (<500k LoC, for sure), and relatively few co-developers.
Same reasoning that folks apply against AI written blog posts.
> I can't think of a functional reason for a no-AI policy
Imagine morals.
That would be part of the non-functional reasons mentioned in the next paragraph.
> I can't
That makes much more sense now. The inability is completely on you, and you admit it at least.
You can’t understand the difference between functional and non-functional.
> I can't think of a functional reason for a no-AI policy
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?
Maybe then it should be a no Oligarchs policy, and include code written by capitalist shills as well to be internally consistent.
> Interesting initiative. What are the guiding reasons behind these lists?
> I can't think of a functional reason for a no-AI policy
These lists don't have you as an audience.
Please define "if it runs, it runs"?
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.
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?
Well, unless you needed those million copies for whatever reason, that is an example of spam or denial-of-service, regardless of how it's generated.
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.
There’s a reason most project don’t have a lot of unit tests. Because a specification, even when fully documented, doesn’t stay static enough to have time to write tests. And if it’s fluid enough, maintaining those tests will hamper velocity.
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.
"If it runs, it runs," is an very naive and irresponsible view of code.
> if it runs, it runs, regardless of who or what made it.
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.
So you didn’t read the article?
"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!
zig's 'contributor poker' is sounding more and more prescient.
looked it up: https://simonwillison.net/2026/Apr/30/zig-anti-ai/
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.
For people that don't get it just check this: https://github.com/godotengine/godot/pull/115280 https://github.com/godotengine/godot/pull/116410
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 contribution is part of a university course project where we are required to make a real open-source contribution
This university is very stupid university. Is there anyway to know which university is forcing these kids to spam open source project?
Yeah the entire community telling devs for the last 15 years that open source contributions is how you get a job. Stupid statements get stupid incentives.
It’s not even a rarity / one-off thing. From my personal heuristics and anecdata, this happens with regularity, near semester end times.
Telltale marks: authors with university emails in github profile, often coming in pairs, with no prior interaction with the project, often trying to add features nobody wanted. Not even a CONTRIBUTING.md read-through, usually.
The first example is not just that it was AI-driven, but that he is young.
There was enough info in his repos to find his aliases and social media accounts. He is a preteen and simply doesn't yet have the foundational understanding needed to begin to grasp the problem or the social constructs involved.
[dead]
That is crazy. What is the actual motivation of that contributor?
The first one was for a $4k bounty. The second one was for a university assignment.
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
The foundation points out something that has always been true, but AI has really brought to the forefront, that any contributor, including AI, could potentially not be relied on to maintain this patch in the future.
This is the core of the issue, not that someone uses AI, but that it’s just one of many smells a patch can have that indicates someone doesn’t understand what they’re submitting. You could be breaking variable naming conventions, changing APIs you shouldn’t, making amateur language mistakes, all indicate that yes, maybe the patch does work, but that there are other good reasons to reject it.
A way around this might be to mark a PR as rejected because of AI and then ask the author to point out some part of it they’re particularly proud of and explain in their own words, not a wall of AI text, what this does and why they like it. Just something where the author has to show that they have something an AI can’t, namely taste and an opinion.
AI is well-capable of fabricating text that looks like an opinion in 2026. This would not help differentiate AI from human authors.
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)
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.
I’m teasing a bit, yes your point is well made, you could just prompt around it. I think the bigger picture is there isn’t going to be some magical panacea that fixes this, we’ll just have to accept some sort of Swiss cheese model, like in the world of aviation safety. This “test” could be just be another layer in the stack.
"(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.
I think you first need to make an assumption of good faith on the submitter’s part. Yes, someone actively hostile to a repo and trying to sneak in changes will be successful, they can just prompt around the challenge.
I think the bigger picture is there won’t be one catch-all solution and we’ll need to embrace the Swiss cheese model from the world of aviation safety, this is just a suggestion for one layer.
It raises the stakes though. Getting challenged for an AI slop PR isn’t great, but ok, try and redeem yourself. Getting caught trying to cheat that challenge, you might as well just close down your account, like what is the point of even spending tokens to do this? These slop PRs are just people trying to pad their GitHub profiles.
I mean, yeah, you can give it style guidelines, but if someone's goal is "mislead people into thinking a person wrote this" then they should really be reevaluating their values.
One of the early selling points of LLMs was their ability to mimic styles. I haven't heard about that for a while though. Wouldn't that at least obscure the classic tells, if not eliminate them? I think the reason most (obvious) AI output is obvious is because people don't bother to hide it.
It's funny how identifiable AI text is. I usually know within like 10 seconds of watching a youtube video if the script is AI generated and it's a huge turnoff.
Plus the video generation, you basically know from the thumbnail. (Why do so many AI generated videos have a weird unnecessary film grain?!)
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.
AI slop PR's aren't really generated by people willing to do even this much effort.
True, but the avenue is always open and the AI code is still present.
That I think is also an important issue if a project wants to keep AI out of its code.
Brandolini's law in action.
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.
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)
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?
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.
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)
Yes, this was a huge problem even before AI. You had people spamming open source repos with 2 line "documentation cleanup" PRs that just capitalized some word or something. Totally pointless, but someone, somewhere is telling these people that it will help them get a job so they're all spamming. AI just let the spamming happen at scale.
Who the hell is looking at someone's "documentation cleanup" GitHub PRs and using them to boost their job application? I've served as an interviewer at every job I've worked and none of them tell you to even look at the candidate's GitHub, let alone allow its existence or nonexistence to influence your appraisal.
They could just fork and have AI contribute to it as a form to pad their CV.
They can even list on their CV that they are the maintainers of those projects.
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.
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.
Well, I tried to contribute using AI. Brew and far2 accepted my work, KDE spectacle maintainers did not answer.
Both PR were tiny, not different from human PR. I still believe these were valuable additions, and obviously some maintainers think the same.
this is like ai use in arts to some degree, people don't want to write, they want to 'have written' and collect the social status that they think it confers. People don't want to code or make products better (or even understand the details) they want 'lines of code' or 'commit' or a pretty github green profile.
Actual source: https://godotengine.org/article/contribution-policy-2026/
I wonder what people think about addressing this with process. For example, on GH:
- 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.
Generally creating a lot of friction around contributing to a project defeats the whole purpose of open sourcing it.
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.
> Generally creating a lot of friction around contributing to a project defeats the whole purpose of open sourcing it.
Is this friction? I think it's quality standards, and a flow that's relevant to a time when code is more of a commodity than before.
And contributing code isn't all that's valuable in OSS. Bug/UX reports and feature ideas are really valuable, more valuable now than code IMO.
Even before LLMs, I was much more likely to report an issue to an project if it was open source and I could go look at the code and confirm what's happening. Reporting a bug w/o this feels like wasting my time. Without source visibility, I'm usually inclined to just stop using the software (e.g. Microsoft products, or even "freeware"). With code viz, I can confidently report a bug with some sense of what the fix might entail, how long it might take, what my expectations for a fix might be.
[dead]
Perhaps move comments to source posted yesterday? 30-jun-2026 "Changes to Our Contribution Policies" https://news.ycombinator.com/item?id=48733236 9 comments
Godot's new contribution policy: https://godotengine.org/article/contribution-policy-2026/
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
A point of wild speculation. This is likely to be the slow decline of Godot.
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.
This is exactly what will make Godot shine in 2 years while the rest of the world will be busy cleaning up inefficient code.
The people who hand write code for a game engine will beat the people who try to vibe code a game engine.
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.
> But they'll both be beaten by people using AI intelligently to generate code, but not letting it drive everything.
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)
I'd put my estimates at 3x speed improvements. The amount of infra required upfront? 5x one time cost. These are estimates from Godot mobile app work. We have been trying out: no reviews under specific file sizes, except at design bottlenecks or large refactors. Number of PRs is probably up 3x with maybe 20% increase in regressions? Number of tests in our CI is up 500% (again, approximate), but this is absolutely required or we'd be awash in uncaught regressions with the velocity of code changes.
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.
Hearing about a Godot mobile app is hilarious to me. If there was ever a signal that Godot is not a serious tool to create releasable games, but rather a toy for beginners to mess around with, spending a bunch of resources on porting the engine to phones is it. Wowza
Seeing what y'all write in the child comments here, I think there is a massive misconception. Games made with Godot can be deployed to mobile fairly easily. The recent "breakthrough" about Godot working on Android was about making the Godot editor (which itself is made with Godot) fully work on Android in the sense that it can actually build project there which is more about getting build tooling to work on an Android device than actually running the Godot engine on Android. Totally different things. For quite some time you can quite easily deploy your Godot game to mobile, it's not a real problem.
I am struggling to understand the exact content of your message. I believe it's that Godot is unserious. Okay? Game engines serve a niche much smaller than broad consumer apps or SaaS platforms. Seems like a dunk I don't quite understand.
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.
I interpreted your comment "Godot mobile app work" to mean you worked on porting Godot itself to mobile, which I then checked and found that it did actually happen https://godotengine.org/article/gabe-stable-release/
If Godot for Android is unrelated to you then I misread. But I still find it hilarious conceptually, unrelated to you, that Godot is spending resources on porting itself to phones while it has so many serious outstanding issues. As though game devs are going to be coding on their phones in any meaningful way.
An important compilation target for Godot is mobile, since it's obviously a very large games market.
And, since the Godot IDE is, itself, an app written in Godot, porting to mobile is almost free. More a question of tweaking than rewriting. That's the same reason there's a version of Godot runnable in a browser... it's a consequence of Godot allowing webapps as build targets.
How does this square with the blog post I linked, that sounds like a lot of work, and its ending blurb, "It’s been a long road to bring full build support to the Godot editor on Android and XR devices, and we are excited to see what you build entirely on device!"?
A long road does not sound like something almost free
Thank you for clarifying! That totally changed my interpretation.
There is a surprising number of projects dedicated to making Godot work on mobile, and I am equally confused by that focus. I guess it's more possible with AI coding though, but couch game dev doesn't feel like a real thing.
By all accounts, with the current curve of model improvement, I don't see strong evidence that aligns with that belief. Perhaps with a plateau in model improvement or a saturation of the tech (a la iPhone 2020s), one could argue the lack of growth. But right now with evidence at hand? I wouldn't take that bet.
> To gain Godot's level of indie marketshare, a single breakout engine project that embraces vibecoding could be enough.
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.
That's basically the same argument Unity made a few years ago.
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.
A serious competitor wouldn't use Rust because it immediately disqualifies your engine from being shipped to consoles. At least at the moment. I know it's less of a technical limitation and more of a political one, but if you are serious about shipping your game to various platforms, you cannot use Rust. But things might be about to change, see https://akaganite.com
But honestly, as of today, you're probably having a better time taking a few days to work out clean C++23 guidelines for your AI agents by letting them churn through all the changes and deprecations that happened to C++ over the years, figure out good clang-tidy and clang-format rules, turn on all the compiler warnings and tell them to regularly use UBSAN, ASAN and TSAN and you're getting really close to a clean workflow similar to what Rust would give you but with the rich platform support of C++. It's just kinda sad that one has to go through so much ceremony while the Rust ecosystem gives you those things for free. But imo a well-crafted AI agent workflow gets really close here.
Mean edit: I was reading more of your comments in this post and I start to think you're a bit of bullshitter who's quite overconfident because you think AI makes you so much more productive. I say this because any seasoned game engine dev wouldn't have suggested Rust for a game engine that is supposed to compete with Godot, Unity, Unreal or whatever due to missing consoles support, but you just did, which makes me suspect that you have really shallow understanding and really, AI won't help here. You could have at least mentioned that if you only target dektop and mobile then Rust is a good choice, but you didn't. But don't get me wrong, I'm quite AI pilled as well, but I still know that some things require expert knowledge to properly steer the AI agents.
> the underlying infra isn't strong enough to ward off the many competitors that will embrace AI at the heart of the engine
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.
Godot has a few elements going for it.
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).
>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.
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.
AI-assisted coding is good for creators. It happens to be good for corporations because it reduces costs, but it's actually much more powerful for creators with imagination. I don't know where that argument comes from.
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.
You can use AI assisted coding in Godot though with addons and an MCP server. That's completely separate from AI pr's in the engine itself.
Also, slight tangent but I'm just going to point out that the new MCP server in Unreal Engine 5.8 totally sucks, so it's not like other engines are that far ahead there. The very first task I gave it was to cache a couple of values in a map, and it couldn't do it because it couldn't figure out how to set the key type to FName (basic stuff). But honestly, I'm not surprised, the surface area of Unreal Engine is HUGE and trying to explain it all to a general purpose agent through tool calls is going to hit limits.
I have never found an MCP server that really crushed it. Totally agree. I think there's something required at a deeper level of integration to get AI coding working inside of engines. MCP is not it.
Yes, it's true, this is not a ban on AI coding with Godot. I didn't mean to conflate those, whoops. It stands to reason that there may be a small anti-AI perspective taking shape inside of the Godot engine team. This is one sign, but not confirmation of that suspicion.
>AI-assisted coding is good for creators. It happens to be good for corporations because it reduces costs, but it's actually much more powerful for creators with imagination. I don't know where that argument comes from.
>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.
We're talking about banning AI coding in the game engine itself, not game creators banning the use of AI to create actual games on top of the platform.
> adds to their brand as something for creators rather than corporations
I'm responding to the idea that banning AI contributions is on brand for being "for creators."
What about their action is creator friendly? Yes, they reject all low quality AI slop, which has some indirect positive benefit. They also won't accept high quality PRs unless they are hand crafted. How does that benefit creators? Most arguments it's "for creators" likely conflate the idea that AI-coding is inherently slop. If so, then we can say that directly instead of implicitly.
Monogame, Wicked, Defold, Gamemaker, Stride, Heaps, just off the top of my head
Funny enough, I see it the exact opposite. LLM slop code degrades software quality. While one person may appear to move quickly, the software quality suffers dramatically. It takes them (or other team members) more time to fix the issues than it would have to just do it right the first time.
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.
I don't know about large teams or companies. I feel more confident with the conjecture: Conditioned on small teams, a team of seniors with AI coding beats a team of junior with AI coding by a wide margin, in my experience.
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.
If the AI tools are that effective, the maintainers can just use them themselves? That way they would have the full oversight on how it's done.
PRs with just the results and final code doesn't seem better even if we assume ai coding will be much faster.
Integrating AI-assisted PRs into an existing team is a skillset all in itself.
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.
> Integrating AI-assisted PRs into an existing team is a skillset all in itself.
What exactly is this skillset? Why should AI created PR's be any different from other PRs?
To me this seems like a very sensible move.. they don't want to deal with bad code from uninvested contributors. I can't possibly see how that would harm them. If they want to use AI themselves, given their track record I trust they would do it tastefully.
Quite simply, volume. Detailed human review is a serious bottleneck on code merging. Skillset includes how to make sure you can get quality code at speed without 100% in-depth human review. I wouldn't recommend merges without human eyes, but there is a spectrum of depth in review.
but their stated reasoning is that they do open PRs to train up new contributors and eventually get them into the community where they'll be more trusted. That doesn't suggest a hardline stance against the tools to me necessarily at least.
On one hand, you could be right! I am making inferences on low data, judging the Godot team based on some of their _strong_ design choices. I would have a better argument if I spent the time tracking the Github issues that seemed quite wild that we encountered while building in Godot. Top of mind (low evidence, sorry) GDScript as a base scripting language (later reversed by C#), refusal to add async/await for GDScript, others that have escaped me.
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.
Any resources for getting better at that skillset (high-velocity but largely stable ai-enhanced coding, if I understand you correctly)? I’m always pretty skeptical of these claims but I wouldn’t mind being proven wrong
> Rust libraries like bevy
Notably bevy also bans AI contributions...
A wicked irony I didn't know!
Most likely then a team that builds on top of bevy as infra and not bevy team itself.
You have to consider the market for Godot: indie developers. They don't need cutting edge features; they need a good workflow, ease of use, a good community, stability, etc. Unity is actually really annoying in this regard, because they're _constantly_ deprecating features in favor of new features that are half baked and poorly documented. It feels like a really unstable platform to build on because by the time you're done with a project most of the things you built now need to be thrown away because the underlying engine changed so much, or you're halfway through a feature and you have to decide if you want to rewrite a huge chunk of code to support something new that came out. Unreal Engine is also going through this at the moment (although they're better about backwards compatibility). Hearing that they're dropping blueprints in favor of verse has a lot of people stuck in "uh, should I bother learning the current engine right now". I don't think it'll hurt UE in the long run, but I could easily see them losing some short term adoption. Stability in a platform is a very important feature!
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.
For many years, it's been difficult to build game engines. It's never been easier today. A half-decently funded startup team could get to Godot feature parity within 6-12 months. There's no VC in games anymore (especially not middleware), so it's less unlikely, but they don't have a moat on features.
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...
Oh god. If you really believe you can vibe code an engine in 6 months I challenge you to do it. I think you'll find you've wildly underestimated what goes into an engine.
Well, this is fundamentally where we end up disagreeing. Within the timeframe of a single mobile app development cycle, the entire coding infrastructure of the world changed. Our collective day-to-day coding experience has morphed within 15 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!
Even getting through the discussions and negotiations with the 3 big game console companies to support their platforms can eat up so much of your time window. You can't really vibecode your way out of that - though I suppose you could generate your email responses or an AI meeting participant and risk blowing up the business relationship.
As a professional developer that's using these tools professionally and worked on multiple game engines and even written a few of my own... nope. Sorry, just, that's so much hype not grounded in anything. I'm guessing your job is to promote this stuff based on that being your purpose of going to GDC?
Also, you're really misunderstanding why people use Godot in the first place. They've always been way behind Unreal Engine and Unity on flashy features, that's not their value proposition. A lot of churn on half baked slop features would be counter to why people want to use it. Developers in a stressful industry want tools they can trust, not buggy unstable things that are constantly changing out from under their feet (a lot of teams freeze their engine version per-project for this very reason).
> that's so much hype not grounded in anything.
Not grounded in anything? Really, anything? There's no evidence you've seen in the last three years that has had any impact on what you think is possible with AI coding?
I'm not a game dev by trade, I am AI researcher turned AI engineer (not the "AI engineer" of the modern era, like getting ML deployed in prod). That being said, I have tried and failed to make plenty of games over the years. Every mistake in the book. Making my own engine, trying to do 3D game as first approach, making mobile apps 2010, using Unity for personal projects, switching to Godot. I'm not at your level in game dev, but I've seen plenty at scale.
> I'm guessing your job is to promote this stuff based on that being your purpose of going to GDC
I'm not an AI hype maker, I'm a stunned observer. A person who has said "no way" AI will impact coding for the last 10 years. I am watching evidence in front of my very eyes and my workflow and simply adapting to the reality on the ground along with reasonable projection of capabilities into the future (based on velocity and reasonable assumptions). I don't need to convince you of anything, but I'm confident your beliefs won't hold up against the stockpile of evidence gathering now and in the near future.
Since you took a swing and miss on who I am, I'm going to guess that you are reluctant to incorporate these tools into your own workflow (perhaps having cast them off quickly after some frustrated probing) and have a deep-seated skepticism of the tech that doesn't really matter what I say.
Where's my inference coming from? The idea that you've conflated that AI coding by its very nature needs to be buggy and unstable. I wish you luck on holding the line as it slips past us on an exponential curve.
> Since you took a swing and miss on who I am, I'm going to guess that you are reluctant to incorporate these tools into your own workflow (perhaps having cast them off quickly after some frustrated probing) and have a deep-seated skepticism of the tech that doesn't really matter what I say.
I actually do use them (daily), and I do find them to be useful. I even bought a couple books about how to implement them, and my own current app has an MCP server I've built. I also find them to be overhyped and not particularly essential (if I had to choose one to take to a desert island, I would take a good IDE over a good AI, for example). The way I currently see them is they make things more convenient, but it doesn't really expand what's possible for me, and that convenience can come at a profound cost (some of which we're just now starting to see). I already enjoy coding, so the convenience of not having to code is not that big of a win for me, and when you factor in the extra factors I don't even think it makes me go that much faster. (I either have to correct its outputs, or spend extra time understanding them, or the codebases become unwieldy and I've DEFINITELY seen that. On average AI code seems to be about 2-3x more verbose than what I would write). I can see why someone that can't code (or doesn't want to) would find them to be amazing, but I also think those people are not in a great position to judge the outputs, which is still pretty necessary and probably will be for the foreseeable future.
I think a common thread with AI use is it seems amazing when you're asking it questions about fields you're not an expert in (I like to ask ChatGPT questions about biology for instance), but it seems very much not amazing when you ask it questions about fields you actually are an expert in.
> Where's my inference coming from? The idea that you've conflated that AI coding by its very nature needs to be buggy and unstable. I wish you luck on holding the line as it slips past us on an exponential curve.
See, but that's what bothers me about these conversations in general, people just go "look at number go up!" like you can take any trend and just keep growing it forever. Or people make really bold claims with no evidence like your "you can vibecode an engine in 6 months" claim. It's hard to even _learn_ all the features of a mature game engine like Unreal Engine over _multiple_ years, and to do so would require at least being partially fluent in multiple different very different domains (art, animation, level design, shaders, workflows, about a trillion 3rd party tools, etc.) How could you vibe code something that quickly when even experts probably know about 15-25% of the feature set? Like how can you prompt an AI to build features you don't even understand? Also these engines evolved over a long period of time, so there are so many micro decisions and customer feedback loops that are completely opaque but important and are embedded in the code. The code in many engines contains decades of important knowledge!
I'm not swayed by the "exponentials" argument because past results do not guarantee future performance. I'm basing my opinions on what I've seen in my job and my personal work, and what I've seen is they're a boost, but not to the degree being sold and I'm kind of sick of people telling me that I need to be on board with the hype train or get "left behind". AI is not that hard to prompt, I don't view that as a real skillset, so to me I can either continue to bet on my own skills and intellect and hope they still hold value, or I can just get out of the industry entirely because my role would be entirely pointless. I would rather bet on myself even if I'm wrong, because all becoming dependent on it is going to do is degrade my skillset and my intellect, and if I'm right, well, honestly it's not particularly hard to train up on current AI harnesses or whatever compared to learning a skill (my computer science degree took 4 years -- learning Claude took a day. In what universe is knowing how to use Claude a marketable skill?)
https://github.com/charlesrw1/MultiplayerFps, its pretty easy. And this is just my hobbyist engine Ive been solo orchestrating agents with. If you had a team of ~10 AI-enabled devs, you could easily reach feature parity with Unity in a month or 2.
> Build: Let your agent figure it out
I'm sorry for going off on a random hobby project, but doing this in a C++ project - even if it is a standard Visual Studio solution - is "putting your whole mouth into the salsa dip"-level rude IMO, agent access should not be a prerequisite to build code!
If you really believe this, I highly encourage you to do it! Unity makes a lot of money, spread that among just 10 people and you'll be doing quite well, especially for a month of two of time spent. And more importantly you'll have the bragging rights of telling an internet commentator they're wrong!
The weird thing though is I see comments like this all the time, and I've yet to see anyone come back a month later as a billionaire so.. I'm going to keep my skepticism for the moment.
As an aside, bragging about lines of code as the first thing in your repo is a very weird flex. Lines of code are a cost, not an achievement, you (or your AI) has to maintain them and the more you have the more it costs.
FWIW good on you for making a thing, my goal isn't to trash your project, but from my perspective this does not look like a serious competitor to any game engine; it reminds me of projects I've seen from college students before AI (I don't meant that as an insult, I just don't find this as compelling evidence for your argument)
You're missing that an AI ban is actually just a poor quality AI ban. No one can tell if you used AI in a quality way and write the description in quality English. All this ban does is filter out the worst slop that would never have worked. People can and will still submit quality PRs that used AI, but no one will know it used AI, because the author was conscientious.
I don't know, once you ban AI-assisted coding outright, it's much higher likelihood this ban will cause the Godot team to spend time and energy being AI detectives, especially if they don't agree with the intent of the contribution.
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?
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.
https://noai.starlightnet.work/list.html
there's a few elsewhere in the comments here but I'm not sure how comprehensive any are
This makes sense in the short term, but we really need the industry as a whole to learn how to code with AI in a safe sustainable way. Open Source has a particular problem of taking a really long time to make changes, fix bugs, etc. A lot of design decisions are due to "we don't have time for this". AI can speed those things up and drastically increase the utility we can get out of open source. We just need to figure out how to do it without creating a mess.
No we don't. It's a bad tool, and we do not need to just roll over and accept it as inevitable.
It's a bad tool how? In that it doesn't automatically do everything perfectly from a 0-shot prompt?
We don't have to do anything. We could continue with the status quo and all the problems that entails. Or we could embrace progress and try to use technology to make our lives easier and better.
Simply choking them up is probably sufficient; if you limit how many commits and changes per commit can be made, limit how many PRs one can have open (or even just not closed) at a time, and limit the length of content in those PRs to a couple paragraphs, and autoclose everything that doesn't fit with a message putting the blame on AI garbage, the signal eventually gets big enough that they will start producing adequate content.
It's a really tricky one, but I think it's the right call for Godot, but probably not for other projects. I'm the current maintainer of GodotJS (TypeScript bindings for Godot). LLMs can generate genuinely useful solutions for Godot e.g. a functional WebGPU implementation for Godot — https://github.com/godotengine/godot-proposals/issues/6646.
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.
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?
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.
> No, reviewing PRs in general is a delightful process
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
That, not being sure if the submitter is willing to meet you part way, is exactly the miserable part I am talking about. Basically, you go in risking it's just a waste of your time. After some trust is established, or when the PR is from someone you already have some trust relationship, the dynamics are very different.
Yes, it can still be a slog to review someone else's code, but you usually have the feeling of "hey, this is probably something good".
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.
>why can't AI-assisted PR reviews make it less tedious?
Godot is a performance critical system in the realm of a million lines of code (?).
Keeping your system both correct AND performant, requires people understand how it works. This kind of technical knowledge is slow to develop, so it's one of the most valuable skills to possess.
I don't see how you continue to understand your system when people are both generating code with AI and using AI to review it's output.
just when the models started to be actually good. these policies need quarterly revisions at the current dynamics.
Assuming you're referring to the policies elsewhere that are overly permissive of model-generated code ;)
I'm referring to any policy actually; it cuts both ways. I'd actually suggest a per-model policy - e.g. personally I'd have much less doubts accepting Fable/Mythos patches than Sonnet ones. this is obviously unworkable, impossible to validate and excludes mixed-model workflows, but in spirit the 'smart' models/model mixes should be treated differently than the dumb ones. another case is one-liner (approximately) fixes - I wouldn't even bother to self-report these as AI generated.
Just 6 months before we get AGI!
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.
Weird that AI is supposed to be able to enable all this and yet all we get is news about how it's really just burning out projects that have limited resources making them more expensive and companies having to hire back devs they laid off.
There is a saying in the services industry, one unhappy person will tell 10 people and it takes 10 happy people to tell one. The quantity of what you read online is not an actual representation. Best not to treat all Ai use and users as one group either.
I think this is a false dichotomy. We’re getting lots of new productive output in some areas and in other areas it is too much slop.
Your argument might carry some weight if you added any kind of argument past "lots of new productive output" and then silence.
I feel like the topic has been discussed ad nausiem but:
* 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-...
[4] https://github.com/cloudflare/workers-oauth-provider
[3] is not openvpn, just some install script a rando not affiliated with openvpn did.
> If it's really better, people will join the fork.
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
Why not use AI to review PRs?
So many thoughts
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.
I think "no-AI" policies are really just ways of gatekeeping low effort contributions from people who have no idea what they're doing. This is a good thing!
To use the current example of Godot--game engine development is really, really, __really__ hard. Building on your engine in a way that doesn't lead to performance regressions, introduce subtle bugs, etc. takes a lot of know how.
If you care about quality and performance, then rejecting work from people who aren't capable of understanding how their contributions impact the greater engine as a whole is a logical choice.
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.
I'm not sure I agree with the policy, but I'm glad we are seeing different project experimenting with different policies. So after a while we can probably see how things shake out in the end.
Definitely sympathetic to their policy, but AI tooling and quality are changing quite fast. In a year I'd expect a modification of this as AI agents get better in virtually every possible way.
Is it though? Gains have been marginal and one of the major weak points is working on complex software
Open source projects now need an "AI-free" label. The 2020s are wild.
Banning the PRs is the easy part. The funny bit is that "understands their own code" is now a filter worth writing down.
Is anyone using LLM on the other side, to vet incoming PRs for quality and whether it's worth reviewing?
most frontier labs have such AI-based triage process, it appears most opensource projects haven't figured how to do this.
And how will this be enforced ?
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
"suspects".... that sounds error prone. And I read it like "we don't want AI generated stuff unless we can't tell the difference".
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.
Sure. My point is that they will probably accept "AI" contributions anyway, without knowing it.
These things are done not to block pr done with the help of ai, but to block the ai slops pr, aka those never reviewed, fully vibecoded, and with the submitter that didn't understand anything about the problem or the code, just trusted claude.
The rule is general on purpose to allow the maintainer to freely remove whatever is very evident is just ai slop
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.
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.
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?
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.
You don't think there are any other aspects worth considering than the mere quality of the code produced?
Sure, but these aspects are rarely brought up by my opponents. And we can discuss them ad lib, but there is no coming back for me.
Don't compromise your professional integrity by lying about how you work. Rather find a job where you don't need to lie about your use of AI if you can.
25 years ago I had to lie about using free software since it was also frowned upon. I even lied to my CTO at the time who wanted me to work completely in a Microsoft environment, with ASP and what not. Being kinda stubborn I did not comply and used only free software. When boss saw the result and the cost I got promoted. My integrity is fine.
You should have been fired for cause, because the way you chose to work exposed your employer to substantial liability due to the “copyright laundering” nature of LLMs. But you prioritized feeling good over everything else. You’re a sociopath and you should be treated as one—a bad-faith actor only out for themselves, who cannot be trusted to collaborate within agreed-upon limits because you don’t think rules apply to you.
There are no agreed-upon limits, everything is new there. And I don't prioritize feeling good over everything else, otherwise I just wouldn't even start the debate. Far from being fired, I was promoted, because the real world is not your fantasy, results matter more than theorical threats. Also keep your name-calling to yourself.
You literally said as much, and I am not calling you names, I am accurately describing your behavior in a way you yourself appear to recognize:
> 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.
You specifically said you would lie about how you work to get accolades if your employer attempted to set rules against working the way you prefer.
The appropriate reaction to your employer setting rules you don’t agree with is to try to convince them to change those rules, engage in a labor action alongside your coworkers to force them to change those rules, or to leave.
Godot is a good engine but the devs are activists.
I understand the struggle, but I feel like so many of these projects are going to ban AI contributions right before it starts getting undeniably better than humans.
Any day now! It's going to become sentient and send us into the future! Just long enough for the IPO!
I don't understand how people can make such sarcastic remarks given AI progress in coding past 8 months
They can always unban it later when we arrive at that reality.
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.
Then those 'competitors' can fork Godot and make their own AI version of it. Will they? No, no they wont. But they sure will complain about the rules while doing nothing about it.
Competitors … in open source?
I predict any project that allows AI will slowly degrade in quality
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.
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?
I get that, but again this seems like a quality problem. As for commitment a simple sorting algorithm which prioritizes repeat contributors should solve that.
Google Godot drama 2024, for some top-notch community mismanagement classes.
All I found is something to do with Discord. Been using Godot for years I have no idea what drama you’re talking about.
As far as I can remember. There was a pro LGBT tweet that some people didn't like. And the moderator decided to blanket ban everyone who disagreed with the tweet. Some of the banned people had reasonable objections like: regardless if they agree with something or not politics and OS should be separated, and were still banned, including on GitHub. Others had objections also shared with the Godot founder and were still banned. There were some other things also but can't remember the details.
LGBT people aren’t “politics”.
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.
Of course it's politics, you have billions of people thinking otherwise than what is accepted in the west.
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.
The drama is in a nutshell someone made a really stupid post claiming only the woke use game engines. Godot community manager said guess that makes us woke (paraphrased), conservatives went batshit, got blocked on Twitter or elsewhere for going insane and a few innocent tweets got caught in the crossfire. Someone went off and made a fork of Godot as a 'non-political version' which went in the only obvious direction it could go.
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.
The fork also had its own drama, resulting in one of the more active developers of the fork, plus the guy who helped kick off the original drama, splitting off to create yet another fork. Both forks are still active, I believe. It was all very silly
Most of it was silly, but being banned on github for a reasonable objection is still very tyrannical.
From what I recall, based on what a Godot developer wrote at the time, nobody got banned from GitHub for "a reasonable objection". The only people who got banned from GitHub were those who posted abuse there, after a few people had gotten blocked by the Godot Twitter account
The problem here is the definition of abuse. And I don't mean to say that I'm 100% sure Godot overstepped in the github ban cases, but if they can ban people for criticizing them I wouldn't be surprised if they overstepped there too.
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.
> write one good PR
is about quality not AI which is exactly my point.
Another problem, AI allows many people to 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.
In order to reject low quality PRs, you first have to determine that they are low quality. Guess what LLM-generated code is really good at hiding.
A global labour crisis and broken reputation signaling in FOSS has produced a deluge of software production that has basically nothing to do with low quality submissions and everything to do with capitalism.
FOSS has become the release valve for too much labour supply.
Why base the decision on what tools are used by the author and not on the quality of their past contributions?
Because it's not about the tool or the quality of the past contributions, but the quality of the current contribution. It's not new either, it's "show me the code" - it doesn't matter who you are, what you say, what you claim to have achieved in the past, the only thing that matters right now is this particular merge request and code.
I don't think the problem is the (AI generated) code per se, but as the article mentions, it's the human interaction. A reviewer can spend hours on reviewing the code and leaving feedback to the author, but if the author just feeds it into an AI (or worse, it's automatically fed into it) and processes it within seconds, only to start with a blank slate for a next change, what's the point of putting in all that effort?
Humans can learn and adapt, AIs can... ingest more stuff into their context, I suppose, but it's been proven that things break down if they have too much stuff in said context, and said context is limited.
If your contributions are genuinely indistinguishable from AI code, then this shouldn’t affect you. There would be no way to enforce it
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"
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/
Why will they fail? They will simply sign it and continue.
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 ?
> I guess that means no IDEs doing refactoring or automating common code. Not linters altering code, etc... right ? Because that's the same thing.
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)
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.
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.
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.
You are not the author with ai.
It's far more time-consuming to judge the quality of someone's past contributions than to have the LLM redo the contribution with quality you can control far more.
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.
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.
They have consistently been proven right. The only thing failing has been the plateau claimers. If anything, it has improved much faster than the optimistic predictions.
Then fork Godot and accept all the PRs you guys want?
No need to ruin existing software?
Why are you directing the question at me? Obnoxious behavior, and your initial "gotcha" is just nonsense on a similar level as "why don't AI companies just clone all SaaS if the models are so good".
In many ways this makes sense. I noticed other projects struggle with this as well. AI slop spam kills time available.
On the other hand ... it is a bit strange though, because what if code contributions objectively improve something? I dislike AI slop spam, but from a purely objective point of view, I am not sure it should be forbidden based on it intrinsically making a change, which COULD be an improve. Now I am also aware of the AI slop spam worsening things; ton of documentation is useless, look at what matz produces with claude, this seems to be written purely by an alien, aka AI. I don't understand anything that this AI generates. But I think from an objective point of view, I'd actually lean more towards not completely disallowing AI slop contribution. The issue seems largely with:
a) the quality
b) the amount of text generated
Both these problems, in my opinion, could be solved. The time required by a real human to look at it, though, will always be a bottleneck, so perhaps the more honest answer would be that humans don't have enough time for contributions from skynet.
> what if code contributions objectively improve something?
If the contribution is complex enough, it is no longer an 'objective improvement' but rather a judgement call, and in the process becomes copyrightable. This is where the trouble lies, and why this kind of AI involvement is banned.
If it is not, for example by being a one-line fix that literally cannot be performed differently, it's a different story. Then it can be merged, viewed either as a menial change (exempt by the ban) or by transfer of ownership (the reviewer becomes the effective author) because it is not copyrightable.
will come back to bite them very soon
FUCK AI. I'm tired of all the AI related bullshit we are living through.
Are they gatekeeping to protect against AI "slop" or are they gatekeeping to protect an inefficient and non-scalable review process against velocity?
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.
In my experience success in a project isn't about the amount of code that can be produced, it's more about the thoughtfulness behind features and fixes. A lot of the work going into reviewing pull requests is understanding it in the context of the project's broader goals.
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.
Part of this is an argument for size limits on PRs.
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.
For now, while it's simple enough to tell.
Just put it behind a paywall for PR prioritization or consideration, more payment to jump the queue.
There, I solved FOSS sponsorship.
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
Doesn’t even have to be merged, it’s for the privilege of even being considered to be merged into a popular library, one can always fork but to put stuff in a popular repo should be pay-walled henceforth
lol, they want to be old school
[flagged]
[dead]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[flagged]
I'm curious how they would know - can't someone just tell Claude not to use excessive comments and write code that matches the style and conventions of the codebase it's being used against?
Most LLM users wants to do less work, not more. Shaping LLM output to be human like is a lot of work, and that assumes you know what the human version looks like.
Godot is one of the worst run open source projects with a crawling pace since 2014.
It’s been wildly successful. Poorly run projects tend to fail.
If Unity didn't commit hara-kiri I'm positive it would be much less successful.
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.
Doing an ad hominem for an argument about Unity/Godot is wild.
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.
I bet you work on AI.. or invested in it... or you are sam.
Care to give arguments?
strong disagree, as a user the recent updates have been awesome and immediately useful.
While I agree with the general message, and wish it will eventually radiate to cooperations as well, it is obviously a decision driven by feelings, not logic.
The idea that you can't trust code that was generated by heavy users of AI, because _they_ don't understand it enough to fix it, is false, because they can use AI to fix it.
In general, I have hard time understanding how one might even block other contributors from using ai.
Community management (which is an important part of PR/issue management for open source projects) should definitely take in account the human aspect, i.e. feelings.
It's a 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.
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
> 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.
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.