Something has changed in how open-source contributions work. AI tools mean anyone can generate a formally correct pull request in minutes — sometimes seconds. The cost of submitting has basically hit zero. The cost of reviewing hasn’t moved at all.
That is a structural cost asymmetry and it is putting real pressure on maintainer bandwidth across major projects. Daniel Stenberg ended curl‘s seven-year bug bounty programme. tldraw auto-closes all external AI PRs. Ghostty moved to invitation-only contributions.
The uncomfortable truth is that good-faith AI contributions and bad-faith ones impose the same triage cost. The reviewer’s workload is identical either way. This article explains why — and it’s the entry point to the broader open-source supply chain risk landscape, which extends to dependency security and licence compliance.
Why did the cost of contributing to open source just collapse?
GitHub’s pull request model was always designed to lower barriers. Before it, contributing meant subscribing to mailing lists, learning community norms, and formatting patches correctly. That friction filtered for real engagement.
The push-based contribution model meant any external actor could submit code to any public repository with no prior relationship required. Code first, conversation later. AI tools then removed the last meaningful friction gate — before LLMs, generating a contribution still required actually reading the codebase and demonstrating some engagement. That time cost filtered for genuine interest.
The numbers show the result. Excalidraw received more than twice as many PRs in Q4 2025 as in Q3. Curl’s security report queue hit AI slop rates above 20% by mid-2025, averaging about two AI-generated reports per week.
Vibe coding is the contributor-side practice producing this volume: AI prompts to generate code without deep codebase understanding, submit, and move on. It weakens the user engagement through which many maintainers earn returns — the kind of engagement that historically made reviewing worthwhile.
That cost gets transferred somewhere. It lands on the reviewer.
What does it actually cost a maintainer to review an AI-generated pull request?
Reviewing a pull request means reading code, understanding intent, running tests, checking alignment with project direction, and formulating feedback or a rejection rationale. None of those steps can be skipped without risk.
A calculation that has circulated widely puts the asymmetry in concrete terms: a contributor spends roughly 7 minutes generating a vibe-coded PR while a maintainer spends roughly 84 minutes reviewing it. That’s a 12× cost multiplier, borne entirely by the person who did not initiate the transaction.
The curl security team consists of seven members; every report engages 3–4 of them, sometimes for 30 minutes, sometimes for several hours. At peak, eight reports arrived in a single week. Stenberg’s team was spending multiple days per week on triage before he ended the bug bounty — one that had been running since 2019, paid over $90,000 in awards, and fixed 81 genuine vulnerabilities.
And even rejected contributions aren’t free. Triage — opening, scanning, categorising, and closing a PR — takes 5–15 minutes per item. Review cost does not scale with generation cost. The two are structurally independent.
The real-world incidents that prove this dynamic — the curl bug bounty shutdown, tldraw’s auto-close policy, the Node.js 19,000-line Claude Code PR — each reflect the same arithmetic playing out at scale.
What is extractive contribution, and why does it apply even to good-faith AI PRs?
“Extractive contribution” comes from Nadia Eghbal’s Working in Public (2020): a contribution where the marginal cost of reviewing and merging it exceeds the marginal benefit to the project. LLVM operationalised this in their December 2025 AI Tool Use Policy with a golden rule: a contribution should be worth more to the project than the time it takes to review it. That standard applies regardless of contributor intent.
The ease of creation adds a burden to the maintainer because there is an imbalance of benefit: the contributor gets the credit, the maintainer gets the maintenance burden. Good-faith contributors using AI tools produce exactly the same review burden as bad-faith ones.
tldraw’s experience illustrates this perfectly. Early AI PRs at tldraw all looked good — formally correct, tests passing. Problems only emerged when patterns of abandonment and wrong-directedness became apparent: the AI had taken the issue at face value without understanding the codebase. The contributor believed they were helping. The result was still extractive.
This is the distinction most coverage misses: because intent cannot be determined without performing the review, the distinction between good-faith and bad-faith AI contributions does not change the maintainer’s workload. The problem isn’t about malicious intent — it is about where the cost falls.
How does vibe coding break the loop that made open source work?
Traditional open-source contribution followed a clear cycle. A developer used a project, hit a problem, engaged with the issue tracker, understood the maintainer’s priorities, and submitted a fix. The submission arrived with embedded project knowledge — and a contributor relationship had begun.
That cycle produced two things at once: a potential contribution and an engaged community member. Vibe coding severs this loop entirely. Building software without directly reading documentation, reporting bugs, or engaging with maintainers means the submission arrives without the context that made it valuable.
Steve Ruiz described his own first major open-source contribution as requiring sustained engagement, issue history reading, and multiple iterations. His framing: context and alignment must come first; implementation is almost ceremonial once those are in place. Vibe coding inverts this entirely.
LLVM explicitly forbids using AI tools to fix issues labelled “good first issue”. These issues exist to grow the contributor base through learning. Outsourcing that learning produces a PR without producing a contributor. As LLVM put it: “Passing maintainer feedback to an LLM doesn’t help anyone grow, and does not sustain our community.”
What is the Eternal September problem, and why are we living it again?
In September 1993, AOL connected millions of new users to Usenet permanently — new, norm-unaware users kept arriving at scale without the infrastructure to absorb them. It became the September that never ended.
GitHub applied this metaphor to the current AI PR surge in February 2026: a continuous inflow of low-context contributions that existing norms and tooling were not designed to handle. Unlike the original surge — a one-time event — AI tool adoption keeps accelerating.
Steve Ruiz sharpened the metaphor with “Eternal Sloptember.” AOL users were human newcomers who could eventually learn norms. AI-generated contributions have no learning mechanism. A rejected AI PR provides no feedback that prevents an identical one tomorrow. The volume compounds without correction.
Usenet did not recover its pre-surge character. The individual project responses — tldraw’s auto-close, LLVM’s policy, Ghostty’s invitation-only model — address the symptoms. The structural shift in contribution economics is what they are responding to.
Push vs. pull: what would a healthier contribution model look like?
When contribution generation cost approaches zero, the push model becomes a mechanism for imposing attention cost on maintainers at zero cost to themselves. The maintainer cannot refuse receipt.
The pull-based model inverts the flow: a maintainer identifies a need, opens a discussion, and invites code after agreement on problem and approach. Friction reappears at the social layer.
Real projects have implemented this. Ghostty moved to invitation-only contributions. LLVM’s issues-first guidance effectively implements a pull model at the policy layer. Mitchell Hashimoto’s Vouch project implements trust management where contributors must be vouched for before participating. Steve Ruiz narrowed tldraw’s community contribution to reporting, discussion, and perspective — the parts where human engagement still has value.
The tradeoffs are real. A pull model requires more maintainer time upfront, reduces serendipitous contributions, and may deter valid contributions from new contributors. But it changes where friction is positioned so that costs and benefits stay aligned.
For platform-level changes underway, GitHub has already shipped repo-level pull request controls — and is exploring criteria-based gating that requires a linked issue before a PR can be opened.
Where does this leave the maintainers bearing the cost?
The cost asymmetry is not self-correcting. The gap between contribution generation cost (trending toward zero) and review cost (fixed) will widen as AI tools become more capable.
The high-profile cases — curl, tldraw, Ghostty — represent a small fraction of the real distribution. The problem is distributed across thousands of less-visible projects maintained by people without the platform to make their situation public. Understanding how AI-generated contribution pressure propagates through your dependency stack is the starting point for treating this as a supply-chain risk question rather than a community etiquette one.
RedMonk analysed the generative AI policies of 77 open source organisations and found stances mapping as permissive, ban, or undecided — with no consensus standard. Each project has developed its own approach independently.
The next escalation layer extends beyond individual PRs. Cloudflare rebuilt Next.js with AI in approximately one week — what the Evilginx author Kuba calls “slop-forking.” If AI can regenerate a codebase with minimal attribution, the economic case for maintaining permissive licences weakens. The legal frameworks for AI-mediated derivation under MIT or Apache 2.0 are not settled.
If your team consumes open-source dependencies, this is not a spectator problem. The libraries your products depend on are maintained by people operating under exactly these pressures. Rising issue response times, maintainers posting about unsustainable workloads, policy changes like auto-close or invitation-only models — these are the signals to watch.
For the full risk picture across the open-source supply chain and how OSS communities are responding with governance policies, the structural question is the same: who bears the cost, and for how long. For a complete open-source supply chain risk overview covering all six risk dimensions — from this cost asymmetry mechanism through to dependency risk management and contributing back — see the full guide.
FAQ
Is AI-assisted coding the same as vibe coding?
No. AI-assisted coding uses AI as a tool within a workflow the developer understands and controls — they review, validate, and are accountable for the output. Vibe coding uses AI to generate code without deep understanding of what it produces or the codebase it targets.
LLVM’s human-in-the-loop policy formalises the line: contributors must read and review all AI-generated content before asking others to review it. Steve Ruiz’s position: “If you know the codebase and know what you’re doing, writing great code has never been easier.” The distinction is contributor knowledge, not tool use.
Can AI PRs ever be good for a project?
Yes — but the bar is higher than it sounds. The difference between high-quality AI-assisted research and AI slop is expertise. AISLE found 12 zero-days in OpenSSL using AI-powered analysis tools. Joshua Rogers’ AI-assisted security research on curl produced around 50 merged fixes. Both used AI to amplify deep knowledge, not replace it.
Using “can AI PRs be good” to sidestep the harder structural question misses the point. Even if some AI PRs are good, the aggregate cost of processing the volume of bad and mediocre ones imposes net harm on the project.
What counts as a good-faith AI contribution?
Good faith alone is not sufficient. LLVM’s policy is the most explicit standard available: contributors must personally review and understand every line of AI-generated content and answer questions about it during review. The submission must represent the contributor’s own work. Note tool usage in the PR description or commit message.
In practice: deep familiarity with the project, prior issue-tracker engagement, a problem statement discussed with maintainers, and personal accountability.
Why can’t maintainers just ignore low-quality PRs?
Ignoring a PR is not neutral. An open PR signals ongoing consideration; an ignored one creates ambiguity about project responsiveness. Ignoring also requires assessment — reading enough to know a PR can safely be ignored is a subset of full review cost, not zero. tldraw found the volume made “just ignore them” unsustainable — auto-closing the entire class was cheaper than triaging individually.
What is “death by a thousand slops”?
A phrase coined by Daniel Stenberg describing the cumulative effect of individually small but collectively overwhelming AI-generated submissions. Each report might consume 10–15 minutes — manageable in isolation. Eight such reports in a week, each engaging 3–4 team members for up to several hours, on a team where members have only a few hours per week for curl, is not.
What is the “push-based contribution model” and why is it a vulnerability?
The push-based model is GitHub’s standard PR paradigm: any external actor can fork a repository and submit a PR without prior permission or relationship. Before GitHub, contributing required mailing lists and patch formats — barriers that filtered for engagement. When generation cost drops to zero, this model becomes a one-way attention extraction mechanism.
What is “slop-forking” and why should your team pay attention?
Slop-forking is using AI to consume an entire open-source codebase and produce a derivative product. Cloudflare rebuilt Next.js with AI in approximately one week — the most prominent current example. The unresolved question: if AI regenerates source code entirely, does the original open-source licence still apply? If the legal frameworks do not constrain this, the incentive to maintain permissive open-source projects weakens for everyone.
Are maintainers overreacting to AI pull requests?
No. The reactions are proportionate to documented volume increases. And even if AI-generated code quality improves to human parity, the generation cost approaches zero while the review cost remains fixed. The structural imbalance does not require quality to be an issue.
How does this affect organisations that consume open-source dependencies?
Directly. A maintainer under the pressure Stenberg’s team was experiencing is an abandonment risk, and abandoned dependencies accumulate technical debt and security exposure. Watch for rising issue response times, maintainers posting about unsustainable workloads, and policy changes like auto-close or invitation-only models. Require human-in-the-loop review before any AI-assisted PR goes to an external project.
What is the “Eternal September” problem in open source?
In September 1993, AOL connected mainstream internet users to Usenet, permanently overwhelming community norms with norm-unaware newcomers. The community never recovered. GitHub applied the metaphor to the current AI PR surge in February 2026. What makes the AI version sharper: unlike AOL users who could learn norms over time, AI-generated contributions have no learning mechanism. A rejected AI PR provides no feedback that prevents an identical one tomorrow. And unlike the original surge, AI tool adoption keeps accelerating.
