Short answer: a blanket ban is not the only reasonable way to handle AI-assisted contributions—and a new large-scale study suggests maintainers should pay at least as much attention to disclosure, human responsibility and enforceable review rules as to whether AI is allowed at all.
A preprint published on August 4, 2026 analyzed 29,624 active GitHub repositories and found only 385—about 1.3%—with an explicit, contributor-facing AI policy during the study window. The authors then compared different policy styles and repository outcomes using matched controls and a difference-in-differences design.
The interesting result is not “AI pull requests are good” or “AI pull requests are bad.” It is that policy design appears to matter.
Repositories in the study’s Regulated & Controlled family—rules that allow some AI use but combine it with clearer oversight—were associated with more disclosure and review participation, lower measured vulnerabilities, and continued AI-assisted contribution activity. Strict-prohibition policies reduced observed AI-assisted merged throughput, but did not eliminate observed AI-assisted activity.
That is useful evidence for maintainers deciding whether to ban, tolerate or regulate AI-generated code. It is not a universal verdict: the paper is a recent preprint, the post-policy observation window is short, and the design is observational rather than a randomized experiment.
Research and policy check: August 17, 2026.
What the study actually measured
The paper, Making AI Visible, Not Vanished: How AI Policies Reshape Developer Experience on GitHub, examined active open-source repositories and identified human-facing rules governing AI-assisted contributions.
The researchers excluded files aimed only at coding agents, such as AGENTS.md and CLAUDE.md, because those are instructions to tools rather than contribution policies for people. They ultimately identified 385 repositories with explicit AI policies adopted between February 2025 and April 2026, then matched 379 of them with repositories without comparable policies.
To compare the policies, the authors created a five-part framework called TRACE:
| Dimension | Question for maintainers |
|---|---|
| Transparency | Must contributors disclose that AI was used? |
| Responsibility | Is a human explicitly accountable for understanding and validating the output? |
| Attribution | Must contributors address provenance, licensing or source-rights concerns? |
| Constraints | Which uses of AI are allowed, restricted or prohibited? |
| Enforcement | What happens when contributors ignore the policy? |
The policies were then grouped into five families: Permissive & Open, Disclosed but Soft-Enforced, Regulated & Controlled, Quiet & Low-Requirement, and Strict Prohibition.
Only 45 of the 385 policies—11.7%—fell into the strict-prohibition family.
The most useful finding: “regulated” did not mean “no AI”
The study’s Regulated & Controlled group produced one of the more interesting combinations.
Compared with matched controls, the paper reports that this family was associated with:
- 7% higher AI-disclosure share;
- 7.3% more reviewers per pull request;
- 28% fewer SonarQube-flagged vulnerabilities;
- 9% higher AI-assisted PR share; and
- 11% higher AI-assisted merged throughput.
Those numbers should not be read as a promise that copying a policy template will make a repository 28% safer. They are estimated short-term associations in the authors’ model, and repository communities differ enormously.
But the pattern is useful: allowing AI and demanding accountability are not opposites. A project can permit AI-assisted work while making contributors explain, test and stand behind what they submit.
What happened under strict bans?
Strict prohibition did reduce observed AI-assisted merged throughput—but only by about 3.9% in the study’s model. The researchers still observed a positive AI-assisted PR share and positive disclosure share in this policy family.
That does not prove people were deliberately evading bans. Detection of AI assistance is imperfect, policies vary, and some identified activity may reflect the study’s classification method.
It does show why a rule that simply says “no AI-generated code” may be incomplete as a governance strategy. Maintainers still need a process for review, responsibility and enforcement.
The strict-prohibition family was also associated with lower code-smell counts and higher maintainer-response share, so the paper is not evidence that bans are useless. Rather, it suggests the trade-off is more complicated than “ban equals quality, allow equals chaos.”
Three policy choices, compared
A practical way to read the study is to separate three common approaches.
| Approach | What it solves | What it can miss | Good fit when… |
|---|---|---|---|
| Blanket ban | Creates a simple boundary and can discourage low-effort generated submissions | AI use may be difficult to identify; the rule says little about review, provenance or accountability | The project has unusually high trust, licensing, safety or maintainer-capacity constraints |
| Disclosure only | Makes AI assistance more visible | Disclosure without validation can still leave maintainers reviewing work the contributor barely understands | The project mainly needs transparency and already has strong review discipline |
| Disclosure + human accountability + scoped restrictions + enforcement | Makes AI visible while defining responsibility and unacceptable uses | Takes more policy design and consistent enforcement | The project wants to accept useful AI-assisted work without treating generated output as trusted by default |
The third option is the most interesting starting point from this paper—not because the study proves it is universally best, but because it turns an argument about tools into a policy about contribution quality.
A maintainer policy can fit into five questions
A project does not need a 2,000-word AI constitution. TRACE can be turned into five concrete decisions.
1. Must AI use be disclosed?
Define what counts. Does autocomplete count? What about generating a test, refactoring a function, drafting documentation, or producing most of a pull request?
A useful rule is specific enough that two contributors would interpret it similarly.
2. What must the human contributor personally verify?
The strongest practical requirement is not “did a model touch this code?” It is:
Can the contributor explain and defend the submitted change?
A policy can require the author to understand the code, run relevant tests, check generated dependencies or APIs, and respond to review questions without delegating responsibility back to a model.
3. What provenance or licensing checks are required?
AI-assisted output can create uncertainty around copied patterns, generated assets, dependency suggestions and source attribution. A project can require contributors to confirm that they have checked relevant licensing and provenance obligations rather than assuming the tool handled them.
4. Are any uses explicitly off-limits?
A policy does not have to choose between “everything allowed” and “nothing allowed.” Projects can restrict narrower categories such as:
- bulk, unsolicited AI-generated pull requests;
- generated issue spam;
- security-sensitive changes without deeper human review;
- changes the submitter cannot explain;
- automated submissions that bypass the normal contributor workflow.
The right boundary depends on the project. The important part is making it explicit.
5. What happens when the policy is ignored?
A rule with no consequence is only a suggestion.
Enforcement can be lightweight: close the pull request, request a disclosure, require additional review, or restrict repeated abusive submissions. The paper’s results are particularly interesting here because stronger enforcement levels were associated with fewer measured vulnerabilities, although they were also associated with fewer active contributors at the highest level.
That is a real trade-off rather than a free win.
A 20-minute implementation checklist
GitHub already provides two simple places to turn an AI policy into a contributor workflow: CONTRIBUTING.md and a pull request template.
GitHub surfaces contribution guidelines to people opening issues and pull requests, while pull request templates can automatically place required prompts into a new PR description.
A small project can start with this:
- Add an AI-assisted contributions section to
CONTRIBUTING.md. - Define what must be disclosed and what does not need disclosure.
- State that the human author remains responsible for correctness, tests, security and licensing.
- Put a disclosure prompt in the pull request template: “Was AI used to produce or substantially modify this change? If yes, describe how.”
- Require the contributor to confirm they can explain the change and have run the relevant tests.
- List any prohibited uses, such as bulk unsolicited generated PRs.
- State the likely response to nondisclosure or repeated low-quality submissions.
- Review the policy after a month or two using actual maintainer workload and defect data rather than arguments about AI in the abstract.
The last step matters. A policy should be treated like any other engineering process: measure whether it reduces review burden and improves contribution quality.
A contributor checklist before opening an AI-assisted PR
Even when a repository has no explicit AI policy, contributors can avoid most of the predictable friction by checking five things before submitting:
- Can every meaningful change be explained without asking the model again?
- Were the relevant tests actually run?
- Were new dependencies, APIs and generated factual claims verified?
- Are licensing, attribution and provenance obligations understood?
- If the project asks for AI disclosure, is it complete rather than strategically vague?
This changes the role of AI from “author whose output should be trusted” to a tool whose output still has an accountable human owner.
What remains uncertain
This study is unusually large, but there are several reasons not to turn it into a universal rulebook.
First, it is a preprint, not a final consensus statement. Second, explicit AI policies are still rare in the dataset, so some policy configurations have small samples. Third, AI-policy adoption is recent, which limits the available post-adoption window.
The researchers used matching, event-study checks and a staggered difference-in-differences design; all 19 measured outcomes passed their reported pre-trend check. That strengthens the analysis, but it cannot remove every difference between repositories that choose to adopt AI rules and those that do not.
The paper also intentionally excludes agent-guidance files such as AGENTS.md. So its conclusions are about human-facing contributor governance, not about whether a repository should include instructions for coding agents.
Finally, both AI coding tools and contributor behavior are changing quickly. A policy that works in 2026 may need revision as agents become more autonomous or as GitHub adds new platform controls.
What to watch next
Three questions will make this topic much clearer over the next year:
- Do longer observation windows preserve the apparent quality gains? Short-term policy effects can fade as contributors adapt.
- Will GitHub add first-class AI contribution metadata? Standardized disclosure would make enforcement and research much easier than free-form text.
- Will projects regulate autonomous agent submissions separately from human-assisted coding? The current study deliberately separates those two problems, but real contribution workflows are increasingly mixing them.
For now, maintainers do not need to settle the philosophical argument over whether AI “belongs” in open source. A more useful question is operational:
What evidence and responsibility should accompany every contribution, regardless of which tools helped produce it?
Conclusion
The new GitHub study does not prove that open-source projects should allow AI-generated pull requests. It does show why a binary allow/ban rule is a weak substitute for contribution governance.
The most practical default is to make AI use visible, keep a human accountable, restrict the uses that create disproportionate review or security risk, and state how the rules will be enforced. Then measure whether those rules actually improve the project.
That is more work than adding “AI PRs prohibited” to a README—but it is also much closer to the problem maintainers are trying to solve.
Sources
- Chen, Zimmermann & Trinkenreich — Making AI Visible, Not Vanished: How AI Policies Reshape Developer Experience on GitHub (arXiv, Aug. 4, 2026)
- GitHub Docs — Setting guidelines for repository contributors
- GitHub Docs — Creating a pull request template for your repository
- GitHub Docs — Managing and standardizing pull requests
- Wikimedia Commons — Wikimedia Hackathon 2013 photo by Sebastiaan ter Burg, CC BY 2.0