AI-Assisted Contributions: Write the Policy Your Project Needs

Since 2024, projects from curl to the Linux kernel have written down what they accept from AI tools, and their answers range from a ban to “use it, and answer for it”. Each answer fits the project that wrote it: how many people review, what its license needs, where the bad contributions landed, and how its own maintainers work. Find your project’s situation below, pick the posture that fits it, and build your policy from blocks of text you can paste.

Projects write a policy for volume, for provenance, or to say how they work#

Most of the policies below started with volume. Generating a plausible pull request, issue or security report now costs its sender nothing, and reviewing one still costs a maintainer an hour. In 2025, fewer than one in twenty of curl’s security reports was real (Daniel Stenberg, January 26, 2026).

Pull requests followed. Ghostty tightened its rules on January 22, 2026 because bad contributions had grown “by 10x if not more”, and tldraw started closing every pull request from outside contributors a week earlier. A preprint that measured 294 repositories found that pull requests grew in 2025 while merge rates fell, most of all for one-time contributors (Afroz et al., July 4, 2026).

Volume isn’t the only reason. Some projects must know who wrote each line, because their license, the certificate their contributors sign or their downstream depends on it. Others use AI tools every day and want contributors to know where they stand: Ghostty’s policy says the project “is written with plenty of AI assistance”. AI Slop Is Flooding Open Source tells how curl and five other projects answered, each from its own constraint.

Most projects that wrote a policy allow AI tools, and about half ask contributors to say when they used one. As of September 2026, a study of 281 AI policies in popular open source projects found that 83.3% permit AI use in code and 48.8% require disclosure (Hora, Robbes and Zacchiroli, September 7, 2026).

Three postures, one rule they all share#

Every policy we found falls into one of three postures. They differ on disclosure and on whether AI output is allowed at all:

Whatever the posture, the rule underneath is the same: you answer for what you send. The Linux kernel’s guidelines put it in one sentence: “You are expected to understand and to be able to defend everything you submit.” CPython’s says the submitter is responsible “regardless of whether AI tools were used”. Node.js adds that disclosing isn’t a disclaimer.

The bans rest on two arguments. The first is legal: QEMU’s contributors certify the DCO on every patch, and QEMU considers that nobody can certify output whose “copyright and license status” is ill-defined. The second is the review cost: Gentoo’s policy cites the “unfair human effort” of finding a tool’s mistakes. Gentoo adds ethics (training data, energy, spam), and says the council will revisit it.

Disclosure takes a form contributors already know. The Linux kernel asks for an Assisted-by: trailer, next to the human’s Signed-off-by:, and forbids the tool from signing off: “Only humans can legally certify the Developer Certificate of Origin”.

Pick the posture from your project, not from the news#

Which posture fits depends on what you can afford to review and what your project must protect, not on what you think of AI. Find the rows that describe your project. Most projects match two or three: take the strictest posture among them, and every block they list. The blocks are in the next two sections.

Each row comes from what the projects above, and a few others, ran into:

• A small library. You’re the whole review team, so the line you’ll use most is the last one of every base text, which lets you close what breaks the rules without a detailed review. Tests do part of the work. curl allows AI in code, and its end-of-bounty post says 200 CI jobs catch bad pull requests before a human reads them.
• A docs or content project. No test suite checks a fact. A tool’s paragraph reads well and its command, link or version number can still be wrong. English Wikipedia prohibits generating or rewriting article content with language models, and allows copyediting and translation under human review (its policies on AI, as of October 2026).
• A project in a foundation. Your foundation may already have answered part of the question. The Linux Foundation accepts AI-generated contributions and lets each project write its own guidance. The Apache Software Foundation asks contributors to check the tool’s terms and any third-party material in the output, and recommends a Generated-by: line in the commit message. Write your policy inside theirs.
• A distribution, or a project that needs the provenance. That’s where the bans are: Gentoo and NetBSD ship what they accept, and QEMU’s contributors can’t certify the DCO for code whose origin nobody knows. Debian is the counterexample: its developers voted on August 29, 2026 for responsibility, because “the use of a generative AI tool does not diminish the contributor’s responsibility”.
• A security inbox. Reports are where no CI helps. curl allows AI in code and asks every reporter whether they used it, and Django closes unverified AI reports without a response. Your rules for reports can be stricter than your rules for code.
• Maintainers who use AI tools. Ghostty’s maintainers use them daily, and its policy exempts them in writing. Applying the same rules to everyone works too. Saying nothing doesn’t, because contributors find out.
• Newcomers. A good first issue exists to teach someone the project. LLVM forbids fixing one with AI tools. Godot went further on June 30, 2026: contributors with three merged pull requests or fewer need a maintainer’s approval before they send a new feature or a significant refactor.
• A flood. Disclosure tells reviewers where to look harder, and the volume settings in Ask for an explanation, not a detector slow down whoever sends ten pull requests in an hour. Godot banned AI-written code because its “number of qualified reviewers is small”.
• No flood yet. Most projects are here. A short policy tells contributors where you stand, and you can tighten it the day you need to.

