When a PR Is Free But Review Still Costs the Same

curl killed its bug bounty, Ghostty banned AI PRs, tldraw auto-closes them. Each is a manual version of what an automated gate should do.

Generating a pull request now costs almost nothing. Reviewing one still costs exactly what it always did: a human has to read the diff, understand the intent, and decide whether to trust it. That asymmetry is why curl shut down its bug bounty program, why Ghostty banned unapproved AI contributions outright, why tldraw started auto-closing every external pull request, and why GitHub spent 2026 weighing, then actually shipping, ways to switch pull requests off entirely. None of this is an AI-ethics debate. It is a capacity failure: review bandwidth is fixed, PR volume is not, and once generation is free, review becomes the thing a bad actor, or just an indifferent high-volume contributor, can exhaust on purpose or by accident.

Sources: GitHub Weighs Pull Request Kill Switch As AI Slop Floods Open Source (Open Source For You), GitHub ponders kill switch for pull requests to stop AI slop (The Register), AI Floods Close Open Source Projects (InfoQ), GitHub's 2026 AI Response (InfoQ)

Review capacity is the resource under attack

Several people arrived at the same metaphor independently. At Pydantic's PyAI conference in March 2026, FastAPI creator Sebastian Ramirez described the pattern as a distributed denial of service attack, not on servers, but on maintainer attention: a contributor spends seconds on a prompt, and the maintainer spends days reviewing what it produced. Flux maintainer Stefan Prodan put it more bluntly in coverage of the same wave of closures that month: AI slop is DDoSing open source maintainers. Red Hat virtualization engineer Daniel Berrange reached the same conclusion in August 2026, after more than 130 patch-free Undefined Behavior Sanitizer reports hit QEMU within minutes, calling it effectively a denial of service attack on the project maintainers. Three different maintainers reached for the same analogy without ever talking to each other. A denial-of-service attack does not need malicious intent behind every request. It only needs the cost of sending one to fall far below the cost of handling one, and generation costs fell faster than review costs ever could.

Sources: AI/LLM Usage Becoming A "Denial of Service Attack" On Open-Source Project Maintainers (Phoronix), Sebastian Ramirez on AI-generated PRs, PyAI panel (Pydantic), AI Floods Close Open Source Projects (InfoQ)

What projects did about it, by hand

Individual maintainers could not wait for a platform-level fix, so each reached for the only lever available without GitHub's help: refuse input at the source. Three 2026 responses show the same underlying move. Reduce volume by whatever means available, because there was no other way to protect a fixed amount of review time.

The timing is a tell on its own. curl's shutdown, Ghostty's ban, and tldraw's auto-close policy all landed within roughly the same few weeks in early 2026, and none of the three maintainers coordinated with each other. Each independently crossed the same threshold: the point where sorting a good contribution from a dumped one took as long as writing the fix from scratch would have. Three unrelated projects hitting the same wall at close to the same time is a different signal than three isolated incidents. It is evidence the cost curve itself shifted under all of them at once.

Sources: AI Floods Close Open Source Projects (InfoQ)

Banning by hand is a blunt version of a gate

Every response above is an access-control decision about identity or volume, not about the content of any specific diff. A ban or auto-close rule asks who submitted something, or how many submissions arrived this week. It does not ask whether a given pull request is actually correct, safe, or even relevant to the project. That is the gap a content-level check is built to close: instead of asking whether a person used AI, it asks whether a diff matches what it claims to do, whether an independent pass found anything wrong with it, and whether an adversarial read turned up anything exploitable, then withholds the merge until every answer comes back clean. A project doing this by hand, with a ban hammer, is approximating with a blunt instrument what a convergence gate does mechanically and per diff. Enforcing the ban still consumes some of the attention it was meant to save: someone has to decide who counts as a trusted collaborator, read enough of a rejected PR to close it with a reason, and keep the policy itself updated as contributors test its edges.

Intent is the wrong thing to screen for

Trying to detect bad intent at the door does not scale any better than review does. Xavier Portilla Edo, head of infrastructure at Voiceflow, estimated in February 2026 that only about 1 in 10 AI-generated pull requests he encountered met the bar required to open one at all, a ratio that holds regardless of whether the person behind any given submission was acting in good faith, being careless, or not caring either way. A maintainer cannot interview every contributor before reviewing their diff, and a self-disclosure rule like Ghostty's only works on contributors willing to disclose. What a maintainer, or a team gating its own merges, can check without ever asking anyone's intent is the diff itself: does it match a spec that existed before the code did, does an independent read find defects in it, does an adversarial read find anything exploitable in it. None of those three checks care why the diff exists. They only care what it does, which is the one property that neither volume nor stated intent ever predicted reliably.

Sources: GitHub Weighs Pull Request Kill Switch As AI Slop Floods Open Source (Open Source For You)

GitHub's own dilemma: it also sells the tool flooding it

GitHub's position is more awkward than any single project's. It sells Copilot, one of the tools generating the volume it is now building controls against, while also being the platform every maintainer above depends on for hosting issues and pull requests. One analysis of GitHub's response called it an 'Eternal September' moment: the recognition that higher contribution volume from cheaper tooling is now a permanent feature of the platform, not a spike to wait out. The tools GitHub actually shipped, letting a maintainer disable pull requests outright, restrict them to existing collaborators, or cap how many a single outside contributor can have open at once, relieve maintainers without touching Copilot itself. That is the platform-operator version of the same blunt instrument every project above reached for: control who gets to submit and how often, rather than evaluate what was submitted.

Sources: What GitHub and the OSS Ecosystem Are Building to Protect Maintainers from AI Slop (SoftwareSeni), GitHub gives maintainers new controls as AI-generated pull requests overwhelm open-source projects (CryptoBriefing)

• GitHub product manager Camilla Moraes opened the issue publicly in February 2026, describing "a critical issue affecting the open source community" around low-quality, often AI-generated contributions.
• GitHub shipped the disable-PRs and collaborators-only settings that same month, then expanded them with per-contributor concurrent-PR caps in August 2026, roughly six months after the internal discussion started.
• RedMonk analyst Kate Holterhoff named the broader pattern "AI Slopageddon" after curl, Ghostty, and tldraw all reached for some form of lockdown within weeks of each other.
• Red Hat's Daniel Berrange reported the same dynamic hitting QEMU as late as August 2026, via a wave of automated sanitizer bug reports with no patches attached, well after curl, Ghostty, and tldraw had already acted.

This is not the internal review problem

This blog has already covered a related problem, and it deserves to stay separate from this one. Qodo's 2026 survey found that review, not generation, is now the top bottleneck inside teams that use AI to write their own code, and a related post on why AI shifts review cost onto senior engineers showed where that cost actually lands. Both are internal-velocity problems: a team's own agents produce more diffs than the team's own reviewers can clear, and everyone touching the diff wants the same outcome. The open-source flood is a different threat model. The contributor and the maintainer are not on the same team, and the contributor does not always want the maintainer's outcome. Some of the volume is careless rather than malicious. Some of it, judging by what hit curl and QEMU, is indifferent to whether the output is usable at all, because trying costs the submitter nothing whether it lands or not. A gate built for internal velocity can assume good faith on the other side of the diff. A gate built for inbound, external contribution cannot assume that.

What a mechanical gate does differently

This is the shape of problem that a governance layer around AI-assisted changes is built for, applied to the part of the flood a team actually controls: the point where a diff is about to merge into its own codebase, whether that diff arrived from an internal agent or an outside contributor. TLM Forge runs a spec audit before an agent generates code, an independent review pass on every diff once code exists, and an adversarial red-team security pass on top of that, then holds the merge behind a convergence gate until flagged issues hit zero, not just logged and set aside. You can read the specifics of how it works. That sequence does not need to know whether a human or a model wrote the original patch, and it does not ban AI-assisted contributions to make the volume problem disappear. It checks the diff itself, every time, against the same bar, which is the thing identity-based bans and blanket zero-tolerance policies cannot do on their own. GitHub's own in-progress tooling is reaching for a version of the same idea from the other direction: one feature under development, according to reporting on its 2026 maintainer controls, would require a pull request to link to an approved issue before it can even open, which is a spec check arriving before the code rather than after it. None of this replaces the judgment call of whether to accept an outside contributor into a project at all. It only means that judgment call can run on what a diff actually does, rather than on who or what produced it.

Sources: What GitHub and the OSS Ecosystem Are Building to Protect Maintainers from AI Slop (SoftwareSeni)