An Empirical Study of Maintainer-Identified AI Slop Pull Requests in Free and Open Source Software Projects

arXiv:2611.15159v1 [cs.SE] 11 Nov 2026

An Empirical Study of Maintainer-Identified AI Slop Pull Requests in Free and Open Source Software Projects Hugo Raskin

Xavier Devroey

Benoît Vanderose

University of Namur Namur, Belgium hugo.raskin@student.unamur.be

NADI, University of Namur Namur, Belgium xavier.devroey@unamur.be

NADI, University of Namur Namur, Belgium benoit.vanderose@unamur.be

Abstract—The FOSS ecosystem has always relied on outside contributions, notably through issues or Pull Requests (PRs), to sustain itself. With the advance of GenAI, the barrier to contributing to FOSS projects has never been lower, leading to the emergence of AI slop PRs: low-quality, low-value generated PRs. Past studies have examined AI slop PRs through theoretical, platform-level, or practitioner-account frames, but not at the project level. To this end, this study investigates the incidence of maintainer-identified AI slop PRs in FOSS projects by focusing on PRs flagged as slop by maintainers. Using a mixed-methods approach, we trace the origins of maintainer-identified AI slop PRs, quantify their volume in FOSS projects, describe their characteristics, and highlight maintainers’ reasons for flagging or closing them. Our results show that the volume of maintaineridentified AI slop PRs increased in mid-2025, peaking in May 2026. These PRs are mostly additive, rarely merged, and typically closed within 3 days. The authors of these PRs disclosed the use of AI in 14% of cases, with 1% disclosing after a maintainer’s request. Most PRs are closed or marked as slop without any reason provided by the maintainer. Based on our open coding, reasons range from concrete elements, like build failures, to ideological or intuitive (i.e., "looks AI to me"). This exploratory study captures a phenomenon in its early stage and highlights GenAI’s potential impact on FOSS, emphasizing the pressure it puts on maintainers and the need to shift current open-source development practices. Index Terms—pull requests, AI slop, FOSS

I. I NTRODUCTION Recent advances in generative AI (GenAI) are changing how software is developed, shifting from human-written code to AI-generated code. This shift has several impacts on the Free and Open Source Software (FOSS) community, including an increase in the amount of code produced. In response, some communities have limited GenAI use. For example, Codeberg has recently changed its terms of service to ban Large Language Model (LLM)-generated contributions [21], and GitHub has announced several new functionalities to limit external contributions [31]. For decades, FOSS has relied on collaborative approaches, enabled by platforms like GitHub, to foster community-based This research was funded by the CyberExcellence by DigitalWallonia project (No. 2110186), funded by the Public Service of Wallonia (SPW Recherche).

project development where external contributors can propose new features and fix bugs [45], [52]. In particular, GitHub’s Pull Requests (PRs) allow external contributors (authors) to propose changes that internal contributors with privileged access (maintainers) can review and assess before acceptance (merging) into or rejection from the codebase [19]. This model has worked for many years, making FOSS a pillar of modern software systems [41]. However, GenAI has lowered the barrier to contributing to FOSS projects by allowing authors with a superficial knowledge of the project to propose changes quickly. For many repositories, this has caused a dramatic increase in the number of PRs to review, leaving the maintainers overwhelmed and forced to drastically adapt their review process. In their work, Baltes et al. [6] qualitatively analyzed 1,154 posts across 15 discussion threads to understand how practitioners name, frame, and respond to AI slop. Their analysis produced a codebook of 15 codes organized into three thematic clusters: Review Friction, Quality Degradation, and Forces and Consequences. Their results also highlight concerns among developers and propose mitigation strategies for developers, team leads, and educators. In a later work, the same authors frame AI slop in the FOSS ecosystem as a tragedy of the commons [5]. This theory explains why an individual might overuse a shared resource for personal benefit, leading to its depletion. In this case, the individual’s productivity gain comes from AI-generated content in the FOSS ecosystem. Additionally, they propose solutions to the proliferation of AI slop for FOSS decision-makers. Another study argues that AI slop in the FOSS ecosystem creates a DDoS effect, overwhelming the FOSS community with increasing pressure from generative AI tools [1]. Using a mixed-methods approach, they derive hypotheses from public accounts and then evaluate them using Bayesian Structural Time Series analysis across 294 repositories. Their results show an increase in PR volume in 2025, a decrease in merge rates, and a decrease in merge rates for one-time contributors relative to other contributors. Additionally, they present 11 remediation strategies from practitioner interviews, which they then validate with a practitioner survey.

Building on this initial work on the emergence of AI slop in the FOSS ecosystem, our study aims to quantify its incidence more precisely at the repository level. Specifically, we investigate how FOSS projects handle PRs identified as “AI slop” and the reasons maintainers give for flagging or closing them. Through this investigation, we seek to understand how maintainer-identified AI slop manifests. Documenting this phenomenon matters, as AI-related development practices evolve rapidly. While authors and maintainers must continually adapt, researchers face the challenge of capturing evidence before it becomes unavailable. For example, we found that seven PRs we mined from GitHub were no longer available when we conducted our manual analysis. To capture how maintainers identify and respond to this phenomenon, we focus on PRs explicitly flagged as AI slop by maintainers. We conducted an exploratory study combining GitHub repository mining with manual coding of PRs to answer the following research questions: (RQ1 ) How do maintainer-identified AI slop PRs impact FOSS projects? To answer that question, we focus on the incidence of maintainer-identified AI slop PRs in FOSS repositories over time, and the structural characteristics of such PRs. (RQ2 ) How do FOSS projects handle maintainer-identified AI slop PRs? To answer this question, we annotate the collected PRs for AI disclosure, linked issues, flagging, and closure, and record the reasons maintainers or bots provide for flagging or closing them. We analyze the annotations using descriptive statistics. (RQ3 ) What reasons do FOSS project maintainers or bots give for flagging or closing PRs as AI slop? For this third question, we perform open coding on the reasons collected in RQ2 and use the resulting codes to derive a taxonomy of the reasons for flagging or closing PRs. The main contributions of this paper are: (i) a dataset of maintainer-identified AI slop PRs, supporting future research on the impact of GenAI on FOSS contributions. (ii) Records of maintainer-identified AI slop PRs, enabling further study of its impact on FOSS projects. (iii) A taxonomy of reasons for flagging or closing slop PRs, which can drive future research and tool development to assist FOSS maintainers. (iv) A replication package containing the dataset, analysis scripts, and codebook [34]. II. BACKGROUND AND R ELATED W ORK A. Collaboration in FOSS Before GenAI With the widespread adoption of distributed version control [7], pull-based development has become increasingly popular [19]. In this model, a developer proposes changes to a repository by submitting a PR. In a code review process, one or more maintainers (i.e., “a role or organization that performs software maintenance activities” [49]) then review the proposed changes and decide whether to integrate them [36]. This aims to prevent defects, improve code readability, and share source-code knowledge [4], [39]. Code review via PRs is critical in FOSS communities as external contributions form a central part of development [41], [52].

