AI Contributions to GHC

Comments

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 Note s 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. Z