Propose Organization AI Policy

Propose a standard AI policy for contributions to Typelevel organization projects and guidance for org and affiliates on using AI with open source.

Initial Research Notes

There are a wide variety of AI policies being used. A sampling:

Permissive Policies

These policies generally allow AI tool contributions, typically with attribution

Apache Foundation: Allows use of AI ensuring output is not subject to restrictions or copyright concerns.
Linux Kernel: Allows use of AI, mentions that developer takes full responsibility for the contribution and suggests indicating AI tools used.
The Linux Foundation also provides some high level guidance for their projects.

Restrictive Policies

The Godot Engine discourages LLM use and forbids entirely AI generated PRs. This policy is actually just integrated into their over PR guidelines
The Zig project completely forbids any use of AI tool whatsoever, for any purpose.

Commentary

I do like the Linux Kernel policy about identifying the tool and being clear about developer responsibility. Daniel's original proposal had similar ideas.

The Godot engine policy is notable, as it came out of practical experience. As a large, popular project, it has received a higher volume of AI-assisted PRs than its maintainers could keep up with and their policy came as a response to that. It might be better to produce an overall contributor policy instead of an AI specific document, to provide overall guidance on how contributors should behave. We saw a number of eager PRs from GSoC participants this year that could have benefited from having some more guidance on how to get involved.

Call for Feedback on TL AI Policies

I know the http4s project had some issue spam, but I haven't heard much about AI use or misuse in practice in TL projects otherwise.
There is also the issue about copilot reviews ( #183 ) as well, though this is more of an issue with Github :/

Reports or thoughts from @typelevel/maintainers would be appreciated.

It's worth noting explicitly that the biggest problem IMO (related to the Godot one, it sounds like) has been AI-driven PR spam -- specifically, PRs that appear to have been created for the sake of creating a PR, not based on an established issue that folks have said need fixing. That is, not only is the PR bad, it is actively undesireable in the first place.

That's not precisely an AI problem per se -- the same thing would be a problem if it was entirely bring written by humans. But LLMs have taken a hypothetical problem and made it very real, by enabling people to simply say "Find something in this repo for me to create a PR about", which at least some people appear to have done.

That said, this problem may be partly dissipating now that the decent LLMs are no longer effectively-free -- we'll see if it continues to be a significant issue.

I'd be clear: I'm against any "AI"-assisted contributions and I want to provide a short reply based on that (from what I observe in my corner of Fedivers - such a view exists, but people with it either retiring, switching out of software engineering and F/OSS contributions or grimly preparing to die soon enough due to lack of jobs for them under current conditions).

In short:

there is no ethical "AI" consumption
there is not enough of will power/discipline/mental strengh to control yourself once an individual starts to use "AI" assistance - sooner or later their work is replaced by the model's output without review
in the long run a permissive approach would allow for the "AI"-assisted contributions to the project to overcome the human-originated, leading to communication degradation from new contributors, disappear ing of the knowledge and understanding transfer, and to the eventual collapse of the project (I handwave a lot here, as we are only in the process of such effects here and there - but I see it already in tools and solutions that I used)

Addendum: Linux Kernel/Linux Foundation model after the latest statement by Linus Torvalds converted to the "this project isn't the place to do any "AI" critique".

@jducoeur

I mostly agree with what @jducoeur said - I don't think AI is a problem per se. I mean in practical terms, disregarding some general issues like the environmental impact or training data IP. But without a real human (either a programmer or someone interested to learn) working towards a well-defined goal / particular issue, it's almost impossible to make a meaningful contribution. Maybe a "find a bug and fix it" approach could lead to some results.

I also think that the person submitting the PR should take full responsibility for the contribution. One complication with it is that a GitHub handle can be de facto anonymous - so does that put the onus on maintainers to gauge if the PR is coming from a person's genuine account or an account used exclusively by AI tools (let's call it a bot)? I think in most cases it's easy to tell, but who knows.

In projects I maintain (which are low-traffic in general) I've seen only a few drive-by AI PRs so the volume hasn't been a problem. But for more popular repositories, I guess a policy would be important to deal with them systematically. I wish GitHub would provide some automation tools here...