In FOSS projects, external contributors typically lack direct write access to the repository. Beyond technical correctness, maintainers assess whether contributions align with project conventions, design, and software architecture [2], [37], [45]. PR acceptance also depends on social and organizational factors, including prior community interactions, responsiveness during review, and the contributor’s reputation [9], [20], [44]. As pull-based development and its supporting platforms have facilitated collaboration, the growing number of open PRs has placed increasing demands on maintainer review capacity [20]. PR decisions, whether acceptance or rejection, can be delayed, which adds to the strain on maintainers, already exposed to stress and burnout risk from unhealthy interactions [33] and sustained maintenance labor [28], and forces contributors to wait for review [51]. B. Collaboration in FOSS After GenAI GenAI has made the tension between maintainer capacity and PR review even more pressing as developers increasingly use them in software development [15], [24]. LLMs can generate code changes [11], PR descriptions [50], and even code reviews and suggestions [12]. These AI-assisted PRs lower the barrier to contribution and let new contributors participate, but they can also slow coordination in collective development efforts [43]. Autonomous agents now also generate and open PRs entirely on their own [27]. Maintainers have increasingly reported instances of “AI slop” [8], [32], [48], referring to low-value or low-quality AI-generated content. The term generally describes unwanted content that is produced rapidly and in large quantities. Public discourse first framed AI slop in the context of social media, political communication, and cultural pollution [25], [29]. AI slop, and vibe coding more broadly, raise concerns about the sustainability of FOSS [6], [26]. III. M ETHODOLOGY As illustrated in Figure 1, we answer the research questions in four steps: we select and mine GitHub repositories to retrieve slop PRs, manually annotate them, and perform open coding based on PR discussions. We provide all collected data, scripts, the annotation procedure, and the open-coding codebook in our replication package [34]. A. Repository Selection We focus our mining on the 10,000 software repositories collected by Mohsenimofidi et al. [30]. They used the SEART GitHub search tool [14] to collect software engineering projects and applied several criteria, such as number of contributors, creation date, programming language, and compliance with open-source licenses, to focus on actively maintained projects with a long development history. Their analysis yielded 48,795 repositories, which they further ranked by popularity and maturity. Finally, they limited their dataset to the 10,000 most popular and mature repositories on GitHub. Our study is based on their dataset, as its filters allow us to focus on actively maintained and popular software repositories.

1

Repository Selection

2

Mining Repositories

3

Dataset Annotation

4

Open coding

RQ1: Mining slop PRs and performing descriptive statistics on timeline, size, status data.

10,000 Repositories

1,786

repositories

RQ2: Manually annotating slop

PRs

PRs on closure, AI disclosure,

dataset

related issue, PRs flagging. Mohsenimofidi et al.:

GitHub URL redirection:

Mine repositories for slop PRs:

Annotation of the dataset:

Open coding

48,795 ranked engineering

305 repositories renamed

467 matched with title

Disclosure of AI use?

Derived from maintainers

RQ3: Performing Open Coding to

software repositories

25 repositories unavailable

1,423 matched with label

Linked issue?

and bots comments

derive a taxonomy on the reasons a

10,000 repositories dataset

25 repositories added from

69 matched with both

Protestation of the author?

Codebook reconciliation

the dataset

173 false positives

Who flagged the PR?

Axial coding to derive

Who closed the PR?

categories

slop PR is flagged or closed.

What types of bot used?

Figure 1. Methodology steps followed to answer the research questions. PRAISE

GitHub API

For each repository, search for slop PRs. Title-based GET /search/issues q="{title_slop_terms} in:title is:pr repo:{repo}" PRs response Label-based GET /repos/{owner}/{repo}/labels Labels response Match received labels with labels slop terms. For each matched label, request PRs with that label. GET /search/issues q="label:{label} is:pr repo:{repo}" PRs response

PRAISE

GitHub API

Figure 2. Query to the GitHub API to retrieve slop PRs. The upper part shows the title-based search. The lower part shows the label-based search.

However, although Mohsenimofidi et al.’s dataset was only a few months old, some repositories were already unavailable, either because they were renamed or no longer exist. For renamed repositories, we updated the dataset based on the GitHub redirection from the old URL to the new one. We identified 305 renamed repositories and 25 unavailable repositories. For each unavailable repository, we added the next repository in their initial list until we reached a total of 10,000 repositories to analyze. B. Mining Repositories To answer RQ1 , we mined the 10,000 repositories using the GitHub API to collect PRs flagged as “AI slop.” We consider a PR flagged if either of the following holds: 1) the PR title mentions slop, or 2) the PR carries a label mentioning slop. Figure 2 represents the interactions between our Python script and the GitHub API to retrieve slop PRs based on their title (upper part) or their labels (lower part). a) Title-based criterion: We base our criterion on an initial manual exploration that revealed that maintainers often rename PRs they consider slop, either by replacing the entire title or by adding a prefix. We collect these PRs by querying the GitHub search API using the following keywords, encountered during our exploration, in PR titles: slop, ai junk, and ai spam. We iterate on the repositories by limiting the search query to one repository at a time.

b) Label-based criterion: During the initial exploration, we also observed that maintainers rely on GitHub labels to mark PRs that they consider slop. For each repository, we collect its labels and retain only those that match the following slop terms: slop, ai-pr, ai-spam, ai spam, or rejected ai. Using the search query, we then query each repository to collect PRs that have at least one matching label. After collecting the PR information, we made a second call to the GitHub GraphQL API to retrieve the number of commits, the comments (reviews, review threads, and comment types), the number of additions and deletions, and author information. This mining process yielded 1,959 PRs considered slop by maintainers: 467 matched by title, 1,423 matched by label, and 69 matched by both. We quantitatively assessed the construct validity of our mining criteria. To do this, the first author manually reviewed the dataset to identify false positives. For example, in some repositories, the term slop meant something unrelated to low-value generated PRs, or that a bot opened the PR. In total, we identified 173 PRs as false positives, achieving a precision of 91.17%. We mined from the first PR of each repository through the end of July 2026. After removing the false positives, the final dataset contained 1,786 PRs considered slop by maintainers. C. Dataset Annotation To answer RQ2 , we iterated through each PR and used the GitHub web interface to answer following questions: 1) Does the author of the flagged PR link a related issue? 2) Does the author of the flagged PR disclose any use of AI? 3) Does the author of the flagged PR protest the closing or flagging of the PR? 4) Who flagged the PR as slop? 5) Who closed the PR? 6) What type of bot was used to flag or close the PR? If a bot was used, we noted the reason it provided for the flagging or closing, usually described in a PR comment. Lastly, we also noted the reason the maintainer provided for flagging or closing the PR, which we use for open coding (see related section). For the reason for flagging or closing the PR, we only consider comments posted directly in the PR comment feed. To answer the questions, we only consider the state of the PR at the time of the annotation, meaning that if the PR was closed multiple times, we only consider the last person or bot that closed it. To ensure annotation validity, the first author annotated the entire dataset, while the second and third authors each independently annotated half of the dataset. We report

the inter-rater agreement using Cohen’s κ for each question: 1) 0.99; 2) 0.98; 3) 0.90; 4) 1.0; 5) 1.0; and 6) 1.0. All authors discussed any disagreements between annotations.

IV. R ESULTS The final dataset contains 1,786 slop PRs mined from GitHub. It is packaged as a MongoDB database in which each PR is represented as a document. The PR document fields fall into three categories: metadata, comment, and size. Metadata consists of the PR state (i.e., open or closed), the title and body of the PR, the URL of the PR, whether the PR was merged, and the dates of opening, closing, and last update. They also include information about the PR author, such as login name and GitHub node ID. Comment fields involve information on the discussion of the PR. The raw list of comments is available, alongside comment authors’ information. The number of comments posted by bots, by the author of the PR, and by other humans (other than the author). To differentiate comment types, we used data available from the GitHub API response, as GitHub marks comments originating from bots with a boolean field. To distinguish comments from the author and other developers, we simply compared the PR author ID to the comment author ID. Finally, size fields focus on PR-size metrics, such as the number of additions and deletions, the number of commits, and the number of files changed. A. Impact of Maintainer-identified AI Slop PRs (RQ1 ) To answer RQ1 we analyze the dataset to describe the incidence of slop PRs and their characteristics. All analysis scripts are available in the replication package [34].

100

#PRs (pseudo−log)

50

10 5

1

20 26 Ju n

02 6 ar 2 M

20 25 ec D

Se

p

20 25

20 25 Ju n

