Linux Foundation Survey: Maintainers Estimate 25% of Incoming Open-Source PRs Are AI Slop

TL;DR

Linux Foundation Research released Navigating Open Source Software Development in the Generative AI Era on October 20. It surveyed 234 open-source contributors and maintainers between April and June 2026. Maintainers estimate that 25% of their incoming pull requests are low-quality AI-generated contributions, and the figure is 31% at projects with more than 50 contributors. The same respondents say AI cut the time it takes them to write code by 52%. Only 35% of projects have a formal policy allowing AI-assisted contributions, and community trust is the outcome maintainers most often say AI has not improved.

Who answered the survey

Sam Boysel of the Linux Foundation and Anni Lai of the Generative AI Commons wrote the report. Brian Proffitt of Red Hat, the sponsor, wrote the foreword. Futurewei, OpenSSF and LF AI & Data also supported it, and the foundation presented the findings at All Things Open in Raleigh.

The survey ran on the web and had 45 questions. It went out through Linux Foundation newsletters and social channels and through partners including Red Hat, OpenSSF, Kaiyuanshe, GOSIM and LF AI & Data. It ended with 234 qualified respondents and a stated margin of error of plus or minus 6.41% at 95% confidence. 206 of them call themselves contributors and 134 maintainers, and many are both. Most have been at it a long time: about 52% have 11 or more years as contributors, and operating systems and Linux distributions are the most common project domain (37%).

Proffitt's foreword explains why the foundation bothered: "Much of the discussion to date has been anecdotal: endless tales of 'AI slop,' overwhelmed maintainers, and eroding trust." For the record, the methodology page says LF Research itself uses generative AI for tasks including "supporting report drafting" and copyediting, with every AI-generated passage reviewed. A report on AI slop that discloses its own AI use is already ahead of the 19% of contributors who never do.

One in four pull requests, and more at big projects

The report defines AI slop as "low quality AI-generated contributions that are unlikely to be worth the review time they demand." 111 maintainers estimated how much of their incoming pull request traffic fits that description, and their answers averaged 25%.

Bigger projects get more of it. Projects with more than 50 contributors report a mean slop share of 31%, compared with 23% for small projects (fewer than 10 contributors) and 20% for medium ones. Co-maintainers report the most of any role, 29%, about 6 points above lead and solo maintainers. The authors think the wider contributor networks behind co-maintained projects get less direct oversight.

Volume is up as well. 59% of maintainers say contributions have increased since generative AI arrived, and 4% say they fell. At large projects, 69% report an increase.

The cost is lopsided. A contributor can produce a plausible pull request for the price of a prompt, but the maintainer still has to read every line of it. Picture a restaurant that lets any customer send a dish to the kitchen for free: the head chef still has to taste each plate before turning it down.

Reviews take longer, and burnout leads at large projects

52% of maintainers say AI-assisted contributions have made their average review time longer, and 17% say shorter. At large projects the split is 64% to 7%.

Solo maintainers break the pattern: 32% report shorter reviews and 23% longer. The report puts that down to the smaller, more familiar group of contributors a solo maintainer usually deals with.

The top concern depends on size. Small and medium projects rank contribution quality first (51% and 50%). At large projects, maintainer burnout comes first at 63%, ahead of quality at 60% and contribution volume at 43%.

Policy and verification are mostly informal

35% of projects have a formal policy permitting AI-assisted contributions. 32% have no policy and no plans for one, 23% plan to write one, and 10% ban AI contributions. Among projects with a policy, 76% cover disclosure of AI use and 76% make the contributor responsible for review. Only 39% address licensing and copyright.

Verification mostly comes down to trust. 47% of maintainers rely on trusting the contributor and 44% inspect the code themselves, while 26% have no way of verifying AI-generated contributions at all. Attestation requirements, where contributors have to make explicit statements or pass provenance checks, rise from 20% at small projects to 41% at large ones.

Maintainers also use AI on the AI. 58% have an LLM explain or summarize the logic in incoming contributions, 48% check for bugs and edge cases through an AI chat or IDE, 39% run automated vulnerability scanning and 38% generate test cases. 23% use no AI tools for vetting.

