RFC: Policy on bot/vibe-coded/stochastic/tainted/non-human contributions

[quinnyo]

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.md applies 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:

• No use of LLMs/chatbots/"AI" to contribute to (interact with) the community is acceptable.
• Communities are humans.
• This is a community.

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!

[ISSOtm]

We should definitely reject drive-by or purely bot-driven¹ 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 spam²) 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

1. Well, unsolicited, anyway: bots we enable ourselves, like Dependabot, are fine, since their contributions are opted into by maintainers. ↩

2. 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. ↩

[quinnyo]

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.md in relation to this repo being a central place to discuss (and implement) this.

Also, thanks @ISSOtm for the sensible words and the links &c.

[ISSOtm]

Here 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.)

[Rangi42]

Yes, 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 mistakes¹. 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

1. "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." ↩

[nitro2k01]

First 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.

[ISSOtm]

I'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 comment

[nitro2k01]

My 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.

[Rangi42]

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.

[pinobatch]

No 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)

[quinnyo]

Accepting 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.

[Rangi42]

If "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 obvious¹, 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

1. Or if it's not obvious, and some secretly-LLM-generated PR makes it past our human review, then mission accomplished. ↩

[nikku4211]

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.

[avivace]

I also agree https://github.com/torvalds/linux/blob/5d6919055dec134de3c40167a490f33c74c12581/Documentation/process/coding-assistants.rst is a good starting point . I've created the .github repo as well

[Rangi42]

This 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.

[ISSOtm]

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.