02 5 ar 2 M

20 24 ec D

p

20 24

0

Se

D. Open Coding Finally, to answer RQ3 , we open-coded the reasons maintainers and bots gave for flagging or closing the PRs. Following Saldaña’s recommendations [40], the authors independently coded the PRs based on discussions between the PR author and the maintainers. Comments posted by bots related to the flagging or closing of the PRs were also considered for the coding. A PR can be assigned multiple codes when maintainers gave multiple reasons. As in RQ2 , the first author coded all PRs, and the second and third authors each coded half. The three codebooks were then reconciled through intensive group discussions among the three authors to define a joint codebook with codes and definitions. We adopt an interpretivist stance and do not report inter-coder agreement, as we treat disagreements as information rather than noise. Lastly, we performed axial coding to group related codes into categories. Each author independently examined the codes and proposed a grouping of related codes. The three proposals were then compared and discussed to reach a consensus on the final categories. Any disagreements were discussed among the authors until an agreement was reached. The category labels were jointly determined through these discussions. We documented the whole process, including traceability links and discussions of disagreements, in an Obsidian vault available in our replication package [34].

300

Month

Figure 3. Number of maintainer-identified AI slop PRs (pseudo-log.c scale) opened per month from the first opened PR to the end of July 2026.

a) The incidence of slop PRs in FOSS repositories: We first present the temporal evolution of maintainer-identified AI slop PRs in FOSS. Figure 3 represents the monthly evolution of the number of opened PRs flagged as slop across all repositories. It uses a pseudo-logarithmic scale to better represent variation between months, including months with no PRs flagged. The observation period ranges from July 2024, the month the first PR was flagged, to the end of July 2026. Between July 2024 and September 2025, the number of PRs opened by month stayed low, ranging from 0 to 5. In September 2025, the number increased from 13 opened PRs marked as slop to 50 the next month. The rest of 2025 was less impacted by slop PRs, with only 36 PRs flagged in November and December 2025. In 2026, new slop PRs increased significantly, rising from 62 PRs in January 2026 to 335 PRs in the last month of the observation period (July 2026). The maximum number of open slop PRs was reached in May 2026 with 342 PRs. The last three months of the observation period (May, June, and July 2026) stayed stable in the number of opened slop PRs, with 342, 327, and 335 slop PRs, respectively. To further analyze the phenomenon at the repository level, Figure 4 shows the incidence of slop PRs by repository. Panel (A) shows a bar chart of the monthly evolution of the number of repositories affected by slop for the first time. The line chart represents the cumulative evolution of new repositories. The date of the opening of the first slop PR in each repository is used to determine when a repository is impacted. We aggregated the opening dates by month to show monthly evolution. Panel (B) shows the number of PRs flagged as slop per repository. The y-axis (number of repositories) uses a pseudo-logarithmic scale. With the observation period going from July 2024 to July 2026, we observe 76 distinct repositories affected by slop PRs. Between July 2024 and May 2025, the monthly number of new repositories affected by slop PRs stayed low, ranging only from 0 to 1 new repository. However, between July 2025 and April 2026, the monthly number increased, ranging from 2 to 6 new repositories per month. In contrast, May 2026 saw a sharp increase from the previous month, with 14 new repositories affected by slop PRs, making it the month with

60 10 40 5 20

6

20 26

Ju l2 02

ay M

6 20 2

ar 20 26 M

25 20 ov N

Ja n

25

5

20 Se p

5

20 25

Ju l2 02

ay M

M

24

20 2

20 ov N

Ja n

4

20 Se p

Ju l2 02

ar 20 25

0 24

0

Cumulative repositories

New repositories per month

A. New slop repositories per month and cumulative total

# Repositories (pseudo−log scale)

Month

B. Distribution of slop PRs per repository

Table I R AW DESCRIPTIVE STATISTICS OF SLOP PR S FEATURES . H ISTOGRAMS ARE ON A PSEUDO - LOGARITHMIC SCALE . Feature

Description

5%

Mean

SD

Med.

95%

Histogram

Comment features comments_total

#Comments (bot and user).

0

2.26

3.91

1

8

comments_from_bot

#Comments from bot.

0

0.91

1.91

0

4

comments_not_from_author

#Comments from users ̸= author.

0

1.83

3.01

1

7

Size features

50

commits

#Commits.

1

9.45

237.58

1

7

changed_files

#Changed files.

1

15

146.89

2

22

additions

#Lines added.

1

1,413.77

15,526.66

33

1,258.5

deletions

#Lines deleted.

0

368.92

8,469.57

2

143.5

src_churn

#Lines added + deleted.

2

1,782.69

18,223.63

37

1,575.75

10 5

1 0

1

100

200

300

400

# slop PRs per repository

Figure 4. Incidence of slop PRs at the repository level. (A) Monthly number of new repositories affected by slop, based on PR opening date (bars, left axis), and cumulative number of affected repositories (line, right axis). (B) Distribution of the number of slop PRs per repository (pseudo-log scale). (A) PRs by author

1

3

10

30

PRs (log scale)

(B) Authors by repository

1

10

100

Authors (log scale)

Figure 5. Box plots of slop PR authorship (log scale). (A) shows the number of slop PRs opened by the same author across all repositories. (B) shows the number of distinct authors who have opened slop PRs by repository.

the highest number of new repositories. June and July 2026 stayed within the range observed before May 2026, with 6 and 4 new repositories, respectively. Regarding the number of slop PRs per repository, Figure 4. Panel (B) suggests a right-skewed distribution, further confirmed by the statistics (mean ± standard deviation: 23.50 ± 62.61; median: 4.50; min: 1; max: 454). The distribution is concentrated near the lower end of the range, with most repositories having fewer than 5 slop PRs (median: 4.50), while a small number of outlier repositories, reaching up to 454 PRs, create the long right tail and pull the mean well above the median. As the histogram shows, two outlier repositories, pallets/click and huggingface/transformers, stretch the right tail with 291 (16.29%) and 454 (25.42%) slop PRs, respectively. The replication package includes the complete list of 76 repositories and their respective numbers of slop PRs. Finally, Figure 5 focuses on the authors of the PRs flagged as slop. Box plot (A) shows the number of PRs, across all repositories, opened by distinct authors, while (B) shows the number of distinct authors who have opened a slop PR by repository. We used GitHub node IDs to identify authors. Across the dataset, a total of 1,074 distinct authors have opened at least one PR flagged as slop. The statistics show that

most authors have opened fewer than two PRs (mean ± standard deviation: 1.66±2.48; median: 1; min: 1; max: 52). With the core of the distribution in a tight window, a group of outlier authors who have opened between 2 and 52 PRs (third quantile to max) stands out. Statistics on the number of distinct authors who have opened a slop PR by repository show that most repositories have slop PRs opened by fewer than three distinct authors (mean ± standard deviation: 15.88 ± 45.13; median: 2.50; min: 1; max: 298). As mentioned, by number of slop PRs per repository, pallets/click and huggingface/transformers also have the most distinct authors, with 256 and 298, respectively. b) Characteristics of slop PRs: Table I presents the overall statistics of the comment features and size features for the collected slop PRs. For each feature, we present the 5% percentile, mean, standard deviation (SD), median, 95% percentile, and a histogram on a pseudo-logarithmic scale. The comments_total feature is the total number of comments in the PR (including discussion and review comments). Slop PRs contain, on average, less than 3 comments (mean: 2.26; median: 1). For the comments_from_bot feature, the results show that PRs contain, on average, less than 1 comment originating from a bot (mean: 0.91; median: 0). Comments_not_from_author counts all comments made by users other than the author of the PR. The results indicate that slop PRs contain less than 2 comments from human authors (mean: 1.83; median: 1). However, for each comment feature, the histograms and 95% percentile indicate a rightskewed distribution, with outliers stretching the tail. The maximum value of each feature, are respectively 47, 31, and 32 comments. The results for the size features describe highly asymmetric distributions: for each metric, the median is substantially lower than the average, and the average even exceeds the 95% percentile for the commits, additions, deletions, and src_churn features. This large variation, along with standard deviations far exceeding the means, indicates that a small subset of extreme outliers pulls the average upward. The histograms further confirm this, showing heavily skewed distributions with long tails. The core of the distribution (between the 5% and 95% percentiles) is comparatively tight: the majority of PRs

