GHC 确立 LLM 辅助贡献政策，明确使用与披露边界

What contributors can do, what they must disclose, and why we think the policy is reasonable.

GHC now has a concrete policy for LLM-assisted contributions. By mid-October, maintainers were already referring to it directly in review discussions: Julian Ospald cited P3 of “the AI policy”, while Andreas Klebinger described LLM-generated bug fixes as “fine, it’s policy”.

The GHC wiki page itself predates this summer’s debate, so the URL alone does not show what changed. The current text does.

The policy follows the document Simon Peyton Jones developed through the ghc-devs discussion, rather than the competing “shared statement” proposed in July. The authors of that statement explicitly said it was not intended to replace a contribution policy, and Teo Camarasu argued against treating it as one.

The structure changed during the discussion. On July 27, the draft was being summarised as three policy points and one recommendation: make merge requests easy to review, take full responsibility for the contribution, declare direct LLM use, and preferably write the final version yourself. The current document has four policy points and one strong preference. “Prioritise people and community” is now P1; the earlier points move to P2–P4; writing the final version yourself becomes P5 and remains a preference rather than a requirement.

We have a direct stake in the discussion. Vladislav Zavialov and Andrei Borzenkov work on GHC at Serokell, and Andrei participated in the policy discussion. Coding assistants have also become part of our own engineering workflow.

For GHC, the practical problem is reviewer cost. Tool-assisted work is useful only if it does not leave maintainers doing the contributor’s thinking for them.

GHC currently has more than 6,500 open tickets. Some are difficult compiler problems. Others are routine but still useful: reproducing an old report, reducing a test case, adding a missing benchmark, or checking whether a bug still exists.

What the policy says

The policy does not take a position on whether LLMs are good or bad overall. It says explicitly that the project has no consensus on their costs and benefits. Instead, it defines expectations for contributions and reviews.

There are four policy points and one strong preference.

P1: prioritise people and community. Contributors may use LLMs, but direct discussion with reviewers is expected to remain human. Generated text should not be relayed as a substitute for the contributor’s own judgement. Using an LLM to navigate the codebase, translate text, or investigate a problem is allowed, but the tool should not replace the conversations through which an open-source project develops contributors and maintainers.

P2: make merge requests easy to review. Contributors are expected to invest substantially more effort in a contribution than reviewers will need to spend understanding it. MRs should have a clear goal, an explained design, useful examples and tests, and be split into digestible pieces. A generated patch that compiles but leaves the reviewer to reconstruct the reasoning does not meet this bar.

P3: human authorship and full responsibility. Every contribution needs an identifiable human author who understands and can explain every line of code and every sentence of documentation submitted for review. Generated material is allowed if the contributor has reviewed it closely enough to take responsibility for it. Tickets are treated more loosely because a useful bug report may come from someone who does not understand the underlying compiler failure. Draft MRs may also contain unfinished or generated work if they are clearly marked as drafts and are not yet asking maintainers for review.

P4: declare direct LLM generation. If an LLM generated any part of the code, documentation, tests, or other material submitted for review, that use must be disclosed. Contributors do not need to publish prompts or account for every interaction. Private use for exploration, debugging, or design ideas does not require disclosure, although the policy encourages it. For submitted material, the declaration should be visible in the issue or MR description and in the commit message, usually with an Assisted-By: line.

P5: preferably write the final version yourself. Generated code is still allowed. The document argues that rewriting the final version is often the simplest way to make sure the contributor has thought through every line, kept the patch small, and removed unnecessary prose. GHC Notes receive particular attention because they preserve architectural reasoning that may matter years later. Generated material can still be submitted if it has been reviewed and revised closely enough to satisfy P3.

LLM-assisted reviews follow the same rules. The document also uses “LLM” broadly enough to cover future systems that play the same role, including agents.

What changed from the draft

The final policy keeps the central position of Simon’s draft: assisted contributions are allowed, direct generation must be disclosed, and responsibility stays with the human contributor.

The main structural change is that community became a policy point of its own. The July draft already discussed human conversation and the health of the contributor community; the current document promotes that concern to P1 and renumbers the operational rules beneath it.

The recommendation to write the final version yourself also survived. Some participants argued during the discussion that this should be softened. The final text keeps the strong wording but states the boundary clearly: P5 is a preference. Contributions are judged under the policy points, not according to whether a human typed every character.

The policy therefore avoids trying to settle the broader argument over LLMs. It defines the condition under which a contribution is ready to consume reviewer time.

Review is the scarce resource

Maintainer time is the main constraint.

GHC already has far more work waiting than people available to review it. Cheaper patch generation does not help much if review becomes more expensive. A patch produced in twenty minutes can still cost a maintainer two hours to understand.

LLVM calls one version of this an extractive contribution, borrowing the idea from Nadia Eghbal’s Working in Public: the contributor receives the benefit of submitting something while the project spends more effort reviewing and integrating it than the contribution is worth.

