Add AI contributions policy - #12630

This is a draft, you're free to propose changes to it.

i cant get the test suite to work fully due to missing dependencies or whatever, so it's gonna take me a bit of time to get everything to pass

also i didnt expect to have to modify other files, so that's why it failed the first time

...not sure what's causing CI to fail

I generally agree with the proposed text, although I'm open to suggestions for adjustments. Fish is GPL-2.0-licensed, so we would want a policy which is compatible with that. @cyrneko has already engaged in discussion regarding LLM usage for fish (#12526), so I think she will be able to indicate whether she wants to make the policy text available under fish's licensing terms.

not sure what's causing CI to fail

I think these are non-deterministic failures unrelated to this PR.

Oh, yes technically the document this was ripped from (CONTRIBUTING.md from wafrn) is AGPLv3 licensed, but as a representative of that project it is perfectly fine to use and relicense here under the regular GPL.

Frankly, we (as in, wafrn, where this document came from) should probably outline that documentation and such aren't under a software license and instead some kind of CC license.

If fish was GPLv3-licensed, we could include AGPLv3 code, since these two licenses explicitly allow including work licensed under the other. But for GPLv2, this is not the case, which is why I brought it up. I agree that other licenses make more sense for documentation and the like. @faho, you have also commented on license issues before, so maybe you want to weigh in on this.

For the record, apart from one line that wasn't copied into this document, the CONTRIBUTING.md from Wafrn was entirely written by me, and as such I give permission for it to be used under a regular GPL license as I am the copyright holder to that file.

As such, if you want to use it verbatim or modify it under the terms of your license, I give you permission to do so.

Vibecoded slop is obviously bad and we should ban it, but I think a blanket ban on all forms goes too far. e.g. "No copilot" is unrealistic, I'll often use an agent as a debugging assistant, etc. I think this policy will make it more difficult to attract quality contributors and contributions.

If we must say anything here I'd rather it be similar to the Ghosttty policy that @krobelus shared, maybe striking the last paragraph ("AI is Welcome Here").

think a blanket ban on all forms goes too far. e.g. "No copilot" is unrealistic

I would actually prefer that and think it is entirely doable. Of course you won't manage to get all bad actors who lie about it to identify themselves, but that's fine.

There are enough ethical concerns about LLMs that I would like a blanket ban.

I think this policy will make it more difficult to attract quality contributors and contributions.

So far, most contributions I've seen that included AI have been worse than average, and more annoying to review because they look more plausible than random garbage. I find that a massive drain on my already affected morale.

Especially the "good first issue" label has attracted a ton of slop that's easier to deal with if you can just explain "no AI".

There are a lot of reasons on why we'd want to act agains AI, this is a first good source https://github.com/Vxrpenter/AIMania/blob/main/WHY.md

I don't think this is unrealistic at all, there are a bunch of projects that are doing just fine without AI (https://noai.starlightnet.work/).

"No copilot" is unrealistic

People have developed software, including fish, for decades without it, so I don't see what's unrealistic about continuing to do so.

I think this policy will make it more difficult to attract quality contributors and contributions.

It's plausible that there might be people who would make high quality contributions using LLMs but would not want to do so if we ban LLM usage. But there's also the other side of this, people who don't want to use or contribute to projects that allow LLM usage. So far, I've mostly seen people of the latter kind in the context of fish. Personally, I don't want to contribute to projects which are fine with LLM usage. There are many reasons for that, and they have been brought up before, so I won't list them all again here. What surprises me is that as far as I'm aware, none of the ethical, legal, and deskilling issues have been addressed by proponents of allowing at least some LLM usage. Why is that? Do you think the observations are incorrect, or do you think they don't matter enough to refrain from using LLMs?

I'd be OK with a policy like Zig's: no AI-generated issues, patches/PRs, or comments (add artwork). These impose a real burden on the project and its maintainers.

But my read of the proposed policy is that it would also ban AI for tasks like navigating the code base, diagnosing bugs, explaining code, searching documentation, etc. This sort of usage does not burden the project. Nobody should feel they are violating our trust for asking ChatGPT what some fish script does before opening a PR.

Most of the projects on @tasiaiso 's list appear to draw that same distinction. Their concern is inclusion of AI output, not AI usage in general. If we can agree on that distinction (banning output but not usage) then I can get on board.

