9 ms·

Godot will no longer accept AI-authored code contributions

• endre 4mo ago
  [flagged]
• manvel_hn 4mo ago
  There are some curated lists of no-AI software. Would be nice to have an index / plot of how that changes in time. https://codeberg.org/brib/slopfree-software-index https://codeberg.org/brib/slopfree-software-index https://noai.starlightnet.work/list.html https://noai.starlightnet.work/list.html
  • TomasBM 4mo ago
    Interesting initiative. What are the guiding reasons behind these lists? I can't think of a functional reason for a no-AI policy: if it runs, it runs, regardless of who or what made it. Also, even if you avoid AI-generated slop, you can't really avoid the human-generated or human+AI-generated slop that passes your filters. Still, I can definitely think of good non-functional reasons: provenance, accountability, proof-of-work, encouraging people to write code themselves, empirically tracking how humans develop codebases, etc.
    • voidUpdate 4mo ago
      I think the main functional reason is that because a human hasn't written the code, its potentially more likely to have subtle hidden bugs that a human cant explain because they didn't write it, as well as large pull requests that have to be validated by a human when smaller human written ones would be better. But I think it's generally the non-functional reasons that projects are rejecting LLM-generated code. Some developers just find LLM generated code icky, and would prefer not to be associated with it
      • mschuster91 4mo ago
        And on top of that - no matter if you develop open-source or proprietary software, who is to guarantee the AI didn't get trained with GPL (or even worse, leaked proprietary) source code? Who is going to pay my lawyer when someone files a copyright lawsuit and all I have as an excuse is that I "AI-laundered" my code? And some projects like WINE or ReactOS probably have to worry about that even more given they need to guarantee clean-room reverse engineering...
        • voidUpdate 4mo ago
          Given the amount of web scraping LLM providers have been doing, I'd say it's likely that any code that is publicly accessible on the internet has been incorporated into it's training data, whatever its license
        • cyclotron3k 4mo ago
          I'm not disagreeing with you, but it's worth noting there were plenty of GPL violations before LLMs existed.
          • mschuster91 4mo ago
            Sure, but at least when I write code by hand I can be fairly certain that I do not copy code without the appropriate license to do so.
            • cyclotron3k 4mo ago
              From godot's pov though, banning AI won't guarantee some arbitrary contributor's PR doesn't include GPL code.
      • drdaeman 4mo ago
        This makes sense, but I'm not sure it's directed at the actual issue. There are probably some subtle bugs I can't explain in the code I wrote all by myself. I sure had a few "what was I possibly thinking when I wrote this" moments working on some old code - and that's only the bits I know about. And I sure had countless times people pointing out "hey, you got this stinky here" in a code review (which is the whole point of it). Attention lapses and brain farts sure happen. Slop can be more frequent with LLMs but it's certainly not a LLM-specific issue. They're very productive, there's a literal outbreak, and by the sheer volume shadow any The Daily WTF stories. However, I can agree that LLM-generated code most likely has higher probability of slop. But then, a policy "a human contributor MUST fully know and understand all the contents of the submitted work, in fine detail, all the way down to every single line of contributed code and documentation" would probably address that in a more functional manner. And then the code can be from an LLM or monkeys with typewriters author had seen in his sleep. That stops to matter because author takes ownership and responsibility: "here's a recognized rational agent who swears by their work". Makes non-self-authored code require a lot more effort (unless it's a trivial change for obvious reason), but arguably even more robust than self-authored code. That is, unless the PR authors tend lie about their knowledge - but that'll be a whole different story, where LLMs will be just a background detail. (I'm not saying Godot should be done something different - their project, their rules, let's use that as an opportunity to watch how it goes. Just musing on the matter in general, if there's any rationally explainable merit in such policy.)
    • Forgeties79 4mo ago
      > Still, I can definitely think of good non-functional reasons For many people that’s enough of a reason. As for functional, you can see it all up and down this comment thread. People don’t check their work and leave these massive walls of text and codebases that someone else has to audit/cleanup. It’s exhausting. Too many people offload their work to AI and put zero effort into vetting the results, which punctually means they are just offloading the work downstream. So many maintainers are simply going “no I will not do your work for you,” which is a very functional decision. To butcher a comment I read on HN that put it very succinctly months ago: everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work. It’s a seriously problematic dynamic on many levels. And that dynamic will not change until the vast majority of people start reliably vetting the results, which I don’t think is going to happen because babysitting a black box and trying to force it to output something a specific way (or constantly copy editing middling work) is not something that most of us enjoy.
      • TomasBM 4mo ago
        I think that's completely fair. There are also plenty of valid personal reasons for refusing to generate code with AI - learning-by-doing and ownership of the result being the main ones, IMO. > everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work. This is also true in my experience. But in my work, I found that I don't care how the code or comment was generated, as long as it doesn't try to overload my brain with irrelevant and obfuscated things, and as long as the person is not pretending that it's true, verified or their own creation (when it isn't).
        • Forgeties79 4mo ago
          >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.
    • 0xMalotru 4mo ago
      There is a "why" a the end of the list https://codeberg.org/brib/slopfree-software-index#why-care-about-slopfree-software https://codeberg.org/brib/slopfree-software-index#why-care-a...
      • kjeksfjes 4mo ago
        > There is a study showing that doctors who use AI to help detect cancer become less skilled at detecting cancer without AI. Not exactly an argument against using AI, is it? It's a bit like saying that GPS makes people worse at navigating by memory, which is true, but also not a strong argument for going back to paper maps. I feel the discourse is more about "stop using AI" and less about "how can we ensure our backup skills doesn't disappear".
        • deniska 4mo ago
          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.
          • TomasBM 4mo ago
            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.
        • ThrowawayR2 4mo ago
    • nasso_dev 4mo ago
      or, maybe, as a form of protest? many people are actively against AI for ethical/moral/personal reasons, so they want to avoid using software made with it you can see it sort of like making a list of vegan restaurants. you might not see anything wrong with other restaurants (they might even have vegan dishes) but to some people it makes all the difference because they get to choose who they support
    • vips7L 4mo ago
      > I can't think of a functional reason for a no-AI policy Imagine morals.
      • degamad 4mo ago
        That would be part of the non-functional reasons mentioned in the next paragraph.
        • seanclayton 4mo ago
          > I can't That makes much more sense now. The inability is completely on you, and you admit it at least.
          • alberto467 4mo ago
            You can’t understand the difference between functional and non-functional.
            • seanclayton 4mo ago
              > 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?
      • CuriouslyC 4mo ago
        Maybe then it should be a no Oligarchs policy, and include code written by capitalist shills as well to be internally consistent.
    • dirkc 4mo ago
      Please define "if it runs, it runs"?
      • TomasBM 4mo ago
        If you have some requirements/specifications, and the piece of code fits them, then it runs. Alternatively, if you have some vague idea [1] about what you expect to see/have, and the running code satisfies that idea, then it also runs. Obviously, there are plenty of non-functional specs (e.g., security, cleanness, readability) that a code should probably fulfill before one finds it acceptable, but these are also not somehow impossible for state-of-the-art models to satisfy. [1] Vibe, if you prefer, tho I dislike the term. Another related term is eyeball estimation.
        • qsera 4mo ago
          But it is hard to verify it, right? If you use rsync clone by an LLM to copy a million files, will you bother to verify every single one was copied correctly?
          • TomasBM 4mo ago
            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.
            • skydhash 4mo ago
              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.
    • vazark 4mo ago
      Because the goal is two-part 1. Accept quality contributions from someone who understands what they're doing 2. Cultivate a relationship with the contributor who might potentially become a core-team member. Maybe even the next maintainer
    • croon 4mo ago
      The reasons are functional in aggregate, but not necessarily per specific PR. You could get a perfectly adequate instance of a PR that is easily readable and verifiable while generated by an LLM, but generally they're not. A policy pushes the aggregate to at least what looks and communicates as a human made PR that is functionally easier to approve. Whether they are created by an LLM or not is then secondary, but it likely pushes all PRs to be better.
      • TomasBM 4mo ago
        Good point. Even if you submit small, verifiable and readable changes, you can still overload the review process by submitting too many of them (e.g., 100s of PRs). But I'd argue that some projects [1] could benefit from the speed (and sometimes, quality) of AI code generation without filtering by something that's difficult to identify (i.e., is it truly human-generated). One way could be to constrain the size of each commit and PR, and invest more heavily into the review process (e.g., tests, static/dynamic analysis, sandbox deployments), so even if you get 100s of contributions, you can knock each out quickly. Obviously, easier said than done. And at that point, you may as well use the AI to make the commits yourself, instead of relying on community contributions. [1] Of course, this is only the case if the project's only purpose is to be a tool, and not also an educational reason for humans to learn how to code - in which case, it makes sense to invest more into identifying the "cheaters".
        • croon 4mo ago
          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.
    • timacles 4mo ago
      So you didn’t read the article?
    • pjmlp 4mo ago
      Same reasoning that folks apply against AI written blog posts.
    • surgical_fire 4mo ago
      > 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.
    • bwfan123 4mo ago
      > 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.
    • bigstrat2003 4mo ago
      > 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.
      • TomasBM 4mo ago
        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.
    • adamddev1 4mo ago
      "If it runs, it runs," is an very naive and irresponsible view of code.
  • postalcoder 4mo ago
    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 https://hcker.news/?ai=exclude&include_domains=github.com
• TekMol 4mo ago
  Why base the decision on what tools are used by the author and not on the quality of their past contributions?
  • throwawayffffas 4mo ago
    Because: 1. In the case of AI generated code, the tool is the author. 2. Its far easier to enforce. 3. The alternative gate keeps against new contributors.
  • superb_dev 4mo ago
    If your contributions are genuinely indistinguishable from AI code, then this shouldn’t affect you. There would be no way to enforce it
    • preisschild 4mo ago
      There is legally. Make sure they sign the DCO (Developer Certificate of Origin). They will fail at the first paragraph (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; [...] https://developercertificate.org/ https://developercertificate.org/
      • mobiuscog 4mo ago
        I guess that means no IDEs doing refactoring or automating common code. Not linters altering code, etc... right ? Because that's the same thing. How about if AI generates code in a file, then I copy/paste bits... like stack overflow ?
        • preisschild 4mo ago
          > I guess that means no IDEs doing refactoring or automating common code. Not linters altering code, etc... right ? Because that's the same thing. 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)
• TomasBM 4mo ago
  It's a fair policy. Getting those verbose, AI-authored walls of text is very annoying, especially when you're expected to thoroughly review it. It's like a denial-of-service attack on the human mind. I can only imagine how frustrating this can get in open projects that get a lot of contributions. However, I don't think this will discourage AI-based coding at all. In fact, I see two potential outcomes of these policies: - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier. - Positive: Submitters actually provide to-the-point, no-bullshit commits and comments - "here's the code, here's why I made that change, here are the effects of that change". Even if AI-generated, these small contributions may become much easier to verify & validate. We may even see some standardization in terms of what qualifies as an appropriately sized contribution, what requires more thorough review (e.g., adding unverified dependencies), etc. I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
  • ivorius 4mo ago
    > - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier. From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much. > Positive: Submitters actually provide to-the-point, no-bullshit commits and comments That would be a dream.
    • watwut 4mo ago
      > From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much. The policy allows the reviewer to reject it on the "AI" grounds.
      • dspillett 4mo ago
        > allows the reviewer to reject it on the "AI" grounds … but still unfortunately leaves reviewers having to spend time checking submissions and rejecting them.
• localhoster 4mo ago
  While I agree with the general message, and wish it will eventually radiate to cooperations as well, it is obviously a decision driven by feelings, not logic. The idea that you can't trust code that was generated by heavy users of AI, because _they_ don't understand it enough to fix it, is false, because they can use AI to fix it. In general, I have hard time understanding how one might even block other contributors from using ai.
  • dgellow 4mo ago
    Community management (which is an important part of PR/issue management for open source projects) should definitely take in account the human aspect, i.e. feelings.
  • SwtCyber 4mo ago
    And it just keeps looping like that until the context window bursts. In practice the model is great at writing new code, but when you feed it its own six month old spaghetti code with a floating bug in the state machine it just starts hallucinating and silently breaking neighboring features
  • eschaton 4mo ago
    You block them from using AI by making sure they know your project doesn’t want contributions from people using AI. Either they’re a decent human being and they’ll comply with the project’s wishes, or they’re a sociopath who will violate the explicit request of the project and lie about the origin of their contribution and hopefully slip up and get caught doing so.
  • strangecasts 4mo ago
    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/ 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 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-godot-4-2/ 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.
• taris2 4mo ago
  Godot is one of the worst run open source projects with a crawling pace since 2014.
  • jokoon 4mo ago
    Care to give arguments?
  • tmountain 4mo ago
    It’s been wildly successful. Poorly run projects tend to fail.
    • throwfaraway135 4mo ago
      If Unity didn't commit hara-kiri I'm positive it would be much less successful.
      • JsonDemWitOster 4mo ago
        And if yomomma had balls, she'd be yopoppa. Puh-lease. Unity's "hara-kiri" was in 2023 by which time Godot was NINE years old. Hara-kiri or no hara-kiri Godot has shown longevity and relevance. Anything gained from Unity's own-goals is just cherry on top.
        • throwfaraway135 4mo ago
          Doing an ad hominem for an argument about Unity/Godot is wild.
  • Stevvo 4mo ago
    This was true until a couple of years ago. Recently things really picked up. That said, there are still many years old open PRs unmerged that make great additions; maybe this policy will free up resources to move forward with those.
  • hairymouse 4mo ago
    I bet you work on AI.. or invested in it... or you are sam.
• thinkingemote 4mo ago
  Godot's new contribution policy: https://godotengine.org/article/contribution-policy-2026/ https://godotengine.org/article/contribution-policy-2026/
  • Aachen 4mo ago
    This is the link for the actual contribution policy: https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html 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
• gitowiec 4mo ago
  "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review," the Foundation said. That is to the point!
  • signa11 4mo ago
    zig's 'contributor poker' is sounding more and more prescient.
    • yubblegum 4mo ago
      looked it up: https://simonwillison.net/2026/Apr/30/zig-anti-ai/ https://simonwillison.net/2026/Apr/30/zig-anti-ai/
  • qsera 4mo ago
    And the worse thing is that their feed back probably goes into the training of the next LLM. So more free labor for the AI companies.
• shevy-java 4mo ago
  In many ways this makes sense. I noticed other projects struggle with this as well. AI slop spam kills time available. On the other hand ... it is a bit strange though, because what if code contributions objectively improve something? I dislike AI slop spam, but from a purely objective point of view, I am not sure it should be forbidden based on it intrinsically making a change, which COULD be an improve. Now I am also aware of the AI slop spam worsening things; ton of documentation is useless, look at what matz produces with claude, this seems to be written purely by an alien, aka AI. I don't understand anything that this AI generates. But I think from an objective point of view, I'd actually lean more towards not completely disallowing AI slop contribution. The issue seems largely with: a) the quality b) the amount of text generated Both these problems, in my opinion, could be solved. The time required by a real human to look at it, though, will always be a bottleneck, so perhaps the more honest answer would be that humans don't have enough time for contributions from skynet.
  • ivorius 4mo ago
    > what if code contributions objectively improve something? If the contribution is complex enough, it is no longer an 'objective improvement' but rather a judgement call, and in the process becomes copyrightable. This is where the trouble lies, and why this kind of AI involvement is banned. If it is not, for example by being a one-line fix that literally cannot be performed differently, it's a different story. Then it can be merged, viewed either as a menial change (exempt by the ban) or by transfer of ownership (the reviewer becomes the effective author) because it is not copyrightable.
