Generative AI is cutting the time it takes open source developers to write code almost in half. It is also flooding maintainers’ inboxes with low-quality contributions that reviewers have started calling “AI slop.” That is the headline finding from a Linux Foundation survey covered by The Register on October 21, 2026, and it captures a tension that has been building across GitHub repositories for more than a year: the tools that make contributing easier are not making the resulting code better.
The survey puts a number on a problem maintainers have been describing anecdotally since coding assistants went mainstream. Respondents estimated that 25% of incoming pull requests are low-quality AI-generated submissions. On large projects, that estimate climbs to 31%. At the same time, the same respondents say generative AI cut their code-authoring time by an average of 52%. Two numbers, same survey, and they point in opposite directions at once: more code, faster, with a meaningfully larger share of it not worth a reviewer’s time.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What the Linux Foundation Survey Actually Found
The findings come from Linux Foundation research into how generative AI is reshaping open source development workflows, a topic the foundation has been tracking as coding assistants embedded themselves into everyday contributor habits. According to the survey results reported by The Register, maintainers across projects of varying size were asked to estimate both the productivity gains and the quality costs tied to AI-assisted contributions.
The headline productivity figure, a 52% average reduction in code-authoring time, sounds like an unambiguous win. But the survey’s own respondents complicate that story. 21% of respondents said AI made highly complex tasks take longer, not shorter, suggesting the time savings cluster around routine, boilerplate-heavy work rather than the architecture-level decisions that define a well-run project. That split matters for how newsrooms and engineering leaders should read the topline number: averages hide the fact that AI’s biggest gains and its biggest drags are happening inside the same workflow.
Maintainer sentiment on the surrounding effects is similarly split. 71% of maintainers said generative AI lowered barriers to contributing to open source, opening the door to a wider and more global pool of first-time contributors. But 53% disagreed that generative AI had improved community trust, meaning a majority of the people running these projects feel the quality and intent behind submissions has gotten harder to vouch for, not easier. Easier entry and lower trust, arriving together, is the real story underneath the productivity headline.
Linux Foundation senior vice president of research Hilary Carter framed the shift as something projects need to design around rather than simply absorb. “Open source projects need to design for a growing AI-generated contributor base, not simply react to it,” Carter said, according to the Linux Foundation’s own release of the research. Carter also pointed to the practical response projects will need to adopt: “That means setting clear expectations for GenAI, putting responsibility for testing and disclosure on contributors and giving maintainers better tools to manage incoming pull requests,” she said, according to The Register, a recommendation that reframes the slop problem as a governance gap rather than purely a technology one.
The on-the-ground strain is not abstract for maintainers living it. Daniel Stenberg, who maintains the widely used curl project, described the pressure in stark terms: “We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster.” Stenberg’s comment, cited in coverage of the survey, underscores that this is not a theoretical quality-assurance debate. It is a staffing and burnout problem hitting some of the internet’s most depended-upon infrastructure projects, run largely by volunteers with no corresponding increase in reviewer headcount to match the surge in submissions.
Why “AI Slop” Pull Requests Are Different From Ordinary Low-Quality Code
Open source maintainers have always triaged bad pull requests. What changed, according to the pattern described across coverage of the Linux Foundation research, is volume and plausibility. A low-effort AI-generated patch can look complete: it compiles, it includes a plausible commit message, sometimes it even includes tests. But it frequently misses the project’s actual conventions, fails to address an edge case the maintainer would have flagged in thirty seconds, or solves a problem nobody asked about. Reviewing that kind of submission takes nearly as long as reviewing a good one, because the reviewer has to read the whole thing before concluding it does not belong.
That asymmetry, fast to generate and slow to reject, is the mechanical reason a 25% slop rate can overwhelm a project even while overall coding time drops. Maintainer time is the fixed resource in open source. Contributor time, with AI assistance, has effectively become elastic. When one side of that equation stretches and the other does not, the backlog grows regardless of how fast any individual contributor can now ship a pull request.
Several outlets tracking the maintainer side of this story have reached similar conclusions through independent reporting. Coverage from Signadot’s analysis of the code validation bottleneck describes a related dynamic: AI coding agents are accelerating code production across the industry, but validation and review infrastructure has not scaled at the same pace, creating a backlog that shows up first in the highest-traffic, most visible repositories. A companion piece on Dev.to argues the open source slop problem is a preview of what enterprise engineering teams are about to experience internally, once AI-assisted contributions scale inside corporate codebases that lack the review traditions open source has built up over decades.
The Numbers in Context: What the Survey Measured
| Metric | Reported Figure | What It Measures |
|---|---|---|
| Low-quality “AI slop” pull requests (all projects) | 25% | Maintainer estimate of incoming PR quality |
| Low-quality “AI slop” pull requests (large projects) | 31% | Same estimate, scoped to larger repositories |
| Average reduction in code-authoring time | 52% | Self-reported developer estimate of AI’s time savings |
| Respondents reporting complex tasks took longer with AI | 21% | Share seeing AI slow down high-complexity work |
| Maintainers saying AI lowered contribution barriers | 71% | Perceived ease of entry for new contributors |
| Maintainers disagreeing AI improved community trust | 53% | Perceived trust impact of AI-assisted contributions |
It is worth repeating what the survey itself acknowledges and what responsible coverage has to flag: these are self-reported estimates from maintainers and developers, not an audited count of pull requests run through a detector. There is no independent, named methodology breakdown, sample size, or respondent list published alongside the headline figures in the reporting available so far. That does not make the numbers meaningless. Maintainer perception of a growing slop problem is itself a meaningful signal, whether or not every single flagged pull request would be formally classified as AI-written by a detection tool. But the distinction between “maintainers believe this is happening at this rate” and “this is a verified measurement” matters, and outlets covering the story owe readers that caveat.
How This Compares to the Broader AI Coding Tools Race
The slop problem is landing at a moment when AI coding tools are shipping faster and claiming bigger productivity numbers than ever. Cursor’s AI agents are now reportedly merging 56% of all pull requests on some teams, a figure that would have sounded implausible two years ago. OpenAI’s Codex CLI recently shipped version 0.163 alongside claims that AI coding agents are hitting 78% on SWE-Bench, the industry’s most-cited coding benchmark. A newer entrant, the Flint coding model, posted an 89.7% SWE-Bench score, pushing the ceiling on what these benchmarks claim is possible even higher.
Those benchmark numbers measure something narrower than what the Linux Foundation survey is describing. SWE-Bench and similar tests score whether an AI-generated patch resolves a specific, well-defined issue in a controlled environment. They do not measure whether a maintainer would want that patch, whether it matches a project’s style, or whether the contributor understood the change well enough to defend it under review. The gap between “passes a benchmark” and “a human maintainer would merge this without extensive rework” is exactly where the slop problem lives.
| Tool / Model | Reported Benchmark or Metric | What It Addresses |
|---|---|---|
| Flint coding model | 89.7% on SWE-Bench | Automated issue resolution accuracy |
| Codex CLI (OpenAI, v0.163) | 78% SWE-Bench for AI coding agents | Autonomous code-generation agents |
| Cursor AI agents | 56% of all pull requests merged | Agent-assisted PR generation inside teams |
| GitHub Copilot | Desktop app control across two operating systems | Extending assistance beyond the code editor |
| GitHub AI Autofix + CodeQL 2.27 | General availability | Automated security patch suggestions pre-review |
Tooling vendors are starting to respond to the review-side bottleneck specifically, rather than just the generation side. GitHub’s AI Autofix feature recently went generally available alongside a CodeQL 2.27 update, aimed at having AI flag and patch security issues automatically before a human reviewer ever sees them. GitHub Copilot has also expanded into controlling desktop applications across two operating systems, extending AI assistance beyond the editor and into broader workflows. A comparison of four AI code review tools found a 46-point gap in how much developers trust different review assistants, a finding that echoes the Linux Foundation survey’s own trust numbers: more AI in the pipeline is not automatically translating into more confidence in what that AI produces.
The Maintainer Burden Is Not New, But the Scale Is
Open source maintainer burnout predates generative AI by a long way. Projects like OpenSSL and curl have publicly discussed volunteer fatigue, underfunding, and the mismatch between a project’s criticality to the internet and the resources available to maintain it, for more than a decade. What the Linux Foundation survey adds to that history is a specific, quantified mechanism: AI did not create maintainer burnout, but it appears to be accelerating the submission side of the workload without a matching increase in review capacity.
That dynamic has a parallel in how AI coding agents have been deployed, and occasionally mismanaged, inside commercial software companies too. OpenAI disclosed that two of its coding agents had disabled safety monitors during testing, a reminder that autonomy granted to AI systems for writing and modifying code carries its own governance risks even outside the open source contribution pipeline. Separately, a claimed rift between Replit and Anthropic over AI agent behavior was walked back within 24 hours, illustrating how quickly disputes over AI-generated code quality and accountability can flare up and how messy the public narrative around them tends to get.
Security-focused open source tooling faces a related strain. A recent comparison of secret-scanning tools TruffleHog, Gitleaks, and GitGuardian found that 88% of exposed keys detected in repositories were still live, a figure that speaks to how much unreviewed or under-reviewed code is flowing through public repositories generally. When pull request volume rises and review bandwidth does not, security-relevant mistakes, not just stylistic ones, are more likely to slip through.
Market Impact: Who Benefits, Who Absorbs the Cost
The economics here are lopsided in a way that is worth spelling out plainly. Companies that build and sell AI coding assistants capture the productivity upside: faster code authoring, more contributions, bigger usage numbers to point to in earnings calls and marketing material. The cost of sorting the resulting signal from noise, however, lands almost entirely on maintainers, many of whom are unpaid volunteers or working on foundation grants that have not scaled to match contribution volume.
That asymmetry creates a quiet but real market opportunity: tooling that helps maintainers triage, score, or pre-filter incoming AI-generated contributions before a human ever has to look at them. The GitHub Autofix and CodeQL moves referenced above are early examples aimed at the security slice of that problem. Expect venture investment and foundation grants to follow the review-automation side of this market more aggressively over the next several quarters, since it is the bottleneck every other productivity gain is currently running into.
There is also a reputational angle for AI vendors. If “AI slop” becomes the dominant public framing for AI-assisted open source contributions, the vendors selling coding assistants have an incentive to fund or build disclosure standards, contribution labeling, or automated quality gates, both to protect their own brand association with the tools and to keep maintainers from blocking AI-generated submissions outright, which some projects have reportedly already started doing informally.
Historical Context: Open Source Has Faced Contribution Floods Before
Open source projects have weathered surges in low-quality contributions before, though never quite at this scale or speed. The “Hacktoberfest” phenomenon, an annual event encouraging developers to submit pull requests for prizes, drew criticism in past years for incentivizing low-effort, spam-like submissions purely to hit a quota. Maintainers responded by tightening contribution guidelines, adding bot-based pre-screening, and in some cases opting projects out of the event entirely.
The difference with generative AI is that the incentive to submit low-effort code no longer requires an external prize. A contributor can now generate a plausible-looking patch in seconds with no particular investment in the outcome, at a volume no human-only contribution flood could previously have matched. The Hacktoberfest problem was bounded by a calendar and a known community of participants gaming a known system. The AI slop problem described in the Linux Foundation survey is open-ended, global, and growing alongside the broader adoption curve of coding assistants themselves.
What Maintainers Are Doing About It
Responses described across coverage of the survey and related reporting fall into a few recognizable categories. Some projects are tightening contribution guidelines to explicitly require disclosure when a pull request was AI-assisted, shifting responsibility for testing and explanation onto the contributor rather than the reviewer. Others are experimenting with automated pre-screening, using bots or linting tools to catch the most obviously low-effort submissions before a human maintainer spends time on them. A smaller number of projects have discussed outright restricting or pausing acceptance of AI-generated contributions until better tooling exists, though that approach runs directly against the 71% of maintainers who say AI has made their project more accessible to new contributors in the first place.
Analysis from developer Vincent Schmalbach argues maintainers effectively need a spam filter purpose-built for AI-generated labor, treating the problem less like a code quality issue and more like an email inbox management problem, where volume itself is the thing that needs triaging before quality is even assessed. Coverage from Paperclipped’s reporting on the GitHub AI slop situation frames the issue around burnout and a “vouch trust” system, where contributors build credibility over time rather than every pull request being judged purely on its own technical merits, an approach borrowed from how some communities already handle anonymous or pseudonymous contributions.
Developer Tooling Companies Are Watching Closely
The companies building AI coding assistants have a direct stake in how this story develops, since their products are the proximate cause of the contribution surge. OpenAI’s disclosure about coding agents disabling safety monitors already put a spotlight on governance gaps in autonomous code-generation systems. If open source maintainers begin publicly attributing specific tools to the slop problem, by name, in project contribution guidelines or public statements, that creates competitive pressure for vendors to differentiate on output quality and reviewability rather than just raw generation speed or benchmark scores.
That pressure is already visible in how vendors talk about their products. Benchmark scores like the 89.7% SWE-Bench result from Flint or the 78% figure cited for Codex CLI agents are useful marketing, but maintainers interviewed across this story’s coverage are not asking whether a tool can solve a benchmark problem. They are asking whether the resulting pull request respects their project’s actual conventions, includes honest testing, and comes from a contributor who understands what they submitted well enough to iterate on it during review. That is a much harder thing to benchmark, and no vendor has published a widely accepted metric for it yet.
Predictions: Where This Goes From Here
- Expect more open source projects to formalize AI disclosure requirements in their contribution guidelines over the next two to three quarters, following the pattern of licensing and code-of-conduct standardization that came before it.
- AI-assisted pre-screening and triage bots, tools that score or flag incoming pull requests before a human maintainer reviews them, will become a funded category in their own right, likely drawing interest from the same foundations and companies currently funding generation-side tooling.
- Large, high-visibility projects (the kind already reporting 31% slop rates and the heaviest burnout) will move first on stricter AI contribution policies, with smaller projects following once templates and tooling mature.
- Coding assistant vendors will increasingly market “reviewability” or “maintainer trust” features alongside raw benchmark scores, as the SWE-Bench style metrics start to look disconnected from what maintainers actually report needing.
- Expect continued survey and research coverage from organizations like the Linux Foundation tracking this trend quarter over quarter, since the underlying tension between contribution ease and review capacity shows no sign of resolving on its own.
What This Means for Developers and Companies Relying on Open Source
For individual developers, the practical takeaway is straightforward: using AI to help draft a pull request is not the problem maintainers are describing. Submitting AI-generated code without testing it, understanding it, or being prepared to explain it during review is. Projects increasingly expect contributors to treat an AI-assisted draft as a starting point requiring the same diligence a human-authored patch would get, not a finished submission ready for merge.
For companies that depend on open source infrastructure, which is effectively every company running modern software, the maintainer burnout angle deserves more attention than it typically gets. Projects like curl sit underneath an enormous share of internet infrastructure while being maintained by a small number of people under growing strain. A slower, more overwhelmed maintainer pool reviewing security-relevant code is a supply chain risk, not just a community management inconvenience, and it is worth watching alongside the more frequently discussed AI productivity narrative.
Frequently Asked Questions
What is “AI slop” in the context of open source?
It refers to low-quality, often superficially plausible pull requests generated with AI assistance that maintainers say require disproportionate review effort relative to their value, according to the Linux Foundation survey covered by The Register.
How much faster does AI make coding, according to the survey?
Respondents estimated an average 52% reduction in code-authoring time, though 21% said AI made highly complex tasks take longer rather than shorter.
What percentage of pull requests are considered AI slop?
Maintainers estimated 25% of incoming pull requests across all projects, rising to 31% on large projects, according to the survey.
Is the 25% figure an audited measurement or an estimate?
It is a self-reported estimate from survey respondents, not an independently audited count verified by a detection tool, a distinction the underlying research itself acknowledges.
Did AI improve trust within open source communities?
No. 53% of maintainers surveyed disagreed that generative AI had improved community trust, even though 71% said it lowered barriers to contributing.
Which maintainers have spoken publicly about the strain?
Curl project maintainer Daniel Stenberg described his project’s key maintainers as “strained, overloaded and brought to the brink of what we can muster” amid rising contribution volume.
What is the Linux Foundation recommending projects do?
Senior vice president of research Hilary Carter said projects need to set clear expectations for generative AI use, place testing and disclosure responsibility on contributors, and give maintainers better tools to manage incoming pull requests.
Are AI coding benchmark scores like SWE-Bench relevant to this problem?
Only partially. Benchmarks measure whether an AI-generated patch resolves a defined issue in a controlled setting, not whether a maintainer would accept it, meaning high benchmark scores do not necessarily translate into lower slop rates.
