{"slug": "ai-contributions-to-ghc", "title": "AI Contributions to GHC", "summary": "GHC has adopted a formal policy for LLM-assisted contributions, built on the document Simon Peyton Jones developed through the ghc-devs discussion rather than the competing \"shared statement\" proposed in July. The policy sets four points plus one strong preference: prioritize people and community (P1), make merge requests easy to review (P2), require an identifiable human author who takes full responsibility for every line of code and documentation (P3), and disclose any direct LLM generation of code, documentation or tests (P4), with writing the final version yourself remaining a preference (P5). The policy matters because GHC carries more than 6,500 open tickets and maintainers such as Julian Ospald and Andreas Klebinger were already citing it in review discussions by mid-October, framing the practical problem as reviewer cost.", "body_md": "## What contributors can do, what they must disclose, and why we think the policy is reasonable.\n\nGHC 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”.\n\nThe [GHC wiki page](https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing/AI) itself predates this summer’s debate, so the URL alone does not show what changed. The current text does.\n\nThe 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.\n\nThe 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.\n\nWe 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.\n\nFor 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.\n\nGHC 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.\n\n## **What the policy says**\n\n**What the policy says**\n\nThe 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.\n\nThere are four policy points and one strong preference.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\nLLM-assisted reviews follow the same rules. The document also uses “LLM” broadly enough to cover future systems that play the same role, including agents.\n\n## **What changed from the draft**\n\n**What changed from the draft**\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\n## **Review is the scarce resource**\n\n**Review is the scarce resource**\n\nMaintainer time is the main constraint.\n\nGHC 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.\n\nLLVM calls one version of this an [**extractive contribution**](https://llvm.org/docs/AIToolPolicy.html), 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.\n\nThe problem predates LLMs. Anyone could submit a 2,000-line patch they barely understood. Generating one is now much easier.\n\nCommercial development shows a similar pattern. [Faros](https://www.faros.ai/blog/ai-software-engineering) 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.\n\nGHC 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.\n\nMaintenance has the same dependency on context. Six months after a merge, the important question is whether anyone understands why a line exists.\n\n## **What about growing new maintainers?**\n\n**What about growing new maintainers?**\n\nOpen-source contributions also train future maintainers.\n\nSmall 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.\n\nLoris Cro calls this [**contributor poker**](https://kristoff.it/blog/contributor-poker-and-ai/) 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.\n\nLLVM 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.\n\nThis 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.\n\nThe 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.\n\n## **A ban is hard to police**\n\n**A ban is hard to police**\n\nOpenJDK took a stricter route. Its [interim AI policy](https://openjdk.org/legal/ai) excludes contributed material generated in whole or in part by LLMs, while still allowing private use for code comprehension, research, debugging, and review.\n\nOpenJDK also acknowledges the enforcement problem: reliably distinguishing generated content from human-written content is generally impossible.\n\nThe 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.\n\nGHC takes a different route. Disclosure gives reviewers context but does not automatically disqualify the contribution.\n\nOther 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.\n\nThe Linux kernel has explicit [guidance for coding assistants](https://docs.kernel.org/process/coding-assistants.html). 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.\n\nFunctional-language projects disagree as well. [OCaml](https://github.com/ocaml/ocaml/blob/trunk/AI.md) 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](https://github.com/agda/agda/pull/8456).\n\nGHC did not have an established community standard to copy.\n\nSome 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.\n\nProjects 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.\n\n## **Policies age too**\n\n**Policies age too**\n\nRules tied closely to the current quality of models can become obsolete quickly.\n\nQEMU 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.\n\nThe 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.\n\ncurl 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%.\n\ncurl 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”](https://daniel.haxx.se/blog/2026/04/22/) 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%.\n\nWithin 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.\n\nA rule based mainly on the claim that current tools produce bad output will need frequent revision.\n\nBroad 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.\n\nThere 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.\n\nZig’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.\n\n## **Speed isn’t very informative here**\n\n**Speed isn’t very informative here**\n\nCoding-assistant discussions often reduce productivity to a percentage: 20% faster, twice as many tasks, some number of extra pull requests.\n\nThose 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.\n\nFor the GHC backlog, it is often more useful to ask whether the task would have been done at all.\n\nTake 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.\n\nGHC 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.\n\nSome 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.\n\n## **Coercion zapping**\n\n**Coercion zapping**\n\nPrograms 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.\n\nIn July, Sylvain Henry produced a proof of concept using Claude Fable. The [Well-Typed report](https://www.well-typed.com/blog/2026/09/haskell-ecosystem-report-june-august-2026/) 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.\n\nSam Derbyshire then rewrote the implementation from the ground up and continued the investigation, finding further optimisations in GHC’s type-family rewriter.\n\nThe 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.\n\nThere 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.\n\nAI 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.\n\nOur 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.\n\nWe therefore would not use our own GHC work as evidence that AI changes compiler development. We do not have enough experience yet.\n\n## **Our view**\n\n**Our view**\n\nWe think the current policy is reasonable.\n\nGHC 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.", "url": "https://wpnews.pro/news/ai-contributions-to-ghc", "canonical_source": "https://serokell.io/blog/ai-contributions-to-ghc", "published_at": "2026-10-29 17:42:30+00:00", "updated_at": "2026-10-29 19:19:45.219938+00:00", "lang": "en", "topics": ["ai-policy", "ai-ethics", "large-language-models", "developer-tools"], "entities": ["GHC", "Simon Peyton Jones", "Julian Ospald", "Andreas Klebinger", "Teo Camarasu", "Vladislav Zavialov", "Andrei Borzenkov", "Serokell"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-contributions-to-ghc", "markdown": "https://wpnews.pro/news/ai-contributions-to-ghc.md", "text": "https://wpnews.pro/news/ai-contributions-to-ghc.txt", "jsonld": "https://wpnews.pro/news/ai-contributions-to-ghc.jsonld"}}