• eru 4mo ago
  I'm not sure I agree with the policy, but I'm glad we are seeing different project experimenting with different policies. So after a while we can probably see how things shake out in the end.
• deftio 4mo ago
  Definitely sympathetic to their policy, but AI tooling and quality are changing quite fast. In a year I'd expect a modification of this as AI agents get better in virtually every possible way.
  • timacles 4mo ago
    Is it though? Gains have been marginal and one of the major weak points is working on complex software
• villgax 4mo ago
  Just put it behind a paywall for PR prioritization or consideration, more payment to jump the queue. There, I solved FOSS sponsorship.
  • Fraterkes 4mo ago
    I honestly think that a 1$ “deposit” to submit a pr for new contributors (to be returned if the pr is merged) could help with a lot of OSS problems
    • villgax 4mo ago
      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
• avaer 4mo ago
  Totally valid. If someone thinks they're building better open source with their AI, let them fork; their AI can maintain downstream. If it's really better, people will join the fork. Good luck. In all likelihood anyone attempting this will realize the value that a maintainer provides. On the odd chance they discover a new working model and produce better software, all the better, everyone wins.
  • terminalbraid 4mo ago
    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.
    • ianm218 4mo ago
      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.
      • terminalbraid 4mo ago
        Your argument might carry some weight if you added any kind of argument past "lots of new productive output" and then silence.
        • ianm218 4mo ago
          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-zero-day-vulnerabilities/ https://blog.mozilla.org/en/privacy-security/ai-security-zer... [2] https://arxiv.org/abs/2506.13131 https://arxiv.org/abs/2506.13131 [3] https://stanislas.blog/2025/12/claude-code-opus-open-source-maintenance/ https://stanislas.blog/2025/12/claude-code-opus-open-source-... [4] https://github.com/cloudflare/workers-oauth-provider https://github.com/cloudflare/workers-oauth-provider
