RFC: Create AI policy

@ashleywolf

Context

AI is all around us and not always for the better, far from it.
We see a deluge of new contributions enabled by AI that have lowered the barrier to contribute dramatically.

Problem

AboutCode repos have roughly between 100 and 150 PR and issues contributed in the last 2 months that feel like entirely vibe coded or mostly AI-generated.

There are several issues we must consider:

AI-generated code and content may not be copyrightable or may commonly be borrowed from open source code used in LLMs training, without any attribution, credits or license
AI-generated content is mostly bland, conventional, flat and lacks substance
The human time it may take to review a machine-generated contribution is not worth the efforts of the maintainers, as it may require asymmetrically more efforts on our side to sort out human from machine-generated contributions. Machine-generated contributions can be seen are a sort of Distributed Denial of Maintainer Services on our projects. They are subtly and superficially acceptable, and may even pass some tests, but are in many cases not understood by their contributors and will result in serious tech debt if merged.
We are a community of people. We did not join this community to work with or for AI agents. Eventually I am warming up to the ASF moto of community over code.
We receive support from orgs like NLnet and they have an AI policy for the projects they support that we must take into consideration.
We cannot grow a community of contributors if our merge queues are flooded with machine-generated contributions.

Our current development environment where issues and pull requests are our primary community communication and exchange media is at risk of collapsing if AI "slop" is left unchecked.

Solution

We must put in place a proper AI policy to avoid the degradation of our community and projects, one that privileges contributions from real persons over most machine-contributions.

We need also to evolve tools and approaches to consistently deal with the current and future issues, and ensure that aspiring contributors understand our policies and ethos https://en.wikipedia.org/wiki/Ethos .

Some existing reference:

@ashleywolf acknowledging this as a serious issue for GitHub https://github.blog/open-source/maintainers/welcome-to-the-eternal-september-of-open-source-heres-what-we-plan-to-do-for-maintainers/
@bagder removing curl from bug bounties because of AI issues https://hackaday.com/2026/01/26/the-curl-project-drops-bug-bounties-due-to-ai-slop/ (he recently stopped by our workshop at https://workshop.aboutcode.org/ to talk about it)
NLnet AI policy https://nlnet.nl/foundation/policies/generativeAI/
@mitchellh AI policy for ghostty https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md
matplotlib AI policy https://matplotlib.org/devdocs/devel/contribute.html#restrictions-on-generative-ai-usage
matplotlib's @scottshambaugh woes at https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ also reported by @sethmlarson https://sethmlarson.dev/automated-public-shaming-of-open-source-maintainers

I like this policy https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md

At matplotlib we've been looking at the LLVM AI policy as a good reference: https://llvm.org/docs/AIToolPolicy.html

@scottshambaugh

@scottshambaugh Thanks! That's handy. I've read your "AI adventures" with amusement and consternation!

I see also this policy emerging from LLVM's https://discuss.scientific-python.org/t/proposal-for-scipy-to-adopt-the-same-ai-policy-as-sympy/2230

FWIW, the LLVM's policy source is at:

https://github.com/llvm/llvm-project/commits/main/llvm/docs/AIToolPolicy.md

The commit message at llvm/llvm-project@18695b2 and PR llvm/llvm-project#154441 are interesting for background:

