AI Cuts Code Time 52%, Floods Reviews With 25% Slop [2026]
![AI Cuts Code Time 52%, Floods Reviews With 25% Slop [2026]](https://trendintech.com/wp-content/uploads/2026/10/ai-cuts-code-time-open-source-slop-2026-gen.webp)
Open-source maintainers are getting faster code and a bigger headache at the same time. A new Linux Foundation Research survey, published October 20, 2026 and reported by The Register on October 21, 2026, finds that generative AI tools are cutting code-authoring time by 52% on average, while roughly a quarter of incoming pull requests across open-source projects are now considered low-quality “AI slop.” The number climbs higher still at large projects, where maintainers estimate 31% of submissions fall into that bucket.
The findings land at an awkward moment for the open-source world. Contribution volume is up, AI slop open source pull requests are piling up in review queues, and maintainers are stuck trying to figure out which submissions came from a careful human engineer and which came from someone who pasted an issue into a chatbot and submitted whatever came out. The curl project, one of the most widely used pieces of software on the planet, has already changed how it handles security reports because of the volume problem. This is not a hypothetical risk anymore. It is a daily triage exercise for thousands of maintainers.
Don't miss new tech stories on Google
Add TrendinTech once in the Google app and our stories appear in your news suggestions.
What the Linux Foundation Survey Actually Found
Linux Foundation Research is the nonprofit’s research arm, founded in 2021 and responsible for a steady output of reports on open-source adoption, tooling, and workforce trends. Its October 2026 newsletter says the group published nine reports during the month alone, including a 35-year retrospective on Linux and the ninth annual State of OSPOs study. The AI slop survey, drawn from 111 respondents across open-source maintainer communities, is the one generating the most attention this week, and for good reason: it puts real numbers on a problem developers have been complaining about anecdotally for more than a year.
The headline finding cuts both ways. Generative AI tools are measurably speeding up the act of writing code, with respondents estimating a 52% average reduction in code-authoring time. But that speed comes with a quality tax. A quarter of incoming pull requests, by maintainer estimate, are considered AI slop, meaning submissions that are low-effort, poorly tested, or generated without real understanding of the codebase they’re touching. At large projects, where visibility and prestige make them an attractive target for drive-by contributions, that estimate rises to 31%.
It is worth being precise about what these numbers represent. They are maintainer estimates gathered through a survey, not a traffic-weighted census of every pull request submitted to every open-source repository. The Linux Foundation itself frames the data this way, and treating 25% or 31% as a hard, measured share of all open-source activity would overstate what the research shows. Still, a survey of this size, backed by a 111-respondent sample from active maintainers, is one of the more concrete attempts yet to quantify a problem that until now has mostly lived in GitHub issue threads and mailing-list rants.
The Numbers at a Glance
| Metric | Finding |
|---|---|
| Average reduction in code-authoring time | 52% |
| Estimated share of incoming PRs considered “AI slop” | 25% |
| Estimated AI slop share at large projects | 31% |
| Maintainers reporting higher contribution volume overall | 59% |
| Large-project maintainers reporting higher contribution volume | 69% |
| Respondents saying highly complex tasks took longer with AI | 21% |
| Maintainers who disagreed that GenAI improved community trust | 53% |
| Projects with a formal policy permitting GenAI use | 35% |
| Projects with no policy and no plans to adopt one | 32% |
Two figures in that table deserve a second look. First, 59% of maintainers said contribution volume has increased since generative AI tools became mainstream, and that figure jumps to 69% at large projects. More people are submitting code than before. Second, 21% of respondents said highly complex tasks actually took longer with AI assistance involved, a reminder that the productivity gains are unevenly distributed. Simple, well-scoped changes get faster. Gnarly, architecture-touching work does not necessarily get easier just because a model can generate a diff in seconds.
Why AI Slop Open Source Pull Requests Are Piling Up
The mechanics behind the AI slop open source pull requests problem are not mysterious. Coding assistants have gotten dramatically better at producing plausible-looking code, fast, and at near-zero marginal cost per attempt. That combination lowers the barrier to opening a pull request on a project you don’t understand, haven’t built locally, and have no real stake in beyond a GitHub contribution streak or a bounty payout. The Linux Foundation’s own survey captures this trade-off directly: 71% of maintainers said generative AI had lowered barriers to contributing to open source. That is, on its face, good news for projects that have spent years trying to attract more contributors. The complication is that lowering the barrier to contribution also lowers the barrier to low-quality contribution.
A maintainer reviewing a pull request has to do work that a model does not: understand the surrounding code, verify the change doesn’t break an edge case nobody wrote a test for, and judge whether the stated rationale in the PR description actually matches what the diff does. When a submission was produced largely by a chatbot, with little human verification before it was opened, that review burden does not shrink. It often grows, because the code can look superficially competent while hiding a subtly wrong assumption. This is one reason this site has previously covered a METR study finding developers were measurably slower, not faster, when using certain AI coding agents on unfamiliar codebases. Speed at the authoring stage does not automatically translate into speed for the project as a whole once review and maintenance are factored in.
curl’s Breaking Point: Daniel Stenberg and the Security Report Flood
No project illustrates the strain better than curl, the ubiquitous command-line data transfer tool and library maintained largely by Daniel Stenberg. According to reporting cited in the Linux Foundation coverage, curl announced it would move low- and medium-severity security flaws to public view rather than handling them through a private disclosure process, a shift maintainers attributed directly to pressure from AI-assisted vulnerability reports overwhelming the project’s small security team. The project had already closed its monetary bug bounty program in February 2026 after a wave of low-quality, AI-generated submissions made the program more costly to triage than it was worth.
Stenberg has been one of the most vocal maintainers on this topic for more than a year, previously describing AI-generated submissions as a drain on volunteer time that produces plausible-sounding reports which turn out, on inspection, to describe vulnerabilities that don’t exist. curl’s decision to make more of its security triage public is a direct structural response to that pressure: when the review bottleneck is a handful of trusted humans, the fix is either more humans or less private process. curl chose the latter. It is a small, telling data point about how an “AI slop” problem documented at a survey level by the Linux Foundation shows up as concrete policy change at the project level.
The Trust Problem Nobody Has Solved
Perhaps the most uncomfortable figure in the whole survey is this: 53% of maintainers disagreed that generative AI had improved community trust. That is a majority, in a field where AI vendors have spent the last two years promising that coding assistants would make open-source collaboration easier and more inclusive, not more adversarial. The trust deficit shows up in small, grinding ways: a maintainer can no longer assume that a thoughtfully worded PR description reflects thoughtful work, because a model can produce a polished description in seconds regardless of what’s actually in the diff. That erosion of the usual social signals, tone, effort, apparent care, is arguably more corrosive to open-source culture than the raw volume of low-quality submissions.
It also helps explain why only 35% of surveyed projects have a formal policy permitting generative AI use, while 32% have no policy at all and no plans to create one. Writing a policy requires projects to decide, often for the first time, what “acceptable AI use” even means: disclosure requirements, testing standards, review thresholds. Many maintainers, already stretched thin, have simply not had the bandwidth to formalize an answer. That governance gap is itself a market opportunity, and it is part of why coverage of Europe’s sovereignty-driven push to support roughly three million open-source contributors has increasingly folded in AI governance alongside funding and tooling concerns.
Competitive Field: Where the Major AI Coding Tools Stand
The Linux Foundation’s survey does not single out a specific AI coding tool as the source of the slop problem, and the available reporting does not establish that any one assistant caused the increase in low-quality submissions. But the tools generating the code that’s now flooding maintainer inboxes are the same ones competing hard for developer attention this quarter. OpenAI’s GPT-6 Sol and GPT-6 Luna, positioned respectively as a balanced coding and agentic-work model and a lower-cost, lightweight option, are both now available inside Codex and ChatGPT Work for Plus, Pro, Business, Enterprise, and Edu users, with usage bundled into existing ChatGPT subscriptions and additional credits purchasable on top. GitHub Copilot has been reshuffling its own model lineup, with GPT-6.1 Sol rolling out to Pro+, Max, Business, and Enterprise subscribers. Cursor, meanwhile, is in the middle of restructuring its entire subscription model around an X and Grok integration, with reported tiers of Plus at $8 a month, Premium at $30, Super at $100, and Ultra at $200.
| Platform | Maker | Current coding models | Pricing structure |
|---|---|---|---|
| GitHub Copilot | GitHub / Microsoft | GPT-6.1 Sol, GPT-6 Luna | Pro $10/mo, Pro+ $39/mo, Max $100/mo, Business $19/seat/mo, Enterprise $39/seat/mo |
| OpenAI Codex | OpenAI | GPT-6 Sol, GPT-6 Luna | Bundled into ChatGPT Plus, Pro, Business, Enterprise, and Edu plans |
| Cursor | Anysphere | Composer 2.5, Grok 4.7 | Plus $8/mo, Premium $30/mo, Super $100/mo, Ultra $200/mo |
| curl (affected project) | Independent volunteers | Not applicable | Ended paid bug bounty February 1, 2026 after report-volume overload |
The competitive dynamic matters because every vendor in that table is racing to make its assistant faster and cheaper to use, which, by the Linux Foundation’s own logic, is exactly the combination that lowers the barrier to opening a pull request without doing the underlying work first. This site’s earlier look at how GitHub Copilot and Cursor are racing to add tools and agent features captured the same dynamic from the vendor side: more surfaces, more models, more ways to generate a change quickly. None of that is inherently bad, but it does mean the volume problem documented by the Linux Foundation is unlikely to ease on its own as long as the tools keep getting more capable and more widely available.
Historical Context: From “Please Contribute” to “Please Stop”
Open-source maintainers have spent decades trying to solve the opposite problem: not enough contributors, not enough reviewers, not enough fresh eyes on aging codebases. Programs like Google Summer of Code and countless “good first issue” labels exist specifically to lower the barrier to entry and pull more people into maintenance work. The AI slop phenomenon is, in a strange way, that effort succeeding too well and too fast. The barrier dropped, just not in the way anyone designing those outreach programs intended.
curl’s own history traces this arc closely. Stenberg has previously described a period, dating back to mid-2025, when AI-assisted security submissions were already running well above historical norms, a figure that predates the Linux Foundation’s newer, cross-project estimate of 25%. That earlier curl-specific number is now a full year old relative to this latest report and should be read as history rather than the current state of play. What’s changed since then is that the problem has been measured broadly, across many projects rather than one, and the resulting 25% to 31% figures give the industry its first real benchmark for how widespread the issue has become.
Market Impact: What This Means for Enterprise Open Source Strategy
For enterprises that depend on open-source infrastructure, maintainer burnout is a supply-chain risk, not an abstract community concern. Companies that ship products built on curl, on major Linux Foundation-hosted projects, or on any widely used dependency are effectively relying on the goodwill and spare time of a small number of unpaid or underpaid maintainers to keep that software secure and current. If those maintainers start spending a third of their review time filtering out AI slop open source pull requests instead of reviewing substantive contributions, release cycles slow down, security response times stretch out, and the risk of a maintainer simply walking away from a critical project goes up.
That risk has already pushed some organizations to formalize their own AI contribution policies before regulators or foundations force the issue. It also explains the growing interest in tooling built specifically to catch low-effort AI contributions before they reach a human reviewer. Earlier this month, this site covered a lightweight git hook project designed to quiz submitted AI-generated code for basic understanding before a human maintainer has to look at it, a sign that the maintainer community is already building its own defenses rather than waiting for AI vendors to solve the problem from their end.
What the Broader Productivity Data Says
The Linux Foundation’s 52% figure does not exist in isolation. A 2023 McKinsey analysis found that generative AI can reduce the time required to write new code by 35% to 45%, with even larger gains elsewhere in the development lifecycle: “Generative AI can reduce code-documentation time by 45% to 50%,” according to McKinsey & Company’s 2023 research, while refactoring work saw smaller but still meaningful gains, with McKinsey separately noting that “generative AI can reduce code-refactoring time by 20% to 30%.” Those earlier estimates, now three years old, are consistent with the direction, if not the exact magnitude, of the Linux Foundation’s newer 52% figure.
The 2025 Stack Overflow Developer Survey adds a useful counterweight. On one hand, Stack Overflow found that 69% of developers who had used AI agents at work agreed that the agents increased their productivity, a strongly positive signal in line with the Linux Foundation’s own coding-time findings. On the other hand, the same 2025 Stack Overflow Developer Survey found that 45% of developers said debugging AI-generated code takes more time than writing the code themselves, a finding that lines up closely with the Linux Foundation’s own 21% of respondents who said highly complex tasks actually took longer with AI involved. Code gets written faster. Code does not necessarily get fixed, reviewed, or merged faster, and in some cases it gets slower precisely because nobody fully understood it on the way in.
Read together, the picture is consistent across three separate surveys spanning three years: generative AI reliably accelerates the act of producing a first draft of code, and just as reliably creates new friction downstream, in debugging, in review, and now, per the Linux Foundation’s newest data, in open-source contribution quality specifically. The 2026 survey is the first of the three to attach a hard percentage to how much of that downstream friction shows up as outright low-quality submissions rather than merely slower debugging.
How Maintainers Are Responding
Projects are not waiting around for a universal fix. Some, like curl, are restructuring how they handle security disclosures to reduce private-channel load. Others are experimenting with AI-assisted triage tools of their own, using models to pre-screen incoming pull requests for obvious signs of low effort before a human maintainer spends time on them, an approach that is itself a little ironic given that AI output is the thing being screened for. Formal contribution policies are also starting to spread, even though the Linux Foundation found only 35% of projects currently have one in place. Expect that number to climb over the next year as more maintainers follow curl’s lead and put a public policy in writing rather than handling every borderline submission on an ad hoc basis.
There is also a quieter trend worth watching: projects adjusting their contributor onboarding to require more context, more local testing evidence, or more detailed rationale before a pull request is even considered for review. That raises the bar back up slightly, offsetting some of the barrier-lowering effect that 71% of maintainers credited to generative AI in the first place. It is a tradeoff open-source governance will likely keep renegotiating for the next several years rather than settling once and for all.
Predictions: Where This Goes From Here
- Formal generative-AI contribution policies will likely become standard at major projects within the next year, pushing the current 35% adoption figure well above 50% as more maintainers follow curl’s example of writing explicit rules rather than deciding case by case.
- More widely used projects will probably follow curl toward partially public vulnerability disclosure, trading some confidentiality for faster triage once private review queues become unmanageable.
- AI-powered pre-screening tools built specifically for maintainers, rather than for contributors, are likely to become a distinct product category over the next 12 to 18 months as the review-burden problem becomes impossible to staff around with volunteers alone.
- The 25% to 31% AI slop range reported this month will probably be treated as the first in a recurring series of measurements, with the Linux Foundation or a similar body likely to re-run this survey in 2027 to track whether the figure grows or stabilizes.
- Expect continued divergence between simple, well-scoped contributions, which will keep getting faster and easier, and complex, architecture-level changes, where the Linux Foundation’s own 21% “took longer with AI” figure suggests the productivity story remains genuinely mixed.
What This Means for Developers and Contributors
For individual developers hoping to contribute to open-source projects, the practical lesson from this survey is straightforward: a pull request that looks AI-assisted, without evidence of local testing, understanding of the surrounding code, or a clear rationale, is now competing for review time against a flood of submissions that look exactly the same. Standing out increasingly means demonstrating the work a model can’t easily fake: running the test suite, explaining tradeoffs in your own words, and engaging with reviewer feedback instead of resubmitting a regenerated diff. This site’s earlier coverage of 42% of developers now reporting that AI writes half or more of their code suggests this dynamic is only going to intensify as AI-assisted authorship becomes the norm rather than the exception, inside companies and in open source alike.
For maintainers, the survey at least offers validation: the review burden they’ve been describing anecdotally for more than a year is now backed by a named, citable data source. That matters for funding conversations, for foundation support requests, and for justifying the kind of tooling investment, like AI-assisted code agents such as those covered in this site’s look at Replit’s recent shift in which AI model it defaults to for coding agents, that maintainers increasingly need just to keep pace with contribution volume.
Frequently Asked Questions
What is “AI slop” in the context of open-source pull requests?
It refers to code submissions that maintainers judge to be low-quality, low-effort, or generated with minimal human review before being opened. The Linux Foundation’s October 2026 survey put the estimated share of such submissions at 25% of all incoming pull requests, rising to 31% at large projects.
Did the Linux Foundation study measure every open-source pull request?
No. The 25% and 31% figures come from a survey of 111 maintainer respondents estimating the share of AI slop they encounter, not a traffic-weighted count of every pull request submitted across every open-source repository.
How much time does generative AI actually save on coding tasks?
The Linux Foundation survey put the average reduction in code-authoring time at 52%. Separately, a 2023 McKinsey analysis estimated gains of 35% to 45% for new code and 45% to 50% for documentation, while the 2025 Stack Overflow Developer Survey found 69% of AI-agent users reported a productivity boost.
Why did curl stop running a paid bug bounty program?
Maintainer Daniel Stenberg’s project closed its monetary bug bounty on February 1, 2026, after a wave of low-quality, AI-generated submissions made the program more costly to review than it was worth.
Do most open-source projects have a policy on AI-generated contributions?
Not yet. The Linux Foundation found only 35% of surveyed projects had a formal policy permitting generative AI use, while 32% had no policy and no plans to create one.
Does AI assistance always make coding tasks faster?
No. The Linux Foundation survey found 21% of respondents said highly complex tasks took longer with AI assistance involved, and the 2025 Stack Overflow Developer Survey found 45% of developers said debugging AI-generated code takes longer than writing it themselves.
Has generative AI improved trust within open-source communities?
Largely not, according to maintainers. The Linux Foundation found 53% of maintainers disagreed that generative AI had improved community trust, even as 71% said it had lowered the barrier to contributing.
Which AI coding tools are most relevant to this story?
The survey does not attribute the AI slop increase to any single tool. The major coding assistants active in the market as of October 2026 include GitHub Copilot with GPT-6.1 Sol and GPT-6 Luna, OpenAI’s Codex running GPT-6 Sol and GPT-6 Luna, and Cursor, which is restructuring its subscription plans around Composer 2.5 and Grok 4.7.
Related Coverage
Yusuf Demir
Yusuf Demir is the Cloud & Software Reporter at TrendinTech, where he covers cloud infrastructure, enterprise platforms, developer tools and the digital transformation of businesses in the UK and the United States. He is most interested in the gap between vendor roadmaps and the systems engineers actually run, and in what the cloud bill looks like once the free credits expire.
All stories by Yusuf Demir (409)![GPT-6 Astra Jumps COBOL Coding Score to 72% [2026]](https://trendintech.com/wp-content/uploads/2026/10/gpt-6-astra-cobol-coding-benchmark-2026-gen-640x360.webp)
![Anthropic’s Claude Duet Joins 4-Way AI Agent Race [2026]](https://trendintech.com/wp-content/uploads/2026/10/claude-duet-anthropic-ai-agent-2026-640x360.webp)
![LoRA and QLoRA Fine-Tuning: 13 Steps, 90 Min [2026]](https://trendintech.com/wp-content/uploads/2026/10/lora-qlora-fine-tuning-tutorial-2026-gen-640x360.webp)