AI Cuts Coding Time 52%, Slop Hits 25% of PRs [2026]

A Linux Foundation survey sponsored by Red Hat and published October 20, 2026 found that open-source maintainers estimate 25% of incoming pull requests are AI-generated "slop," rising to 31% on the largest projects, while those same maintainers report generative AI has cut their code-authoring time by 52% on average. Fifty-nine percent of maintainers said contribution volume has grown since generative AI tools became mainstream, a figure that rises to 69% among maintainers of large projects. The Register reported the findings under the headline "AI cuts coding time, but it's also filling open source's inbox with crap.

Open-source maintainers are getting more code than ever, and a growing share of it is garbage. A new Linux Foundation survey, published on October 20, 2026, puts hard numbers on a problem developers have been grumbling about for months: generative AI tools are cutting coding time nearly in half, but they are also flooding maintainers’ inboxes with low-quality, AI-generated pull requests that reviewers have started calling “AI slop.” The Register broke the story under the headline “AI cuts coding time, but it’s also filling open source’s inbox with crap,” and the figures inside the report explain why the phrase stuck. The research, sponsored by Red Hat, puts a number on something that has mostly lived as anecdote until now: maintainers estimate that 25% of incoming pull requests across open-source projects are AI slop, a share that climbs to 31% on the largest projects. At the same time, the same maintainers report that generative AI has cut their own code-authoring time by 52% on average. Those two numbers sitting side by side are the real story here. AI is making individual contributors faster while making the overall review pipeline slower and more exhausting for the people who have to say yes or no to every patch. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F What the Linux Foundation Survey Actually Found The Linux Foundation’s research team set out to measure how generative AI is reshaping the daily mechanics of open-source development, not just whether developers like the tools. The resulting report, backed by Red Hat, landed on October 20, 2026, and immediately became one of the most discussed pieces of open-source research this year. The Register’s coverage https://www.theregister.com/ai-and-ml/2026/10/21/ai-cuts-coding-time-but-its-also-filling-open-sources-inbox-with-crap/5304389 framed the findings bluntly: AI is a net productivity win for individual contributors and a net headache for the people who maintain the repositories those contributors send code to. Fifty-nine percent of project maintainers told researchers that contribution volume to their projects has grown since generative AI tools became mainstream. That growth is not evenly distributed. Among maintainers of large projects, the share reporting increased volume rises to 69%, a gap that tracks with the obvious reality that bigger, more visible repositories attract more drive-by contributions, AI-assisted or not. More contributions sounds like good news for any open-source project starved for help. The catch is in how much of that new volume is actually usable. The 25% Problem: Measuring “AI Slop” in Pull Requests “AI slop” has become shorthand across developer communities for contributions that look superficially plausible, pass a cursory glance, and fall apart under real review: code that does not compile, documentation that contradicts itself, or patches that solve a problem nobody asked about. The Linux Foundation’s survey gives that complaint a number. Maintainers estimate that 25% of incoming pull requests across all surveyed projects qualify as AI slop. For large projects specifically, the share of AI slop PRs rises to 31%, meaning maintainers on the busiest repositories believe close to a third of what lands in their queue is not worth their time. That is a self-reported, perception-based figure rather than a forensic audit of every commit, and the Linux Foundation’s own framing treats it that way. But perception is exactly what drives maintainer behavior and burnout, which is why the figure matters regardless of how it would hold up under a stricter methodology. If a maintainer believes a quarter of their inbound queue is noise, they will triage, review, and respond accordingly, and that defensive posture has knock-on effects for genuine contributors who now compete with bot-assisted noise for attention. Why Large Projects Carry a Heavier Slop Burden The gap between the 25% overall AI slop estimate and the 31% figure for large projects is one of the more quietly important findings in the report. Large, high-visibility projects are the ones most likely to show up in a generative AI model’s training data, the ones most likely to be referenced in tutorials that teach new contributors how to “get started,” and the ones most likely to attract opportunistic contributors looking to pad a resume or a GitHub profile with a visible pull request. All of that makes them disproportionately attractive targets for low-effort, AI-generated submissions. It also means the maintainers with the least slack in their schedules, the ones already managing the largest and most complex codebases, are absorbing the heaviest additional load. A small, niche project might see a handful of AI-assisted drive-by PRs a month. A flagship project with thousands of watchers can see that volume multiply, and every one of those submissions still needs a human to read it, run it, and decide whether it is real. Code-Authoring Time Falls 52%, but the Gains Are Not Evenly Shared The productivity side of the ledger looks dramatically different from the slop side. Respondents estimated that generative AI tools reduced the time they spend authoring code by 52% on average, a figure in line with what vendors of AI coding assistants have claimed for the past two years, now backed by independent survey data rather than marketing copy. Time spent on proposal discussions, the back-and-forth that happens before code is even written, fell by an estimated 19%, suggesting AI is also compressing the planning and scoping phase of contributions, not just the typing. Those averages, however, hide an important asterisk. Twenty-one percent of respondents said that for highly complex tasks, generative AI actually made the work take longer, not less time. That is a meaningful minority of developers reporting that AI tools are a net drag once a problem crosses a certain complexity threshold, whether because the AI-generated first draft needs substantial rework, because debugging AI-authored code takes longer than debugging code a developer wrote and understood from the start, or some combination of both. The 52% headline number is real, but it describes an average across task types, not a guarantee that applies to every kind of work a maintainer or contributor does. Red Hat’s Role and the Research Behind the Headline Red Hat sponsored the Linux Foundation research, a detail worth noting given the company’s position as one of the largest commercial stewards of open-source software. Red Hat’s business model depends on healthy upstream projects, from the Linux kernel to Kubernetes to the dozens of smaller tools that feed into its enterprise products, so a survey quantifying maintainer strain is directly relevant to its own supply chain, not just an academic exercise. The Linux Foundation’s official announcement https://www.linuxfoundation.org/press/new-lf-research-survey-shows-generative-ai-cuts-open-source-coding-time-in-half-but-25-of-incoming-pull-requests-are-considered-ai-slop frames the findings as a call to action for the community to develop better tooling and norms around AI-assisted contributions, rather than a reason to restrict AI use outright. That framing matters because it shapes how the open-source world is likely to respond. A report that simply said “AI is bad for open source” would invite a defensive, restrictive reaction. A report that says AI cuts real work in half while also creating a triage problem invites a more constructive one: build better filters, set clearer contribution norms, and let maintainers decide project by project how much AI-assisted work they can absorb. Maintainer Burnout Becomes the Real Bottleneck Open-source maintainer burnout is not a new concern, but the Linux Foundation’s findings give it a fresh, AI-specific edge. Reviewing code has always been more expensive than writing it, and that asymmetry is precisely what AI slop exploits. A contributor can generate a plausible-looking pull request in minutes with an AI coding assistant. A maintainer still has to spend real time reading it, testing it, and in many cases explaining, patiently, why it does not meet the bar, work that offers little of the satisfaction that comes from merging a genuinely useful contribution. Projects that have already dealt with AI-coding-agent reliability problems understand this dynamic well. Our earlier coverage of a GitHub supply-chain incident that hit thousands of repositories https://shattered.io/github-teampcp-breach-3800-repos-2026/ showed how quickly automated activity at scale can overwhelm manual review processes built for a slower, more human pace of contribution. AI slop is a less adversarial version of the same underlying problem: volume that outpaces the humans responsible for checking it. Trust, Barriers to Entry, and a Divided Community The survey captures a community that is genuinely split on whether AI’s net effect on open source is positive. Seventy-one percent of maintainers said generative AI has lowered barriers to contributing, opening the door to people who might never have attempted a pull request without AI assistance helping them navigate an unfamiliar codebase or write their first patch. That is a real and valuable outcome for a movement that has long struggled with narrow, homogenous contributor pipelines. Set against that, 53% of maintainers disagreed that generative AI has improved community trust. Lowering the barrier to contribute and improving trust within a community turn out to be two very different things, and the survey suggests open source is getting more of the first and less of the second. More people can submit code. Fewer maintainers feel confident that what lands in their inbox was thoughtfully made, reviewed by its author, or submitted with real understanding of the project’s goals. A Familiar Pattern From the AI Coding Tools Market This tension between access and trust is not unique to open source. It mirrors debates that have played out across the AI coding assistant market more broadly, where tools promise to let anyone ship production code while critics warn that lowering the skill floor also lowers the quality floor. Our coverage of AI code review tools benchmarked against each other https://shattered.io/ai-code-review-tools-bugbot-vs-codex-2026/ traced the same underlying logic: as AI makes it easier to generate code, the market has responded by trying to make it easier to review and filter that code automatically, because human review capacity was never going to scale at the same rate as AI-assisted output. A Short History: How Open Source Got Here Open-source maintainers have dealt with low-quality contributions since long before generative AI existed. Drive-by pull requests fixing a single typo to pad a GitHub profile, half-finished patches abandoned after the first round of review feedback, and well-meaning but under-tested contributions from first-time committers are all familiar to anyone who has maintained a public repository for more than a few months. What generative AI changes is the volume and the plausibility. A typo fix takes seconds to evaluate. A multi-file AI-generated patch that compiles, passes a superficial glance, and still contains a subtle logic error takes far longer to catch, and far longer to explain to a contributor who may not fully understand the code they submitted in the first place. That shift tracks the broader arc of AI coding tools over the past two years, from early autocomplete-style assistants to the agentic coding tools and command-line agents that now dominate developer workflows. Our recent roundup of Claude Code, Codex CLI, and OpenCode shipping coordinated updates within a four-day window https://shattered.io/claude-code-codex-cli-opencode-update-4-days-2026/ is a reminder of how fast the underlying tools are iterating. Every improvement in an AI coding agent’s ability to generate plausible-looking code is, from a maintainer’s perspective, also an improvement in that tool’s ability to generate plausible-looking slop. Market Impact: What This Means for AI Coding Tool Vendors For companies selling AI coding assistants, the Linux Foundation’s findings cut in two directions at once. The 52% average reduction in code-authoring time is exactly the kind of independent, third-party validated statistic that vendors like to point to when justifying subscription prices for tools such as GitHub Copilot, Cursor, and the various command-line coding agents now competing for developer attention. It confirms, with survey data rather than vendor benchmarks, that the core productivity promise of generative AI coding tools is real. The slop numbers, though, create a different kind of market opportunity: demand for tools that specifically address the review and quality-control side of the pipeline, not just the generation side. GitHub’s decision to retire several legacy Copilot models in favor of newer defaults, covered in our report on GitHub Copilot retiring six models and shifting to GPT-5.6 https://shattered.io/github-copilot-retires-6-models-gpt-5-6-2026/ , reflects a market that is consolidating around fewer, more capable models partly because inconsistent output quality across many model options makes the slop problem worse, not better. Fewer models, in theory, means more predictable output and an easier target for review tooling to calibrate against. Competitive Landscape: Who Is Trying to Solve the Slop Problem A competitive field is forming around the exact gap the Linux Foundation survey exposes: tools that filter, score, or automatically review AI-generated contributions before a human maintainer ever has to look at them. The table below summarizes how several vendors and projects already covered on this site are positioned relative to that problem, based on their most recent public moves. | Vendor or Project | Recent Move | Relevance to the AI Slop Problem | |---|---|---| | GitHub Copilot | Retired six legacy models, shifted default generation to GPT-5.6 | Fewer model variants in production, aimed at more consistent and predictable code output | | Cursor Bugbot | Benchmarked its automated code-review feature against Codex and five rival tools | Positions automated review as a dedicated filtering layer ahead of human maintainers | | Claude Code, Codex CLI, OpenCode | Shipped coordinated product updates within a four-day window | Rapid iteration suggests vendors are actively responding to developer and maintainer feedback | | Reflection AI Beam | Open-sourced its Beam model under an Apache 2.0 license with more than 40 partners | Expands the pool of open contributors and code generators, raising the stakes for triage at scale | | Anthropic | A company executive publicly pushed back on calls for a blanket open-source AI ban | Signals the policy debate over how open projects should govern AI-assisted contributions is still unsettled | None of these moves were made explicitly in response to the Linux Foundation survey, which published only on October 20, 2026. But they illustrate a market already converging on the same conclusion the survey’s data points toward: generation speed stopped being the bottleneck a while ago, and review and trust are now the harder problems to solve. Survey Data at a Glance The table below collects the Linux Foundation’s headline figures in one place for reference. | Metric | Figure | Scope | |---|---|---| | Maintainers reporting increased contribution volume | 59% | All surveyed projects | | Maintainers reporting increased contribution volume | 69% | Large projects only | | Incoming pull requests considered “AI slop” | 25% | All surveyed projects | | Incoming pull requests considered “AI slop” | 31% | Large projects only | | Average reduction in code-authoring time | 52% | Generative AI users | | Reduction in time spent on proposal discussions | 19% | Generative AI users | | Respondents saying AI slowed highly complex tasks | 21% | All respondents | | Maintainers saying AI lowered barriers to contribute | 71% | All surveyed maintainers | | Maintainers disagreeing AI improved community trust | 53% | All surveyed maintainers | What Maintainers and the Data Say The Linux Foundation’s own research findings, cited directly, lay out the shape of the problem without much ambiguity. “Open-source developers estimated that generative AI reduced code-authoring time by 52% on average,” according to Linux Foundation Research. The same study found that “maintainers estimated that 25% of incoming pull requests were low-quality AI-generated contributions, commonly called ‘AI slop,'” a figure that climbs further on larger projects: “among large open-source projects, maintainers estimated that 31% of incoming pull requests were low-quality AI-generated contributions,” per the same research. On the growth side, Linux Foundation Research also reported that “59% of project maintainers reported that contribution volume to their open-source projects had grown since the rise of generative AI.” And on the limits of AI’s usefulness, the research is equally direct: “for highly complex open-source development tasks, 21% of respondents reported that generative AI made the work take more time,” a finding that undercuts any claim that AI tools are a uniform productivity win regardless of task difficulty. How This Compares to Other AI-and-Open-Source Flashpoints This is not the first time AI and open-source governance have collided publicly in 2026. Our earlier reporting on an Anthropic executive who pushed back against calls for a blanket ban on open AI models, in a piece examining open-source AI risk and policy https://shattered.io/anthropic-princen-open-source-ai-risk-2026/ , covered a related but distinct fight: whether open-weight AI models themselves pose security risks, separate from the question of whether AI-generated code contributions are degrading open-source project quality. Both debates share a common thread, though: open source’s traditional governance model, built on volunteer trust and informal norms, is being tested by AI at a pace that formal policy has not kept up with. Separately, the broader push toward open-sourcing AI models themselves, covered in our report on the AI open-source bet reaching a new high as projects like Beam and Mistral ship open releases https://shattered.io/ai-open-source-bet-86-percent-beam-mistral-2026/ , adds another layer. As more of the AI tooling that generates code becomes open and freely available, the population of people capable of generating large volumes of AI-assisted pull requests grows too, which is part of why maintainers are seeing both numbers, contribution volume and slop share, rise together. A Useful Reference Point: Independent Coding Statistics Outside outlets tracking AI coding adoption more broadly have reached similar directional conclusions in 2026, even where exact figures differ from the Linux Foundation’s survey. A roundup of AI coding statistics compiled from across the industry https://blockonomi.com/ai-coding-statistics-2026-what-the-data-shows/ shows developer-reported time savings in a similar range to the Linux Foundation’s 52% figure, reinforcing that the productivity gains reported by open-source maintainers are consistent with what developers report in commercial and enterprise settings as well. What an AI-Contribution Disclosure Policy Might Look Like One response already emerging in developer communities, and discussed in coverage of the survey such as a dev.to analysis of maintainers drowning in AI-generated pull requests https://dev.to/signadot/open-source-maintainers-are-drowning-in-ai-generated-pull-requests-enterprise-teams-are-next-36l , is a push for explicit AI-disclosure clauses in project contribution guidelines. No single template has become a de facto standard, but the kind of language maintainers are experimenting with tends to follow a common pattern, illustrated below purely as an example and not as an official policy from any named project. Example CONTRIBUTING.md clause illustrative only AI-assisted contributions If you used a generative AI tool to help write this pull request, please disclose it in the PR description, for example: AI-assisted: yes tool: , scope: boilerplate/tests/docs You remain responsible for: - understanding every line you submit - running and passing the full local test suite - being able to explain your design choices in review PRs that appear AI-generated without disclosure, or that the author cannot explain, may be closed without full review. Templates like this will not eliminate AI slop, since a contributor acting in bad faith can simply decline to disclose. But several maintainers quoted in coverage of the survey have framed disclosure norms as a first step toward restoring the trust gap the 53% figure points to, by at least giving reviewers context before they dive into a review. Five Predictions for AI and Open Source Through 2027 - Expect more large projects to formalize AI-disclosure requirements in their contribution guidelines over the next year, following the pattern already visible in early community discussions of the survey. - AI-assisted code review tools, the category covered in our piece on Bugbot, Codex, and rival review tools https://shattered.io/ai-code-review-tools-bugbot-vs-codex-2026/ , will likely see faster enterprise and open-source adoption as projects look for automated first-pass filters against slop. - The gap between large-project and small-project AI slop rates, 31% versus the 25% overall average, is likely to widen further before it narrows, as the most visible projects remain the most attractive targets for low-effort contributions. - Maintainer burnout, already a chronic open-source problem, will likely become a more explicit factor in why maintainers step back from or hand off popular projects, with AI slop cited as a contributing cause in post-mortems. - Expect follow-up research from the Linux Foundation or similar bodies within the next year attempting to separate self-reported perception of AI slop from more rigorous, code-level measurement, given how much weight this first survey’s perception-based figures are already carrying in public debate. What Happens Next The Linux Foundation’s survey does not resolve the tension it documents, and it was not designed to. It gives the open-source world, for the first time, shared language and shared numbers for a problem that maintainers have been describing anecdotally for a couple of years. Fifty-nine percent more volume. Twenty-five percent slop. Fifty-two percent faster code authoring. Those three figures, taken together, describe an ecosystem that is simultaneously more productive and more strained than it was before generative AI tools became a normal part of a developer’s toolkit. How individual projects respond will likely vary widely. Smaller projects with less exposure to drive-by AI contributions may see little need to change their contribution norms at all. The largest, most visible projects, the ones absorbing 31% AI slop rates, will almost certainly need new tooling, new norms, or both. Red Hat’s sponsorship of this research suggests the commercial open-source world sees this as a problem worth funding more research into, which is itself a signal that the current moment, developers moving fast with AI while maintainers scramble to keep up, is not expected to resolve on its own. Frequently Asked Questions What is “AI slop” in the context of open-source pull requests? “AI slop” refers to pull requests that appear to have been generated largely or entirely by AI tools and that maintainers consider low-quality, whether because the code does not work, the contributor does not appear to understand it, or the submission does not meaningfully address a real need in the project. The Linux Foundation’s October 20, 2026 survey estimates that AI slop accounts for 25% of incoming pull requests across surveyed projects. How much faster is coding with generative AI, according to the survey? Respondents to the Linux Foundation survey estimated that generative AI tools reduced their code-authoring time by 52% on average. Time spent on proposal discussions fell by an estimated 19% as well, suggesting the planning phase of contributions is also getting faster, not just the writing itself. Why do large open-source projects see more AI slop than smaller ones? Large projects estimated their AI slop share at 31%, compared with 25% across all surveyed projects. High-visibility projects tend to attract more opportunistic and drive-by contributions in general, a pattern that predates generative AI and appears to be amplified by it. Who sponsored the Linux Foundation’s AI and open-source survey? Red Hat sponsored the research, which the Linux Foundation published on October 20, 2026. The Register and other outlets covered the findings the following day. Does generative AI make every coding task faster? No. While the average reported time savings across all tasks was 52%, 21% of survey respondents said generative AI actually made highly complex tasks take longer, not less time. The productivity gains the survey documents are an average across many types of work, not a universal result. Has generative AI improved trust within open-source communities? According to the survey, no, on balance. While 71% of maintainers said generative AI has lowered barriers to contributing, 53% disagreed that it has improved community trust, pointing to a split between access and confidence in what gets submitted. What are open-source projects doing to manage AI-generated contributions? Responses vary by project, but common approaches discussed in coverage of the survey include adding AI-disclosure expectations to contribution guidelines, leaning more heavily on automated code review tools as a first filter, and in some cases tightening review requirements for first-time contributors specifically. Where can I read the full Linux Foundation report? The Linux Foundation published its findings and a press announcement on October 20, 2026, covering the full survey methodology and results. The Register’s October 21, 2026 report summarizes the headline figures alongside additional industry reaction.