Key Takeaways
- A study posted to arXiv on November 11, 2026 by University of Namur researchers found 1,786 pull requests that maintainers had flagged as AI slop in 76 open-source repositories, from July 2024 to July 2026.
- Flagged PRs went from 0 to 5 a month through August 2025 to 342 in May 2026, the peak, and stayed above 300 in June and July 2026.
- Only 11 of the 1,786 (0.6%) were merged. The paper compares that with 84.73% for ordinary pull requests in earlier research. The median flagged PR was closed in about 6.5 hours.
- Authors disclosed AI use up front in 13.9% of cases. AI policy violations (cited 141 times) and contribution guideline violations (167 times, 79 of them by bots) were among the most cited reasons.
- By our count of the paper's reason table, 652 of 1,321 named-reason mentions (49%) are things a contributor can check before or while submitting.
The AI slop pull requests study from the University of Namur is the first project-level count of AI-generated pull requests that open-source maintainers rejected as slop. It measures how many arrive, what they look like and why they get closed. This post sets those numbers against the platform changes that followed and turns the closing reasons into a pre-submit checklist.
What happened
On November 11, 2026, Hugo Raskin, Xavier Devroey and Benoît Vanderose of the University of Namur posted "An Empirical Study of Maintainer-Identified AI Slop Pull Requests in Free and Open Source Software Projects". They searched 10,000 popular GitHub repositories for pull requests whose title or label calls them slop, such as "slop", "ai-spam" or "rejected ai". After removing false positives, 1,786 PRs in 76 repositories remained. Three authors then coded each PR's origin, handling and the reason the maintainer gave.
The study doesn't decide what counts as slop. It counts what maintainers themselves labeled that way, which makes it a record of how projects are reacting, not a measure of AI code quality.
The details that matter to engineers
Small, additive and closed within hours
The typical flagged PR is small. The median one changed 2 files, added 33 lines and deleted 2. In 94.1% of them, more lines were added than deleted. The means are much larger (1,413.77 lines added on average), so a minority of very large drops pulls the average up.
Maintainers dealt with them fast. 1,748 (97.9%) were closed without merging, 27 were still open and 11 were merged. The median unmerged PR was closed in 0.27 days, about 6.5 hours, with a mean of 3.25 days. The paper puts the gap with ordinary contributions plainly: "barely 1% are merged, compared with 84.73% for non-slop PRs." That baseline comes from an earlier study of GitHub pull requests, not from the same repositories, so treat it as a reference point rather than a controlled comparison.
Few authors said they used AI
Only 13.9% of the PRs disclosed AI use up front, and another 1.6% did so after a maintainer asked. The other 84.5% said nothing. Two thirds (66.6%) linked to an existing issue. Maintainers, not bots, did almost all the flagging (97.5%) and most of the closing (90.0%). Authors pushed back on the decision in 4.1% of cases.
The load is concentrated. huggingface/transformers had 454 of the PRs and pallets/click had 291, about 42% between them. The median affected repository had 4.5, and 1,074 different accounts opened them. The median account opened just one.
Why maintainers closed them
The paper coded each stated reason, and a PR can carry several. Its abstract says "Most PRs are closed or marked as slop without any reason." In the reason table, the largest single code is "unspecified," on 439 PRs. Among the named reasons, the paper says they "range from concrete elements, like build failures, to ideological or intuitive ones."
"Looks AI to me" was cited 171 times, 54 of them by bots. That's a judgment no checklist fixes. But the next two codes are rules a contributor can read before opening anything: contribution guideline violations (167 times, 79 of them enforced by bots) and AI policy violations (141).
AI slop pull requests study: what the numbers show
The study ends in July 2026, but platforms and projects had already started reacting. We lined up the paper's monthly counts with the dated responses. The paper mentions some of these measures. The timeline is ours.
| When | Flagged AI slop PRs (paper) | Platform or project response |
|---|---|---|
| Jul 2024 – Aug 2025 | 0 to 5 a month | None of the measures below yet |
| Sep – Oct 2025 | 13, then 50 | |
| Nov – Dec 2025 | 36 across both months | |
| Jan 2026 | 62 | |
| Feb 2026 | Not given in the text | GitHub adds settings to turn pull requests off or limit them to collaborators (Feb 13). Ghostty moves to Vouch: "This moves Ghostty to a vouch-based contribution system." |
| May 2026 | 342 (peak); 14 repositories hit for the first time | |
| Jun 2026 | 327 | GitHub lets maintainers cap open PRs for users without write access (Jun 17), citing "repeated low-quality or drive-by contributions" |
| Jul 2026 | 335 | Codeberg members vote 358 to 144 for a Terms of Use change to prohibit "vibe-coded projects" (vote ends Jul 22) |
| Aug 2026 | After the study window | GitHub extends PR limits to the organization level (Aug 6) |
Two things stand out. Volume kept rising after the February controls shipped, and the new affected repositories jumped in May. The GitHub controls are opt-in, so a timeline can't tell you whether they worked. It does show that four of the five responses limit who can open a PR or how many, rather than judging the code inside it.
What the study can't tell you
The authors call keyword and label mining "the main threat" to validity. Projects that close slop without labeling it are invisible, so "our results provide a lower bound on the incidence of slop PRs." The sample is popular, mature repositories. Two projects supply about 42% of the PRs. The paper doesn't measure which tools produced the code. It says the surge "temporally coincides with the widespread adoption of agentic coding tools during the course of 2025" and that it "cannot establish causality." Its summary statements also don't always match its tables. For example, the abstract says PRs were "typically closed within 3 days," while Table II gives a median of about 6.5 hours. We use the table figures.
What this means for you
If you send AI-assisted pull requests to open source
We sorted the paper's reason codes by whether the contributor controls them. The grouping is our reading, not the authors'.
| Reason code (times cited) | What to do before you open the PR |
|---|---|
| Contribution guidelines violation (167) and AI policy violation (141) | Read CONTRIBUTING and the AI policy, if there is one. It tells you whether AI-assisted PRs are welcome and how to disclose them. |
| Insufficient verification (77) and build failure (42) | Run the build and the tests locally and paste the output. The paper's definition: the PR "does not include sufficient elements to show that the changes have been verified." |
| Duplicated PR (76), issue already fixed (18), superseded (12) | Search open and recently closed PRs for the same fix first. |
| Speculative change (46) | Don't fix "a fault that never occurs in practice." Open an issue and get agreement before writing a feature. |
| Inappropriate change size (37) | Keep the diff to one change a reviewer can read in one sitting. |
| Unresponsive author (20) and issue hijacking (16) | Answer review comments, and don't take an issue that's assigned to someone else. |
Disclose AI use either way. In this dataset, 84.5% of authors didn't. "Looks AI to me" was cited 171 times, so staying quiet about it doesn't hide anything. It just costs you trust.
If you maintain a project
- Write the AI policy down. It gives you a reason to cite. "AI policy violation" (141) is a concrete code, while "looks AI to me" leaves the contributor nothing to fix.
- Automate the checkable reasons. The authors suggest that verifiable signals, such as build failures, missing verification and policy violations, could be partly automated. Bots already enforced the contribution guidelines on 79 PRs.
- Use the platform controls. GitHub's per-user open-PR cap, its collaborators-only setting and vouch lists all limit how much one account can send you.
How this connects
The review cost behind these numbers matches what we saw in the Harvard AI coding agents study: agents raised code volume, and review became the bottleneck. Slop PRs are the open-source version of that, landing on volunteers. Passing a review isn't the same as being correct, either. Our AI-generated code security study post found agent code that passed tests and was still exploitable. For more on reviewing and shipping with AI, see the AI engineering hub and Will AI Replace Software Engineers? What the 2026 Data Actually Says.
Open-source work is also part of many engineers' public record, and reviewers notice who sent what. "Author's profile" was cited 94 times. The habits that get a PR merged are the same ones reviewers look for in a take-home coding assignment: a scoped change, proof it works and a clear explanation. Mastering the Tech Interview covers how to talk about that work in interviews.
FAQ
What is an AI slop pull request?
In this study, it's a pull request that a project's maintainers labeled as slop, AI junk or AI spam, either in the title or with a label. The researchers didn't judge the code themselves. They counted what maintainers flagged: 1,786 PRs in 76 open-source repositories from July 2024 to July 2026.
Do AI-generated pull requests get merged?
Rarely, once a maintainer flags them as slop. Of the 1,786 flagged PRs, 11 (0.6%) were merged and 1,748 (97.9%) were closed unmerged. The median unmerged PR was closed in about 6.5 hours. AI-assisted PRs that maintainers didn't flag aren't in the dataset.
Should I disclose AI use in an open-source pull request?
Yes, and follow the project's AI policy if it has one. Only 13.9% of the flagged PRs disclosed AI use up front, and AI policy violations were cited 141 times. A project's AI policy or CONTRIBUTING file is where it says whether AI-assisted contributions are allowed and how to mark them.
How are GitHub and other platforms responding to AI slop PRs?
GitHub added settings to turn pull requests off or restrict them to collaborators (February 13, 2026), a per-user cap on open PRs for users without write access (June 17, 2026) and organization-level PR limits (August 6, 2026). Ghostty moved to a vouch-based contribution system in February 2026, and Codeberg members voted in a ballot that closed July 22, 2026 to change its Terms of Use to prohibit "vibe-coded projects."
Further Reading
- Raskin, Devroey & Vanderose, "An Empirical Study of Maintainer-Identified AI Slop Pull Requests in Free and Open Source Software Projects": the paper (arXiv, November 11, 2026), with the reason taxonomy and replication package.
- GitHub Changelog, "Limit open pull requests for users without write access": the June 2026 per-user PR cap.
- GitHub Changelog, "New repository settings for configuring pull request access": disabling PRs or limiting them to collaborators.
- ghostty-org/ghostty #10559, "Introduce the Vouch/Denouncement Contribution Model": how one project gates new contributors.
- Codeberg, "Protecting our FLOSS commons from LLMs": the July 2026 vote and Terms of Use change.