The problem predates LLMs. Anyone could submit a 2,000-line patch they barely understood. Generating one is now much easier.

Commercial development shows a similar pattern. Faros found that teams with heavier AI adoption produced more and larger pull requests while review times also increased. The data is observational, and a corporate engineering organisation is not directly comparable to GHC, but the bottleneck is the same: code production is only one part of the development process.

GHC review also depends heavily on project history. A patch may look correct in isolation while contradicting a proposal from four years ago, reintroducing an old performance regression, or making a planned compiler change harder. Human contributors can make exactly the same mistakes when they do not know enough of the surrounding history. LLMs mainly reduce the amount of context someone needs before they can produce something that looks plausible.

Maintenance has the same dependency on context. Six months after a merge, the important question is whether anyone understands why a line exists.

What about growing new maintainers?

Open-source contributions also train future maintainers.

Small issues are useful partly because contributors have to work through them. A reviewer explains why the obvious solution fails, the contributor learns another part of the system, and after enough iterations may eventually review other people’s work.

Loris Cro calls this contributor poker in his explanation of Zig’s policy. Maintainer time is an investment, and Zig prefers to spend it on people who may stay with the project rather than on drive-by patches produced cheaply with an LLM.

LLVM takes a narrower version of the same position. Its policy does not allow AI tools to solve good first issue tasks because those tasks are intended to introduce people to the project.

This becomes a real problem when generated patches displace other contributors or consume a significant share of reviewer attention. We do not see much evidence of that in GHC today. The project has a reviewer shortage, but not a flood of low-quality LLM submissions competing with a large queue of human contributors for the same tickets.

The policy can be tightened if that starts happening. Today, a blanket ban would be aimed at a problem GHC is not yet seeing at scale.

A ban is hard to police

OpenJDK took a stricter route. Its interim AI policy excludes contributed material generated in whole or in part by LLMs, while still allowing private use for code comprehension, research, debugging, and review.

OpenJDK also acknowledges the enforcement problem: reliably distinguishing generated content from human-written content is generally impossible.

The rule can still serve a purpose. A project may want a clear norm, or may have legal and provenance concerns that justify a stricter boundary. The practical incentive is less tidy: a contributor who discloses model use can be rejected immediately, while another contributor who used the same tool privately and says nothing may be indistinguishable.

GHC takes a different route. Disclosure gives reviewers context but does not automatically disqualify the contribution.

Other projects have made different choices. GCC rejects legally significant contributions containing or derived from generated material, while allowing AI for investigation and review. LLVM accepts assisted contributions when a human checks the result and takes responsibility for it. GraalVM expects submitters to understand the change well enough to answer reviewers and maintain it afterwards.

The Linux kernel has explicit guidance for coding assistants. AI-assisted contributions are allowed. The human contributor reviews the code, takes responsibility for it and certifies the DCO; the assistance is recorded with an Assisted-by: tag.

Functional-language projects disagree as well. OCaml allows AI-assisted contributions under conditions and asks for disclosure when a significant part of the contribution was generated. Clojure rejects LLM-generated code. Agda debated a blanket ban on generated contributions, but the proposal was closed without being adopted.

GHC did not have an established community standard to copy.

Some of the stricter positions are driven by legal concerns. GCC draws its line at “legally significant” contributions because the FSF’s licensing claims depend on clear provenance. OpenJDK also points to contributor-agreement requirements around ownership of contributed material. The GHC discussion reached the same issue in August, when a contributor asked the Haskell Foundation to fund legal advice on whether content-rights waivers from model providers would hold up. The Board declined, arguing that the question was not Haskell-specific and had not yet been tested sufficiently in court.

Projects with copyright assignment or contributor agreements have stronger reasons to be conservative here. GHC uses a different licensing model and has chosen a different balance.

Policies age too

Rules tied closely to the current quality of models can become obsolete quickly.

QEMU is a useful example. Its published policy still rejects AI-generated contributions, but Paolo Bonzini has been working on a replacement. In May, he argued that the ban had been easier to justify when LLM output was rarely useful without substantial rewriting. By September, the proposal had expanded into a broader policy that includes instructions for AI agents operating inside the repository.

The replacement is still under discussion, but the scope of the discussion has changed. The question is no longer only whether generated work should be kept out; it also covers how agents should behave when they are used inside the tree.

curl saw an even faster shift. At the end of January 2026, the project closed its bug bounty after maintainers were overwhelmed by poor security reports, many associated with AI use. Historically, more than 15% of reports had turned into confirmed vulnerabilities; the rate had fallen below 5%.

curl returned to HackerOne in March, not because the bounty had resumed but because HackerOne was a better place to process security reports than GitHub. On April 22, Daniel Stenberg wrote in “Higher volume, higher quality” that almost every incoming security report appeared to involve AI in some way, but low-quality slop was no longer the main problem. The confirmed-vulnerability rate had climbed back to around 15–16%.