What surprises me is that as far as I'm aware, none of the ethical, legal, and deskilling issues have been addressed by proponents of allowing at least some LLM usage. Why is that?

I personally don't view using ChatGPT as inherently unethical. That said, the focus ought to be the health of the fish-shell project and its maintainers, not an ideological debate.

I'd be OK with a policy like Zig's: no AI-generated issues, patches/PRs, or comments (add artwork). These impose a real burden on the project and its maintainers.

The Zig policy would also be acceptable to me. But the way I read it it is "AI doesn't write for us". That means no AI output in pull requests (including the copilot reviews that are a button away on github), code (including tests) and patches (including commit messages featuring AI explanations).

We have had all of those things, sometimes by a maintainer.

The way I read that policy and would like it to be interpreted, that would have to stop.

Given that it describes itself as a "Strict No LLM / No AI Policy", that's probably in-line with the spirit of the policy.

But my read of the proposed policy is that it would also ban AI for tasks like navigating the code base, diagnosing bugs, explaining code, searching documentation, etc.

I'd like to have a second opinion from the author @cyrneko, but i don't read it that way. It only applies to contributions, therefore explaining the codebase for you only isnt explicitly prohibited by the policy. Explaining the codebase and committing the text to it is though.

I did write it with the intention of "if you contribute, don't use AI in your contribution", though perhaps we could be clearer. The end-goal of the document was to prevent committing AI-generated code, as well as Issues/PR comments.

I also think that a policy along the lines of Zig's would be acceptable, and it seems that the intention of the proposal here is similar in nature. I like being explicit about specific types of uses we don't want, as done in Zig's policy, to remove the need to speculate on what exactly is meant by the policy.

Alongside stating rules for contribution, we should also decide what to do when they are violated, especially for cases that aren't entirely clear. For clear cases, I think closing with a link to the policy would be sufficient. What do you think would be the best reaction to suspected violations?

All right, sounds like we're in agreement. No AI-written contributions including code, issues, comments, artwork. Please adjust the PR to focus on AI-written output and we're good to go.

Alongside stating rules for contribution, we should also decide what to do when they are violated, especially for cases that aren't entirely clear. For clear cases, I think closing with a link to the policy would be sufficient. What do you think would be the best reaction to suspected violations?

Yes a quick close with a link to the policy sounds right to me. Repeat offenders get banned.

Let's wait and see what contribution policy the Rust Project adopts: rust-lang/rfcs#3950.

Please adjust the PR to focus on AI-written output and we're good to go.

Does it not already? I seem to be missing something here.

Since fish-shell is licensed under GPLv2 and GNU AGPL isn't compatible with GPLv2, this seems problematic.

...if you want to use it verbatim or modify it under the terms of your license, I give you permission to do so.

After contributions in the first sentence, i could add "(in issues, pull requests, discussions and the wiki)"

Before the last paragraph i could add "Usage of AI for personal purposes (explaining the codebase, searching through the documentation, working on fish without submitting a pull request, etc), as this policy doesn't apply there, is allowed. "

Also, I'd like to state that if we did disallow use of AI for personal purposes, that'd make fish non-free software as it restricts how users can use the software, which isn't my goal at all.

After contributions in the first sentence, i could add "(in issues, pull requests, discussions and the wiki)"

I think changing the first two paragraphs to this is clearer:

We do not accept contributions that had Artificial Intelligence, specifically
Large Language Models or Image Diffusion Models, involved in any step.
This includes, but isn't limited to GitHub Copilot, Zed AI, Cursor.dev's AI features and other "Coding Assistants",
as well as full-on code generation through the likes of GitHub Copilot, ChatGPT and others.
We ask contributors to refrain from using such tools to make contributions, including pull requests, issues, discussions, and the wiki.

We could also drop the , specifically Large Language Models or Image Diffusion Models, , unless you think there is a good reason to list specific technologies on which generative models are based.

Before the last paragraph i could add "Usage of AI for personal purposes (explaining the codebase, searching through the documentation, working on fish without submitting a pull request, etc), as this policy doesn't apply there, is allowed. "

Also, I'd like to state that if we did disallow use of AI for personal purposes, that'd make fish non-free software as it restricts how users can use the software, which isn't my goal at all.