• marsven_422 4mo ago
  [dead]
• Mabusto 4mo ago
  The foundation points out something that has always been true, but AI has really brought to the forefront, that any contributor, including AI, could potentially not be relied on to maintain this patch in the future. This is the core of the issue, not that someone uses AI, but that it’s just one of many smells a patch can have that indicates someone doesn’t understand what they’re submitting. You could be breaking variable naming conventions, changing APIs you shouldn’t, making amateur language mistakes, all indicate that yes, maybe the patch does work, but that there are other good reasons to reject it. A way around this might be to mark a PR as rejected because of AI and then ask the author to point out some part of it they’re particularly proud of and explain in their own words, not a wall of AI text, what this does and why they like it. Just something where the author has to show that they have something an AI can’t, namely taste and an opinion.
  • ivorius 4mo ago
    AI is well-capable of fabricating text that looks like an opinion in 2026. This would not help differentiate AI from human authors.
    • Mabusto 4mo ago
      You’re absolutely right - AI is not just capable, it’s on the leading edge. It’s not about vibes, it’s about results. (It’s famously not well capable of sounding human)
      • ivorius 4mo ago
        Right. Reviewers still have the advantage of being able to spot AI text because it's often overtly different. I just meant to say that, if you prompt ai "what would a human be proud of having written this code" you'll get an answer. They're not categorically incapable of fabricating an "opinion", they're just trained not to express one by default.
        • Mabusto 4mo ago
          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.
• SwtCyber 4mo ago
  AI accidentally found one of the most expensive resources in the industry: the free time of people who maintain open source in the evenings after their day job
• JodieBenitez 4mo ago
  And how will this be enforced ?
  • yulaow 4mo ago
    How they enforce it in every other project with the same policy, if the reviewer/maintainer suspects the pr is ai slope he closes it. That's it, it works fantastically well, I do the same even in my job
    • JodieBenitez 4mo ago
      "suspects".... that sounds error prone. And I read it like "we don't want AI generated stuff unless we can't tell the difference".
      • eschaton 4mo ago
        How do they enforce that contributions aren’t copied and pasted from AGPLv3 or proprietary codebases? The honor system and intuition and occasionally flat out asking people. Do you think sociopaths willing to lie about how they came up with a contribution are really that common?
        • JodieBenitez 4mo ago
          Let me tell you a story: I use agents at work. Not to add more useless features, not in a let-loose way, not so that I can slack all day but to produce better output. Think performance optimizations, security fixes, better use of underlying frameworks, produce better documentation, get useful hints from the code base, that kind of thing. In a word, to produce objectively better software. that is my honor: giving the best I can. Because AI is frowned upon where I work, I kept that under the radar. And I got nothing but praises for the good work, everybody loving it. Later I had the opportunity to port a piece of software from one language to another. LLMs are great for porting stuff when steered well. Again, nothing but praises for the amazing work done in a very short time. And this is where I tried to open a debate about AI by disclosing my tools and methods. And boom, suddenly I was evil. Praises gone. But still, none had the guts to throw the port to trash, because it's still very good. Hypocrisy. So yes, call me sociopath if you like, but I will lie, produce better software and get the praises if I have to work in an environment that values tools and methods over results.
• frb 4mo ago
  ...the influx of contributions authored or submitted by AI is sapping the projects' maintainers of their willingness to confront the "already tedious" work of reviewing pull requests.... To me this seems a core issue: PR reviews for most people feel tedious and this has been the case way before AI already. Don't get me wrong, slop is slop, no matter if AI or entirely human-fabricated. But just like AI-assisted coding can actually be helpful, why can't AI-assisted PR reviews make it less tedious?
  • Sharlin 4mo ago
    It can, but using a technology just to work around problems caused (or at least exacerbated) by the very same technology is obviously not something we should be doing or encouraging.
  • pferde 4mo ago
    No, reviewing PRs in general is a delightful process. The tedious part is in the initial triage when the PR comes from a previously unknown submitter, and you cannot be sure what is the intention of the submitter, what is their technical level, whether they are talking out of their ass or not. It's basically the same issue as spam in emails. It was bad before, and automation made it a zillion times worse.
    • bluefirebrand 4mo ago
      > 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
      • pferde 4mo ago
        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".
• mellosouls 4mo ago
  Underlying announcement might be a better link: https://godotengine.org/article/contribution-policy-2026/ 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.
  • timacles 4mo ago
    Competitors … in open source? I predict any project that allows AI will slowly degrade in quality
  • fzeroracer 4mo ago
    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.
