Short answer: The Glasgow Haskell Compiler (GHC) now has a written policy for LLM-assisted contributions: they are allowed, but a human author must understand and be able to explain every line, direct LLM generation must be disclosed, and conversation with reviewers should stay human. In an October 28, 2026 write-up, Serokell, whose engineers work on GHC and took part in the discussion, walks through the policy and compares it with other open-source projects, several of which chose to ban AI-generated code outright. Note the source: Serokell discloses its own stake, so read the framing accordingly.
TL;DR
| Question | Answer |
|---|---|
| Are AI-assisted patches allowed? | Yes, with a human who owns every line |
| Must I disclose? | Yes, direct LLM generation |
| Is writing the final version myself required? | No, it is a strong preference (P5) |
| Can an LLM argue with reviewers for me? | No: P1 expects human discussion |
| Do tickets follow the same rules? | More loosely; a useful bug report can come from someone who does not understand the cause |
| Are AI reviews covered? | Yes, same rules; wording also covers future agents |
| Who disagrees? | OpenJDK, Zig, Clojure, QEMU (for now) restrict or ban |
The policy in plain words
Serokell describes four policy points and one strong preference. The document follows a draft by Simon Peyton Jones developed in the ghc-devs discussion, not a competing "shared statement" proposed in July, whose authors said it was not meant as a contribution policy.
- P1, prioritize people and community. LLMs may be used to navigate the codebase, translate text or investigate a problem, but generated text should not stand in for the contributor's own judgment in discussion with reviewers.
- P2, make merge requests easy to review. Contributors should invest substantially more effort than reviewers need to understand the change: a clear goal, explained design, examples and tests, digestible pieces. A patch that compiles but leaves the reviewer to reconstruct the reasoning fails.
- P3, human authorship and full responsibility. An identifiable human must be able to explain every line of code and every sentence of documentation. Tickets are treated more loosely, and draft merge requests may contain unfinished or generated work if clearly marked.
- P4, disclosure. Direct LLM generation is declared.
- P5, preferably write the final version yourself. Generated code is still allowed; rewriting is a simple way to ensure you thought through every line. It stays a preference, so a contribution is judged under the policy points, not on whether a human typed every character.
The policy deliberately takes no position on whether LLMs are good or bad overall, saying the project has no consensus on costs and benefits.
Why reviewer time is the real constraint
GHC has more than 6,500 open tickets and more work than reviewers. Serokell's point is that cheap patch generation does not help if review gets more expensive: "A patch produced in twenty minutes can still cost a maintainer two hours to understand."
It borrows LLVM's term extractive contribution, from Nadia Eghbal's book Working in Public, where the contributor benefits from submitting while the project spends more effort than the contribution is worth. The problem predates LLMs, since anyone could submit a 2,000-line patch they barely understood, but generating one is now much easier. Serokell also cites an observational Faros finding that teams with heavier AI adoption produced more and larger pull requests while review times rose, while cautioning that a corporate engineering team is not directly comparable to GHC.
Review also needs project memory. A patch can look right in isolation while contradicting a proposal from four years ago or reintroducing an old regression. LLMs mainly reduce how much context someone needs before producing something plausible.
How other projects chose
Serokell's survey is the most useful part for anyone setting a policy. As it reports:
| Project | Position |
|---|---|
| OpenJDK | Interim policy excludes contributed material generated in whole or part by LLMs; private use for comprehension, research, debugging and review is fine |
| GCC | Rejects legally significant contributions containing or derived from generated material; AI allowed for investigation and review |
| LLVM | Accepts assisted contributions when a human checks and takes responsibility; AI tools may not solve good first issue tasks |
| Linux kernel | Allows AI-assisted contributions; the human reviews, takes responsibility, certifies the DCO and records the assistance with an Assisted-by tag |
| OCaml | Allows under conditions; asks for disclosure when a significant part was generated |
| Clojure | Rejects LLM-generated code |
| Zig | Prohibits LLM-authored contributions; frames maintainer time as an investment in people who may stay |
| Agda | Debated a blanket ban; proposal closed without adoption |
| QEMU | Still rejects AI-generated contributions; a replacement policy is under discussion |
OpenJDK's own page, the Interim Policy on Generative AI, cites risks "to reviewer burden, to safety and security" alongside productivity opportunities. Serokell notes OpenJDK itself admits that reliably distinguishing generated from human-written content is generally impossible, so a ban rewards silence: a contributor who discloses can be rejected while one who used the same tool privately may be indistinguishable.
Legal motives differ from review motives
Some strict positions are about provenance, not quality. GCC draws its line at legally significant contributions because the FSF's licensing claims depend on clear origin, and OpenJDK points to contributor-agreement requirements. Serokell says a GHC contributor asked the Haskell Foundation to fund legal advice on whether model providers' content-rights waivers would hold up; the Board declined, arguing the question was not Haskell-specific and not yet tested enough in court. Projects with copyright assignment have stronger reasons to be conservative; GHC uses a different licensing model.
Policies age quickly
The article's strongest argument is that rules based on current model quality can become obsolete fast. Serokell's examples:
- curl closed its bug bounty at the end of January 2026 after poor, often AI-linked security reports; the share of reports that were confirmed vulnerabilities, historically above 15%, fell below 5%. By April 22 Daniel Stenberg wrote that almost every report involved AI but slop was no longer the main problem, and the rate was back around 15 to 16%.
- QEMU's maintainers have been drafting a replacement for its ban that also covers instructions for AI agents working inside the repository.
- Bun reported a large debug compile-time improvement in its Zig fork and said it would not upstream it because Zig bans LLM-authored contributions. Serokell notes a Zig core developer found technical problems, including nondeterministic behavior, so the patch was not obviously acceptable anyway.
Serokell also cautions that speed percentages are hard to interpret for compiler work, and suggests asking whether a task would have been done at all: reproducing an old bug on current GHC or reducing a 500-line reproducer is valuable but rarely attracts volunteers. It describes a case where Sylvain Henry built a proof of concept for GHC's coercion-size problem in July using Claude Fable, combining ideas from earlier attempts by experienced compiler engineers.
What this means if you maintain or contribute to a project
For maintainers, three ideas transfer directly. Put the burden of proof on the contributor (P2 and P3). Require disclosure so reviewers know how much context to supply. Keep human conversation human, so mentoring still happens. If you worry about drive-by patches displacing newcomers, tighten the policy when you see evidence, as GHC says it can.
For contributors using coding agents, the working rule is simple: if you cannot explain a line, do not submit it. Reduce the diff, write the design note yourself, add tests, and disclose. We have covered the other side of the queue as well, such as QGIS banning AI-assisted contributions, Google freezing its open-source bug bounty over AI slop reports, and Anthropic's free scanner for open-source maintainers. For how well agents do on real maintainer merge decisions, see FrontierCode's maintainer-merge benchmark.
For teams, policy can be enforced in tooling. An open-source governance layer like Bernstein turns rules into checks that run before a pull request exists.
A starter template for your own project
If you are drafting a policy, GHC's structure suggests a minimal checklist you can adapt:
- State plainly that assisted contributions are welcome or not, and why.
- Require a named human who can explain and maintain every change.
- Ask for disclosure of direct generation, and say what happens after disclosure.
- Set review-cost expectations: small, tested, well-explained changes.
- Keep mentoring conversations between people.
- Name the review process for AI-assisted reviews too.
- Schedule a revisit, since model quality and project needs will change.
Caveats
This is a vendor-adjacent summary: Serokell engineers participated in the debate and use coding assistants. We read the article, not the GHC wiki text itself, so check the project's own policy page for exact wording. And Serokell reports that GHC has not seen a flood of low-quality LLM submissions, which is why it considers a blanket ban aimed at a problem the project does not yet face at scale. Other projects may have different experiences.
Related reading
- QGIS bans AI-assisted contributions
- Google freezes its OSS bug bounty over AI slop
- Anthropic's free AI scanner for open-source maintainers
- FrontierCode 1.1: maintainer-merge benchmark
- Bernstein: policy-as-code for coding agents
Sources: Serokell, AI Contributions to GHC, OpenJDK Interim Policy on Generative AI.
Policy details are as described by Serokell on October 28, 2026 and may have changed; confirm with the GHC project.