As there was a call for reports, here are a few possibly related issues/PRs (I am not claiming these are all LLM-generated, just that they may be relevant; I'll let everyone analyze these, and make up their own minds):

#4628 (multiple admittedly LLM-generated "reproducers"; I personally found none of them useful)
#4608 (there is a mention of LLM-policy there; related)
#4512

(I don't have anything specific to propose here, just adding more data points.)

I'd like to raise an important aspect in this discussion. It's your call if Typelevel wants to go hardline on not allowing LLM-generated content but it should be clearly signaled in the issue and PR creation flows. The linked ticket I created had a comment indicating that I had broken Typelevel's AI policy but then I see it seems actually undefined and there's ongoing discussion. Is there an older version of the policy or was it something made up on the spot?

I'll say it plainly so it's properly assessed: how can you avoid bias in the judgement of what's AI-generated or not? From my POV, bias was exactly the reason that comment was posted. The bug is accurately reported, a proper reproducer is provided, and I can't see any issues with the description. For the record, I do use AI for development but the ticket was not created by Claude directly.

Given Typelevel's stated goals of inclusivity and building a welcoming environment, any decision regarding this topic should have clear mechanisms to avoid bias when judging people's contributions. Incorrect inferences like in this case can be quite offensive. It'd be interesting to also consider accessibility for people who don't have English as their first language.

@gemelen

Personally I'd be in favour of a policy more aligned with the example from Godot (which I like a lot). More generally, the idea of clear contribution guidelines, LLM specific and otherwise, sounds good to me!

I don't want to get into all of my feelings, but just the one thing that concerns me most: the long-term health of the community, kind of echoing @gemelen third point. First I think that LLMs are capable of solving day-to-day problems, routine problems, well-defined problems within the scope of the training set, etc. BUT LLMs are not entirely capable when a problem is novel or the context is far removed from the scope of the training set. I think in those cases there needs to be an experienced maintainer prompting in order to make progress in those problem spaces. (I don't think these are particularly unique or controversial takes, just wanted to spell them out for my concern)

With those two points in mind, my concern is that automated PRs via LLM take "good first issues" and resolve them without a person gaining context and experience. No maintenance skills for a project are built, and so the overall community doesn't grow, even though the review burden on existing maintainers does. I think this will be problematic long term, as existing maintainers naturally ebb but no new maintainers flow.

I feel similarly about PRs that are not automated but make heavy use of LLMs for "good first issues". Is the issue accomplishing its goal of teaching if it's an LLM doing the work? My feeling is no. I really appreciated the GSoC policy in this regard, where LLMs could be used for code but not communication, as an attempt to bridge any potential LLM vs learning gaps.

@samspills

With those two points in mind, my concern is that automated PRs via LLM take "good first issues" and resolve them without a person gaining context and experience. No maintenance skills for a project are built, and so the overall community doesn't grow, even though the review burden on existing maintainers does. I think this will be problematic long term, as existing maintainers naturally ebb but no new maintainers flow.

I feel similarly about PRs that are not automated but make heavy use of LLMs for "good first issues". Is the issue accomplishing its goal of teaching if it's an LLM doing the work? My feeling is no. I really appreciated the GSoC policy in this regard, where LLMs could be used for code but not communication, as an attempt to bridge any potential LLM vs learning gaps.

Excellently put @samspills, I feel the same about AI use in education.

With those two points in mind, my concern is that automated PRs via LLM take "good first issues" and resolve them without a person gaining context and experience.

I also quite like the Godot policy focus on community. It doesn't really help us if people drive-by AI contributions that maintainers have to deal with¹. OSS projects ultimately need new contributors learning the codebase and becoming maintainers for a project to continue. Most of the things a contributor heavily using AI tools can do that causes issues is possible without tools. The tools just make it easy to casually do so without really understanding anything. The contributor guides currently in TL projects are more mechanics focused than Godot's how to interact with the community guidelines.

Godot's guidelines are not going to be surprising for anyone with plenty of open source experience, but less so for new contributors (we see this with GSoC applicants), so an educational guide would be useful. Contributors ignoring them should be an educational issue [and escalating when needed], whether they're doing it with AI tools or not. The ones using AI tools to ignore guidelines will just end up speedrunning the process 🙃 .

Regarding actual PRs, I would prefer more the linux style "Taking full responsibility for the contribution" than Godot's discouraging in general, and leave individual projects free to be more restrictive if they prefer. Expecting contributors to take responsibility for their contributions is a very reasonable expectation regardless of how they work, or as the Godot docs also say:

Please only submit code that you understand and are prepared to explain to a maintainer.

Godots guidelines are also CC BY 3.0, so would serve as a good starting point to develop contributor guidelines.

if the maintainers had time to do the ticket with AI, it would have been faster for them to prompt the AI themselves! ↩

Hello,

I think that you need to address the elephant in the room ... which is that you can't actually detect AI use, and any anti-AI policy will result in false accusations. Consider that false accusations will disproportionately affect non-native English speakers for the obvious reason that many use AI tools for correcting their English. And AI is getting better while at the same time people are learning more and more from AI-generated code, so whatever signals people think are useful now for detection, will be useless in only a couple of months from now.

Yes, it is true that AI changes the dynamic of Open-Source contributions, such as first-time issues now being closed with the help of AI, robbing beginners of learning opportunities. It's a shame, but this isn't something that you can actually stop. Because AI is a tool, and people will always be free to use tools on their own laptop without maintainers finding out about it.

And of course, maintainers can provide guidelines in the hopes that future contributors will actually listen and play by the rules. Appealing to people to behave responsibly is a good idea, but banning what they do on their own computers is not.

In case somebody here will find it helpful, I think this approach to AI is interesting:

TLDR: in tickets/PRs body, have a separate section for humans to fill and a separate section for AI to fill. Seems like best of both worlds. Maintainers can easily have a glance of what the human actually wrote. And can dig into the details that the AI is good at providing.

@alexandru

I tend to agree with @alexandru. The AI keeps improving, and even now, in some cases, it's impossible to say whether the code/description was AI-generated. If we assume even marginal AI improvements over time, it will be even harder to do so in the foreseeable future.

So realistically, I see 2 main problems:

PR spam for non-existent bugs / new features / security issues
"good first issues" being resolved with AI

PR spam

This forces maintainers to spend time verifying whether the bug/security issue is actually real.

One thing I saw was that some repos moved to the "issue-first" approach, where all PRs without a relevant issue are rejected. Unless the issue is moved to "approved for development" or something, we can reject most unrelated PRs.

While it might move the problem to another layer - issue spam - we still can have a strict guideline for the reported issue. We might require reproduction steps, motivation to do the change, etc.

I believe this can be feasible for projects that suffer from PR spam.

"good first issues" being resolved with AI

This is sad, but realistically I don't see a simple way to prevent such things. Even if we ban AI entirely for the "good first issues", we still get back to the initial problem: how can we tell it was solved with AI?

Bottom line, in my opinion, the Linux Kernel policy fits well: you are responsible for the AI-generated code and for the contribution. Disclosing which tools were used seems also reasonable.

As it happens, I'm dealing with AI use within large projects as part of my job currently. While it's hard to tell whether the code itself is AI generated, the comments absolutely give the game away and will continue to do so. Students, at least, recognise this and may remove incriminating comments (though seemingly do not have the sense to do so in the commit they introduced the comments, which leads to a convincing evidence chain); people contributing to open source repos likely will not, particularly the ones who are lazy with their AI use.

As others have noted, it's not that we want to ban AI outright, but we would like to discourage thoughtless use of it. That kind of AI code is still easy to pick up on.

Besides, sometimes it's the thought that counts: I've just drafted up an AI policy surrounding the projects I'm in charge of at work, and while I'm aware that there will be some who will ignore it; for those who are academically honest, it will serve as a deterrent enough to use their brains. Doesn't catch everyone, but does help.

Couple scatter-shot thoughts (I haven't had a moment to read this whole thread in depth but, skimming, I think I align with most of what's being said here).

First off, pushing back a bit on the assertions around model capability. I still hand-write code in Cats Effect, but I've experimented with frontier models on varying problems over the past couple years, and I'm confident in saying they're now at least as good as I am at addressing novel problem spaces, and they're better than I am at teasing out really subtle and complex race conditions. They still require careful prompting and oversight, but I think we're safely to a point where "out of distribution" is no longer a meaningful thing to point to. The models just don't work that way anymore.

Broadly, I agree very strongly that we should forbid generated prose. Ultimately, open source is a social activity, and most of socialization is communication. Speaking as a project maintainer here, not as a board member… If you interpose a synthetic entity in your communication, you are basically neutering that whole side of the equation, regardless of how capable the model is. I feel very, very strongly about this. If you can't take the time to write a couple sentences describing your pull request, then I will not take the time to read your agent's detritus.

I feel strongly enough about this that I'm not even willing to risk false positives on my slop detection. I read a lot of model generated text. If I think you're generating your comments, issues, or PR descriptions, I'm going to warn you and close your stuff. If you keep doing it after my warning, I'm going to ban you. If I get it wrong, I'll willingly listen to your explanation and allow myself to be convinced, but I'm really honestly comfortable with my filter failing closed in self defense.

Btw the one exception I'll make to this is translation. If you aren't a native English speaker and you're laundering your words (and presumably my words) through an LLM just to bridge that gap, but you're still constructing the thoughts yourself, I support you 100%. This is actually something that LLMs are incredibly good at and, hopefully, in time will serve to break some of the anglophonic hegemony in tech. As a quick aside on this, one of the most significant tells of AI generated prose is nonsensical or misplaced metaphors (stemming from the fact that present-day model architectures lack strong world model understanding). This is almost never a problem in the translation case though because, outside of the base level of rhetorical device which exists in all language, the content is actually being synthesized by a human being.

One immediate consequence of this is that it really forces anyone opening a PR to have an understanding of what they (or their agents) did. If you can't hand-write a description and have a technical discussion, then you don't understand it well enough and thus, you didn't really learn anything (particularly thinking of GFIs here) and you aren't adding anything to the discourse.

In general, I'm also going to be pretty aggressive about drive-by slop. GitHub makes it super easy to just throw compute at random things in the open space and karma farm. If I think someone is doing that, I'm going to shut it down just in self defense. I have very, very little time to devote to this stuff, and I'm not going to waste it on a ten thousand line sprawling PR that purports to do something crazy and unanticipated.

I resonate with the idea that LLM contributions are by essence deeply anti-social, and fostering community is the most important thing to let ecosystems survive and develop.

Personally speaking, I'm fine with using an LLM in the code-writing process -- frankly, at this point that's true for 3/4 of my PRs nowadays, in all contexts. I hand-write code if it's small, or persnickety in ways that I understand, but most of my PRs are primarily LLM-authored.

That's a far cry from vibe-coding, mind. These PRs usually involve anywhere from a paragraph to half a page of prompt, usually including a substantial bullet list of details and requirements, and often following a long conversation with the LLM to produce extensive planning documents. (Eg, this entire directory planning out a migration of Querki's UI to Calico.)

