AI Contributions to GHC

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?