A policy you can paste#

Pick the base text for your posture, then add the blocks your rows list. Copy them into your CONTRIBUTING.md, replace the words in square brackets, and change what doesn’t fit: the text in every block on this page is in the public domain (CC0), no attribution needed.

Allow with responsibility, for a project whose review and tests already catch bad changes:

## AI tools

You may use AI tools to contribute. You're responsible for what you send, as if you had written every line yourself.

- **Understand it.** You must be able to explain every line in your own words. If a maintainer asks and you can't, we close the pull request.
- **Run it.** Build and test the change yourself before you open the pull request. "The tool says it works" isn't a test.
- **Keep it small.** No changes unrelated to the issue, however tidy.

You don't have to tell us which tools you used, but it helps the review.

Maintainers may close contributions that break these rules without a detailed review.

Disclose, for a project that wants its reviewers to know where to look harder:

## AI tools

You may use AI tools to contribute. You're responsible for what you send, as if you had written every line yourself.

- **Say so.** If a tool wrote a significant part of your change, name it in the pull request description. Line completion doesn't count.
- **Understand it.** You must be able to explain every line in your own words. If a maintainer asks and you can't, we close the pull request.
- **Run it.** Build and test the change yourself before you open the pull request. "The tool says it works" isn't a test.
- **Keep it small.** No changes unrelated to the issue, however tidy.

Maintainers may close contributions that break these rules without a detailed review.

Then add a line to your pull request template, so that disclosure is a checkbox and not a confession:

### AI tools

- [ ] I didn't use AI tools for this change, or only for line completion.
- [ ] I used: <!-- tool and what for -->. I reviewed, ran and can explain every line.

Ban, for a project that must know who wrote each line. Say why, so contributors know what they agree to.

## AI tools

Don't send us code, documentation or text generated by AI tools, because [why: your license, the DCO, what your downstream requires].

Line completion and spell checkers are fine, and so are tools that help you research or debug, as long as their output isn't in your contribution.

By opening a pull request, you confirm that you wrote it yourself. If you're not sure whether a tool counts, ask us first.

We'll review this policy by [a date].

Each line comes from projects that needed it:

• “Say so” is Ghostty’s, Fedora’s and the Linux kernel’s rule, limited to significant use, because nobody wants a disclosure for autocomplete.
• “Understand it” is in every policy above, ban or not. It’s also the one you can check, by asking.
• “Maintainers may close” is what makes the rest enforceable without an argument, whatever the size of your team.
• The ban’s exceptions are QEMU’s, which doesn’t cover research, static analysis or debugging “provided their output is not included in contributions”, and Godot’s, which allows “code completion, regex, or find and replace”. The review date follows Gentoo, whose council said it would revisit its ban.

Add the blocks your project needs#

Each block adds a few lines under your base text. Keep the ones your rows list and delete the rest. The comments say who each line is for, and GitHub doesn’t show them.

<!-- Facts and sources, for docs and content: no test checks a fact. -->

- **Check every fact.** Run every command a tool wrote, open every link, and check every version number against its source. Don't cite a source you haven't read.

<!-- Conversations: keep one of the two lines. -->

- **Write to us yourself.** Descriptions, comments and replies to reviews are yours. Translation tools are fine.
- **Edit what a tool wrote.** You may use AI tools for issues and comments, but read and trim every one before you post it.

<!-- Newcomers, for projects that mentor them. -->

- **Leave good first issues to people learning the project.** Don't solve them with AI tools.
- **Start small.** Until you've had a few pull requests merged, ask a maintainer before you send a new feature or a large refactor.

<!-- Agents. -->

- **No unattended agents.** Don't let a tool open pull requests, issues or comments here without you reviewing each one first.

<!-- Volume, after a flood. -->

- **Open an issue first.** We review pull requests for issues a maintainer has accepted. Others may be closed without review.
- **Repeat senders are blocked.** We block accounts that keep sending contributions that break these rules.

<!-- Sign-off, if you use the DCO. -->

- **Sign off yourself.** If this project asks for a `Signed-off-by:` line, only a human adds it. Name the tool in an `Assisted-by:` line instead.

If you have a security inbox, the rule goes in your SECURITY.md, as Security for Maintainers explains:

## Reports written with AI tools

Reproduce the problem yourself before you report it, and put the steps in the report. Say whether you used an AI tool to find the problem or to write the report. We close reports we can't reproduce without a reply, and we block repeat senders.

If your maintainers use AI tools, tell contributors how. Keep one of the two last sentences:

### How we use AI tools

Maintainers use [which tools] for [what: reviews, tests, triage, code].
The rules above apply to us too.
The rules above apply to outside contributions. Maintainers use AI tools at their own discretion and answer for what they merge.

The blocks come from these projects:

• “Write to us yourself” is Jellyfin’s rule: its code may be LLM-assisted, its conversations may not. “Edit what a tool wrote” is Ghostty’s: issues and discussions may use AI if a human reviewed “and edited” them.
• “Good first issues” and “No unattended agents” are LLVM’s and Node.js’s. “Start small” is a softer version of Godot’s rule for new contributors.
• “Sign off yourself” is the Linux kernel’s, for projects that use the DCO.
• The security block combines curl’s question on its report form and Django’s rule for unverified reports.
• “How we use AI tools” puts Ghostty’s exemption, or its opposite, where contributors read the rules. “Check every fact”, “Open an issue first” and “Repeat senders” are ours, for situations the policies above leave to the reviewer.

Ask for an explanation, not a detector#

You’ll see the signs: an API that doesn’t exist in your version, a refactor nobody asked for, a description three times longer than the diff, confident and wrong. Humans do all of these too, and detection tools are wrong often enough that you shouldn’t close anything on their score.

Ask the one question a tool can’t answer for the author: why this change, in their own words. Reviewing Pull Requests uses the question: label for it. An author who answers gets a normal review. One who pastes a generated answer, or doesn’t answer, gets closed under “Understand it”, with no accusation.

When volume is the problem, limit volume. A project that hasn’t had a flood can leave these settings off, and know where they are. GitHub added three in 2026:

The cap is the one to try first: it doesn’t close the door; it slows down whoever sends ten pull requests in an hour. Collaborators-only is what tldraw did by hand, and it turns your project into a read-only one for outsiders.

Ghostty built a middle way: a vouch list. A pull request from someone not on it is closed by a bot, and a maintainer can vouch for them in one comment. On this translation, a maintainer vouched 37 seconds after the bot’s comment, and the pull request was merged the next morning:

Don’t accuse, and don’t pretend it isn’t happening#

This section is our opinion, from reading the policies above and the threads around them.

• Close on the rule, not on the suspicion. “This looks AI-generated” can’t be proven and starts an argument. “This changes files the issue doesn’t touch” or “you couldn’t explain this function” can, and it’s what you’d say to a human.
• Hold yourself to the rule you write. Ghostty exempts its maintainers and says so, and that’s a legitimate choice. A policy that bans a tool the maintainers use in secret isn’t one. Contributors notice.
• Say where you stand, even in one sentence. Without a line, each reviewer decides alone, and two contributors doing the same thing get two answers. “Our usual review applies to AI-assisted work, and you answer for every line” is a policy too.
• Publish your blocklist only if you’re ready to maintain it. Ghostty keeps a public list of people it denounced. A public list is a public accusation, and someone will ask to be removed.

The copyright question isn’t settled#

In the United States, output with no human author can’t be copyrighted. The Copyright Office’s report of January 29, 2025 says AI output is protected “only where a human author has determined sufficient expressive elements”, and that prompts alone aren’t enough. The courts agreed in Thaler v. Perlmutter (March 18, 2025), and the Supreme Court declined the appeal on March 2, 2026. Code a person wrote with a tool’s help can still be theirs.

What that means for a contribution under your license, and for code a model reproduces from its training data, is open, and it differs from country to country. It’s the strongest argument for the bans. Licenses for Things That Aren’t Code covers what’s known about model licenses. For a real dispute, ask a lawyer.

Do this now#

• Find the rows that describe your project, and pick the strictest posture among them.
• Add an “AI tools” section to your CONTRIBUTING.md: that posture’s base text and the blocks your rows list, or one sentence of your own.
• If you ask for disclosure, add the “AI tools” checkboxes to your pull request template.
• If you have a SECURITY.md, add that a report needs a reproduction and must say whether AI tools were used.
• If your maintainers use AI tools, say how, and whether the rules apply to them.
• Save a reply that asks the author to explain the change in their own words.
• If outside pull requests outnumber your reviews, set a limit on open pull requests without write access.

Go further#

• AI Slop Is Flooding Open Source: how curl, Godot, Ghostty, the Linux kernel, Debian and Jazzband answered, each from its own constraint.
• Linux kernel guidelines for tool-generated content: the shortest policy from the largest project, with the reasons.
• ASF Generative Tooling Guidance: what a foundation asks of every project under it, license checks included.
• Contributing with AI Tools Without Annoying Maintainers: the same rules, from the contributor’s side.