So I would recommend that we avoid getting reductive here. It's clear that there are misuses of AI that we should be forbidding, and bad social patterns that we should be steering folks away from. But the reality is that it's become a central workflow element for some of us, and IMO we should be open to reasonably responsible use of that.

(I acknowledge that there's a fair case to be made that the AI industry as a whole is harmful; there's some truth to that, but IMO it's largely a special case of "there is no ethical consumption under capitalism".)

I'd be clear: I'm against any "AI"-assisted contributions and I want to provide a short reply based on that (from what I observe in my corner of Fedivers - such a view exists, but people with it either retiring, switching out of software engineering and F/OSS contributions or grimly preparing to die soon enough due to lack of jobs for them under current conditions).

In short:

there is no ethical "AI" consumption

there is not enough of will power/discipline/mental strengh to control yourself once an individual starts to use "AI" assistance - sooner or later their work is replaced by the model's output without review

in the long run a permissive approach would allow for the "AI"-assisted contributions to the project to overcome the human-originated, leading to communication degradation from new contributors, disappear ing of the knowledge and understanding transfer, and to the eventual collapse of the project (I handwave a lot here, as we are only in the process of such effects here and there - but I see it already in tools and solutions that I used)

I'd try to be as precise as possible, but it never comes easy to me even in my native language.

Please, refer to my previous comment for the basis of why I'm sayhing this:

the project / the community may either forbid an "AI"-assisted contribution (for all) or join a never-ending goalpost moving of defining what is allowed and how to detect if a particular contribution falls under the rules. This is already happening in this exact
discussion.

If such a contribution is forbidden, it's on a contributor to decide if they want to use any such tool for whatever reason they think it is right for them, and, probably, to lie to the people handling their contribution. It doesn't mean that a project caretaker must run around in order to prevent any such usage, however it'd be better to have a clear set of points on where and when to ask a confirmation from a contributor to enforce that policy.

In the opposite model the representative of the community has to decide for each case if this particular contribution is human-made enough, valuable enough, good enough, ethical enogh? to be accepted or to be requested being improved. This opens a myriad of ways to interpret the permission in however it is convenient to the contributor and go around it.

On the other note: it is already looks like the restrictive approach is in minority, so I won't be taking more of your time.

The last thing I want to comment on: "... in practical terms, disregarding some general issues like the environmental impact or training data IP" - it is impossible to disgregard these and all other issues arisen with "AI" tools, they always are on the scales.

The last thing I want to comment on: "... in practical terms, disregarding some general issues like the environmental impact or training data IP" - it is impossible to disgregard these and all other issues arisen with "AI" tools, they always are on the scales.

Just because this one is a particular bee in my bonnet right now… I would really recommend we steer clear of this particular line.

Disclaimer time! I work for Nvidia, so naturally I have some vested biases. Please take that into account. I will, of course, recuse myself from any actual vote on these matters for this reason so please consider me a) a project maintainer, and b) a very informed but probably not entirely impartial advisor.