Contributors say they test, and many do not disclose

From the other side of the pull request, 61% of contributors say they review AI-generated code line by line and run full functional tests before they submit. 34% run high-level functional tests only, and 5% do minimal or no review. Disclosure varies more. About half label AI-assisted work always or most of the time, 29% sometimes, and 19% never.

Those answers sit oddly next to the maintainers' 25% estimate. Either the people sending slop mostly skipped the survey, or "detailed review" covers a wider range of effort than it sounds. The data cannot say which.

The report holds up the Linux kernel's guidance, which asks for an Assisted-by tag naming the model and any tools used, as a better convention than the Apache Software Foundation's suggested Generated-by. The authors call Generated-by misleading when a human wrote or edited part of the change.

Where the time savings show up

Respondents who use AI estimated how long typical tasks took before and after they started. Writing code fell from 4 hours 18 minutes to 2 hours 6 minutes on average, which the report calls a 52% reduction, and code review and feedback fell 44%. Discussion moved much less: technical discussion fell 20% and discussion on proposals 19%.

The savings shrink as tasks get harder. 79% save time on low-complexity tasks and 83% on moderate ones. On high-complexity tasks, 64% still save time, but 21% say AI makes the work take longer. Most of the saved time goes back into the projects: 66% put it toward technical debt, 63% toward new features and 58% toward learning.

Maintainers split the same way on community health. 71% agree AI lowers the barrier to entry for open source, but 53% disagree that it has improved community trust, and only 13% agree. 46% say AI increases the mentoring new contributors need, and 32% say it reduces it.

Curl got its slop problem under control

The report cites curl as evidence that the problem can shrink. Lead developer Daniel Stenberg wrote in July 2025 that AI-generated vulnerability reports were swamping the project, in a post titled "Death by a Thousand Slops." By April 2026, the report notes, he said curl had "stopped getting AI slop security reports" and was instead getting "an ever-increasing amount of really good security reports, almost all done with the help of AI."

The authors also warn against banning everything. Policies that reject every AI-assisted security report "put users at extreme risk," they write, quoting Michael Catanzaro's June blog post: "banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable."

Caveats

• The 25% figure is what maintainers estimated, not a count of labeled pull requests. The chart in the report describes it as the share of PRs "that are low-quality and/or AI-generated," so some respondents may have included ordinary bad PRs.
• Respondents chose to answer, came through Linux Foundation and partner channels, and lean toward long-tenured infrastructure developers.
• 111 people answered the slop question and 96 answered the productivity question. The stated 6.41% margin of error applies to all 234 respondents, so subgroups such as large projects have wider error bars.
• The time savings are before-and-after estimates from memory, not measured task times.

What to do with it

If you maintain a project, write the policy before your queue forces you to. Require disclosure, make contributors responsible for testing their changes, and add an attestation step once volume makes trust-based review impractical, which is roughly where the large projects in this sample already are. "Open source projects need to design for a growing AI-generated contributor base, not simply react to it," said Hilary Carter, the Linux Foundation's SVP of Research, in the announcement.

If you contribute, testing and tagging your AI-assisted patch takes a few minutes, and it is the one part of the job the maintainer cannot do for you.

Key Takeaways

• Maintainers in a 234-person Linux Foundation survey estimate that 25% of incoming pull requests are low-quality AI contributions, and 31% at projects with more than 50 contributors.
• 64% of large-project maintainers say AI-assisted contributions made reviews take longer, and burnout (63%) is their top concern.
• Only 35% of projects formally permit AI contributions, and 26% of maintainers have no way to verify them.
• Self-reported savings reach 52% for writing code but only 19-20% for discussion, and 21% say complex tasks take longer with AI.
• Curl went from drowning in AI slop reports in 2025 to receiving mostly good AI-assisted reports by April 2026, according to Daniel Stenberg.
• The numbers are self-reported estimates from a self-selected sample, so read them as a direction rather than a census.

Sources: Linux Foundation press release, LF Research report page, full report (PDF), Phoronix, Daniel Stenberg, Michael Catanzaro, Linux kernel docs