I agree that it does not make sense to put restrictions on LLM usage for local tasks that don't affect other people involved with fish, i.e. things other than contributions, into our policy. If we're already explicitly saying that LLM contributions are not welcome, I don't think it is useful to tell people about other uses of LLMs which don't affect us being "allowed". We're in no position to allow or forbid LLM usage that has no effects on us other than the general population-wide externalities of LLMs, so I don't see a reason to explicitly allow such uses in our policy.

Regarding the positioning of the section in CONTRIBUTING.rst, I think we probably want to feature the policy more prominently, maybe before the Mailing List section, instead of having it at the very end of the file.

Let's wait and see what contribution policy the Rust Project adopts: rust-lang/rfcs#3950.

Why? The proposed policy there seems quite different from what we've discussed here. The Rust RFC seems to be about only banning unsupervised LLM usage.

The Rust RFC appears more practical than the policy proposed in this PR. A blanket prohibition on AI involvement at any stage is not realistic; it would, for example, also rule out translation tools used by non-native English speakers, spell-checking tools, or even search engines.

This includes products such as GitHub Copilot, Zed AI, Cursor.dev's AI features, other coding assistants, and ChatGPT.

I'd specifically mention Claude Code just because it is so popular right now.

allow existing maintainers to be exempt from this policy in contributing code directly

That would create a two tier system where an inside group is allowed to use something but outsiders are not. IMO that in itself is unwelcoming to new contributors and reason enough not to make such an exception.

I’m not really seeing why that would be unwelcoming. Open source projects already run on different levels of trust: maintainers can merge directly, make release decisions and are trusted with responsibilities that new contributors are not. Letting maintainers use their own judgment for direct commits seems pretty consistent with that.

If the policy should state why a policy like this is being put in place, I feel that it is best to mention ethical issues and link resources such as https://ai-sucks-actually.fyi and https://codeberg.org/small-hack/open-slopware#why-not-llms.

The more practical and trust-based issues are potentially fixable, but the ethical ones are not.

If the policy should state why a policy like this is being put in place, I feel that it is best to mention ethical issues and link resources such as https://ai-sucks-actually.fyi and https://codeberg.org/small-hack/open-slopware#why-not-llms.

I do not think we should be linking to curated lists that may be used to single out, shame, or harass people or projects. The fact that this PR is now being tracked and discussed externally illustrates my concern: decisions should be driven by project participants, not by attention from outside campaigns.

I don't think every fish user that might care about this is also regularly looking through PRs, issues and discussions to find these topics that they might care about being discussed. As such, I think it's only fair to talk about the issue and raise awareness, which naturally leads to people coming here to state their opinion on the matter as fish users.

That said, I don't see how this is comparable to a list to "single out, shame or harass" project participants. Raising awareness and a harassment campaign simply are not the same. I feel it is important not to conflate the two, or to insinuate (intentionally or not) that they are comparable. The motivation is entirely different.

If the policy should state why a policy like this is being put in place, I feel that it is best to mention ethical issues and link resources such as https://ai-sucks-actually.fyi and https://codeberg.org/small-hack/open-slopware#why-not-llms.

I do not think we should be linking to curated lists that may be used to single out, shame, or harass people or projects. The fact that this PR is now being tracked and discussed externally illustrates my concern: decisions should be driven by project participants, not by attention from outside campaigns.

That's a fair point. That link could be replaced with another resource.

I feel like it's better to link to resources that have all of the reasons why GenAI is awful, than replicate the same text in every project. Both are fine, though.

I've changed the text to @zanchey's proposal, i don't know if we have changes we can get a consensus on, otherwise i'm satisfied with this version.

It seems like @krobelus really likes LLMs. Case in point:

• They were the person to originally add the AGENTS.md file, and they were the only person to touch it before it was removed.
• The only two LLM-generated commits before the LLM policy issue was created came from them.
• They recently merged an LLM-generated PR (Fix Vi mode cW deleting trailing whitespace #12790), despite it being closed due to being against the likely LLM policy. They also seem to review/interact with other rejected LLM-generated PRs after they were closed, despite likely policy.

This is making things increasingly complicated, and I would personally like to see some sort of consequence for them.

If I can make a suggestion—given there doesn't seem to be a consensus, and the two biggest contributors (krobelus/fish) seem to be leaning towards this policy being too strict, it might make sense to start off with the places where there's definitely a consensus: requiring LLM usage to be disclosed, prohibiting LLM-written comments, and establishing users are responsible for any AI code they put forward.

They recently merged an LLM-generated PR

If I rewrite an unsatisfactory patch like this one I usually preserve the Git commit author even when the patch looks very different from the original one (which was LLM-generated here). Changing authorship and adding commit trailers like Co-authored-by: $contributor or Reported-by: $contributor would probably be more honest; either way the important thing is that the final result is the combination of everyone's best efforts. I don't have a super strong opinion on how to credit bug reporters.

I would personally like to see some sort of consequence for them.

Not entirely sure why we would take action against krobelus (for breaching a contribution guideline that didn't exist at the time?) nor how it would help.

I just discovered the whole discussion. For the context, I’m also against genAI tool only for ethical reasons. The "technical/trust issues" will probably be resolved in a near future (or most will learn how to deal with them). But that’s not the case of the unethical exploitation of people hardwork, environmental issues, erasing of human alterity into common soup, etc. So I must admit I’m glad to see that my shell of choice is leaning toward refusing to blindly follow the crowd without thinking twice about the consequences of our acts. Sorry end of context.

I like the current state of the proposal. Just 2 points:

• I think nowadays there is a general understanding of what are the genAI tools. IMHO listing some of them as exemple does not help: it might introduce a doubt on whether tool A is allowed or not as not part of the list. And mainaining such a list each time a new spammer will try to push a slopified MR with a new tool will be tedious. So I’d prefer to not list any tool.
• I also understand part of @krobelus point of view. Some people might be unaware of the implication of usage of those tools. I agree just banning them altogether might appear surprising to some, and writing down a clear explanation will help a lot to explain why we do so. I like the current proposal of @zanchey on the matter:

This policy was enacted because these contributions are often of poor-quality and are not understood by the submitters. This places a significant burden on maintainers. Some maintainers also have concerns regarding the copyright status of these contributions and/or ethical concerns regarding the use of these tools.

However I must admit I’d prefer to reverse the order of concerns to speak first about ethical and copyright issues (not fixable in a near future), before speaking about quality issue (which again might be generalized, independently of the genAI usage).

Side note: I also like very well the servo wording on genAI.

Finally, a point which might be missing here, is to precisely describe what happen in case of a genAI submission, despite this policy:

• who is responsible to close such MR?
• who I should contact if I disagree a decision (i.e. my very carefully hand work has been falsely flagged AI and I’d like to object this decision)?

I’m very sorry to be late on this and reopen some subject. To be honnest, I’m totally fine with the current version, and agree that we could merge it now and improve it step by step in follow up MR.

FWIW, maybe this perspective can shed some light on how to think about this policy. Perhaps in how to respond to future AI contributions.

I have always been an avid fan of fish shell, I still am. I took time out of my day to carefully describe a problem in a PR #12764 and to provide a fix for it. Only to find it was immediately marked as "slop" and closed so I couldn't even follow up.

I had tasked Claude with figuring out how hard the fix would be since I have a pretty busy day and I wanted to help if I could. I believe in leaving AI attributions in place if AI was involved and that's what ultimately got the PR rejected.

I'm waiting patiently to hear back (here) since this PR (#12630) was linked as the reason for closing my PR (#12764). Because the bug still exists, I'd like to submit a non-AI fix for it.

But, what I don't get is the "slop" part... was that because I used AI or was it because there was a problem with the code? Not giving any explanation is incredibly disheartening. Is that how you want people to feel?

I'm left wondering if there's something legit wrong or if there's just so much hatred directed at AI that that is the explanation for the reaction to my PR?

Definitely isn't aligned with the stated policies in the CODE_OF_CONDUCT:

• Demonstrating empathy and kindness toward other people
  

  fish-shell/CODE_OF_CONDUCT.md

  Line 21 in 11d6e92

  * Demonstrating empathy and kindness toward other people

• Giving and gracefully accepting constructive feedback
  

  fish-shell/CODE_OF_CONDUCT.md

  Line 23 in 11d6e92

  * Giving and gracefully accepting constructive feedback

What should the policy be w.r.t. how future PRs are handled when AI usage is mentioned? People, even those with good intentions and that are good coders, will miss the warnings about using AI... it might be a good idea to come up with a non-provocative way to address the issue. And I think it would be wise to allow well intentioned people the chance to resubmit the work after redoing it w/o AI tooling. Leave the PR open. Mark it as ai-policy or smth neutral if you need to tag and track them.

Some people tend to define the term "slop" differently than others, personally I use the term "slop" to refer to all generative model outputs, others will use it to only refer to low-effort generative model outputs.

I agree that we should try to be nice to people, not everyone knows why generative models are bad. If someone has good intentions but merely missed the policy, or misunderstood the policy, I feel like they should be given a second chance.

This doesn't mean the PR should be accepted; it should not. But we should strive to be nice to one-another, Not everyone is equally as aware of why generative models are awful, and it can take some time to let that sink in. People usually are not instantly convinced, it tends to take time.

The enemy is GenAI, not the people using it.

I took time out of my day to carefully describe a problem in a PR #12764 and to provide a fix for it. Only to find it was immediately marked as "slop" and closed so I couldn't even follow up.

I cannot find a place where it was marked as "slop". I closed it with an explanation pointing towards the policy.

Also I locked it, which was admittedly overzealous. For that, I picked one of the four reasons github provides ("resolved", "too heated", "off-topic" and "spam"). And tbh "spam" is the closest thing I can think of, because a lot of the AI engagement we've had has been as much of a waste of time as spam is - comments that are five times as long as they need to be and factually wrong with operators behind the AI that may or may not listen to what you reply.

It is immensely frustrating to deal with.

I'm not sure what kind of documentation about reasons

@danielrainer I'd say it doesn't necessarily need to be in the policy but at least in the commit message, so we can revisit it later ("Chesterton's fence"). I think we should use Occam's razor so we can highlight the main reason.

How do we think we should handle the recently mentioned cases, where the original versions of the patches were LLM-generated?

• 4b2aba3 (complete: tab-complete anywhere-position abbrs in non-command position, 2026-05-17)
• eb53532 (Fix cW Vi mode regression deleting trailing space, 2026-05-29)

Ask them to redo the patches without LLM-assistance? That was trivial in these cases so I did it for them (since they're probably just one-time contributors).
Should we have someone else implement the changes, promising not to look at the tainted implementation?
Should we not credit contributors who wasted our time using LLMs?

I'm not sure what the proposed policy wants us to do.
Feels like there's some gray area, not to mention that it's impossible to tell how a contribution was produced.
I'm not sure if the policy is meant to be taken literally or if it's more like lip service that can be overruled (like what happened sometimes to CODE_OF_CONDUCT.md) and it helps (future) maintainers and possibly also contributors, then sure.
(Some time ago I was gonna suggest we remove CODE_OF_CONDUCT.md because it seemed quite hypocritical due to scenarios like the one mentioned above.)

I'd say it doesn't necessarily need to be in the policy but at least in the commit message, so we can revisit it later ("Chesterton's fence").

I'm not opposed to having such documentation, I just consider it somewhat unnecessary and it's another thing where we'd have to agree on the content and wording. Given the prevalence of LLM contribution policies, I think people won't be surprised by the existence of a policy. Adding documentation to the policy about why we have chosen this particular policy and what we try to achieve with it might make sense and should provide sufficient information about why the policy is in place. The third paragraph of zanchey's proposal seems like it would achieve that purpose.

I think we should use Occam's razor so we can highlight the main reason.

That runs into the problem of us needing to agree on what "the main reason" is, which I don't think is productive to discuss. This thread has already shown that different people have different concerns with LLM use, so if we document reasoning about why we chose the policy, I think it's best to list all concerns without explicit or implicit prioritization, or implying that everyone agrees with all concerns to the same extent. That is not to say we need a detailed list. As I see it, the concerns fall into the categories of ethics, quality, and legality/copyright, so listing those should be enough. We can add references to external resources if we feel like more detail about the concrete issues in each category is warranted, but I don't think it makes sense to go into excessive detail or to block adopting a policy on deciding on which references to add. These can easily be added later if we want to.

How do we think we should handle the recently mentioned cases, where the original versions of the patches were LLM-generated? [...] I'm not sure what the proposed policy wants us to do.

That's exactly what I was getting at when saying

Existing practice is not well-established and is handled differently by different people on an ad-hoc basis. This is not a suitable basis for a useful policy. By formulating a policy, we set clear expectations for everyone involved, which avoids wasted effort and frustration.

By having a policy in place, we can prevent such issues from occurring in some cases, by people realizing that some ways of contributing are not welcome. Of course that only works for well-meaning people who care enough to read the policy, but I'd argue that this is the most important group of potential contributors. So having a policy in place, even without concrete steps for addressing problems, already reduces issues.

How we deal with the remaining problems also needs to be decided, and should probably be included in the policy, but I don't think we need to wait for a consensus on that. Adding the current proposal or something similar without enforcement steps now and deciding on enforcement policies later also has the benefit of us having more information about compliance with the existing policy in practice.

So overall, I think the best course of action is starting with a policy which only says what we want, and possibly why we want it, and merge that. Then, we can observe the results of having the policy in place and decide separately on enforcement mechanisms. I don't see a benefit to delaying merging the "what we want" part of the policy until we have agreed on what to do if we get something different.

But, what I don't get is the "slop" part... was that because I used AI

Yes. I don't make the labels, but very likely yes.

it might be a good idea to come up with a non-provocative way to address the issue

A pull request template, featuring a checkbox saying "I have not knowingly used AI in the creation of this PR" or similar.

Quoting #12630 (comment):

I'm waiting patiently to hear back (here) since this PR (#12630) was linked as the reason for closing my PR (#12764). Because the bug still exists, I'd like to submit a non-AI fix for it.

The fact is that there's nothing to fix at all, and your "fix" only broke existing features (see #12838). I just want to reiterate my opinion that I posted at #12764 (comment): Turns out AI slop always makes things worse, lol. Even if it's not just about the quality of the code, AI makes people think less before implementing anything. Fixing one thing while creating several more new bugs, or adding a new feature that breaks several existing features.

Quoting #12630 (comment):

How do we think we should handle the recently mentioned cases, where the original versions of the patches were LLM-generated?

• 4b2aba3 (complete: tab-complete anywhere-position abbrs in non-command position, 2026-05-17)

Glad to see this one got reverted in 2c17c96, and it once again proved that contributions made through AI will only be a pain for everyone. As I said above, it's not just the code quality, it's the whole thinking process that AI is taking away from people and ultimately making everything worse. I understand some people may want things get implemented faster with the help of AI, but do we really want to trade stability with speed?

I think LLMs really have a place assisting with the creation of good completions, and must be able to do a great job with the simplest harness and instructions. Their speed and ability there should be of great utility. I would not want to review PRs that were simply asking their agent to do it, just as I didn't love PRs of create_manpage_completions.py output.

But I don't think people on the team should be prohibited from doing it.

That ignores the ethical issues, I feel we all should make a stand against this dehumanizing technology.

GenAI should be banned everywhere.

Just want to throw my name in the hat too. Generative AI is just a speculative bubble, manufactured to make Sam Altman rich. You have to make a choice who to stand with. You're either with the people, or against them. LLMs are a scourge on the earth.

The thing is, you can argue about code quality, you can argue about legality, but there are just too many issues. It's not just the code quality, even if you fix that, you have all the other problems. No matter what angle you look at it from, it just gets worse and worse.

You're not a corporation, you don't have shareholders, you can't ignore ethics and morals. But even if you do, genAI is total BS.

I also want to make clear to the anti-AI advocates here: Don't compromise. Because if you give them an inch, they'll take a yard. Stand your ground. NO generative AI is the policy, nothing more, nothing less.

About whether it is enforceable: That doesn't matter. Don't give up on a policy just because you worry you won't be able to enforce it. That's not relevant to what the policy should be, it's a different problem altogether, one to be discussed separately.

Open source software worked fine before LLMs even existed. The idea that they're necessary for anything is total nonsense, in my mind.

Please consider this proposal. I don't want to have to stop using fish, I quite like it.

I would recommend merging this sooner rather than later. As others have mentioned, don't worry about enforcement. Just put the policy in place and worry about the rest later.

can we expect to see any movement here soon?

Alright, merged. I've had it with the slop PRs.

You've done the community a great service. Thank you!