Table II S LOP PR S STATE DISTRIBUTION AND CLOSURE TIME . State

#PRs

%

Mean time

Median time

Closed (unmerged) Merged Open

1748 11 27

97.9% 0.6% 1.5%

3.25 days 13.70 days /

0.27 days 3.33 days /

Table III A NNOTATION WITH THE NUMBER OF PR S CONCERNED (#PR S ). Question

Answer

#PRs

Linked issue? AI disclosure? Author protestation? Flagged by?

Yes (66.6%); No (33.4%) Yes (13.9%); No (84.5%); After (1.6%) Yes (4.1%); No (95.9%) Author (0.4%); Bot (1.7%); Maintainer (97.5%); Both (0.4%) Author (4.1%); Bot (5.9%); Maintainer (90.0%) coderabbitai (1.7%); electron-issue-triage (28.6%); github-actions (69.7%)

1779 1779 1779 1778

Closed by? Bot type used?

contain between 1 and 7 commits, change between 1 and 22 files, and have a total source churn (additions + deletions) of between 2 and 1575 lines.

We further analyze the additions and deletions features. We define the addition ratio of a PR as additions/(additions + deletions). 94.1% of PRs add more lines than they delete (nonparametric Wilcoxon signed-rank test, p−value < 2×10−16 ), with a median addition ratio of 0.934, confirming that PRs in this dataset are predominantly additive rather than balanced or deletion-heavy. This pattern remains robust after excluding the top 1% largest PRs by src_churn size.

Finally, we compare the data distributions of the full dataset and the dataset without PRs from huggingface/transformers and pallets/click, as they account for 25.42% and 16.29% (resp.) using a nonparametric Mann-Whitney U test. All pvalues are lower than 0.01, except for the number of comments from bots (comments_from_bot, p − value = 0.5329) and the number of commits (commits, p − value = 0.5238). In both cases, the mean increases: from 0.91 (SD=1.91) to 1.06 (SD=2.08) for comments_from_bot and from 9.45 (SD=237.58) to 14.82 (SD=311.13) for commits. However, the median values remain unchanged, denoting potential extreme values bringing the mean values up.

Regarding PR state and closure time, Table II describes the distribution of PR states, mean closure time, and median closure time in days. Most PRs are closed (unmerged): less than 1% are merged, and 1.5% were still open at the time of mining. Unmerged PRs close in about 3 days on average, with a median of 0.27 days (about 6 hours). In contrast, merged PRs close in about 13 days on average, with a median of about 3 days. When excluding huggingface/transformers and pallets/click (outlier repositories), the number of unmerged PRs decreases from 1,748 (97.9%) to 1,005 (96.5%). All PRs in those repositories were closed without merging, with only two still open. However, the mean closure time slightly increases from 3.25 days, with a median of 6.5 hours, to 4.07 days, still with a median of 6.5 hours. This denotes that the closure time is slightly faster in those two repositories.

1738 119

Û RQ1 How do maintainer-identified AI slop PRs impact FOSS projects? Slop PRs emerged in July 2024 and remained rare until mid-2025, then rose sharply, peaking at 342 PRs and 14 newly affected repositories in May 2026. Most repositories saw fewer than 5 slop PRs opened by less than 3 distinct authors, though outliers reached 454 PRs and 298 authors. Slop PRs are mostly additive, sparsely discussed, and rarely merged (less than 1%); 97.8% are closed, typically in less than a day (median), while merged PRs are integrated into the codebase in about three days (median). B. Maintainer-identified AI Slop PRs Management (RQ2 ) This section presents the results of RQ2 , based on the manual annotation of the dataset. For each question, Table III shows the annotation results, including the total number of PRs associated with each question. After mining, the dataset comprised 1,786 PRs. However, between the mining and the annotation, 7 PRs became unavailable on GitHub. Therefore, we excluded those PRs from the annotation and open coding results. We discussed those deletions in the discussion section. Our data show that if a majority (66.6%) of PRs link to a related issue, only 13.9% of PRs disclose upfront the use of AI. An additional 1.6% of PRs disclose AI use afterward, either in a comment or by updating the PR description, after a maintainer asks whether AI was used. We used the comment date and description update date to identify such cases. Only a small number (4.1%) of the authors protest the flagging or closing of their PR, either by questioning the decision, claiming that no AI was used, requesting that the PR be reopened, or even by lashing out at the maintainers. Regarding closed PRs, we identified 9 PRs where the GitHub interface does not show who closed them. Similarly, for the PR flag question, one PR is flagged by label, but the GitHub interface does not indicate who added the label. These PRs are therefore excluded from our analysis. For both questions, maintainers flagged (97.5%) and closed the PRs (90.0%) in the majority. The authors closed 4.1% of PRs themselves, and a bot automatically closed 5.9%. For PR flagging, the author flagged 0.4% of PRs themselves, a bot automatically flagged 1.7%, and both a maintainer and a bot flagged less than 1%. The last question (bot type used) focuses on the bot types used to close or flag PRs. In the dataset, 119 PRs used such a bot, with GitHub Actions used in 69.7% of the

PRs, against 28.6% for electron-issue-triage, and coderabbitai accounting for only 1.7% of the PRs. Excluding outlier repositories changes the percentages for linked issues, AI disclosure, author protestation, and flagging by less than 2.2%. However, excluding huggingface/transformers and pallets/click increases the shares of PRs closed by bots (10.2%) and authors (6.3%), with maintainers at 83.5%, consistent with Table II. Bot proportions remain similar: coderabbitai (1.9%), electron-issue-triage (32.1%), and github-actions (66.0%). Û RQ2 How do FOSS projects handle maintaineridentified AI slop PRs? Slop PRs are linked to an issue in 66.6% of cases, but only 13.9% disclose AI use, with an additional 1.6% doing so after a maintainer’s request. In 4.1% of cases, authors protested the flagging or closure of their PR. Maintainers flag and close most slop PRs, while bots, primarily GitHub Actions, were used to close or flag 119 PRs. C. Slop PRs Flagging and Closing (RQ3 ) Table IV presents the final codebook of reasons maintainers and bots close or flag PRs as slop. Each code includes its description and the corresponding number of PRs for maintainers and bots, respectively. We group codes into categories and sort them from the most concrete to the most abstract criteria used to tag PRs as slop. We detail each code hereafter with examples of PRs. We also report the number of PRs without huggingface/transformers and pallets/click. The main differences are (i) the drop in the number of unspecified PRs, and (ii) the usage of bots based on the author’s profile in huggingface/transformers. a) Desk rejection: This is the most concrete category where maintainers rely on factual elements to mark the PR as slop. It includes AI fingerprints, where AI has explicitly signed a commit (freqtrade#12819) or left a message in the source code (transformers#45076), build failures, including compilation (electron#51538), continuous integration (airflow#68277) or quality checks failures (gemrb#2249), and insufficient verifications when a “proof of work” (terraformprovider-proxmox#2039) or screenshot (refined-github#9561) is required to show that the changes have been verified, or if the PR fails to provide evidence of testing (vllm#46672). b) Bad code: Relying on expertise, PRs are also flagged when they could be malicious, e.g., containing committed binary files (autokey#1167) or suspicious dependencies (transformers#47278), have incorrect fixes due to wrong assumptions (freqtrade#12951) or unchecked code like comments left for future implementation (transformers#45076). c) Already done: Similarly, based on the knowledge of the project, maintainers mark or close PRs when: they address issues already fixed (OctoPrint#5169, airflow#68124), when they are duplicated PRs that only contain changes already present in another previously opened PR (transformers#44791, click#3494), or when the PR is superseded by another PR.

This latter case happens when part of the original PR is considered interesting for the project by the maintainer and integrated in another new PR (transformers#43330, pugixml#693). d) Unaware changes: This denotes changes submitted without considering the project context. Issue hijacking is the most illustrative case: a PR is submitted, addressing an issue that is not assigned to the PR’s author (Nettacker#1579, transformers#46672) or that is still being debated or discussed on how to address it (transformers#45043, pip-tools#2432). A speculative change is the opposite: e.g., when a PR tries to fix a problem that cannot happen in practice based on (false positive) static analysis (transformers#47389), code that is actually intended (transformers#44652), or introducing changes, such as new features, that have not been discussed beforehand (vllm#44723, gnuradio#7956). Finally, low hanging fruits PRs add small value to the project, e.g., rephrasing documentation or fixing typos (airflow#67758), while pointless changes are for PRs that do not bring any value according to the maintainer, e.g., changes in deprecated code (vllm#41921), or changing the formatting of the code (GmsCore#3639). e) Unreasonable diff: PRs pointed out for having an inappropriate change size are either too big (meson#15894) to be reviewed by a human or too narrow to bring interesting elements (vllm#40025). We use this code for PRs where the maintainer explicitly pointed out the size as the reason for flagging or closing the PR. Maintainer also point PRs bringing low-quality contributions, based on code and test quality (searxng#6209, RadioLib#1735). Unlike cases of build failures and insufficient verifications, the maintainer uses an authoritative argument and does not point to any additional factual element to tag or close the PR. Unlike PRs displaying inconsistent changes within the code (piptools#2357) or between the changes and the PR’s description (pandas#63093) for which the maintainer understands the modifications but finds them inconsistent, PRs recognized as having preposterous modifications do not make sense to the maintainer (transformers#46486: “Not sure it makes sense”). In some cases, it indicates a possible lack of control over AI agents: e.g., PRs for which the GitHub workflow was edited (transformers#46455) or the CI configuration was removed (uptime-kuma#6137) to make the build pass. f) Repository policy violation: We distinguish three policy levels pointed out by maintainers: AI policy, contributor guidelines, and general open-source principles. Depending on the repository, AI policy violation can include, e.g., not automatically submitting PRs (pip-tools#2371), allowing generative AI but requiring a human-written PR description (typescript-eslint#12272), disclosing the use of generative AI in the PR description (freqtrade#13161), not allowing generative AI for a first-time contribution (transformers#47686), or not allowing generative AI at all (click#3651). Classical contribution guidelines violations include, e.g., not following the PR template (typescript-eslint#11426), ignoring the project’s coding style (meson#16050), not using proper commit messages (tensorflow#92771), etc. Finally, Repository misuses denote PRs not respecting more general open-source principles, e.g.,

Table IV C ODES EXPLAINING THE REASONS PR S ARE CLOSED OR FLAGGED AS AI SLOP BY MAINTAINERS AND BOTS , GROUPED BY CATEGORY, WITH THE TOTAL NUMBER OF PR S FOR ALL PROJECTS AND FOR ALL PROJECTS WITHOUT HUGGINGFACE / TRANSFORMERS AND PALLETS / CLICK IN PARENTHESES . Code

Description

Maint.

Bots

An AI has signed a commit, a message, or a piece of code. The PR could not be built, either by the CI or locally by the maintainer. The PR does not include sufficient elements to show that the changes have been verified (e.g., test files, a proof of test, or decreased test coverage).

7 (5) 42 (40) 67 (64)

10 (10)

The maintainer suspects that the change would introduce malicious code to the codebase. The code change does not fix the underlying problem.

3 (2) 64 (56)

-

The issue the PR addresses has already been marked as fixed. The PR is a duplicate of another PR that is still open. The PR has been superseded by another PR: i.e., changes or part of the changes introduced by the PR have been included in the new PR.

18 (7) 76 (48) 12 (8)

-

The issue was opened and assigned to a contributor, but another author hijacked it to address it. The PR tries to fix a fault that never occurs in practice or add a feature that has never been discussed beforehand. The PR addresses minor issues or nitpicks without added value. The maintainer does not see the added functional or non-functional value of the changes made in the PR.

15 (4) 46 (35) 5 (5) 92 (73)

1 (1) -

The scope of the change is unreasonable, either too large or too small. The changes are of poor quality and the maintainer points to a specific part of the committed data or artifact, not the PR’s title or description. The changes are inconsistent with each other or with the PR’s description or title. The changes do not make sense to the maintainer, and the maintainer points to a specific element in the PR.

37 (33) 36 (32)

4 (4)

49 (42) 122 (99)

-

The author did not follow the project’s AI policy. The project’s contributor guidelines were not followed, regardless of the AI policy. The author opened the PR for personal reasons that do not align with open-source principles.

141 (90) 88 (87) 13 (12)

79 (45) -

The author submitted the PR and did not respond afterward. The PR was closed based on the author’s profile.

20 (16) 82 (68)

12 (-)

The maintainer has a strong stance against AI-generated contributions for personal or ideological reasons. The maintainer gave no reason for marking the PR other than that it looked AI-generated.

9 (6) 117 (79)

54 (54)

No reason was specified by the maintainer for marking the PR.

439 (100)

-

Desk rejection AI fingerprint Build failure Insufficient verification Bad code Could be malicious Incorrect fix Already done Issue already fixed Duplicated PR Superseded by another PR Unaware changes Issue hijacking Speculative change Low hanging fruits Pointless change Unreasonable diff Inappropriate change size Low-quality contribution Inconsistent changes Preposterous modifications Repository policy violation AI policy violation Contribution guidelines violation Repository misuse Contributor’s profile Unresponsive author Author’s profile Arbitrary judgment Ideological stance Looks AI to me Undisclosed Unspecified

trying AI tools on a third-party repository (freqtrade#12609), or advertising a tool or service (freqtrade#12987). g) Contributor’s profile: Unresponsive authors denote cases where the author opened a PR without responding afterward, also referred to as “drive-by” PRs (transformers#46313, freqtrade#13011). PRs can also be marked and closed based on the author’s profile. E.g., new accounts opening several PRs in a short amount of time (pip-tools#2417), which can lead to banning the author (vllm#37389). h) Arbitrary judgment: Maintainers can also tag and close PRs based on an arbitrary judgment, either by adopting an ideological stance and refusing to review AI-generated code (uptime-kuma#7426) or discouraging AI contributions (pandas-dev#62976), or by considering that the PR “looks AI to me” (flask#6034, pandas#64820). i) Undisclosed: Finally, a majority of PRs have been closed and marked by maintainers without any comment or review (transformers#45565, uptime-kuma#6667, click#3433). We hypothesize that this latter case is consistent with fatigue,

leading maintainers to mark or close PRs without further comment after processing several PRs, but alternative explanations such as an internal policy requiring them not to answer such PRs (“do not feed the troll” policy), or discussions happening via another (potentially private) channel remain plausible. j) Bots flagging and closing PRs: Bots rely on a small set of reasons to flag or close PRs, usually based on the analysis of the changes or PR’s metadata. E.g., githubactions can automatically close PRs if their description does not include proof of testing, denoting insufficient verification (refined-github#9562), or if the PR’s author hijacked an issue (Nettacker#1579). Similarly, coderabbitai is used to detect low quality contribution (Nettacker#1478: “This PR exhibits several hallmarks of a low-value contribution”). The most frequent contribution guideline violation concerns PRs not respecting the PR template or lacking elements in the description, detected using github-actions (trl#6485) or coderabbitai (prowler#11762). A github-actions bot is also used to automatically flag PRs based on the author’s profile

(transformers#45565: “Common reasons for flagging: New GitHub account; Unusually high number of repository forks in a 24-hour window”). Finally, PRs are also flagged or closed by bots based on unclear criteria (refined-github#9770: “This looks like an AI-generated PR”), sometimes asking for additional elements (refined-github#9829: “If you’re human and tested it, include a screenshot/video/gif [...]”), or even reopening a new issue (electron#51335: “If you believe your PR was closed in error, we welcome you to resubmit.”) Û RQ3 What reasons do FOSS project maintainers and bots give for flagging or closing PRs as AI slop? Most PRs are closed or marked as slop without any reason. Based on our open coding, reasons range from concrete elements, like build failures, to ideological or intuitive ones (“looks AI to me”). A large majority of PRs are also closed for AI policy violations or based on the PR author’s profile. V. T HREATS TO VALIDITY a) Conclusion validity: Our analyses are mostly descriptive. Given the sample size (1,786 PRs), statistical significance is uninformative on its own (e.g., p < 2 × 10−16 for the addition ratio). We therefore privilege proportions (94.1% of PRs add more lines than they delete). As our features follow heavily skewed distributions, we report medians and percentiles alongside the means. b) Construct validity: “AI slop” is a recent, unstable notion. We built our mining criteria on an initial exploratory study of the keywords and labels developers actually use, and we quantified the instrument’s precision: a manual review of all 1,959 matched PRs identified 173 false positives (91.17%), though a single author conducted this review. Since we cannot estimate recall as other projects may use different tactics or none at all, our results provide a lower bound on the incidence of slop PRs, grounded in maintainers’ judgment. We consider this the main threat to our validity. c) Internal validity: We retrieve only the latest PR state at mining time (e.g., reworked PRs are measured at their last commit). Our identification of slop relies on maintainer judgment, which may conflate AI-generated content with other low-value contributions by inexperienced contributors. Author protestations, observed in only 4.1% of cases, partially mitigate this. The mid-2025 increase could partly reflect confounders such as “AI slop” becoming a community meme, so we interpret trends as correlational rather than causal. For RQ3 , (i) seven PRs deleted between mining and annotation, and PRs deleted before collection entirely, may cause a survivorship bias toward extreme cases. Quantifying it requires longitudinal mining, left for future work; (ii) we code only reasons posted in the PRs and may have missed reasons expressed elsewhere (e.g., potentially private channels), which may inflate the unspecified category; (iii) two repositories account for ∼42% of the dataset. Our analysis (in IV) shows that unspecified PRs are overrepresented and that bots relying on author’s profile information have been observed in only

one repository; (iv) maintainers’ stated reasons are post-hoc rationalizations that may favor socially legitimate codes over intuitive ones. Nevertheless, such rationalizations provide a basis for defining stronger criteria for the future. d) External validity: Our incidence estimate (76 of 10,000 repositories) is conditioned on a profile of popular, mature, actively maintained projects [30], which likely increases both exposure to slop and the likelihood of flagging. Our strategy also ties to GitHub’s terminology and infrastructure, so incidence figures may reflect the diffusion of this vocabulary as much as the phenomenon itself. We conjecture that our taxonomy of reasons (RQ3 ) transfers better than our incidence figures (RQ1 ), but this remains to be verified. Finally, our window ends in July 2026 at an apparent peak. We cannot predict whether the volume will stabilize or continue to grow. e) Reliability: Independent annotators double-coded half of the dataset for RQ2 (Cohen’s κ from 0.90 to 1.00 with disagreements discussed and resolved). The manual review of false positives involved a single author. The list of false positive PRs is documented in the replication package [34]. For RQ3 , consistent with an interpretivist stance, we do not report inter-coder agreement and instead treat disagreements as information, relying on a jointly negotiated codebook and fully documented traceability. Since GitHub data evolves continuously, our results are tied to the frozen snapshot in the replication package. Re-running our scripts should be expected to yield different figures. f) Ethical Considerations: We mined only public data from GitHub, without interacting with human participants, complying with the platform’s terms of service. Nevertheless, the flagged PRs concern identifiable authors, and our aggregate “slop” labeling creates a lasting characterization of these individuals. We therefore limit citations to what illustrates the coding categories and report author behavior at an aggregate level where possible. As slop PRs are often deleted, preserving this snapshot also helps the research community document a transient phenomenon. VI. D ISCUSSION A. Incidence of maintainer-identified AI slop PRs Regarding the incidence within the FOSS ecosystem, our results identify mid-2025 as the tipping point after which slop PRs increased sharply. These results confirm Afroz et al.’s findings [1]. Although our study cannot establish causality, the observed surge temporally coincides with the widespread adoption of agentic coding tools during the course of 2025. Unlike code-completion assistants, agentic coding tools can autonomously identify issues, generate patches, produce PR descriptions, and submit PRs with limited human oversight (“one-click PRs”). This evolution changes the dynamics of FOSS contribution by lowering the barriers to opening a contribution, regardless of its value to maintainers (the occurrences of Already done and Unaware changes PRs tend to support this hypothesis). The contributors’ motivations for relying on this one-click approach remain unclear, but they might range from a willingness to boost their GitHub profile

to simple curiosity about their agents’ capabilities, without ruling out a genuine desire to contribute to the project, albeit pursued in an ill-advised manner. It is also worth noting that although the phenomenon is intense from the affected repositories’ point of view, slop PRs are not yet a homogeneous ecosystem-wide phenomenon; only 76 repositories out of 10,000 were identified. These results suggest that factors such as project popularity and issuetagging practices determine how exposed a repository is. B. Maintainer-identified AI slop PRs Characterizing AI slop PRs requires a non-slop PRs baseline. Gousios et al. [19] offer such information. The study explores the popularity of the pull-based development model with quantitative and qualitative methods. It analyzes 166,884 PRs across 291 projects. This provides a suitable baseline because the original work was published before AI-assisted coding tools emerged. The comparison reveals both similarities and differences. On the one hand, for the size fields, our slop PRs show similar medians, 1 commit and 2 changed files in both datasets, but higher means: 9.45 commits and 15 changed files in our dataset, compared to 4.47 commits and 12.12 changed files in the baseline. This highlights outliers pulling the distribution, while the core distribution of slop PRs is similar to that of non-slop PRs. In contrast, the end of slop PRs’ life cycle differs dramatically from that of their non-slop counterparts: barely 1% are merged, compared with 84.73% for non-slop PRs. The processing time for non-slop PRs is comparable to that of slop PRs, with both typically taking less than one day. However, their outcomes differ substantially. The number of comments is also similar, with an average of 3 comments for slop and non-slop PRs. Based on this observation, we conjecture that the high number of undisclosed PRs suggests that maintainers develop uncompromising classification heuristics. This suggests that AI-generated contributions are not as uniformly large and disruptive as one might think but are mostly driven by a few extremely “bad” and rapidly discarded PRs. The results suggest that, at the FOSS level, the phenomenon may be less severe than the disruption perceived by maintainers directly exposed to it. Nevertheless, for maintainers of affected repositories, the feeling of being overwhelmed appears well founded. Our findings also suggest a progressive erosion of maintainers’ willingness to engage with such contributions, as reflected in the increasing reliance on rapid rejection, automated filtering, and closures without justification. C. Maintainers response The following summarizes maintainers’ responses to AI slop, based on what we observe in the literature and the studied FOSS repositories. First, much work has focused on contribution guidelines and AI policies to regulate AI use [10], [23], [38]. These guidelines require, for example, disclosing the use of AI or forbidding its use altogether. Another response is to automate PR triage. Even before generative AI emerged, past studies focused on creating triage tools to prioritize

incoming PRs [3], [35], [47]. Additionally, researchers have automated code review, from research [42], [46] to industrial tools such as CodeRabbit [13]. To reduce the flow of incoming PRs, GitHub now allows maintainers to limit the number of open PRs by user [17] or even to disable PRs entirely [18]. FOSS communities have also begun to adapt, for example, by using trust management systems in which new contributors must be vouched for before contributing [16], [22]. Several categories in our taxonomy are grounded in objective and verifiable criteria, including build failures, insufficient verification, issue hijacking, and repository policy violations. These signals can be partially automated, reducing the review burden placed on maintainers. However, a substantial fraction of the reasons identified in our study depend on subjective assessments, such as determining whether a change is pointless, preposterous, or simply looks AI to me. Such evaluations require contextual knowledge of the project and, more broadly, alignment within the community regarding what constitutes a valuable contribution. The fact that the authors themselves flagged 0.4% of the annotated PRs as AI-generated might suggest that alignment between contributors and maintainers on the issue is possible, provided that authors understand why AI-powered submissions are problematic. In any case, these responses are the first of their kind, addressing a new systemic phenomenon that poses a real threat to the sustainability of the FOSS ecosystem. Future studies should investigate these strategies and assess their viability for FOSS. However, these investigations might be made more difficult (even impossible) due to the ephemeral nature of the phenomenon: between the mining phase and the annotation phase of our studies, 7 PRs were already deleted by the maintainers or the contributors themselves (hinting that more slop PRs might have been deleted even before the mining phase). Such deletions create survivorship bias and may complicate future longitudinal studies. VII. C ONCLUSION AND F UTURE W ORK In this study, we investigate the emergence of maintaineridentified AI slop PRs in FOSS. We found that the first trace of identified AI slop dates back to July 2024, but the monthly number of PRs does not increase significantly until mid-2025. In total, 76 repositories are affected, with the majority having fewer than 5 PRs. Those PRs are mostly additive, rarely discussed, and rarely merged (in less than 1%). 97.8% are closed and typically processed within 3 to 4 days. We manually annotated the PR dataset and found that 66.6% link to an issue, while only 13.9% disclose AI use. An additional 1.6% disclosed AI use only after the maintainer requested it. In 4.1% of cases, the author protested the flagging or closing of their PR. Bots were used to automate the flagging or closing in 119 PRs. Finally, our coding shows that most PRs are closed or flagged for unspecified reasons. Other reasons range from verifiable elements (e.g., Build failure) to more ideological or intuitive ones (e.g., Look AI to me). Most PRs are also closed for AI policy violation or based on the author’s profile.

The main limitation of this study is that our mining relies on an exploratory study of the keywords and labels developers actually used to identify PRs as AI slop, which may not be representative of the broader FOSS ecosystem. Additionally, because the term “AI slop” is relatively recent and its usage remains unstable, we treat our results as a lower-bound estimate of the incidence of “AI slop” PRs. Future work should replicate this analysis later to determine whether the prevalence of maintainer-identified AI slop PRs has changed or remained stable over time. Additionally, our open coding revealed several verifiable reasons for flagging or closing PRs as AI slop, which could inform the development of new tools to assist FOSS maintainers. Finally, since this study relies on maintainers’ judgments to identify AI slop PRs, future work should investigate whether these judgments can be explained by PR characteristics, such as code quality metrics or the relevance of proposed features to the project. Acknowledgment. Generative AI was used as a tool to help create scripts, in brainstorming exercises, in LATEX document editing, and to improve phrasing. R EFERENCES [1] S. Afroz, C. Miller, T. Menezes, E. Gilmour, A. Sarma, and Z. Feng. "AI Slop is DDoSing Open Source": Understanding the Impact of AI-Generated Contributions on Open Source Sustainability. [Online]. Available: http://arxiv.org/abs/2607.04003 [2] A. Alami, R. Pardo, M. L. Cohn, and A. Wasowski, ˛ “Pull Request Governance in Open Source Communities,” IEEE Transactions on Software Engineering, vol. 48, no. 12, pp. 4838–4856, 2021. [3] M. I. Azeem, S. Panichella, A. Di Sorbo, A. Serebrenik, and Q. Wang, “Action-based Recommendation in Pull-request Development,” in Proceedings of the International Conference on Software and System Processes. ACM, 2026, pp. 115–124. [4] D. Badampudi, M. Unterkalmsteiner, and R. Britto, “Modern Code Reviews – Survey of Literature and Practice,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 4, pp. 1–61, 2023. [5] S. Baltes, M. Cheong, and C. Treude. AI Slop and the Software Commons. [Online]. Available: https://ui.adsabs.harvard. edu/abs/2026arXiv260416754B [6] ——, ““An Endless Stream of AI Slop”: How Developers Discuss the Burden of AI-Assisted Software Development,” IEEE Software, pp. 1–8, 2026. [7] E. T. Barr, C. Bird, P. C. Rigby, A. Hindle, D. M. German, and P. Devanbu, “Cohesive and Isolated Development with Branches,” in Fundamental Approaches to Software Engineering, J. De Lara and A. Zisman, Eds. Springer Berlin Heidelberg, 2012, vol. 7212, pp. 316–331. [8] BleepingComputer, “Curl ending bug bounty program after flood of AI slop reports,” Jan. 2026, (last visited: 2026-10-23). [Online]. Available: https://www.bleepingcomputer.com/news/security/ curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/ [9] F. Calefato, F. Lanubile, and N. Novielli, “A preliminary analysis on the effects of propensity to trust in distributed software development,” in 2017 IEEE 12th International Conference on Global Software Engineering (ICGSE). IEEE, 2017, pp. 56–60. [10] Y. Chen, T. Zimmermann, and B. Trinkenreich. Making AI Visible, Not Vanished: How AI Policies Reshape Developer Experience on GitHub. [Online]. Available: http://arxiv.org/abs/2608.03329 [11] M. Chouchen, N. Bessghaier, M. Begoug, A. Ouni, E. Alomar, and M. W. Mkaouer, “How Do Software Developers Use ChatGPT? An Exploratory Study on GitHub Pull Requests,” in Proceedings of the 21st International Conference on Mining Software Repositories. ACM, 2024, pp. 212–216. [12] U. Cihan, V. Haratian, A. İçöz, M. K. Gül, Ö. Devran, E. F. Bayendur, B. M. Uçar, and E. Tüzün, “Automated code review in practice,” in 2025 IEEE/ACM 47th International Conference on Software Engineering:

Software Engineering in Practice (ICSE-SEIP). IEEE, 2025, pp. 425– 436. [13] CodeRabbit, “Ai code reviews,” 2026, (last visited: 2026-10-23). [Online]. Available: https://www.coderabbit.ai/ [14] O. Dabic, E. Aghajani, and G. Bavota, “Sampling projects in github for MSR studies,” in 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, 2021, pp. 560–564. [15] A. Fan, B. Gokkaya, M. Harman, M. Lyubarskiy, S. Sengupta, S. Yoo, and J. M. Zhang, “Large language models for software engineering: Survey and open problems,” in 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE). IEEE, 2023, pp. 31–53. [16] Ghostty. Ghostty/CONTRIBUTING.md at main · ghostty-org/ghostty. GitHub. [Online]. Available: https://github.com/ghostty-org/ghostty/ blob/main/CONTRIBUTING.md [17] GitHub. Limit open pull requests for users without write access GitHub Changelog. The GitHub Blog. [Online]. Available: https://github.blog/changelog/ 2026-06-17-limit-open-pull-requests-for-users-without-write-access/ [18] ——. New repository settings for configuring pull request access GitHub Changelog. The GitHub Blog. [Online]. Available: https://github.blog/changelog/ 2026-02-13-new-repository-settings-for-configuring-pull-request-access/ [19] G. Gousios, M. Pinzger, and A. V. Deursen, “An exploratory study of the pull-based software development model,” in Proceedings of the 36th International Conference on Software Engineering. ACM, 2014, pp. 345–355. [20] G. Gousios, A. Zaidman, M.-A. Storey, and A. van Deursen, “Work Practices and Challenges in Pull-Based Development: The Integrator’s Perspective,” in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 1, 2015, pp. 358–368. [21] B. Greshake Tzovaras, O. Richter, and W. Zijl, “Protecting our FLOSS commons from LLMs,” Codeberg News (blog), 2026, (last visited: 2026-10-23). [Online]. Available: https://blog.codeberg.org/ protecting-our-floss-commons-from-llms.html [22] M. Hashimoto, “Vouch: A community trust management system,” (last accessed: 2026-09-23). [Online]. Available: https://github.com/ mitchellh/vouch [23] A. Hora and R. Robbes, “AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI?” in Proceedings of the 42nd International Conference on Software Maintenance and Evolution (ICSME ’26). IEEE, 2026. [24] X. Hou, Y. Zhao, Y. Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large Language Models for Software Engineering: A Systematic Literature Review,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 8, pp. 1–79, 2024. [25] M. Klincewicz, M. Alfano, and A. E. Fard, “Slopaganda: The interaction between propaganda and generative AI,” arXiv Prepr. arXiv250301560, 2025. [26] M. Koren, G. Békés, J. Hinz, and A. Lohmann. Vibe Coding Kills Open Source. [Online]. Available: http://arxiv.org/abs/2601.15494 [27] H. Li, H. Zhang, and A. E. Hassan. The Rise of AI Teammates in Software Engineering (SE) 3.0: How Autonomous Coding Agents Are Reshaping Software Engineering. [Online]. Available: http://arxiv.org/abs/2507.15003 [28] J. Linåker, G. Link, and K. Lumbard, “Sustaining Maintenance Labor for Healthy Open Source Software Projects through Human Infrastructure: A Maintainer Perspective,” in Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ACM, 2024, pp. 37–48. [29] D. Ø. Madsen and R. W. Puyt, “When AI turns culture into slop,” AI & Society, vol. 41, no. 2, pp. 1287–1288, 2026. [30] S. Mohsenimofidi, M. Galster, C. Treude, and S. Baltes, “Context engineering for ai agents in open-source software,” in Proceedings of the 23rd International Conference on Mining Software Repositories. ACM, 2026, p. 194–198. [31] C. Moraes and A. Wolf, “How pull request limits are cutting down the noise,” The GitHub Blog, 2026, (last visited: 2026-1023). [Online]. Available: https://github.blog/open-source/maintainers/ how-pull-request-limits-are-cutting-down-the-noise/ [32] ppkarwasz, “Addressing AI-slop in security reports,” Apache Logging Services Discussion #4052, Feb. 2026, (last visited: 2026-1023). [Online]. Available: https://github.com/apache/logging-log4j2/ discussions/4052

[33] N. Raman, M. Cao, Y. Tsvetkov, C. Kästner, and B. Vasilescu, “Stress and burnout in open source: Toward finding, understanding, and mitigating unhealthy interactions,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: New Ideas and Emerging Results, ser. ICSE-NIER ’20. Association for Computing Machinery, 2020, pp. 57–60. [34] H. Raskin, X. Devroey, and B. Vanderose, “Replication package,” (to be uploaded). [35] ——, “PRECOG: Pull Request Prioritization and Visualization,” in 2026 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2026, pp. 1040–1044. [36] P. C. Rigby and C. Bird, “Convergent contemporary software peer review practices,” in Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering. ACM, 2013, pp. 202–212. [37] P. C. Rigby and M.-A. Storey, “Understanding broadcast based peer review on open source software projects,” in Proceedings of the 33rd International Conference on Software Engineering. ACM, 2011, pp. 541–550. [38] G. Robles and D. M. German. You can contribute if you... An Empirical Framework of AI Contribution Policies in OSS. [Online]. Available: http://arxiv.org/abs/2609.07919 [39] C. Sadowski, E. Söderberg, L. Church, M. Sipko, and A. Bacchelli, “Modern code review: A case study at google,” in Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice. ACM, 2018, pp. 181–190. [40] J. Saldaña, The coding manual for qualitative researchers. Sage, 2009. [41] Y. Shen, T. Wang, X. Zhang, Y. Zhang, C. Yang, Y. Yu, and H. Wang, “Are External Contributions Important to Project Productivity in Open Source Software? A Deep Insight based on Issue Entropy,” Proceedings of the ACM on Human-Computer Interaction, vol. 9, no. 7, pp. 1–26, Oct. 2025. [42] S.-T. Shi, M. Li, D. Lo, F. Thung, and X. Huo, “Automatic code review by learning the revision of source code,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 33, no. 01, 2019, pp. 4910– 4917. [43] F. Song, A. Agarwal, and W. Wen. (2026) The Impact of Generative AI

on Collaborative Open-Source Software Development: Evidence from GitHub Copilot. [44] J. Tsay, L. Dabbish, and J. Herbsleb, “Influence of social and technical factors for evaluating contribution in GitHub,” in Proceedings of the 36th International Conference on Software Engineering. ACM, 2014, pp. 356–366. [45] ——, “Let’s talk about it: Evaluating contributions through discussion in GitHub,” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. ACM, 2014, pp. 144–154. [46] R. Tufano, O. Dabić, A. Mastropaolo, M. Ciniselli, and G. Bavota, “Code review automation: Strengths and weaknesses of the state of the art,” IEEE Transactions on Software Engineering, vol. 50, no. 2, pp. 338–353, 2024. [47] E. Van Der Veen, G. Gousios, and A. Zaidman, “Automatically prioritizing pull requests,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories. IEEE, 2015, pp. 357–361. [48] R. Verschelde, “Honestly, AI slop PRs are becoming increasingly draining and demoralizing for #godot maintainers,” Bluesky, Feb. 2026, (last visited: 2026-10-23). [Online]. Available: https://bsky.app/profile/ did:plc:v6vo5mafc2uirknvv5jegtzz/post/3meyerixvhs2p [49] H. Washizaki, Ed., Guide to the Software Engineering Body of Knowledge (SWEBOK) Guide, Version 4.0. IEEE Computer Society, 2024. [Online]. Available: https://www.swebok.org/ [50] T. Xiao, H. Hata, C. Treude, and K. Matsumoto, “Generative AI for Pull Request Descriptions: Adoption, Impact, and Developer Interventions,” Proceedings of the ACM on Software Engineering, vol. 1, pp. 1043– 1065, 2024. [51] Y. Yu, H. Wang, V. Filkov, P. Devanbu, and B. Vasilescu, “Wait for it: Determinants of pull request evaluation latency on github,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories. IEEE, 2015, pp. 367–371. [52] M. Zhou and A. Mockus, “Who will stay in the floss community? modeling participant’s initial behavior,” IEEE Transactions on Software Engineering, vol. 41, no. 1, pp. 82–99, 2014.

Related documents

• An Empirical Study of Maintainer-Identified AI Slop Pull Requests in Free and Open Source Software Projects#1658491
• How Developers Discuss Generative AI: A Longitudinal Study of the Visual Studio Code Community#927947
• Developers and generative AI: A study of self-admitted usage in open source projects.#1346734
• What Will Replace Pull Requests? Rethinking Software Collaboration for AI Agents#1458087
• What Will Replace Pull Requests? Rethinking Software Collaboration for AI Agents#1450860