---
slug: ai-contribution-policy
type: pattern
summary: "Set explicit rules for agent-assisted contributions so maintainers can demand disclosure, evidence, ownership, and limits before spending review time."
created: 2026-08-31
updated: 2026-08-31
related:
  agentic-pull-request:
    relation: governs
    note: "The contribution policy defines what an agentic pull request must disclose and prove before maintainers review it."
  agent-provenance:
    relation: uses
    note: "Disclosure requirements depend on provenance that records how an agent-assisted artifact was produced."
  approval-policy:
    relation: specializes
    note: "An AI contribution policy applies approval rules to contributions that involve coding agents."
  human-in-the-loop:
    relation: uses
    note: "Contributor accountability requires a person who understands the change and can answer for it."
  review-bottleneck:
    relation: mitigates
    note: "Eligibility rules and evidence requirements keep low-effort agent output from consuming scarce review time."
  verification-loop:
    relation: enforces
    note: "Required checks turn a claim that the contribution works into evidence maintainers can inspect."
  instruction-file:
    relation: uses
    note: "Repository instructions put the contribution rules where coding agents can read them before they act."
---
# AI Contribution Policy

> **Pattern:** A named solution to a recurring problem.

*Publish a repository-level contract for agent-assisted contributions, then put its disclosure, evidence, and accountability rules in the paths humans and agents actually read.*

*Also known as: Generative AI Contributions Policy, AI-Assisted Contribution Policy*

A maintainer opens a pull request that looks plausible but can't tell who understood the change, which parts an agent wrote, or whether anyone ran the claimed tests. Maintainers need enough ownership and evidence to decide whether the contribution deserves review; detecting AI use doesn't answer that question.

## Understand This First

- [Agentic Pull Request](agentic-pull-request.md) — the reviewable artifact governed by the policy.
- [Agent Provenance](agent-provenance.md) — the record of which agent, model, and instructions produced an artifact.
- [Review Bottleneck](review-bottleneck.md) — the scarce maintainer capacity the policy protects.

## Context

Coding agents make it cheap to produce a branch, fill out a pull request, and respond to review comments. They don't make review cheap. A maintainer still has to recover intent, check fit, inspect the code, and decide whether the submitted evidence is trustworthy.

That mismatch is sharpest in open repositories and shared internal platforms. Contributors arrive with different tools, skill levels, and incentives, while maintainers carry the cost of every plausible-looking change. A normal contribution guide may say how to format commits and run tests, yet leave agent-assisted work unaddressed.

An AI Contribution Policy is a repository-level contract for that missing case. It states which uses of coding agents are allowed, what contributors must disclose, what they must personally understand, which evidence must accompany the change, and when maintainers may close it without further review.

## Problem

A blanket ban is hard to verify and may reject careful contributors who use agents as tools. A permissive policy without proof shifts the cost to maintainers: contributors can generate changes faster than reviewers can establish whether those changes are correct.

How do you accept useful agent-assisted work without turning the review queue into a free verification service for unowned output?

## Forces

- **Access versus ownership.** Agents can help more people contribute, but the person submitting the change still has to understand and defend it.
- **Disclosure versus detection.** Honest disclosure supports good review. Trying to infer agent use from prose or code is noisy and doesn't prove who verified the result.
- **Uniform rules versus repository capacity.** A mature project may accept guarded agent use, while a small maintainer team may need strict eligibility or volume limits.
- **Written policy versus actual behavior.** A policy nobody reads won't change a contribution. The repository has to surface it to both the human and the agent.
- **Fast submission versus costly proof.** Generating a patch is quick; producing trustworthy tests, explanations, and reproduction steps is where the contributor earns review.

## Solution

**Write an explicit AI Contribution Policy and make compliance part of contribution admission.** Treat it as an extension of the contribution guide, not as a statement of attitude toward AI. The policy should answer operational questions a contributor can follow and a maintainer can enforce.

Set the allowed-use boundary first. You might allow agents for brainstorming, tests, documentation, or implementation under human supervision while refusing unattended submissions. Another project may allow autonomous agents only for labeled issue classes. The right boundary depends on review capacity and consequence, so name it instead of relying on a social norm.

Require disclosure that helps review. Ask which parts were agent-assisted, which tool was used when that affects reproducibility, and what the contributor checked personally. Don't ask for ritual confession. [Agent Provenance](agent-provenance.md) is useful when it tells a maintainer how the artifact was produced; a bare "AI used" label isn't.

Make a human contributor accountable for the whole change. They should be able to explain the design, answer review questions, and revise the code without forwarding every comment blindly to an agent. If nobody understands the submission well enough to own it, the repository doesn't have a contributor. It has an unverified patch.

Define the evidence bar in concrete terms: tests on the submitted revision, reproduction steps for a bug fix, an explanation of non-obvious choices, and any project-specific checks. Connect these requirements to the [Verification Loop](verification-loop.md) and the [Agentic Pull Request](agentic-pull-request.md) template so the evidence arrives with the change.

Put the policy in every path that matters. Link it from `CONTRIBUTING.md`, add disclosure and verification fields to the pull-request template, and summarize its operative rules in the repository's [Instruction File](instruction-file.md). Add mechanical checks for fields or labels you can verify. A prose rule and an automated gate solve different parts of the problem.

State the enforcement path. Maintainers may request missing evidence, close noncompliant submissions, limit contribution volume, or suspend agent-assisted work when review capacity is exhausted. Include an appeal or clarification route for cases the policy didn't anticipate. Enforcement should protect the queue, not invite arguments about whether a detector thinks a person used AI.

> **⚠️ Warning:** Don't make AI detection your enforcement mechanism. A detector scores a proxy for authorship, can flag human work, and still can't tell whether a contributor understood or verified the change. Enforce observable submission requirements instead.

## How It Plays Out

An infrastructure project allows agent-assisted pull requests but requires a human-authored rationale, a disclosure checkbox, tests run on the submitted commit, and a contributor who can answer review questions. A contributor submits a generated cache refactor with no explanation and a pasted claim that tests passed. The maintainer asks once for the missing evidence, then closes the pull request under the published policy. The decision rests on absent proof, not a guess about who typed the code.

A small library has two volunteer maintainers and a flood of generated feature requests. Its policy permits agents for documentation and tests but accepts agent-written implementation only for issues labeled `agent-ready`. The pull-request template copies that limit, and the repository instruction file tells agents to check the label before editing. Submission volume falls, while contributors still use agents on work the maintainers have chosen to review.

Inside a company, a platform team takes the more permissive route. Any employee may submit agent-assisted code, but changes to authentication and billing require a named human reviewer plus CI evidence from the branch. Low-risk documentation fixes clear a lighter gate. The policy composes with [Approval Policy](approval-policy.md): one contract governs contributors, while the other sets the action and merge boundaries enforced by the platform.

## Consequences

**Benefits.** Contributors know the rules before they spend time on a change. Maintainers can reject incomplete submissions by pointing to an observable contract, which reduces case-by-case argument. Disclosure and provenance improve auditability, while required evidence moves part of verification back to the person asking for review. A policy can also preserve access: careful agent use remains welcome even when unattended output isn't.

**Liabilities.** The policy adds work for contributors and maintainers. Strict disclosure can create stigma or encourage evasive wording, while loose requirements won't protect the queue. Mechanical checks can verify that a box was checked, not that a person understands the code. The policy also ages: agent tools, repository capacity, and failure modes change, so maintainers have to revise the contract when its rules stop matching the work.

The deepest limitation is enforcement. A repository can judge the submitted artifact, evidence, and contributor behavior; it usually can't establish every tool used along the way. A sound policy therefore governs what maintainers can observe and what contributors must stand behind.

## Sources

GitHub's [maintainer guidance for AI-first contributors](https://github.blog/open-source/maintainers/your-contributors-are-ai-first-now-is-your-project/) describes repository instructions, pull-request templates, and automated gates as ways to shape agent-assisted contributions before review.

Two July 2026 studies ([arXiv:2607.26819](https://arxiv.org/abs/2607.26819) and [arXiv:2607.04003](https://arxiv.org/abs/2607.04003)) examine the sustainability cost of high-volume agent contributions and test how coding agents comply with repository rules. The compliance experiments found that agents rarely retrieved those rules without deliberate steering, while quoted rules, reminders, and verifier feedback improved compliance.

The Cloud Native Computing Foundation's [account of contribution policy in the Kyverno project](https://www.cncf.io/blog/2026/03/10/sustaining-open-source-in-the-age-of-generative-ai/) grounds the policy tradeoff in maintainer capacity and open-source sustainability.

The Carpentries' [Generative AI policy](https://docs.carpentries.org/policies/genai-policy.html) and Mastodon's [AI contribution policy](https://github.com/mastodon/.github/blob/main/AI_POLICY.md) are two concrete contracts that assign responsibility to the human contributor while setting different limits on autonomous work.

---

- [Next: Approval Fatigue](approval-fatigue.md)
- [Previous: Agentic Pull Request](agentic-pull-request.md)