• Semkas 4mo ago
  I'm getting the feeling that many people here are mostly reacting to the title instead of reading the actual policy: they state that an important part of the reason is that they use PR review to train new contributors and find possible future maintainers. Irrespective of the quality of ai-contributions, that seems hard to argue with. (unless you believe ai will make the whole concept of OS contributions / maintenance redundant. If that's your belief I don't think it makes much sense to submit PR's to Godot though, instead of just forking the engine and having your agents work on it)
• dude250711 4mo ago
  If AI is so good, there should be hundreds of new engines far exceeding Godot. Yet all that is being produced is piggy-backing unchecked vibe-slop.
  • terminalbraid 4mo ago
    It's also telling with all the comments of "just wait a few months the models are getting so much better" which has been said for years and will continue to be said for years. It's the same with any other scam with tenuous value (see cryptocurrency). At some point you just call it failed.
    • Kiro 4mo ago
      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.
      • dude250711 4mo ago
        Then fork Godot and accept all the PRs you guys want? No need to ruin existing software?
        • Kiro 4mo ago
          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".
• brettermeier 4mo ago
  Do those AI contributors really think they are helping out? Don't they get, that they are destroying such projects with their "work"? Why do they spend money for stuff nobody wants and gets rejected. I don't get it... Don't these people have any hobbies? Or are these free-roaming OpenClaw instances that have been forgotten by their creator and are now doing their own thing?
  • muvlon 4mo ago
    We are no longer in the era of FOSS where contributions are purely motivated by either scratching your own itch, altruism or curiosity. Haven't been for over a decade, since that's how long companies have been checking out applicants' GitHub pages during hiring. These people are farming contributions to major FOSS projects as a form of CV-padding. The same is happening with vulnerability reports. The sloppers may genuinely think they're helping out, or they may know their 'contributions' are a net negative for the projects, in the end it doesn't matter much. When you're motivated by direct economical incentives and your situation is precarious enough (in today's labor market, it is), externalities are not high on your list of concerns.
    • alberto467 4mo ago
      Exactly. That’s the only real core issue. Wild AI usage is just a consequence. Developers who have a nice job and career, and are making good money, might think of doing open source to “contribute to society” or something like that. But new developers who are seeing those golden opportunities shut in front of their faces, they feel like they have to desperately fight for the last places on the lifeboat, so I don’t blame them for wanting to farm cv points and game the system of incompetent recruiters who make much more then they will do, instead of spending time and effort doing something nice for society hoping someone will notice (lol they will not, especially if you’re a nobody)
      • ryandrake 4mo ago
        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.
• MagicMoonlight 4mo ago
  [dead]
• bickov 4mo ago
  Banning the PRs is the easy part. The funny bit is that "understands their own code" is now a filter worth writing down.
• claud_ia 4mo ago
  [flagged]
• ThePhysicist 4mo ago
  Interesting that on one hand the valuation of these AI providers is based on the assumption that all code (and everything else producing digital artefacts) will be written using AI in the near future, on the other hand almost all popular open source projects fight to keep AI contributions out. Hard to reconcile. Personally I'm also experiencing a bit of AI hangover after using it a lot in my own open-source projects. I find it's a bit like taking drugs (not that I have much experience with that) in the sense that in the moment I'm using these tools I feel great and powerful, writing features in a span of hours that would've taken me weeks to write by hand. But inevitably some time later I will look at the code and notice all the subtle cracks and inconsistencies the tool introduced, and despair a bit at the mess. I now plan to use these tools less for extensive feature development and more for planning, debugging and narrow refactoring where I can put very strict guardrails on them. I'd still say it accelerates my work but not by a factor of 10, more like 1.5-3 (which is still a lot) given the care you need to ensure what is being built is actually good. For what I really like these tools is that I need less mental focus to do coding, but on the other hand I have this new kind of fatigue of being in a constant chat loop with a machine and trying to get it to do stuff based on natural language, never knowing how it will interpret what I write and wrote before. In that sense, these tools don't feel satisfying, it's like operating a machine where you try to push some buttons to get it to do something but the internal wiring changes all the time so you never know exactly what a given button combination will do and you have to figure it out by watching the machine and constantly adapting.
  • neonstatic 4mo ago
    > the moment I'm using these tools I feel great and powerful, writing features in a span of hours that would've taken me weeks to write by hand. But inevitably some time later I will look at the code and notice all the subtle cracks and inconsistencies the tool introduced, and despair a bit at the mess. Very relatable. I wasted 2 weeks of full time effort earlier this year building a helper library with Sonnet. It was the first (and the last) time I vibe coded something. Once I was satisfied with it, I began using the library and within 2 days I was certain it was all for nothing. I will never get those 2 weeks back, but a lesson has been learnt.
• HelloUsername 4mo ago
  Perhaps move comments to source posted yesterday? 30-jun-2026 "Changes to Our Contribution Policies" https://news.ycombinator.com/item?id=48733236 https://news.ycombinator.com/item?id=48733236 9 comments
• Aachen 4mo ago
  Actual source: https://godotengine.org/article/contribution-policy-2026/ https://godotengine.org/article/contribution-policy-2026/
• minraws 4mo ago
  As a former extensive Godot contributor(I haven't contributed much since post 4.1 era), I am sad to see people target a project like Godot with AI Slop PRs. I am with the maintainers on this one, I am not quite sure how they plan to filter out AI slop, but atleast all slop PRs should stop now, I am sad to not have the free time to contribute to the project or maybe just not enough energy. In generally, I am just sad that this is where the public contributions and open source has come down to, couldn't we all have been more fun working together, what makes someone think they can vibe code their way to a meaningful PR and not even mention that it's a vibe PR. Why does this PR appear to add any value, and if it does provide some insights into solving a problem, why do you expect it to be merged and reviewed? The best defense of these drive by vibe PRs can be I found a bug, tried to fix it, seems to work, here's my code, someone who has more time could take a look and see if it has any insights. Also only works on PRs that are specifically bug fixes or address some issue specifically. Not your omega 10K+ line feature commits... Why do some people feel compelled to make these PRs? I am genuinely curious, I don't hate these people but do these folks think that this is adding some value?
• throwfaraway135 4mo ago
  Wouldn't it make much more sense to just reject _low_ quality PR's? On an unrelated note, I lost all respect and eagerness to try it out after the drama.
  • koteelok 4mo ago
    No, it wouldn't. The goal of reviewing PRs is to mentor and find new maintainers who will eventually replace the current ones. You just can't expect someone who isn't willing enough to write one good PR to be willing to become a good maintainer.
    • throwfaraway135 4mo ago
      > write one good PR is about quality not AI which is exactly my point.
  • nkrisc 4mo ago
    They want people who will be around to maintain the features as well. There have been several areas of the project that have languished at times because no current maintainer had the capacity or familiarity to move it forward. Also, what drama?
    • throwfaraway135 4mo ago
      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.
      • nkrisc 4mo ago
        All I found is something to do with Discord. Been using Godot for years I have no idea what drama you’re talking about.
        • 4mo ago
• prymitive 4mo ago
  Silicon Valley is working round the clock to make bad behaviour as cheap and easy as possible, while taking all the profits. PR floods are probably the most innocent of this. Imagine if you want to send someone abusive text, previously you’d have to spend time and energy writing insults, now the machine can text or even phone someone on your behalf and harass them all day all night. Being a pest to the society was never as easy as right now.
• baq 4mo ago
  just when the models started to be actually good. these policies need quarterly revisions at the current dynamics.
  • duskdozer 4mo ago
    Assuming you're referring to the policies elsewhere that are overly permissive of model-generated code ;)
    • baq 4mo ago
      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.
  • marcosdumay 4mo ago
    Just 6 months before we get AGI!
• kriro 4mo ago
  Is there a list or overview of all open source projects that refuse to accept AI-code? It pops up every now and then but would be nice to have a good reference. Could also be interesting for quality analysis and so on in the future. I can fully understand the reasoning for it and I also think it's by and large a good idea because one of the cool things about open source projects is that they are traditionally good places for younger developers to get started or hop in and learn. There's a lot more to be learned from writing everything yourself and thinking through it.
  • nemomarx 4mo ago
    https://noai.starlightnet.work/list.html https://noai.starlightnet.work/list.html there's a few elsewhere in the comments here but I'm not sure how comprehensive any are
• flowerthoughts 4mo ago
  Is anyone using LLM on the other side, to vet incoming PRs for quality and whether it's worth reviewing?
  • treme 4mo ago
    most frontier labs have such AI-based triage process, it appears most opensource projects haven't figured how to do this.
• SubRadar 4mo ago
  [dead]
• cws_ai_buddy 4mo ago
  [flagged]
• timcobb 4mo ago
  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.
  • nemomarx 4mo ago
    [dead]
  • jillesvangurp 4mo ago
    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.
    • 4mo ago
• romaaeterna 4mo ago
  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.
  • anang 4mo ago
    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.
    • romaaeterna 4mo ago
      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.
• felix-the-cat 4mo ago
  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?
  • skydhash 4mo ago
    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.
• alienbaby 4mo ago
  For now, while it's simple enough to tell.
• maiybe 4mo ago
  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.
  • rschiavone 4mo ago
    This is exactly what will make Godot shine in 2 years while the rest of the world will be busy cleaning up inefficient code.
    • maiybe 4mo ago
      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.
    • deleted 4mo ago
• Benjamin_Dobell 4mo ago
  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 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.
  • zacharylee 4mo ago
    [flagged]
• strangescript 4mo ago
  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.
  • b40d-48b2-979e 4mo ago
    Any day now! It's going to become sentient and send us into the future! Just long enough for the IPO!
    • treme 4mo ago
      I don't understand how people can make such sarcastic remarks given AI progress in coding past 8 months
  • Strom 4mo ago
    They can always unban it later when we arrive at that reality.
• quinndupont 4mo ago
  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.
• gyosko 4mo ago
  FUCK AI. I'm tired of all the AI related bullshit we are living through.
• pineappletooth_ 4mo ago
  For people that don't get it just check this: https://github.com/godotengine/godot/pull/115280 https://github.com/godotengine/godot/pull/115280 https://github.com/godotengine/godot/pull/116410 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.
  • noio 4mo ago
    That is crazy. What is the actual motivation of that contributor?
    • Boxxed 4mo ago
      The first one was for a $4k bounty. The second one was for a university assignment.
  • cute_boi 4mo ago
    > 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?
    • shimman 4mo ago
      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.
    • spaceman_atlas 4mo ago
      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.
• simul007 4mo ago
  lol, they want to be old school
• bwfan123 4mo ago
  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.
• terekhindc 4mo ago
  [dead]
• 0xbadcafebee 4mo ago
  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.
  • bigstrat2003 4mo ago
    No we don't. It's a bad tool, and we do not need to just roll over and accept it as inevitable.
    • 0xbadcafebee 4mo ago
      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.
• peterbell_nyc 4mo ago
  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.
  • jplusequalt 4mo ago
    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.
• OldGreenYodaGPT 4mo ago
  will come back to bite them very soon
• adrianwitaszak 4mo ago
  [flagged]
• betorabinovich 4mo ago
  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.
• lobocinza 4mo ago
  Godot is a good engine but the devs are activists.
• zftnb666 4mo ago
  Open source projects now need an "AI-free" label. The 2020s are wild.
• ezgamer 4mo ago
  Why not use AI to review PRs?