AI Slop in Pull Requests: What the 25% Statistic Actually Measures

The Linux Foundation reported in October 2026 that one in four incoming pull requests is “AI slop.” The figure is useful evidence of maintainer concern. It is not a measured rate across GitHub.

The chart shows observable queue pressure in three public GitQuick snapshots. It does not identify AI-authored pull requests or assess code quality.

The distinction matters. Teams cannot copy 25 percent into an engineering dashboard and call it an AI pull request quality metric. They need repository evidence for intake, review coverage, and stale work, plus a separate and explicit method for identifying AI assistance.

What the Linux Foundation published

The Linux Foundation announced the report on October 20, 2026. OpenSSF republished the press release on October 30. The underlying report is titled Navigating Open Source Software Development in the Generative AI Era.

The study used a 45-question web survey fielded from April through June 2026. Its analytical sample contained 234 qualified open-source contributors and maintainers. Respondents came through Linux Foundation and research-partner newsletters, email lists, and social channels.

The widely repeated 25 percent result comes from Figure 2. That figure uses 111 respondents and reports their average estimated percentage of incoming pull requests that were “low-quality and/or AI-generated.” The surrounding text describes them more narrowly as AI-generated low-quality contributions.

Those wordings are not identical. “Low-quality and/or AI-generated” can include an AI-assisted contribution that is not low quality, depending on how the respondent interpreted the question. The report text intends the combined concept of low-quality AI-generated work. Either way, respondents estimated the share. Researchers did not classify a representative sample of GitHub pull requests.

This does not make the finding useless. It makes it a survey finding with a defined sample and wording. Hilary Carter, the Linux Foundation’s SVP of Research, said projects “need to design for a growing AI-generated contributor base.” Adrianne Marcum of OpenSSF added that contributors “still need to understand and test what they submit.”

Why the 25 percent figure is not a repository metric

A repository metric needs a repeatable numerator and denominator.

For an AI slop rate, the denominator could be all opened pull requests in a period. The numerator would require two separate judgments:

1. Was the pull request generated or assisted by AI?
2. Did it meet a documented definition of low quality or inadequate verification?

Public GitHub metadata does not answer either question reliably. Bot-like account names can identify some automation, but human accounts also submit AI-assisted work. Commit messages, pull request descriptions, and disclosure labels are incomplete unless a project enforces a convention.

Quality is harder. A large change, a fast review, or a change request is not proof of poor code. A pull request may be rejected because it duplicates existing work, violates project scope, lacks tests, or arrives against the wrong branch. Those are different review outcomes and should not be collapsed into one label.

What repository data can measure instead

The report’s operational concern is maintainer pressure. Repository data can measure parts of that pressure directly.

GitQuick’s public Showcase listed 21 organizations when the following snapshots were fetched on November 2, 2026.

Opened and merged per week describe different event counts in the same organization window. They are not a cohort funnel. A pull request opened during the window may merge later, while a pull request opened earlier may merge during the window.

GitQuick defines a stale open pull request as an open PR with no recorded review activity for at least 72 hours at the run end. Comments outside submitted review events are not included in this definition. The first-review median includes only pull requests with valid creation and first-review timestamps, so every median is paired with its eligible sample.

The rows are not rankings. These organizations have different repositories, contributor policies, automation, and maintenance models. The table cannot show whether AI caused intake growth, whether any stale PR is low quality, or whether a maintainer is overloaded.

Build an AI contribution policy before a score

Start with disclosure. Define what counts as AI-assisted work and require contributors to use a label, pull request field, or commit trailer. Treat missing disclosure as unknown, not human-authored.

Then define verification requirements. A useful policy can require the contributor to understand the change, run named tests, explain the validation performed, and disclose generated sections. These are auditable conditions. “Low quality” without criteria is not.

Measure the workflow around that policy:

• opened and merged pull requests per week for queue pressure;
• stale open count and share for unattended work;
• first-review median and p90 with eligible samples;
• merged-without-review share for visible review coverage;
• change-request and later-approval activity for follow-up.

Segment by repository and contribution source when the labels are trustworthy. Review a sample of affected pull requests before changing contributor limits or reviewer allocation.

GitQuick exposes these workflow measures through Metrics, Trend, Compare, and deterministic Signals. It does not currently identify AI-authored pull requests or grade contribution quality. Use it to locate queue and review pressure, then inspect the underlying pull requests and policy evidence.

Takeaway

The Linux Foundation report documents a real maintainer concern. Its 25 percent figure is an estimate from a survey subgroup, not a universal GitHub baseline.

Keep the claim attached to its method. Measure observable queue pressure separately. If a project wants an AI contribution quality rate, it must first establish reliable disclosure and a reviewable definition of quality.

For related guidance, read More PRs Open Than Close? Your Review Queue Is Growing and Your Code Review Metrics Are Missing Part of the Story.

Explore the GitHub public Showcase, compare all public organizations, or try GitQuick on your organization.

Disclaimer: The Linux Foundation figures describe responses to a web survey fielded from April through June 2026. GitQuick Showcase figures use public GitHub metadata for the organization-wide windows shown above and were fetched on November 2, 2026. Public metadata cannot establish AI authorship, contribution quality, developer performance, maintainer burnout, or causality. GitQuick is not affiliated with or endorsed by the Linux Foundation, GitHub, or any organization mentioned.