The environmental impacts of AI are not as clear or as dramatic as certain circles make them seem to be. The water use in particular is a massive red herring, to the point where in most cases, if the data center in question is built on land previously used for agriculture, it's probably using less water than what was there before. The conspiratorial part of me almost thinks that this talking point has been intentionally amplified by accelerationists because it's so easy to refute.

Energy consumption on the other hand, and particularly behind the meter fossil fuel usage (which is getting a lot more common since grid upgrades are politically stonewalled) is definitely a real concern, but it needs to be kept in perspective. If you live in Europe, North America, or East Asia, even if you're a heavy AI user, your day is already full of pretty drastic energy use that is far beyond inference costs or even amortized training costs. Pause and think about a microwave for a moment, or an air conditioner, or an oven, to say nothing of an automobile.

I'm not saying it doesn't matter but I am saying that the magnitudes are being manipulated by the popular discourse. I think it's a distraction in this context. We don't tend to include verbiage in our statements about the importance of photovoltaic solar generation, grid topology reconfiguration, or energy storage technology, and those are drastically more environmentally impactful issues right now in that same topic space.

@joroKr21

The last thing I want to comment on: "... in practical terms, disregarding some general issues like the environmental impact or training data IP" - it is impossible to disgregard these and all other issues arisen with "AI" tools, they always are on the scales.