Within roughly two months, AI-assisted reports went from contributing to the decision to close the bounty to arriving at a quality level much closer to the project’s historical norm. We cannot separate better models from better use of those models, but that distinction does not matter much for policy. The input quality changed quickly.

A rule based mainly on the claim that current tools produce bad output will need frequent revision.

Broad restrictions also have an opportunity cost. Bun maintains its own Zig compiler fork and reported a large improvement in debug compilation times after adding parallel semantic analysis and splitting LLVM code generation across multiple units. The team said it did not plan to upstream the work because Zig prohibits LLM-authored contributions.

There is an important caveat. A Zig core developer later pointed out technical problems in Bun’s implementation, including nondeterministic behaviour around parallel semantic analysis. It was not a polished patch that Zig would necessarily have accepted if it had been written without AI.

Zig’s policy nevertheless keeps that implementation out of its normal upstream review process in its current form. Some of the ideas might survive review; none might. Zig accepts that cost. GHC has made a different choice.

Speed isn’t very informative here

Coding-assistant discussions often reduce productivity to a percentage: 20% faster, twice as many tasks, some number of extra pull requests.

Those measurements are difficult to interpret for compiler work. You cannot solve the same problem twice under identical conditions because the first attempt changes what you know about it. Even if implementation takes half as long, that says little about review cost or maintenance over the next three years.

For the GHC backlog, it is often more useful to ask whether the task would have been done at all.

Take an old bug report. Someone has to reproduce it on current GHC, discover that it no longer occurs, find the change that fixed it, connect the history, and close the ticket. Or take a 500-line reproducer and reduce it to something another compiler engineer can reason about.

GHC has plenty of this work. It matters, but it does not reliably attract contributors. If an assistant makes someone willing to spend an afternoon on it, that is useful even if there is no clean productivity percentage to attach to the result.

Some problems are much harder than backlog cleanup. GHC has a recent example where model assistance entered a problem that several experienced compiler engineers had already worked on.

Coercion zapping

Programs with heavy type-level computation can make coercions in GHC’s Core representation grow enormous, with correspondingly bad compiler performance. Ben Gamari, Adam Gundry, Sam Derbyshire, and Richard Eisenberg had already explored several approaches. Some helped particular cases but introduced regressions elsewhere.

In July, Sylvain Henry produced a proof of concept using Claude Fable. The Well-Typed report describes it as combining ideas from several previous attempts. One new piece was tracking dependencies between coercion variables in a mutable variable, so the coercion being zapped did not itself have to be forced.

Sam Derbyshire then rewrote the implementation from the ground up and continued the investigation, finding further optimisations in GHC’s type-family rewriter.

The model did not independently solve the research problem. The problem definition, the earlier attempts, and the judgement needed to evaluate the result all came from engineers who knew the compiler. The proof of concept gave them another route through a problem where previous approaches had stalled.

There are more routine examples. Simon Jakobi has been sending GHC patches with trailers such as Assisted-by: Claude Fable 5 and Assisted-by: Claude Fable 5.1. They are ordinary compiler and testsuite changes and are reviewed like other patches.

AI assistance is also appearing outside patches. Asked recently about the status of a stalled GHC plan, Simon Peyton Jones said it had stalled for lack of cycles: he was submerged in bug reports, many of them AI generated, but almost all of them accurate. Here the model is closer to a testing or analysis tool than to a code generator. The reports still have to be read and acted on by the same small group of maintainers.

Our own experience is still limited. Serokell’s work on visible forall, RequiredTypeArguments, namespace-specified imports, and the broader path toward dependent types mostly predates the coding-assistant workflows we use now. Looking at an old difficult patch and asking whether a current model could have produced it would not tell us much.

We therefore would not use our own GHC work as evidence that AI changes compiler development. We do not have enough experience yet.

Our view

We think the current policy is reasonable.

GHC has more than 6,500 open tickets, limited maintainer time, and a large amount of useful work that does not attract enough volunteers. Coding assistants will not solve that backlog. A ban would not solve the underlying shortage either.

The bar for a contribution should stay where it is. A contributor needs to understand a patch well enough to explain its design and convince a reviewer that it belongs in GHC. Using a model does not move that responsibility to the reviewer.

The policy leaves maintainers plenty of room to reject poor assisted work. A large patch from someone who cannot explain it is a bad contribution. So is a polished-looking Note whose author does not understand the invariant it describes. Using a model to reproduce an old bug, reduce a test case, build a benchmark, or explore a compiler problem is different: the tool does not make the resulting work less useful by itself.

The standard stays ordinary: the contributor understands the work, the patch is reviewable, and the change improves GHC without adding more maintenance debt than it removes.