GHC Adopts LLM-Assisted Contribution Policy, Requiring Human Authors to Explain Every Line of Code

In October 2026, the GHC project adopted a specific policy document that explicitly allows LLM-assisted code contributions while requiring human authors to be able to explain every line of code and documentation. The policy document was drafted by Simon Peyton Jones and finalized after discussion on the ghc-devs mailing list, with the first priority being “people and community first.”

Four Core Requirements of the Policy

The first point requires that direct communication between contributors and reviewers remain human-led, and that LLM-generated text must not replace individual judgment. The second point requires merge requests to be easy to review; contributors need to invest effort far beyond what is needed for reviewers to understand, including clear goals, design explanations, examples, and tests. The third point establishes human authorship and full responsibility: any identifiable human must be able to explain every line of code. The fourth point requires disclosure of direct use of LLM generation. The fifth point is a strong preference—contributors should ideally write the final version themselves—but it is not mandatory.

The policy document explicitly states that the project has no consensus on the overall benefits and drawbacks of LLMs, so it only defines expectations for contribution and review.

Review Costs Become a Practical Constraint

GHC currently has more than 6,500 open tickets, some involving complex compiler issues and others routine but useful tasks. Policymakers noted that cheaply generated patches provide no benefit if they increase the review burden. A patch generated in 20 minutes can still consume hours of maintainer time to reconstruct the reasoning process. An April 2025 article on Well-Typed.com documented that when developers used tools such as Cursor and Claude-3.7-sonnet on GHC and Cabal tasks, they needed to combine them with the Haskell Language Server to provide context in order to get effective feedback.

Differences from Other Projects

Explainx.ai summarized that OpenJDK, Zig, Clojure, and QEMU currently restrict or prohibit AI-generated code, while GHC chooses to allow it with additional disclosure and accountability requirements. The policy does not apply to ticket reports; initial merge requests may include unfinished or generated content as long as it is clearly marked.

Deeper Mechanism Analysis

The policy adjustment stemmed from community debate in summer 2026. An early draft was summarized as a three-point policy plus one recommendation, and later evolved into a four-point policy plus one strong preference. The authors of the original “shared statement” explicitly stated that it was not a contribution policy, so it was not adopted. The actual driving factor is the scarcity of maintainer time; the policy reduces downstream review costs by increasing contributors' upfront investment, rather than making a value judgment about LLM technology itself.

Industry Impact Assessment

The policy provides a replicable template for other Haskell-related open-source projects: allow tool use while locking down the boundaries of human responsibility. At the implementation level, whether the tool can actually be enforced depends on whether contributors can explain the logic of changes to reviewers in human language. On cost-benefit grounds, under the same review effect, increased upfront investment by contributors can reduce total maintainer time consumption. The policy does not promise that LLMs will necessarily increase productivity; instead, it filters low-quality generated content through disclosure and accountability mechanisms.

Independent Judgment: At the current stage, GHC's policy balances tool usability and community sustainability; its effect depends on whether reviewers' actual time investment declines in subsequent implementation.