I took @joroKr21 to be bracketing those issues in order to address direct engineering concerns, which is certainly something that one can do without stipulating that those concerns are of no importance.

In any case, deciding whether or not to take an activist stance on general ethical concerns with AI is certainly something Typelevel can do.

@durban

@durban , @fwbrasil , @djspiewak , while I appreciate the reference to typelevel/cats-effect#4608 to help inform a TL-wide policy, this issue is here to discuss future policy. Please do not continue discussions from other issues here.

This isn't the issue to litigate one interaction.
Justin asked for folks to stay on-topic so I've deleted one message and hidden another.
I'll take further moderation action if necessary so please let's just move on

Thank you for the feedback folks! Reviewing the comments:

there is only minority support for blanket AI bans
there is broad support for discouraging use of AI tools without understanding
there is broad support for requiring communications to be human written, while a few comments do note this can be hard to tell.
Automated PRs via LLM taking "good first issues" is a concern raised by a few people. I'm unclear if this is hypothetical or not.

My plan from this feedback is:

not to create a standalone AI policy document
make some updates to a pending "start contributing" guide PR for the website so we do have more guidance for newcomers, and get it published
add a general contributing guide to the site as well, based on the Godot page and our google summer of code AI policy, which can be referenced by project-specific CONTRIBUTING.md pages, so we do have an evergreen document for people looking to contribute
make a blog post to announce the above

I will link that PR here for reference when I get it out.

Navigation Menu

Repository navigation

Propose Organization AI Policy #194

Initial Research Notes

Permissive Policies

Restrictive Policies

Commentary

Call for Feedback on TL AI Policies

PR spam

"good first issues" being resolved with AI

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Propose Organization AI Policy #194

Description

Activity

reardonj commented on Jul 18, 2026

Initial Research Notes

Permissive Policies

Restrictive Policies

Commentary

reardonj commented on Jul 18, 2026

Call for Feedback on TL AI Policies

jducoeur commented on Jul 19, 2026

gemelen commented on Jul 19, 2026

joroKr21 commented on Jul 19, 2026

durban commented on Jul 19, 2026

fwbrasil commented on Jul 19, 2026

samspills commented on Jul 20, 2026

j-mie6 commented on Jul 20, 2026

reardonj commented on Jul 20, 2026

Footnotes

alexandru commented on Jul 21, 2026

sideeffffect commented on Jul 21, 2026

iRevive commented on Jul 21, 2026

PR spam

"good first issues" being resolved with AI

j-mie6 commented on Jul 21, 2026

4 remaining items

djspiewak commented on Jul 21, 2026

Koroeskohr commented on Jul 21, 2026

jducoeur commented on Jul 21, 2026

gemelen commented on Jul 22, 2026

djspiewak commented on Jul 23, 2026

bplommer commented on Jul 23, 2026

fwbrasil commented on Jul 24, 2026

reardonj commented on Jul 24, 2026

samspills commented on Jul 24, 2026

reardonj commented on Jul 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions