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

@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!

@vincent067

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.

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

@ISSOtm

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.

@avivace

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

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

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

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.

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

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.

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.

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)

@Rangi42

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.

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

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.

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

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.

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.

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.

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

Nevertheless, 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.

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

I mean, you don't have to wait, they are already here. I can point at some that I know, but I'm not sure what it'd bring to this discussion, especially since some are slop but some have been genuinely useful (there's room to quibble over how much exactly, but I have no interest in trying to argue something this subjective here). And most of us are still irritated that we feel screwed over, so I feel wary of witch-hunting or other harassment.

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 don't really buy that line of thought, because...

if forking projects was so easy, GitHub wouldn't be full of one-off forks that got one or two extra features before becoming abandoned. Maintainership is hard, and requires specific knowledge that's often very different from the skills involved in using said tool (you can use programming languages without ever thinking about a compiler query or LR(1) ambiguities!) and requires a lengthy ramp-up during which upstream (your competitors as far as the contributor pool goes) are keeping pace. Consider the activity on KeePassXC vs. ChiPass if you want a practical example.

How does this differ from simply saying LLM code is accepted? Who is it discouraging and how?

My own stance, as a maintainer of several of GBDev's major projects, is “I may accept LLM-assisted contributions, but also reserve the right to summarily reject anything that seems to be wasting my time if it quacks too much like AI¹, and in that eventuality I will also deny you the right to complain”. That may discourage slop-slingers, and if it doesn't, then it gives me license to waste as little time on them as possible.

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

I care about environmental issues, and yet I still take a plane to visit Sylvie every few months. Going across the entire Atlantic by sailboat is infeasible. (I can come up with plenty more examples of how many of the products we buy day-to-day rely on sweatshops, the point is that you and I do a lot of indirectly immoral things every day.) Yet we gotta live within this system; in other words, I'm choosing my battles, and I have come to the conclusion that AI is not one we can win anymore—look around you! see how useful it's made itself! look how it has achieved a threshold effect and is becoming mundane!—, so I have taken a few weeks to deal with the emotional pain and loss that this is the end of an era, but that I must now live within it.

I'm not ignoring any of those issues, but so what, should I just succumb to eco-anxiety? People still drive cars to meetings about planning better public transportation, and I don't believe that makes them hypocritical. I'm just doing the best I'm able to, man.

There is no existing way to ensure or verify that these contributions do not include stolen code, incompatible licensing, etc.

This ain't new. This already was a problem even before the advent of LLMs. So what? We have already been trusting contributors that they aren't submitting us code copy-pasted from some proprietary codebase. We're not expecting slop-slingers to actually perform any provenance checking, we're only explicitly disclaiming responsibility for having to do it ourselves. And if not the maintainers, who's left in a PR but the contributors?

We certainly can close contributions off that aren't vouched for, but when that would exclude people like you in the first place, I don't see how that would really do anything for you. Not to mention that several of the people that we would vouch for do use AI in various ways, which some of us deem acceptable and the rest of us don't. I mean, if there was consensus in the community this issue would already be closed, wouldn't it?

it was a wonderful example of open source and hobby communities at their best

I'll not go into any details here, but considering some of this community's history and bad reputation (ask anyone over in GB Studio's or GBDK's Discords if you'd like examples) I'm not agreeing with that evaluation. doing our best, sure; but “at their best” sounds far more rose-tinted than I'd (personally) agree with.

Either way, GBDev is going to remain about people having fun. I will pack up and retreat to my friend circle if I feel GBDev is no longer sparking joy, but it doesn't feel this way for me right now.

Why are we allowing this when it's so easy to say no?

I've found it harder and harder to say no, because I am feeling the effects of being left behind. You don't have to agree, in large part because our circumstances certainly differ; but please trust that it is with great pain that I am giving in, because the alternative (giving up programming entirely) gave me even more despair. I will not elaborate here because TMI.

Not because I judge LLM-assisted contributions as inherently lesser (a tasty sausage is very tasty even if it's made in a way I hate), but because I will invest the same order of magnitude of effort as what I perceive the contributor has. Hell, look at the length of that reply—if I had thought you had generated your reply with idk Mistral AI, then you would've just gotten a curt reply and then been shoved aside. And, yes, I type every single one of those em-dashes manually as — because my desktop's keymap has a combo for it, but not my laptop's. ↩

@dragonked2

Great RFC [...]
-@dragonked2

I don't think ads for people's AI tools should be allowed here.

An ad is an ad even if it's auto-generated. I'm going to hope that this was a genuine misstep, but consider this a warning that this kind of self-promotion is bad form, plus here and now is especially inappropriate.

You're also not exactly giving your camp an appealing or easy-to-defend look, either.

I don't think I could have changed the outcome but I want to explain why I stopped actively participating in this discussion, because I feel like I let you down. And I feel like I should make this sort of thing known in general.

I stopped because every time I posted in this thread I suddenly had various accounts of mine being attacked. Repeated attempts to gain control over a period of time following each post. The attacks appeared to be mostly semi-automated in the traditional sense.
I've been deliberately vague for reasons. I'm sure some people would like to ask for details, all I will say is that I have no doubt about what I've said here. I have complete confidence that I was being attacked in retaliation for essentially saying mean things about "AI".

Please understand that I'm posting this at risk to myself and crucially: I am in no way accusing anybody actually involved here (if you posted genuine comments above you count as "actually involved") of doing this.

Since we based the GBDev AI policy explicitly on the Linux one, I think it's worth noting that the kernel maintainers "reached consensus to deprecate the Assisted-by tag" (https://www.phoronix.com/news/Linux-Dropping-Assisted-By-Req).

A rationale from this July (https://www.phoronix.com/news/Linux-AI-Attribution-Again):

We've had this requirement in place in the Documentation for several months, but it's becoming clear that the signal to noise ratio from this is quite low.

1/ It's not universally followed. While many people do try to attribute the LLMs in good faith, not everyone does for various reasons.

2/ It basically serves as free advertising for proprietary LLM companies.

3/ It's not clear why we want to collect this info in the first place.

Given that the data this provides is flawed at best and is being collected for a purpose that isn't clear, let's just kill the requirement for these tags from the kernel at large.

GBDev has only recently added the requirement, and we haven't seen many Assisted-by contributions across projects yet (awesome-gbdev, pandocs, gb-asm-tutorial, rgbds, etc). But after we've had more of them, some months later in 2027, it may be worth reflecting on how and if the Assisted-by tag has been useful. (For example, whether the information about precisely which tool+model was used has been relevant for any maintenance/review work, or whether the AI-assisted nature of specific commits has been helpful to anyone checking git blame history.)

We have too few contributions to GBDev itself for the ratio to be meaningful. Nonetheless, my own experience is that LLM-generated commits are bad—just more quickly generated, so they're like the hot glue and prayers that we've been memeing on Game Freak about for decades now—so I want to keep giving them extra scrutiny, or when they're already done, know that it's much more likely that any mistakes I spot in there are actual mistakes and not the author having some insight that I should dig into.

And if the signal-to-noise ratio remains too small even then because people lie, then I will not want to continue contributing any more, plainly enough.

I see the point about not giving free advertising by listing a specific model, but I think LLM use should always be disclosed and keeping a record of that in commit messages in some form is a good way to be transparent.

Navigation Menu

Repository navigation

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

42 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

ISSOtm commented on May 11, 2026

Footnotes

quinnyo commented on May 11, 2026

ISSOtm commented on May 11, 2026

Rangi42 commented on May 11, 2026

Footnotes

nitro2k01 commented on May 11, 2026

ISSOtm commented on May 11, 2026

nitro2k01 commented on May 11, 2026

Rangi42 commented on May 11, 2026

pinobatch commented on May 11, 2026

quinnyo commented on May 11, 2026

Rangi42 commented on May 11, 2026

Footnotes

nikku4211 commented on May 12, 2026

avivace commented on May 14, 2026

Rangi42 commented on May 15, 2026

ISSOtm commented on May 15, 2026

42 remaining items

avivace commented on Oct 2, 2026

ghostsoft commented on Oct 9, 2026

Trekintosh commented on Oct 9, 2026

zlfn commented on Oct 10, 2026

ghostsoft commented on Oct 10, 2026

nitro2k01 commented on Oct 10, 2026

ISSOtm commented on Oct 11, 2026

Footnotes

dragonked2 commented on Oct 11, 2026

dogboydog commented on Oct 11, 2026

dragonked2 commented on Oct 11, 2026

ISSOtm commented on Oct 11, 2026

quinnyo commented on Oct 12, 2026

Rangi42 commented on Oct 16, 2026

ISSOtm commented on Oct 16, 2026

dogboydog commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions