System76 has banned LLM-generated content from pull requests to COSMIC, the Rust desktop environment that ships with Pop!_OS. Under the policy published October 2, 2026, contributors must certify that they have "not included any LLM (also known as AI) generated content in this PR, including code, comments, and descriptions." The stated reason is maintainer load: lead developer Jeremy Soller said such submissions strain maintainers, and that while AI let many first-time contributors take part, their changes were "unplanned and rarely accepted."
It is a small project decision with a large signal: the first wave of open-source maintainers is now writing AI policy as a survival tool, not a philosophy.
TL;DR: the COSMIC policy at a glance
| Question | Answer |
|---|---|
| What changed? | COSMIC pull requests must certify no LLM-generated content |
| When? | Reported October 2, 2026 (XDA Developers) |
| Scope | All COSMIC repositories except cosmic-flatpak, per that report |
| What counts? | Code, comments, and PR descriptions |
| Who decided? | System76, with Jeremy Soller explaining the rationale |
| Stated reason | LLM submissions strain maintainers and are rarely accepted |
| Exceptions? | Non-generative uses such as bug finding do not appear to be banned |
| How is it enforced? | A contributor checklist and maintainer review; no reliable detector exists |
| Compare | Linux kernel and Ubuntu accept high-quality AI content rather than ban it |
What the rule actually says
The mechanism is a checklist item in the pull request template. Contributors confirm they have not included LLM-generated content in the change, covering code, comments, and the description text. The policy also lines up with the usual expectations: test your changes and take responsibility for review feedback.
Two details matter. First, the ban covers prose as well as code. A PR description written by a chatbot counts. Second, it is a certification, not a detection system. There is no dependable way to prove a patch was or was not machine-written, so the rule works the way many contribution norms do: it states a standard, gives maintainers a clear reason to close a PR, and puts the false-statement risk on the contributor.
Why maintainers reach for a ban
Open-source review is a scarce resource. A generated patch costs seconds to produce and minutes to hours to review. When the cost to submit falls to near zero, the cost to evaluate does not, and that asymmetry lands on a handful of unpaid or under-resourced reviewers.
Soller's phrasing is revealing. He did not say AI code is always wrong. He said it helped newcomers get involved but that the resulting changes were unplanned and rarely accepted. In other words, the project was spending review time on work that did not fit its roadmap, then declining most of it. Declining is itself work: explaining, closing, answering follow-ups.
This is the same dynamic we described in what AI slop is and why it floods quality channels and in the broader slopocalypse overview. Software projects are the newest place it shows up.
Is a ban the right call? The arguments on both sides
The case for it
- Review is the bottleneck. If you cannot review more, you must admit less. A bright line is cheaper to apply than judging each patch.
- Provenance and licensing worry some maintainers. Projects with strict licensing expectations sometimes prefer to avoid generated code altogether.
- Learning is the point for newcomers. A contributor who cannot explain their patch is not being mentored by the review process.
The case against it
- It is hard to verify. Careful contributors who disclose are punished, while undisclosed use passes unnoticed.
- It blocks good AI-assisted work. Careful contributors who use assistants as a drafting aid are shut out, even when they review every line.
- It targets the tool, not the failure. The real problem is low-effort, unplanned changes. A human can submit those too.
The Linux kernel and Ubuntu, which have also been hit by waves of automated bug reports, took the opposite approach and allow high-quality AI content, according to the same coverage. Both stances are defensible; they reflect different tolerance for review cost and different trust in contributors.
For a practitioner's view of how fast teams adopt agents anyway, see our look at Cursor's free credits for FFmpeg developers, where a major project took the opposite posture toward AI tooling for maintainers.
How the three policy styles compare in practice
Projects facing the same flood are converging on three styles. The differences show up mostly in who carries the cost.
| Style | How it works | Who carries the cost | Main weakness |
|---|---|---|---|
| Outright ban (COSMIC) | Contributors certify no generated content | Contributors who must rewrite or walk away | Cannot be verified; honest people are the ones constrained |
| Disclosure plus accountability | AI use is allowed if declared and the author can explain every line | Maintainers, who still review each patch | Relies on honest disclosure and still admits volume |
| Open acceptance with quality gates | Anything is welcome if it passes tests, style, and an agreed issue | Automation and CI | Gates must be strong, and the review queue can still grow |
COSMIC chose the first style because its bottleneck is reviewer attention on a young desktop with many first-time contributors. A project with a deep bench of reviewers and strong CI may reasonably choose the third. The takeaway is not that one style is correct, but that the choice should follow the constraint you actually have.
Enforcement is the part most announcements skip. Without a detector, maintainers rely on signals that have always indicated low effort: no linked issue, a description that does not match the diff, changes that touch unrelated files, and an author who cannot answer a basic question about their own patch. Those signals work regardless of whether a model was involved, which is one reason a rule about conduct and accountability can age better than a rule about tools.
What people are asking
Does this mean Pop!_OS itself is AI-free?
No. The reported policy concerns contributions to COSMIC repositories. It says nothing about what tools users run on Pop!_OS, and it does not claim to audit existing code. Treat claims that the whole distribution is "AI-free" as unverified.
Can I use an AI assistant to understand the codebase?
The coverage suggests non-generative uses are not the target. Reading code with an assistant, asking it to explain a function, or using it to locate a bug is different from pasting generated code or text into a pull request. Still, if your workflow blurs that line, ask maintainers in an issue before you submit.
Will other projects follow?
Some will, some will not. Expect a spectrum: outright bans, disclosure requirements, and quality-gate approaches. Whatever a project picks, writing it down in the contributing guide saves everyone time.
What if I used an AI tool and my patch is genuinely good?
Under COSMIC's rule, you cannot certify the checklist if generated content is in the PR. The practical options are to rewrite it yourself, or to contribute to a project whose policy permits assisted work. Do not check a box you cannot honestly check.
A template for projects writing their own policy
If you maintain a repository and are weighing this, a short policy covers most of the ground:
AI-assisted contributions
- You are the author. You must understand and be able to explain every line.
- Disclose any AI tool use in the PR description.
- Open an issue and get a maintainer's agreement before large changes.
- Unreviewed, bulk, or unplanned generated changes will be closed without comment.
- Test locally. Include the commands you ran.
A ban is the strictest option on the spectrum. Disclosure plus accountability is the middle path. Open acceptance with quality gates is the loosest. Pick the one you can enforce.
If you are the contributor, the same logic applies in reverse. Before submitting to any project, read its contributing file, search closed pull requests for rejected AI patches, and open an issue first. Our guide on vibe coding mistakes and how to avoid them covers the habits that keep generated code from becoming someone else's cleanup job, and the earlier piece on agentic fatigue and the productivity paradox explains why more code per hour does not mean more value per hour.
What this means for what you build
If you ship an open-source project, assume the volume of AI-generated contributions will rise. Decide your policy before the first flood, not after. If you ship an agent that opens pull requests, build in the constraints maintainers care about: scope the change, link an agreed issue, run the tests, and keep a human accountable. Agents that respect project norms will be welcome; agents that spray patches will be banned, as COSMIC just showed.
Teams building their own agent guardrails can start with what agent skills are, which is a practical way to encode a project's contribution rules for an agent to follow.
Limitations of this report
- Secondary sourcing. The primary policy lives in COSMIC repositories on GitHub. Our description relies on XDA Developers and the Neowin report, which we could not fetch directly. Read the repository's contributing file for the authoritative wording.
- Details may change. Projects often adjust wording after community feedback.
- No enforcement data. There are no public numbers yet on how many pull requests were closed under the rule.
Related reading
- What is AI slop and how to avoid it
- The slopocalypse: AI slop and the internet
- Cursor gave FFmpeg developers free credits
- Vibe coding nightmares and how to avoid them
- Agentic fatigue and the developer productivity paradox
- What are agent skills? Complete guide
- Claude Code commands reference
Sources: XDA Developers, Neowin.
Policy details are accurate as of October 4, 2026 and may change as System76 updates its contribution rules.
Update — October 5, 2026: Google has frozen OSS VRP product vulnerability submissions over AI-generated reports: read the coverage.