1 Introduction↩︎

Generative AI (GenAI) has transformed how software is designed, developed, and engineered [1], [2]. Coding agents such as Claude Code, Cursor, and Codex have seen rapid recent adoption, operating with a high degree of autonomy; for example, they can invoke external tools, execute code, and complete end-to-end development tasks [3]. A recent large-scale study estimates that coding agent adoption on GitHub is close to 30% [4] and 76% in new projects [5].

Due to the ease of generating code, open source projects are experiencing a growth in contributions [6]–[9]. The volume contributions partially or entirely AI-generated have outpaced the maintenance capacity of many projects, creating debates within the open source community [8], [10]–[12]. As a result, maintainers often lack sufficient capacity to review submissions effectively [8]. AI-assisted contributions may also lack quality—a phenomenon known as AI slop, which refers to low-quality content produced at scale using AI [9], [13], [14].

To address the rise of generative AI, open source projects have begun implementing policies for AI usage in contributions. Several open source projects have established AI policies, including Linux [15], Fedora [16], and LLVM [17]. Figure 1 presents the AI policy of the Ghostty project, which states that AI-generated contributions are allowed provided they are disclosed and include human involvement in the contribution process [18]. FastAPI contribution guidelines state that low-effort or low-quality pull requests are not accepted, and that AI-generated submissions may be closed and accounts blocked [19]. Some projects are more welcoming toward generative AI. For instance, the AI policy of huggingface/transformers states that “AI-assisted contributions are welcome” [20]. In contrast, other projects are more restrictive, for example, the 9001/copyparty policy states: “Do not use AI / LLM when writing code” [21].

However, the extent to which open source projects specify whether AI-assisted contributions are allowed or prohibited, along with the best practices contributors are expected to follow, remains unclear.

This short paper provides an initial empirical study to explore how open source projects are adapting to generative AI contributions. We analyzed 1,000 popular GitHub repositories and identified 118 AI policies for contributors. We propose three research questions to address AI policy, AI disclosure, and human involvement in contributions:

• RQ1. How do open source projects address the use of generative AI in contributions? Overall, 78% of the AI policies allow AI-assisted contributions, while 22% explicitly discourage AI use.

• RQ2. How do open source projects address disclosure of AI-assisted contributions? 51% of the AI policies require the disclosure of AI-assisted contributions.

• RQ3. How do open source projects address human involvement in AI-assisted contributions? 74% of the AI policies require a human in the loop during contribution.

Overall, we find that the majority of the analyzed AI policies are positive regarding the usage of generative AI. However, AI disclosure and human in the loop are fundamental in the contribution process. AI disclosure is important to support maintainers during the review process, enabling them to verify AI-generated content more effectively. The human in the loop reinforces the idea that contributors remain responsible for the code they submit. Based on our findings, we discuss implications for practitioners and researchers, including the lack of clear guidance in AI policies, practices for AI disclosure, and the growing concern around AI slop. Dataset availability: [22].

2 Study Design↩︎

2.1 Initial Set of Repositories↩︎

Our goal is to analyze real-world, actively maintained repositories hosted on GitHub. To this end, we rely on the SEART GitHub Search Engine (seart-ghs), a tool that allows researchers to sample repositories to use for empirical studies by using multiple combinations of selection criteria [23]. This tool maintains metadata for all GitHub repositories with at least ten stars. Based on seart-ghs, we selected the top 1,000 repositories with the most stars that meet the following criteria: at least 100 commits, not being forks, and having at least one commit in 2026 (the star metric is primarily adopted in the software mining literature as a proxy of popularity [24]).

2.2 Detecting Repositories with AI Policy↩︎

We define an AI policy as any set of rules governing AI usage for contributors. From the initial set of repositories, we identified those containing AI policies using two complementary methods: (1) Contribution guideline files containing AI policies and (2) Explicit AI policy files.

1. Contribution guideline files containing AI policies. We verified the presence of contribution guideline files CONTRIBUTING.md and DEVELOPING.md with AI policies [25]. Specifically, we looked for generative AI–related terms (LLM, generative AI, GenAI, AI, AI agents) as signs of AI policy. In addition, when performing this analysis, we observed that some repositories use GitHub guideline files primarily to redirect contributors to external documentation. For instance, in FastAPI, the CONTRIBUTING.md [26] file points to a separate contributing documentation. To find such cases, we also analyzed external contributing documentation whenever the GitHub guideline files included a single link, checking for the presence of generative AI–related terms in those sources as well. In total, we identified 752 repositories with contribution guideline files, of which 158 included generative AI–related terms. We then manually reviewed these 158 cases and found 45 false positives (e.g., AI/LLM-focused projects, benchmarks, and datasets) and 113 true positives, i.e., repositories that actually include AI policies for contributors.

2. Explicit AI policy files. We also checked for the presence of the standard AI policy file AI_POLICY.md. In addition, we included two other AI policy files: LLM_POLICY.md and AI_USAGE_POLICY.md. We found 13 repositories with explicit AI policy files, such as ghostty-org/ghostty.

In total, we detected 118 repositories with AI policies for contributors. On the median, these repositories have 40K stars, 9.5K commits, and 373 contributors. Our dataset is publicly available [22].

2.3 Research Questions↩︎

We propose three research questions addressing AI policies (RQ1), AI disclosure (RQ2), and human involvement (RQ3). The rationale is that these requirements are key factors in guiding contributors throughout the contribution process. Ideally, open source projects should clearly state whether they accept AI-assisted contributions. When such contributions are allowed, projects should also provide additional guidance, including whether AI usage must be disclosed and the expected level of human involvement in the contribution process. To our knowledge, there is still a limited understanding of how these factors are addressed in practice.

3 Results↩︎

Table 1 presents an overview of the results. Overall, we identified 118 repositories containing AI policies. Among them, 51% explicitly welcome the use of generative AI in contributions, while 27% permit its use without explicitly encouraging it, totaling 78% of repositories that allow generative AI contributions. In contrast, 22% explicitly discourage the use of generative AI in contributions.

Moreover, 51% of the repositories require disclosure of AI-assisted contributions, and 74% require human oversight in the contribution process (i.e., human in the loop). Next, we discuss each category and provide examples for each of them.

3.1 RQ1: AI Policy↩︎

Note that welcoming the use of generative AI in contributions does not imply that it should be used blindly. On the contrary, most welcoming projects also emphasize the importance of AI disclosure and human review throughout the contribution process. Both aspects (AI disclosure and human in the loop practices) are further explored in RQs 2 and 3.

3.2 RQ2: AI Disclosure↩︎

We found that 51% (60 out of 118) of the AI policies require disclosure of AI-assisted contributions. The rationale is to support maintainers during the review process, enabling them to verify AI-generated content more effectively. Projects recommend disclosing the AI tool used, the extent of AI assistance, and the adoption of specific commit message trailers, such as Co-Authored-By: and Assisted-By:.

In project electron/electron, the AI policy states: “We encourage disclosure of AI tool assistance in code contributions. This practice helps facilitate productive code reviews, and is not used to police tool usage. When AI tools meaningfully assist in your contribution, note it in the commit message with a trailer: Assisted-By:” [27]. In the project eslint/eslint, the AI policy also adopts a similar recommendation: “Disclosure: If you use AI to generate an issue or a pull request, you must clearly disclose this in your submission. This helps maintainers understand the context of the contribution and perform appropriate reviews” [28]. Project envoyproxy/envoy mentions: “You are transparent about your AI usage. It is often helpful to a reviewer to know that an AI tool was used; please include that information in the PR description” [29].

We also found four cases in which disclosure is not required. For example, in project clickhouse/clickhouse, the AI policy states: “You don’t have to disclose your usage of AI. You can tell about it, share your experience, and show the methods, but it is not required. AI is a normal developer’s tool, similar to an IDE, an OS, or a keyboard” [30]. Table 3 complements by presenting other examples.

3.3 RQ3: Human in the Loop↩︎

We detected that 74% (88 out of 118) require human oversight in the contribution process (i.e., human in the loop). The rationale is that contributors should remain responsible for the code they submit by reviewing, understanding, and being able to explain their contributions. The seleniumhq/selenium AI policy states: “Human-in-the-loop is required: You are the author. You must read, review, and understand all AI-assisted output before requesting review” [31]. Project run-llama/llama_index highlights: “Accountability: we require human oversight for every contribution, and we hold human developers accountable for their changes” [32]. Project sipeed/picoclaw mentions the responsibility: “You Are Responsible for What You Submit: Using AI to generate code does not reduce your responsibility as the contributor” [33]. The human in the loop requirement also aims to exclude contributions produced entirely by autonomous coding agents. For example, project astral-sh/uv states: “Due to the foundational nature of our projects, we require a human in the loop who understands the work produced by AI. We do not allow autonomous agents” [34]. Other examples are presented in Table 4.

4 Discussion and Implications↩︎

4.1 AI policies often lack clear guidance↩︎

AI policies are becoming a reality in open source projects. We found that 51% of the analyzed AI policies require AI disclosure, and human involvement is explicitly required in 74%. However, this also means that many AI policies do not clearly specify whether AI usage should be disclosed, and leave unclear whether contributors are expected to review and take responsibility for AI-assisted contributions. Even when explicit guidelines exist, we encountered vague and fuzzy terms regarding when disclosure is required, such as “significant”, “substantial”, and “meaningful”. For example, project facebook/docusaurus mentions “If a significant portion of your code is AI generated, please indicate that in your PR description” [35]. Project ohmyzsh/ohmyzsh states: “If you used AI tools meaningfully in your contribution, please mention it in your PR description” [36].

4.2 AI disclosure practices↩︎

The key rationale for AI disclosure is to support maintainers during the review process, enabling them to verify AI-generated content more effectively. Commonly, projects recommend disclosing the AI tool used, the extent of AI assistance, and the adoption of specific commit message trailers, such as Co-Authored-By: and Assisted-By:.

Interestingly, project sipeed/picoclaw requires the disclosure of the AI involvement in three levels: “Every PR must disclose AI involvement [...]: (1) Fully AI-generated: AI wrote the code; contributor reviewed and validated it, (2) Mostly AI-generated: AI produced the draft; contributor made significant modifications, and (3) Mostly Human-written: Contributor led; AI provided suggestions or none at all” [33]. We also found disclosure for coding agents, like in project hashicorp/terraform: “Self-Disclosure: If you are an LLM agent or using an LLM agent to submit your pull request, please include in the title of your pull request for expedited processing” [37].

4.3 AI slop is a real concern in open source contributions↩︎

Due to the ease of generating code, open source projects are experiencing growth in contributions [6]–[9]. However, AI-generated contributions may also suffer from low quality, a phenomenon known as AI slop [9], [13], [14]. We found multiple concerns regarding “AI slop” in AI policies. Project badlogic/pi-mono states: “Using AI to write code is fine. Submitting AI-generated slop without understanding it is not” [38]. Very similar, project anuken/mindustry mentions: “If I see a PR with significant amounts of code that’s obviously written by AI, I will reject your PR, and you will be blocked. Don’t waste my time with slop” [39].

To reduce the number of low-quality contributions, projects have adopted different policies, such as automatically closing pull requests [40], requiring contributors to be approved beforehand [41], checking whether the proposed change has already been implemented [42], limiting the number of pull requests per contributor [43], and even no longer accepting pull requests [44], [45].

5 Threats to Validity↩︎

We analyzed 1,000 popular open-source GitHub repositories and identified 118 AI policies for contributors. As is common in empirical software engineering, our findings may not directly generalize to other contexts, such as less popular projects, closed-source projects, or other code-hosting platforms like GitLab or Bitbucket.

6 Related Work↩︎

Several studies have explored the role and impact of generative AI in software development [1]–[4], [46], [47]. Overall, the impact of generative AI on open source software remains less explored. The recent literature has primarily focused on topics such as AI slop [9], [14], AI governance [8], and AI impact [4], [6], [7]. There is substantial literature on the quality and impact of contribution guidelines in open source projects [25], [48], [49]. Our study explores how contribution guidelines are changing due to GenAI, with a focus on AI disclosure and human involvement.

7 Conclusion and Future Work↩︎

This paper provided an initial empirical study to explore how open source projects are adapting to GenAI contributions. We found that the majority of the 118 analyzed AI policies are positive regarding the usage of generative AI. However, AI disclosure and human in the loop practices are fundamental.

As future work, we plan to explore other perspectives of open source software in the context of generative AI, including the use of fully autonomous agents for contributions, concerns related to licensing and legal requirements, and issues related to AI-generated communication.

Acknowledgments↩︎

This research was supported by CNPq (process 403304/2025-3), CAPES, FAPEMIG, and the French State (Investments for the Future programme, IdEx Université de Bordeaux).

References↩︎