Repository navigation
RFC: Policy on bot/vibe-coded/stochastic/tainted/non-human contributions #103
Description
Activity
We should definitely reject drive-by or purely bot-driven1 interactions, yeah. I think it's fair to require a human to sign off on every change, if only to preserve the symmetry of the author and the reviewer's time investment, and also accountability.
I also agree with the “communities are humans” argument, and believe that “contributor poker” is a real thing that matters.
Should we disallow any use of LLMs? I don't know, but I feel like that may not be a good idea because we can only rely on self-reporting, and blanket bans have led to people changing what they state instead of what they actually do.
In summary, my personal vote goes to preferably requiring human sign-off on every interaction (and treating those that aren't as spam2) and disclosure of anything committed to the repo that originated at least in part from a LLM (both code and docs). If this turns out to be unenforceable or undesired, then my second preference goes to banning LLM usage entirely.
I also feel that maintainers should be allowed to override parts of this policy on their own repos, depending on circumstances, since they're those who ultimately bear the consequences.
Also, this feels more of a Code of Conduct issue rather that contributing guidelines, since the latter are generally more technically oriented.
Footnotes
-
Well, unsolicited, anyway: bots we enable ourselves, like Dependabot, are fine, since their contributions are opted into by maintainers. ↩
-
I have intentionally interacted in good faith with one such “slop” PR (docs: Add comprehensive README GBEmulatorShootout#77); this was intended as a personal experiment to see how the bot would reply back (@vincent067 never did lol), and because the PR was a good opportunity to dump some of my thoughts on the subject in a place we'd be able to easily reference again later. ↩
Reacted by Rangi and JeahnohReacted by Quinn-
I'm not advocating for heavy policing/bans here so much as making the policy (or code of conduct, as you say) unambiguous and visible.
I'd support implementing enforcement measures when and where they're reasonable and effective, but I have a pretty high bar for that. Making it harder for humans to be involved is an anti-goal.
I certainly don't want people hurling accusations around, for one thing.I considered calling it a 'policy on human contribut{ions,ors}' but it seemed a bit too confusing. My point being that I really mostly care about the message being sent to humans. I am under no illusions about being able to stop non-human contributions entirely, but I don't want to tell humans that they shouldn't bother.
Yep, agree on "Code of Conduct" -- I only mentioned the
contributing.mdin relation to this repo being a central place to discuss (and implement) this.Also, thanks @ISSOtm for the sensible words and the links &c.
Reacted by Eldred Habert, Nikku4211 and JeahnohReacted by Eldred HabertHere is some precedent we can try drawing from: the Linux kernel policy on coding assistants. (This only covers code contributions, so that'd go into
CONTRIBUTING.md, but the ideas can be expanded to all “meta” interactions.)As for the place to put this issue, GitHub's docs mention that “community health files” can be pulled by default from https://github.com/gbdev/.github. cc @avivace for creating that repo and moving this issue there? (We can think of how to deal with the coexistence of that and https://github.com/gbdev/meta afterwards.)
Reacted by RangiYes, GBDev is a community of humans. And when those humans offer contributions, they're accepting responsibility for those contributions. This has always been the case -- "autocorrect did it" is not an excuse for misspellings, "my IDE's refactor tool messed up" is not an excuse for broken code, and so on.
Same goes for LLMs. They're a tool that people can use in many degrees:
- Researching information as you would with a search engine, before writing contributions entirely by hand
- IDE-based "fancy autocomplete/spellcheck" (which unlike the non-LLM versions of those tools, can take context and comments into account)
- Automated code review and testing, like a "fancy rubber duck", checking your own contribution before submitting it for human community review
- Automated code generation, like copy+pasting from Stack Overflow, still doing the same sort of thoughtful editing you'd do when borrowing code from other humans
- Agent-based development, giving the LLM more control over the whole write→review→test→debug→PR workflow (the kind of use that with little-to-no human input gets called "vibe coding")
Personally I think that Linus Torvalds' policy for Linux contributions makes the most sense here. Humans are responsible for what they do, and invoking an "agent" program doesn't lose that responsibility. The fact that an AI agent can submit large amounts of "slop" faster than a human, and is more prone to doing so, doesn't make it okay, it just means it's even more important for the human to participate in what their AI agent is doing.
We can't realistically say "No use of LLMs ... is acceptable", because no use short of a PR actually signed by Claude/Copilot is provably LLM-based. I think what we really want is high-quality contributions (no matter what tools the contributor used) -- or at least sincere ones, by inexperienced people who can learn from mistakes1. Spamming slop is bad, period, not just because it came from an LLM.
Edit: Okay, glad we agree on Linux's policy being a good model to follow. :)
Footnotes
-
"Contributor Poker and Zig's AI Ban" justifies this nicely: "just like people say about the actual card game, “you play the person, not the cards”. In contributor poker, you bet on the contributor, not on the contents of their first PR." ↩
Reacted by JeahnohReacted by JeahnohFirst for full disclosure. I've warmed up a bit to using LLMs to assist with coding for my personal projects, either for the whole project, or aspects of the project that I don't enjoy doing. Most of this has so far been things that either are not made public yet, or are purely personal tools that will never be made public. The reality for me is that a lot of times I don't have the time or mental bandwidth to do projects I would like to do, in part due to health reasons. So the choice for me has been to end up never doing the project due to mental fatigue, or take the oppoortunity that has presented itself in recent years. For my own use, I still take try to take an active role in the design process, and I like to think of it more like a form of pair programming.
With all of that said, 1) a lot of people would not use these tools in the same way as I would, which is to say that these people use them more lazily, and 2) I might use these tools more extensively in personal projects than I might be comfortable with in a communal project like GB Dev. And 3) when these projects do go public I plan on being very transparent about what parts were done with AI assistance.
So, to my point:
I think a blanket ban is far too restrictive, and also unrealistic. (While writing the prelude, other replies were made, addressing the same points.) People can just lie about where their contribution comes from. It's better to encourage people to be honest. People can use tools to varying degrees. A 100% automated contribution is not the same as someone, say, trying to clean up their grammar, or using AI for research before writing a contribution by hand.
The main focus should be on preventing mass-produced, low quality contributions, colloquially called slop. I'm reminded of the bot policy of one of EFNet's nodes, which goes something like: "We don't allow bots. (But if we don't know it's a bot and it's not causing any trouble for the server we don't care.)" I'd advocate a similar policy here. Require people to sign off on their contributions, and if it's clear that you submitted something that's generated and you didn't even look at it, you can go kick rocks.
Reacted by Rangi, DelayRGC, Eduardo Cruells and JeahnohI'd like “if it's clear that you submitted something that's generated and you didn't even look at it” to be treated as a form of spam, i.e. not just dismissed but potentially earning a ban (according to the same escalation procedures as everything else).
As for the broader policies we want to promote, I think that's part of a larger endeavour to write a CoC (or similar); but so that this issue currently remains focused on “how should we treat bot contribs”, and in particular so that people can keep voicing their opinions even if they come to this thread later, I'd like to tighten the leash on this discussion. Thus I'm going to mark Rangi's above comment as off-topic, despite it being a good insight that will be pertinent to the broader CoC creation process.[EDIT] She has deleted that commentReacted by JeahnohMy suggestion for wording the policy:
Contributions submitted to this project should primarily be the personal work of the submitter. Contributions which consist (or are suspected to consist) of material completely or mostly generated by an AI tool are likely to be rejected. If an AI tool was used in the process of creating the contribution, the contributor must disclose which tool was used, and for what purpose. A contributor must sign-off any contribution to indicate that they've manually reviewed the contents in full.
I'm not necessarily saying we should do this, but I think it's worth considering the possibility:
We're a small community of peers working on a multitude of projects just for the fun of it. We're not a large organization that has to deal with regulations and lawsuits and customers. So maybe our policy can sound more casual, and not like a legalese document. (The purpose of legalese is for professional lawyers to express precisely what they need to, much like code, but that doesn't mean anything that sounds formal and legal-ish is doing something precise -- especially with all that "primarily"/"mostly"/"likely" wiggle room.) So we may as well just say what we do and don't want; something like:
Contributions to GBDev projects are welcome, but should be your own work. Anything you submit is your responsibility, even if you used AI or other tool assistance to help create it, but you should explain which tools you used and what they did (like citing sources for written work). If you're submitting a large amount of machine-generated code or documentation that you haven't personally read, understood, and verified, that's probably going to be rejected as spam.
Reacted by Eldred HabertNo use of LLMs/chatbots/"AI" to contribute to (interact with) the community is acceptable.
We'll have to be careful when describing this so that the IRC bridge does not confuse newcomers.As for LLM-generated code in games and the libraries they use: itch.io requires disclosure if anything in the download was made with a generative system. I doubt this will affect the code part of a Game Boy game unless, say, a GBDK or GB Studio maintainer adds LLM-generated code to the library. I, for one, don't plan to use LLM-generated code for anything in my own Game Boy projects, such as the controller reading, random number generation, tile data decompression, or text drawing code that I recommend to newcomers.
A ban might affect build tooling, however. Should we refrain from recommending that people write asset converters in Python, on grounds that the Python language's reference interpreter (CPython) has accepted LLM-generated contributions after version 3.14.0a4? (Source: https://codeberg.org/small-hack/open-slopware#programming-languages)
Reacted by Nikku4211Accepting fake art compromises the genuine stuff that gbdev has been nurturing.
This is why I chose the word 'acceptable'. We should not accept it. I do not accept it. Having a policy to accept it conditionally is having a policy to accept it.
I'm worried about the humans in the world, not the stinking worthless chatboxes. Yes, that does necessarily include some humans with ideas that I think are bad and I'm OK with that. I'm worried about them, too, and this is not a pattern unique to the "AI" thing.
I don't want to turn away people genuinely interested in contributing, even if they think AI is a good way to do that.
But turning away someone who is keen to offer their unique perspective on the world? Someone with an actual point of view that's no doubt increasingly finding less and less outlets for it? Turning them away is a tragedy.You have to be selective -- this is Contributor Poker. Why encourage the cheater to sit at the table?
// The term "cheater" here is strictly on the poker side of the metaphor.
If you're worried about liars misrepresenting the source of the material they're submitting, they're going to do that even if they're supposedly bound to pinky promise to Linus Torvalds in the sky (or equivalent). If people are going to lie about using the thing at all, they'll also lie about how much they used it. They obviously get something out of it, more glory (or whatever) for them if they claim to have done more work, I guess?
To clarify, I think there's some merit, and more importantly, little choice for the Linux Kernel adopting the policy they did. I don't see that it is a particularly portable policy, however. Linux is a singular (unique) project.
Contributions submitted to this project should primarily be [...]
Contributions to GBDev projects are welcome, but should be your own work.
I don't see much point in having this as a gentle suggestion. This is overall feedback that applies to both of the suggestions above, but for one specific point: the use of "should". It reads as completely optional. Which, to be clear, reads as an endorsement for the people that need to be told "how much bullshit is acceptable".
If the policy doesn't send a clear message, it's worse than no policy, regardless of the particular balance of opinions represented by it.I don't disagree with @Rangi42 about the tone and avoiding trying to sound like lawyers. I think "just say what we do and don't want" is the right idea. But you can be firm and speak plainly at same time.
// Yes, everything is fuzzy and analog. Yes, you can use an LLM to search the web, it probably won't kill me and Linus Torvalds in the sky knows you can't use a search engine to do that anymore. I don't see having strong principles as being mutually exclusive with being reasonable/kind/lenient/friendly, although it can be challenging, ask me how I etc.
// None of this is meant to be hostile to anyone here. I have no ill-will but I do have a long list of times I upset people in surprising (to me) ways. It's one of my superpowers, please forgive me.
Reacted by Nikku4211, dogboydog and ghostsoftIf "should" sounds too optional, "must" is also fine (just let's not capitalize it like RFCs do :P ).
GBDev projects: pandocs, rgbds, gb-asm-tutorial, hardware.inc, rgbds-live, gb-emulator-shootout, gb-opcodes table, etc. Code and documentation, not visual/audio art -- things where human-reviewed, human-tested, human-edited LLM generations are already being useful, as projects like Linux and CPython recognize. (LLM generations also make it possible to create useless contributions that lack any human oversight, hence the need for a policy around that.)
So I don't think that distaste for "fake art" is relevant to what this policy would be trying to do. (Sure, spammers can claim they hand-wrote everything, but their careless nature is still obvious1, like with gbdev/GBEmulatorShootout#77. The point of a policy is to make the correct actions clear to well-intentioned contributors, and give GBDev grounds to ignore/close/delete/ban bad-intentioned ones.)
Footnotes
-
Or if it's not obvious, and some secretly-LLM-generated PR makes it past our human review, then mission accomplished. ↩
-
I personally agree behind the sentiment of a blanket ban on LLM slop as someone who personally refuses to use that kind of stuff. However, I do know that's unrealistic due to just how prevalent it is now. So I think putting responsibility on contributors themselves is at least better than nothing, even if I'm one of the few people who have still not warmed up to that tech and don't intend to.
People who lie about what they do and are clearly trying to piss everyone off in bad-faith even if just to prove a petty, pedantic point are people you don't want anyway. So maybe let's not be concerned about their feelings as one individual over the experience everyone else will have as a result of this.
I am aware that LLMs didn't create every issue, but they do make plenty of them worse. There's always been bad code, there's always been badly-written code, there's always been newbies copying code from other open-source projects, or even people stealing code from proprietary projects. But now it's very easy to steal code without even realising it.It's very important that you know what you are doing when learning how to code in general. That's kind of why I'm still oldschool, despite being in my early 20s.
Reacted by dogboydog and QuinnI also agree https://github.com/torvalds/linux/blob/5d6919055dec134de3c40167a490f33c74c12581/Documentation/process/coding-assistants.rst is a good starting point . I've created the
.githubrepo as wellReacted by Rangi and Eldred HabertThis person's professional AI policy for their own dev team may also be a good example: https://brianmeeker.me/2026/05/14/have-a-coherent-ai-policy/ An excerpt from the code-specific section:
Any code generated by AI tools is your code. It does not matter how much of your PR that AI wrote for you, you are expected to understand what the code does. It is expected that the code fits into our existing patterns. Our AGENTS.md file should help with this, but does not guarantee anything. You are responsible for making sure the code you submit for review is up to snuff.
Do not put undue burden on reviewers. We all submit questionable PRs at times. This could be because of time constraints around a incident level production bug or because we’re in new design space. It is still the responsibility of the PR submitter to call this out. Using AI tools is not an excuse to call out all of your PRs as questionable.
Humans ultimately make our architecture decisions, not AI. When there is a choice between accepting code that makes it easier for machines vs. code that is easier for humans, we prefer humans. If AI tooling is constantly spitting out code that does not conform to our coding standards, the AI tooling is what needs to change, possibly by improving our AGENTS.md file.
I do not want to commit any LLM-specific documentation or tooling to the repos. Everything should be accessible to humans as much as anything else, and I view the inability of those systems to parse human-intended information (which is their entire premise in the first place) as limitations for them to fix, not me to work around. I'm not going to maintain workarounds for third-party technology that I feel both very iffy about and is a constantly-moving target. I'm open to reconsidering this, but not before a few years at the very least.
Reacted by dogboydog33 remaining items
I have nothing to add that hasn't already been said better about the lack of quality, the massive ethical problems and the absurdity of accepting AI "vibe-coding" into a niche hobby like this but I'll leave my voice here anyway saying that I find it completely unacceptable and existentially upsetting. Full ban.
Reacted by Nikku4211, dogboydog, Quinn, Coffee "Valen" Bat, braids and Tachytaeniushttps://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html presents some recommendations in the optics of furthering FOSS; we have also the aspect of this being a hobby, but I think that this does not affect the recommendations beyond a surface level. At this point, I feel like the organisation-level policy should mandate LLM usage disclosure and set up whatever processes are necessary for prompt etc. archival; but that it should leave usage bans to the maintainers, letting them weigh their own preferences, availability, and traffic on a given project.
Jumping in to say I would be disappointed if gbdev embraces LLM contributions. SFC put that statement out and it gets extremely bad after the first point. LLMs are black boxes that are the opposite of FOSS and are generating code with stolen, scraped code from people like me that were never given the option to opt-in to having our code be included. Embracing these theft machines would be a huge disappointment from a community that I have directed people to in the past as an example of an excellent Game Boy-focused dev community. If a ban on LLM usage isn't enforced, then it's akin to permitting plagiarism.
Reacted by ghostsoft, dogboydog, Nikku4211 and QuinnAnother policy that can be used as inspiration: https://nlnetlabs.nl/llm-policy/
Reacted by dogboydogAnd someone's crude back-of-the-envelope reality check on how much a full AI ban affected Flathub: https://geopjr.dev/blog/democratizing-abandonware
Reacted by dogboydogIf we're posting more relevant policies, Codeberg just voted on and wrote a fantastic article about disallowing "vibe-coding"/LLM generated projects https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html
Another relevant policy as "a small project with a single maintainer", which describes some projects under the gbdev umbrella: https://github.com/grunt-lucas/porytiles/blob/develop/AI_POLICY.md
Here's a fun one: hawkw/mycelium@b77e854
Should we consider this closed by 6f9db06? I think the current position is quite clear, and what remains is possibly revisiting it later, but there's little point in keeping this issue open for that.
This space is meant to collect and welcome subsequent observations/comments/opinions on the topic and it's linked/described as such even in the AI Policy we published, which mentions this RFC as open as the policy is a living document.
Reacted by Eldred Habert and QuinnThis being open serves as a nice reminder of how the massive amount of negative feedback got ignored in favor of a toothless "both sides" policy that ignores every problem brought up here and all the support for a stronger policy.
This was such a wonderful hobby but now I don't think I can ever trust tools like RGBDS again due to the uncertainty introduced by this lack of a policy.
Reacted by EeeRika-1005HA, Trekintosh and MaffiNevertheless, gbdev acknowledges that these practices are already in use and likely here to stay.
(from the policy update commit)Oh I love when something sucks and we just accept it instead of doing things we actually have the power to do to fight against it. This is great. Acknowledging that and forbidding its usage anyways are not mutually exclusive.
Reacted by C.Hall and MaffiThis being open serves as a nice reminder of how the massive amount of negative feedback got ignored in favor of a toothless "both sides" policy that ignores every problem brought up here and all the support for a stronger policy.
This was such a wonderful hobby but now I don't think I can ever trust tools like RGBDS again due to the uncertainty introduced by this lack of a policy.
I think an org-wide policy shouldn’t be overly prescriptive, and that discretion should be left to the maintainers of individual projects wherever possible.
If you don’t want this kind of AI policy, you can simply fork the project and maintain it yourself. That’s what open source is about.
I realize my previous comment doesn't add much to the conversation so in order to hopefully foster more discussion around this I present my issues with the policy in plain language:
LLM-assisted contributions are accepted but discouraged
What does discouraging do in this case? How does this differ from simply saying LLM code is accepted? Who is it discouraging and how? The second part of this sentence provides nothing of value and it comes across as "we'll accept it but we'll turn our noses up" which pleases no one on either side of the issue.
gbdev as a community does not endorse or recommend the use of generative AI assistants for software development, as it raises multiple concerns about ethics, legality, copyright, etc. Nevertheless, gbdev acknowledges that these practices are already in use and likely here to stay. Rather than banning their use, the project chooses to place responsibility on contributors
Presenting a lot of the heavy issues so plainly and then not taking responsibility for it is a terrible look. If you cared about the ethical and legal issues you would not be okay with this, so the sentence effectively says "we see the issues but choose to ignore them."
All contributions MUST comply with the licensing terms of the project you are contributing to. Verify that any AI-generated content does not introduce incompatible or unclear licensing. Contributors are responsible for ensuring the contribution is clean.
This along with the previous mentions of "placing responsibility on contributors" is the real issue of this policy as it writes off the burden of responsibility for the policy itself effectively making it a pointless document, as well as asking the impossible. These LLMs are not built in a way where it's possible to verify if the code is "clean" or stolen, they are machines built on massive theft and it's foolish to believe you can simply prompt it to go "claude pinky promise there's no stolen code please :)" and get a clean result. There is no existing way to ensure or verify that these contributions do not include stolen code, incompatible licensing, etc. and saying that the policy does not take a stance on this and asks the contributor to "verify" it is a magical non-solution to absolve everyone of responsibility. I understand that trust is important in open source development but this is unrealistic to the point of parody.
It's not possible to "both-sides" an issue like this. You either accept the ethical, legal, environmental and human costs of this and the effects it will have on the hobby, the community and the software or you don't. The current policy tries to feign a moral stance while accepting LLM generated code and it's not working.
Now, to get a bit emotional, gbdev was something I was intensely fond of and often praised and shared with friends both devs and non-devs alike, it was a wonderful example of open source and hobby communities at their best with passionate people, incredible tools and so many resources. A pure hobby that people do for fun and not work, it's the last place I expected to see AI worm its way into. Seeing the floodgates opened the way this policy provides genuinely breaks my heart. Why are we allowing this when it's so easy to say no?
Who is it discouraging and how?
From my understanding, the discretion of the maintainers. This is detailed in the next paragraph:
Even where a project's policy allows AI-assisted contributions, an individual maintainer may still decline to review a specific PR on that basis, at their discretion.
Not every contribution will be accepted, and in particular not every AI assisted contribution will be accepted. If it has too much of an AI smell, maintainers are free to just say no thanks. In fact, discouraged in this case is probably meant to say that "no" is the default position, while leaving the door a little open. This is substantially different from just saying yes. (Substantially in the sense of which contributions would be rejected in either case.)
I would say, wait until there are AI contributions (confirmed or suspected) and see how they're handled in practice.
Edit by @avivace
This is an open RFC on adopting an AI policy across gbdev projects. We'd like to hear from the community.
This covers all types of interactions (code, docs, issues, reviews, discussions) and all levels of AI involvement - from fully bot-generated contributions, to AI-assisted work, to using LLMs/copilots as a drafting or editing aid. If you have thoughts on where the line should be drawn (or whether there should be one), please share them.
Original body follows:
// I'm putting this in this repo because it's the de facto gbdev "policy" repo -- in essence: because
contributing.mdapplies to all gbdev repos/projects.// I want to spend zero time having to think about this, let alone hours burning out trying to (re)write words that people (mis)understand. I'm willing to argue about it if anything reasonable comes up, but I'm not (going to survive) writing an essay upfront.
Why have a policy?
It sends a message about the type of community this is. Sending a clear message enables people to judge if this is a safe place that welcomes them or not. Bots will, of course, be unaffected.
My idea of an acceptable policy would cover the following points:
I'm willing to negotiate on this, but not really.
gbdev/gb-asm-tutorial#187, gbdev/gb-asm-tutorial#188
Have a look at how productive these guys are on their hundreds of forks they just started contributing to in seconds. Amazing!