=== page 1 === Self-Admitted GenAI Usage in Open-Source Software Tao Xiao, Youmei Fan, Fabio Calefato, Christoph Treude, Raula Gaikovina Kula, Hideaki Hata, Sebastian Baltes B Abstract—The widespread adoption of generative AI (GenAI) tools such as GitHub Copilot and ChatGPT is transforming software develop- ment. Since generated source code is virtually impossible to distinguish from manually written code, their real-world usage and impact on open- source software (OSS) development remain poorly understood. In this paper, we introduce the concept of self-admitted GenAI usage, that is, developers explicitly referring to the use of GenAI tools for content creation in software artifacts. Using this concept as a lens to study how GenAI tools are integrated into OSS projects, we analyze a curated sample of more than 200,000 GitHub repositories, identifying 1,292 such self-admissions across 156 repositories in commit messages, code comments, and project documentation. Using a mixed methods approach, we derive a taxonomy of 32 tasks, 10 content types, and 11 purposes associated with GenAI usage based on 1,292 qualitatively coded mentions. We then analyze 13 documents with policies and usage guidelines for GenAI tools and conduct a developer survey to uncover the ethical, legal, and practical concerns behind them. Our findings reveal that developers actively manage how GenAI is used in their projects, highlighting the need for project-level transparency, attribution, and quality control practices in AI-assisted software devel- opment. Finally, we examine the longitudinal impact of GenAI adoption on code churn in 151 repositories with self-admitted GenAI usage and find no general increase, contradicting popular narratives on the impact of GenAI on software development. Index Terms—Software Engineering, Generative Artificial Intelligence, Large Language Models, Software Maintenance and Evolution 1 I NTRODUCTION T H e emergence of generative artificial intelligence (GenAI) tools such as ChatGPT and GitHub Copilot has redefined software development, as documented by litera- ture reviews [1], developer studies [2, 3], and productivity studies [4]. These tools assist developers in writing and re- viewing code, refining documentation, and automating vari- ous aspects of the software development lifecycle. Although Sebastian Baltes is the corresponding author. • T. Xiao is with Kyushu University, Japan. E-mail: xiao@ait.kyushu-u.ac.jp • Y. Fan is with Nara Institute of Science and Technology, Japan. E-mail: fan.youmei.fs2@is.naist.jp • F. Calefato is with University of Bari, Italy. E-mail: fabio.calefato@uniba.it • C. Treude is with Singapore Management University, Singapore. E-mail: ctreude@smu.edu.sg • R. G. Kula is with University of Osaka, Japan. E-mail: raula-k@ist.osaka- u.ac.jp • H. Hata is with Shinshu University, Japan. E-mail: hata@shinshu-u.ac.jp • S. Baltes is with Heidelberg University, Germany. E-mail: sebastian.baltes@uni-heidelberg.de ✦ prior research has evaluated the technical capabilities of GenAI tools [5] and surveyed their usability [3], only a few studies have systematically investigated their real-world adoption and usage patterns, for example, by mining GenAI mentions in repositories [6], analyzing AI-generated pull request descriptions [7], or compiling datasets of developer- ChatGPT conversations [8]. One reason is that only the tool vendors have access to fine-grained usage data [4] that allows them to determine which code suggestions were accepted and hence which code was co-authored by GenAI tools. Without additional context, generated code is virtually impossible to distinguish from human-authored code. As a result, much of what we know about GenAI usage in software development is inferred indirectly, either from vendor-controlled telemetry, laboratory studies, or analy- ses of repository activity that rely on aggregated metrics rather than direct evidence of GenAI use. This makes it difficult to understand how GenAI tools are actually in- tegrated into collaborative development workflows, how their use is governed in practice, and how their impact should be interpreted at the project level. In real-world settings, developers must decide how much to rely on or revise AI-generated content, and maintainers must deter- mine whether to prohibit, restrict, or encourage GenAI use. Researchers increasingly rely on aggregate metrics such as code churn to assess claims about software quality degra- dation. Without observable, project-level signals of GenAI usage embedded in software artifacts, these decisions risk being shaped by assumptions, anecdotal evidence, or broad industry narratives rather than by empirical data. Studying explicit references to GenAI usage offers a way to ground these discussions in real development practices, making it possible to examine not only what GenAI is used for, but also how it is acknowledged, regulated, and followed by human action in open-source software (OSS) projects. These projects, with their collaborative nature and pub- licly accessible repositories [9], offer a unique context to study the adoption of GenAI tools. Although such tools promise to support OSS projects by automating develop- ment tasks, there are also reports of “AI slop” wasting valuable time of maintainers [10] or GenAI-generated con- tributions leading to more rework [11]. We introduce the concept of self-admitted GenAI usage, inspired by the notion of self-admitted technical debt [12]. Just as developers acknowledge technical debt through === page 2 === comments and commits, they sometimes explicitly refer to using GenAI tools. These self-admissions can highlight tasks delegated to GenAI tools, challenges encountered, or changes made due to AI-generated content. Identifying such usage enabled us to explore three research questions (RQs). First, to understand the practical applications of GenAI tools in software development, we examined which tasks (e.g., writing test cases) are supported or automated by these tools, which contents (e.g., methods in source files) are referenced in GenAI-related mentions, and which pur- poses (e.g., acknowledging GenAI use) such mentions serve. We then investigated the regulation and recommendation of GenAI usage, and concluded with an analysis of code churn following the first GenAI mention in a project. RQ1 For which tasks, contents, and purposes do open-source developers mention GenAI tools? One finding that emerged was that project maintainers have begun to establish policies and usage guidelines re- garding their use (see Table 7). These regulations provide insights into emerging best practices, ethical considerations, and potential concerns surrounding GenAI adoption. Un- derstanding project-level policies is crucial for the respon- sible integration of GenAI tools in collaborative software development, leading to our second RQ: RQ2 How do open-source projects regulate or recommend the usage of GenAI tools? In addition to understanding how developers use GenAI tools and how projects regulate their usage, it is impor- tant to understand their impact on software quality and maintenance. The 2024 GitClear report [11], which received considerable attention in the developer community, claimed that increased code churn after GenAI adoption indicates “downward pressure on code quality.” The report defines code churn as “the percentage of lines that are reverted or updated less than two weeks after being authored,” interpreting such changes as “either incomplete or erroneous when the author initially wrote, committed, and pushed them” to the repository. To investigate this claim, we formulate a third RQ: RQ3 Does the code churn change after open-source projects start using GenAI tools? We conducted a large-scale empirical study of more than 200,000 OSS repositories hosted on GitHub. Our investiga- tion focused on identifying explicit mentions of GenAI tools in various artifacts and analyzing how these mentions relate to development activities. We followed a mixed methods approach, combining a qualitative analysis of GenAI-related mentions with a quantitative examination of code churn over time, resulting in four main contributions: 1) We introduce self-admitted GenAI usage as an empir- ical lens for studying GenAI adoption in open-source software and curate a dataset of 1,292 self-admitted GenAI usages across 156 GitHub repositories. 2) Using a mixed-methods approach, we derive a tax- onomy of GenAI usage comprising 32 development tasks, 10 content types, and 11 purposes, grounded in a qualitative analysis of the identified usages. 3) We empirically analyze how open-source projects gov- ern GenAI usage by examining 13 policies and usage guidelines, contextualized through a developer survey. 4) We assess the longitudinal impact of GenAI adoption on software evolution using a repository-level analysis of code churn in 151 projects, showing that GenAI adoption does not lead to a general increase in churn and that effects are stronger for generation tasks. 2 M ETHODOLOGY We followed a mixed-methods research design. Our data collection process is visualized in Figure 1. After retrieving instances of self-admitted GenAI usage from open-source GitHub repositories, we conducted a qualitative analysis to answer RQ1. Through multiple iterative coding phases, we labeled these instances to classify supported tasks and generated content. Since this qualitative analysis yielded a considerable number of statements that focused on the reg- ulation or recommendation of GenAI practices, we followed up with a closer analysis of these aspects as part of RQ2. For RQ3, we used self-admitted GenAI usages to approximate the time when the projects started using GenAI tools, to analyze the effect of GenAI usage on code churn using a Regression Discontinuity Design (RDD). 2.1 Repository Sampling The foundation of our research is a large sample of open- source GitHub repositories. We selected GitHub as our study platform because it is the largest and most widely used open-source hosting service, with over 500 million repositories according to the 2024 Octoverse report [13], making it the most suitable environment for analyzing trends of GenAI usage in open-source software develop- ment. Using the GitHub search tool provided by Dabic et al. [14], we selected repositories primarily written in the five most popular programming languages as of the above- mentioned report [13]: Python, JavaScript, TypeScript, Java, and C#. This focus on the most popular languages en- sures that our study is both manageable and relevant to the most commonly used development ecosystems. Since RQ3 aims at a comparison of code churn before and after projects started using GenAI tools, we only selected repos- itories that: (1) were created before the ChatGPT launch date (30 November 2022) and (2) had at least one com- mit on or after this date. Moreover, to eliminate dupli- cates, we excluded forks. Our initial sample of GitHub projects contained 207,062 repositories distributed across Python (77,542), JavaScript (48,500), TypeScript (37,424), Java (25,160), and C# (18,436). Since our interest is to study “engineered” software projects [15], we applied three additional filtering criteria. First, we excluded repositories not declaring a license or using non-standard licenses (marked as Other in the GitHub search tool). For the remaining repositories, we labeled all 38 distinct licenses we found and then removed projects declaring licenses not commonly used for software projects. These licenses included Creative Commons Attribution 4.0 International, Creative Commons Zero v1.0 Universal, Creative Commons Attribution Share Alike 4.0 International, and the SIL Open Font License 1.1. Second, we excluded repositories without any release on GitHub, fewer than two contributors, and those marked as archived. Third, we filtered the reposi- tories based on an analysis of various descriptive statistics. === page 3 === Select initial Filter engineered Search for mentions Identify self-admitted RQ1: 1. 2. 3. 4. repositories: software projects: 207,062 14,785 repositories repositories GitHub Search • Language: Python, Exclude repositories: JavaScript, TypeScript, • No or non-standard Java, or C#. license. • Creation: before 30 Nov • No release on GitHub. 2022 (ChatGPT launch). • < 2 contributors. • Activity: ≥ 1 commits after • Archived. ChatGPT launch. Additional filters based • Forks: Exclude. on #pull requests, #issues, LoC, and code ratio. of GenAI tools: GenAI usage: Manually annotate tasks, content types, and purposes of all self-admitted usages. 3,004 1,292 mentions usages RQ2: Analyze usages in context of Clone repositories and Manually analyze policies and guidelines in 12 search for mentions of GenAI mentions repositories; conduct follow-up Copilot/ChatGPT in all: according to our survey with contributors. • Source code files. inclusion criteria. • Code comments. RQ3: • Documentation files. Use date of first GenAI mention • Commit messages. as project-specific cutoff date for RDD analysis comparing code churn in 151 repositories. Figure 1. Overview of the data collection process used to answer our three research questions, from the selection (1) and filtering (2) of GitHub repositories to the extraction of GenAI mentions (3) and the identification of self-admitted GenAI usage (4) in these repositories. Table 1 Descriptive statistics for studied GitHub repositories (n = 14, 785). Min Mean Median Max Std Dev. # Issues 9 372 98 171,039 1,880 # Pull Requests 9 454 134 38,421 1,334 # Contributors 2 30 15 475 49 # Lines of Code 1,800 135,223 25,399 47,165,225 734,845 Code Ratio (%) 4.300 78.274 78.721 99.996 12 We analyzed the distribution of central repository properties per programming language. The properties we considered were the number of pull requests, the number of issues, and the repository size measured in lines of code (as provided by the GitHub search tool). To select engineered software projects with sufficient development data, we excluded repositories in the first quartile (Q1 ) for each metric, therefore removing the low- est 25%. Furthermore, we excluded repositories with a code ratio (defined as lines_of _code/(lines_of _code + lines_of _comments)) outside the 97% confidence interval. The rationale behind this threshold is that engineered soft- ware projects are usually documented using source code comments. Filtering out repositories beyond the 97% con- fidence interval helps eliminate outliers, that is, repositories with very little code, or codebases dominated by code without comments. A sanity check further confirmed that this ratio serves as a reliable indicator for filtering out non- software or poorly structured projects. Our final sample of GitHub repositories, obtained in February 2024, contained 14,785 GitHub repositories dis- tributed across Java (5,060), C# (3,544), TypeScript (2,464), Python (1,875), and JavaScript (1,842). Table 1 provides descriptive statistics for the studied GitHub repositories. 2.2 Identifying Self-Admitted GenAI Usages To identify self-admitted GenAI usage in our filtered sample of GitHub repositories, we retrieved mentions of the two most popular GenAI tools among developers as of the 2023 Stack Overflow Developer Survey [16]. In that survey, ChatGPT was identified as the most popular general AI tool and GitHub Copilot as the most popular AI developer tool. Then, in the second step, we annotated these mentions to identify those related to content generation. We wrote a Python script for the following process: Table 2 File extensions we included when searching for mentions of GenAI tools in our sample of GitHub repositories. Type Language File Extensions Code Python .py, .ipynb Code Java .java, .jsp Code TypeScript .ts, .tsx, .vue Code JavaScript .js, .jsx, .vue, .mjs, .cjs Code C# .cs, .aspx, .cshtml Doc. All .md, .markdown, .mdown, .mkdn, .mkd, .mdwn, .mdtxt, .mdtext, .txt, .text, .adoc, .asciidoc, .rst, .textile, .dbk 1) Clone the default branch of the repository. 2) Search all source code files for mentions of ChatGPT or Copilot within code comments; save the complete com- ments along with their language (i.e., the natural language such as English or Chinese). 3) Search all documentation files for mentions of ChatGPT or Copilot; save the lines in which the mentions were found, again along with their language. 4) Search all commit messages for mentions of ChatGPT or Copilot; save the corresponding commit messages along with their language. An initial analysis of all files in the repositories revealed a large number of false positive matches, that is, mentions of GenAI tools that were not related to content generation. Therefore, we decided to focus on specific file types when searching for mentions in source code and documentation files. We derived these lists based on common file extensions for the particular programming languages, as well as an analysis of all unique file extensions in which we found mentions during our first data collection run (see Table 2). We further decided to only search mentions of GenAI tools in source code comments, not across the whole source code. This is because, during our initial analysis, we found many false positives that were not related to content generation but to code that calls APIs related to ChatGPT or Copilot. We developed heuristics to reduce these false positives, which we outline in the following. For identifying mentions of GenAI tools, we employed regular expressions with the following pattern: re.compile(r'(.?)' + llm_tool + r'(.?)', re.IGNORECASE | re.DOTALL) === page 4 === where the variable llm_tool was assigned the value r'chat[ \-_]{0,1}gpt' for ChatGPT and r'co[ \-_]{0,1}pilot' for Copilot. These patterns allowed us to capture variations in how these tools were referenced while minimizing false positives. We developed heuristics to further reduce the number of false positives. For example, we noticed that in false positive matches, the mentions of GenAI tools were often surrounded by commas or underscores, e.g., when they were part of URLs for API calls. Our supplementary material contains the full source code that documents our retrieval approach. Running the above retrieval process on all repositories yielded 3,004 mentions of GenAI tools: 1,572 in commit messages, 397 in source code comments, and 1,035 in doc- umentation files. These mentions were automatically ob- tained using regular expressions and filtered according to heuristics. However, they still included mentions that were not related to content generation. Thus, we conducted a thorough manual inspection of all mentions to eliminate false positives. This review process was guided by the following instructions: 1) We include mentions indicating that content was gen- erated using ChatGPT or Copilot and then copied into the repository. We use a broad definition of “content” that includes not only source code but also comments, translations, and other textual elements. 2) For commits, we also include mentions that indicate a modification of previously generated content (e.g., a refac- toring or fix for previously generated content) or commits that remove comments indicating the usage of ChatGPT or Copilot to generate content. 3) For documentation files, we include mentions that indi- cate content generation, discuss or regulate the usage of ChatGPT or Copilot in the repositories, and mentions that acknowledge the use of these tools. To evaluate the coding instructions, two authors inde- pendently labeled a sample of mentions, deciding whether they should be included or not. We calculated a sample size of 341 mentions (of 3,004) to achieve estimates with a 95% confidence level and a 5% confidence interval. The inspec- tion resulted in disagreement between the two authors for only 14 cases (4% of the sample). The two authors discussed these cases and tried to reach a consensus. During these dis- cussions, a third author helped resolve each disagreement and suggested possible improvements to the categories. To assess inter-rater reliability, we computed Fleiss’ kappa [17] by applying bootstrap resampling methods with 1,000 iter- ations. The resulting 95% confidence interval was estimated to be (0.87, 0.95), indicating an “almost perfect” agreement. Given this high agreement, the first author continued to inspect the remaining mentions alone. In total, we identi- fied 1,292 true-positive mentions of GenAI tools that were aligned with our inclusion criteria. We found true-positive mentions in 156 repositories (11 Python, 12 JavaScript, 37 TypeScript, 47 C#, and 49 Java repositories). We did not merge mentions referring to the same GenAI action (e.g., a commit message and a code comment referring to the same change), as they may indicate distinct usage patterns. 2.3 Data and Code Availability To enable replication and future research, we have prepared supplementary material that includes the filters we used to sample GitHub repositories, the raw data we retrieved, the manually labeled GenAI tool mentions, the Python scripts we used for data retrieval and analysis, and the questionnaires used for our developer survey. The package is available online [18]. 3 R EASONS FOR M ENTIONING G EN AI TOOLS To answer RQ1, we qualitatively analyzed the GenAI men- tions that we collected and curated, categorizing them ac- cording to tasks, contents, and purposes. 3.1 Method We performed an open-coding methodology combined with card sorting to manually analyze our sample of 1,292 GenAI tool mentions (see Section 2.2). The initial coding [19] in- volved systematically examining and categorizing the data according to emerging conceptual themes. In our study, this involved analyzing individual GenAI tool mentions to identify recurring patterns and assign corresponding codes. Following this initial coding phase, we performed open card sorting to organize low-level codes into higher-level abstract categories, allowing us to recognize broader themes and relationships (focused coding). Three authors of this paper collaborated throughout this process to ensure a rigorous and consistent annotation. A preliminary analysis identified 1,008 mentions related to Copilot for Pull Requests.1 Of these, 1,000 instances occurred in a single repository (pancakeswap/pancake-frontend) where commit messages directly reused pull request descriptions generated by the tool, while the remaining eight mentions in other repositories explicitly documented that developers used Copilot for Pull Requests to generate pull request descriptions, without reusing those descriptions as commit messages. In addition, we identified one separate case in which contributors were encouraged to use ChatGPT to produce pull request descriptions (P11); this case was not part of the Copilot for Pull Requests group. Given the overrepresentation of a single, highly repet- itive use case, namely the reuse of Copilot-generated pull request descriptions as commit messages, we set aside these 1,008 mentions during the initial round of coding to avoid skewing the development of the coding schema. After es- tablishing a stable set of categories based on the remaining data, we revisited these deferred cases and incorporated them into the analysis. To build the code book, two authors independently analyzed 284 GenAI mentions. The code book development was guided by the following questions: • Task: Which task has the GenAI tool supported or automated? Tasks include, for example, writing a test case, fixing a bug, and refactoring the code base. • Content: Which content is the GenAI mention referring to? Content categories include methods in source files, sec- tions in documentation files, and commit messages. • Purpose: Why has the GenAI tool been mentioned? Possible purposes include acknowledgment of usage for code gen- eration and regulation of usage within the project. 1. https://githubnext.com/projects/copilot-for-pull-requests === page 5 === Table 3 GenAI-assisted tasks (RQ1): Definition and frequency of categories and codes (n = 284 + 1,000 + 8 = 1,292); the code PR description is counted and discussed separately because most of it only occurred in one repository (see Section 3.2.1). Category Code Definition # Code Understand coding tasks written in natural language and generate corresponding code. 105 Test data Create test input/output based on software requirements or the existing codebase. 9 Comment Generate code comments that explain the purpose and logic of code blocks. 9 Test file Create test files based on software requirements or the existing codebase. 8 Regex Craft regular expressions tailored to specific text matching needs. 6 README Create README files that provide essential information, e.g., project descriptions. 4 Dummy text Produce placeholder text that mimics real content in style, structure, and format. 4 Test method Create test methods based on software requirements or the existing codebase. 2 Code review Generate reviews that suggest improvements and identify potential issues in code changes. 2 Generation Commit message Generate commit messages that summarize code changes. 2 Tutorial Produce instructional content on specific topics and step-by-step guidance for projects. 2 Zod schema Create Zod schemas in TypeScript and JavaScript for type safety and data validation. 2 Test class Create test classes based on software requirements or the existing codebase. 1 Coding practices Generate guidelines and best practices for coding in the projects. 1 Variable Suggest meaningful variable names that improve code semantics and readability. 1 Changelog Compile changelogs that document changes, features, and fixes in new software versions. 1 Configuration Generate project-specific configuration files, e.g., performance and security settings. 1 Text Generate general text that is not mentioned above. 8 PR description Create explicit PR descriptions to assist understanding the changes in the PRs. 1,009 Text Convert text between different languages, e.g., software internationalization (i18n). 49 Translation Code Convert code between different programming languages, preserving the original logic and 1 functionality while adapting to the syntax and idiomatic patterns of the target language. Code refactoring Restructure code without altering its functionality, aiming to make the code maintainable. 29 Optimization Code improvement Improve existing code, mention is accompanied by “improve.” 5 Label revision Analyze, update, and improve text labels, ensuring clarity, accuracy, and consistency. 8 README revision Analyze, update, and improve README files, ensuring clarity, accuracy, and consistency. 7 Document revision Analyze, update, and improve documents, ensuring clarity, accuracy, and consistency. 4 Changelog revision Analyze, update, and improve changelogs, ensuring clarity, accuracy, and consistency. 2 Prompt refinement Optimize and clarify the prompts to elicit the most relevant and accurate responses. 1 Maintenance Color suggestion Suggest color schemes for UI/UX design based on best practices and design requirements. 1 Dependency Analyze software dependencies and suggest updates to ensure compatibility and security 1 upgrade while minimizing breaking changes. Version update Suggest meaningful version numbering for software releases for systematic version control. 1 Comment revision Analyze, update, and improve code comments, ensuring clarity, accuracy, and consistency. 1 Other - Operate general functionality, like Q&A and blog generation. 12 None - There is no specific task for the GenAI tool. 9 Our coding process allowed coders to assign multiple codes per mention. During the iterative refinement of the codes and categories, we observed an interesting pattern in how developers describe their work with GenAI tools. Each mention typically encompasses two distinct but inter- connected perspectives: (i) the specific task delegated to the GenAI tool and (ii) the broader development task the human developer aims to accomplish. To capture this pattern, we split the task-related codes into two sub-categories: GenAI task and developer task. We provide the final code book and code assignment as part of our supplementary material. Using Fleiss’ kappa [17], we assessed the interrater reliability between the two coders. The analysis yielded “substantial” to “almost perfect” agreement levels on task (k = 0.81 − 0.89), content (k = 0.95 − 0.99), and purpose (k = 0.79 − 0.92), according to standard guidelines for inter- preting k [20]. Through iterative discussions, the two coders worked to achieve consensus on the categorizations, with a third researcher arbitrating unresolved disagreements and recommending refinements to the categories. The first au- thor then independently checked the 1,008 mentions that we had initially deferred. 3.2 Results Our analysis of mentions revealed distinct patterns in how developers integrate GenAI tools into their development workflows. In the following, we describe the categories and codes capturing development tasks, content types, and usage purposes, which emerged from our analysis. 3.2.1 GenAI-Assisted Tasks Our analysis identified 32 distinct task categories in which developers use GenAI tools in their workflows. Table 3 presents these categories along with their definitions and usage frequencies, while Table 4 shows a list of examples of self-admitted GenAI usage. Unsurprisingly, excluding PR-related activities, generation tasks were most common, with code generation being particularly prominent (105 instances). Translation followed with 50 instances, while optimization and maintenance tasks accounted for 34 and 26 instances, respectively. As mentioned above, we distinguish between developer tasks and GenAI tasks. While Table 3 lists the GenAI tasks, we also want to discuss human tasks related to GenAI tasks. For example, in one commit message that we analyzed (E1) the developer acknowledged that the code was written “a bit === page 6 === Table 4 Examples of self-admitted GenAI usage referenced in this paper. ID Artifact Link E1 commit aksio-insurtech/cratis/commit/e97e... E2 comment iportalteam/imm.../PortalShape.java#L95 E3 commit fusion-flux/portal-cubed/commit/0a9d... E4 commit vercel/next.js/commit/d210... E5 commit pancakeswap/pancake.../commit/4e0f... E6 doc. pancakeswap/.../CONTRIBUTING.md E7 comment LAMP-Platform/LAMP/.../Format.cs#L171 E8 doc. ant-des.../github-actions-workflow.en-US.md E9 doc. Minecraft-AMS/Carpet-.../README_en.md --> E10 comment BdR76/.../CsvGenerateCode.cs#L733-L735 E11 commit VelvetToroyashi/Silk/commit/35d9... E12 commit deephaven/web-client-ui/commit/d852... --> E13 comment hypar-io/elements/.../Ellipse.cs#L166-L167 E14 comment dominokit/domino-.../Slider.java#L546-L550 E15 doc. Anime4000/IFME/.../changelog.txt#L210 E16 commit dotnet/project-system/commit/3aa2... E17 commit ediwang/moonglade/commit/a185... hasty on previous release” due to “trust in GitHub Copilot.” The developer task described in the commit message was bug fixing, while the initial task that the GenAI tool supported was code generation. We identified 20 mentions exhibiting this pattern of human actions triggered by an earlier GenAI action. Among them, 13 referred to code that was initially generated using GenAI tools and then changed. The most common follow- up activity was to fix bugs in AI-generated code (9). In other cases, changes were reverted (1), AI-generated comments were deleted (2), or the generated code was commented out (1). For example, one developer commented out code generated by Copilot with the note: “Note: do not trust GitHub Copilot. It may use z as up axis” (E2). Another de- veloper reverted a commit that was created with the help of ChatGPT: “Revert ‘ChatGPT’ This reverts commit 71e3...” (E3). In addition to the 13 human actions that followed AI code generation that we discussed above, we found seven human actions following the generation of configuration and validation files or an unclear role of the GenAI tool. In five cases, developers specified restrictions or exclusions regarding GenAI usage without mentioning a specific task. In two other cases, they removed and rewrote AI-generated configurations or validations. For instance, one pull request superseded another that “heavily relies on GitHub Copilot (which makes the progress slow and tedious)” (E4). The de- veloper manually replaced the generated validation schema with a handwritten version. Recent research has shown that using AI-generated PR descriptions reduces review time and increases PR merge rates [7]. We found that developers reused gener- ated PR descriptions as part of their commit messages. As mentioned in Section 3.1, this approach was very com- mon in one particular project, which contributed 1,000 such mentions to our sample. These generated messages are not limited to this one project—similar patterns ap- pear in popular projects such as pytorch/pytorch and hasura/graphql-engine. They are added when devel- opers use the PR description as the message for merge or squash commits. This practice represents a form of explicit, self-admitted GenAI usage, embedding a clear marker of AI contribution directly into the software project’s official history. Note that, although this single use case contributes a large absolute count, it represents only one entry in our taxonomy of GenAI tasks (Table 3) and does not affect our broader findings. To illustrate this particular use case, we include an excerpt below (E5). Interestingly, the linked contribution guidelines (E6) do not discuss GenAI usage. chore: Remove no used deps (#7349)