[docs] Add human-in-the-loop policy for tool-assisted contributions (#154441)
Over the course of 2025, we observed an increase in the volume of
LLM-assisted nuisance contributions to the project. Nuisance
contributions have always been an issue for open-source projects, but
until LLMs, we made do without a formal policy banning such
contributions. However, LLMs are here, so we are adopting this policy,
abbreviated as "human in the loop", which requires that every
contribution has a human author attesting to the value of that
contribution, and that it is high enough quality that it is worth the
time it takes to review the contribution.

This policy evolved over time based on community input from the
following Discourse threads and a few area team and LLVM project council
meetings:

Our AI policy vs code of conduct and vs
reality

[RFC] LLVM AI tool policy: start small, no slop

[RFC] LLVM AI tool policy: human in the
loop

@rnk @maflcko @hubert-reinterpretcast thanks for all the work there and in LLVM as this helps a lot

See also Gentoo's policy: https://wiki.gentoo.org/wiki/Project:Council/AI_policy which sounds pretty extreme, but is also about two years old, from 2024-04:

It is expressly forbidden to contribute to Gentoo any content that has been created with the assistance of Natural Language Processing artificial intelligence tools. This motion can be revisited, should a case been made over such a tool that does not pose copyright, ethical and quality concerns.

@pombredanne

I've started a draft for contribution guidelines, not limited to AI slope though, for the DejaCode and ScanCode.io repos.

@pombredanne @DennisClark @mjherzog I'd like your take before enforcing those:

# Contributing to DejaCode

Thank you for your interest in contributing to AboutCode projects.
Please **read the following guidelines carefully before submitting a pull request**.

## Pull request rules

- **Attach your PR to an existing issue.** Discuss the approach and implementation
  details in the issue first, before writing any code.

- **You must fully understand your code changes** and be able to explain them
  clearly. If you cannot walk a reviewer through your changes, the PR will not
  be accepted.

- **Write your own descriptions, comments, and documentation.** All written
  content in a PR must be authored by a human.

- **Disclose any AI usage.** If any part of your contribution was generated or
  assisted by AI, you must disclose this and specify the tools used.

- **Include tests.** Any code change or addition must be accompanied by proper
  unit tests. Untested code will not be merged.

**Any PR that violates these rules will be closed.**

## Pull request tips

To maximize your chances of a successful contribution:

- **Keep changes focused.** Address only what the issue requires. Do not bundle
  unrelated changes together.

- **Be patient.** Do not solicit maintainers for a review.

- **Remember:** project maintainers have no interest in reviewing code
  generated by machines.

## GSoC candidates

- **Fixing typos does not count.** This does not help us assess your coding
  capabilities.

- **Do not make structural changes** to the codebase such as adding type hints.
  These are not useful contributions for evaluation purposes.

- **Do not rely solely on generative AI.** This will most likely eliminate your
  chances of being selected. We can tell.

@tdruez

@tdruez thanks for doing this. Perhaps we can expand the first bullet point a bit as follows:

- **Attach your PR to an existing issue.** Discuss the approach and implementation
  details in the issue first, before writing any code. Please note that if the issue has 
 already been assigned to someone else, you are welcome to comment on it, but it 
 would be best to contribute code in such a case only if you are invited to do so.

@pombredanne

@pombredanne I took liberty of rephrasing some of Context/Problem text for clarity - I expect that we will want to make some public statement like this to explain our policy.
@tdruez I think that your draft makes sense, but I have some questions/comments:

Will this text be merged into https://dejacode.readthedocs.io/en/latest/contributing.html? I assume so, but I suspect that we will also want to make a short statement about our AI policy in the README with a new Contributing section that points to the RTD section for details but gets this policy front and center (at least for now).
I would prefer that we communicate this to GSoC participants somewhere else - this is too specific/ephemeral for the policy. We can always redirect GSoC to the policy.
We probably also need to also say that this policy will evolve further.

Beyond this we will probably want to publish the policy on www.aboutcode.org and perhaps publish a blog post.

Will this text be merged into https://dejacode.readthedocs.io/en/latest/contributing.html? I assume so, but I suspect that we will also want to make a short statement about our AI policy in the README with a new Contributing section that points to the RTD section for details but gets this policy front and center (at least for now).

Yes we should update https://dejacode.readthedocs.io/en/latest/contributing.html, it's outdated considering the problems we are facing now regarding PRs.

I would prefer that we communicate this to GSoC participants somewhere else - this is too specific/ephemeral for the policy. We can always redirect GSoC to the policy.

Fair enough, I've included notes about patterns I've noticed with Gsoc participations, but a dedicated location for those is fine.

Beyond this we will probably want to publish the policy on www.aboutcode.org

Yes, I think we should have a single source for the AboutCode contributions policy, so each project can reference it and extend as needed with its local specifics.

Contribution policy added to the DejaCode and ScanCode.io repos as a start.

@pombredanne

@pombredanne @tdruez I think the strongest problem in this thread is not really AI disclosure itself — it is the asymmetric maintainer cost of deciding whether a contribution is even worth reviewing.

Rather than propose another policy or integration, I'd like to test one concrete thing against your real review queue:

For one recent AI-assisted PR that made a maintainer wonder “did this actually fix the thing it claims to fix?”, would a one-screen before/after evidence receipt materially reduce review time?

The experiment would be deliberately small:

one real PR
one concrete claim
the exact submitted regression evidence

run the same evidence on PR HEAD
run the same evidence on BASE

HEAD PASS / BASE FAIL -> the claimed delta is witnessed
HEAD PASS / BASE PASS -> the submitted evidence does not witness the fix
cannot execute -> inconclusive

plus:
did the PR also change the test / fixture / CI judge that produced the evidence?

No AI detector, no quality score, no merge recommendation, and nothing to install.

If you point me at one recent PR where the reviewer cost was real, I'll run the experiment against that exact case and bring the result back here.

Then the only question is: did this save the maintainer meaningful review effort?

If the answer is no, that's useful too — I'll record it as a negative result and stop rather than add another tool to your workflow.

For context, the experiment is being built here:
https://github.com/hippoley/CounterProof

Navigation Menu

Repository navigation

RFC: Create AI policy #265

Context

Problem

Solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

RFC: Create AI policy #265

Description

Context

Problem

Solution

Activity

pombredanne commented on Feb 14, 2026

scottshambaugh commented on Feb 14, 2026

pombredanne commented on Feb 14, 2026

pombredanne commented on Feb 15, 2026

tdruez commented on Feb 25, 2026

DennisClark commented on Feb 26, 2026

mjherzog commented on Feb 26, 2026

tdruez commented on Feb 26, 2026

tdruez commented on Mar 3, 2026

hippoley commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions