贡献者能做什么，他们必须披露什么，为什么我们认为政策是合理的。
卫生理事会目前有一项具体政策，规定由LLM协助捐款。 到10月中旬，维护者已经在审查讨论中直接提到它：朱利安·奥斯帕德引用了"AI政策"的P3，而安德烈亚斯·克勒宾格(Andreas Klebinger)则将由LLM产生的bug修复描述为"很好，这是政策".
GHC维基页面本身早于今年夏天的辩论，目前的案文确实如此。
该政策遵循的是西蒙·佩顿·琼斯通过ghc-devs讨论编写的文件，而不是7月份提出的相互竞争的“共同声明”。 该声明的作者明确表示，称并非打算取而代之，Teo Camarasu反对将它视为一项贡献政策。
讨论期间结构发生了变化。 7月27日，草案被归纳为三个政策要点和一项建议：使合并请求易于审查，对贡献承担全部责任，宣布直接使用LLM，最好自己写出最终版本。 本文件有四个政策要点和一个强烈的倾向。 " 优先考虑人民和社区 " 现为P1；较早的点移到P2-P4；你自己写出最终版本成为P5，仍然是首选而非要求。
讨论与我们直接有关。 Vladislav Zavialov和Andrei Borzenkov在塞罗凯尔从事GHC方面的工作，Andrei参加了政策讨论。 编码助理也成为我们自己的工程工作流程的一部分。
对GHC来说，实际的问题是审查者成本。 工具辅助工作只有在不让维护者替贡献者思考的情况下才有用。
目前GHC拥有6500多张开通票。 有些是难以编译的问题。 其它的则是常规的，但仍然有用：复制旧报告，减少测试大小写，添加缺失的基准测试，或者检查是否有错误存在。
什么政策称
该政策对总的LLMs是好是坏没有立场。 称明确表明，该项目没有就其成本和效益达成共识。 相反，它界定了对捐款和审查的期望。
有四个政策要点和一个强烈的倾向。
P1：优先考虑人民和社区。 贡献者可能使用LLMs，但与审查者的直接讨论预计将仍然是人。 所产生的案文不应取而代之，取而代之的是缴款国自己的判断。 使用LLM来导航代码库，翻译文本，或调查一个问题是允许的，但该工具不应取代开源项目开发出贡献者和维护者所通过的对话。
P2：使合并请求易于审查。 贡献者为贡献投入的精力要多得多，而审查者需要花费更多的时间来理解它。 MR应有一个明确的目标，一个解释性的设计，有用的例子和测试，并被分成可消化的块。 生成的补丁会编译，但让审查者重建推理不符合此条。
P3：人文著作权与全部责任。 每项贡献都需要一位可以识别的人类作者，他能够理解并解释每一行代码和提交审查的每句话。 如果提供方已仔细审查这些材料，以承担责任，则允许制作材料。 由于一个有用的bug报告可能来自不理解基本编译器故障的人，所以对出票的处理较为松散。 如果MRs草稿被明确标为草稿而尚未要求维护者进行审查，那么它也可能包含未完成或产生的工作。
P4：宣布直接LLM生成。 如果LLM生成了代码的任何部分、文件、测试或其他提交审查的材料，则必须披露这种用途。 贡献者不需要为每次互动发布提示或说明。 私人用于勘探，调试，或设计理念不需要披露，尽管政策鼓励披露。 对于提交的材料，声明应当在问题或MR描述和承诺信息中可见，通常带有辅助-By：行。
P5：最好自己写出最终版本。 仍然允许生成代码。 文件认为，重写最终版本往往是最简单的方法，可以确保贡献者通过每行思考，使补丁保持小，并去掉不必要的道词。 GHC 指出尤其受关注，因为它们保留了多年后可能很重要的建筑推理。 生成的材料如果经过仔细审查和修订，足以满足P3的要求，仍可提交。
LLM协助审查遵循同样的规则。 该文件还广泛使用“LLM”来涵盖今后发挥同样作用的系统，包括agents。
A. 草案的改变
最终政策保持了西蒙草案的中心地位：允许援助性贡献，必须披露直接生成，责任由人类贡献者承担。
主要的结构变化是社区成为其自身的政策点。 7月的草案已经讨论了人类对话与贡献者社区的健康；目前的文件向P1宣传了这一关切，并将下面的业务规则重新编号。
自己写最终版本的建议也幸免于难。 一些与会者在讨论期间认为，这一点应有所缓和。 最后案文保留了强有力的措辞，但明确指出了边界：五常是一种偏好。 贡献是根据政策要点来判断的，而不是根据一个人是否为每个角色打字。
因此，这项政策避免试图解决关于LLMs的更宽泛的争论。 它界定了一笔捐款准备消耗审查人员时间的条件。
审查是稀缺的资源
维护者的时间是主要的制约因素。
GHC已经比人们有更多的工作等待审查。 如果审查费用增加，廉价补丁的生成就无济于事了。 20分钟内生产的补丁仍需要维护者2小时才能理解。
LLVM称这个计划是一个采掘性贡献，借用Nadia Eghbal在公共场合工作的想法：
问题早于LLMs. 任何人都可以提交2000行补丁他们几乎不理解。 生成一个现在容易得多。
商业开发显示是类似模式。 法洛斯发现，AI采用更重的团队产生更多和更大的拉力请求，而审查时间也有所增加。 数据是观测性的，一个企业工程组织并不直接与GHC相比，但瓶颈是一样的：代码制作只是开发过程的一部分。
GHC审查也在很大程度上取决于项目历史。 一个补丁可能孤立地看起来是正确的，同时与四年前的提议相矛盾，重新引入了老的性能回归，或者使计划中的编译器更难改变。 人类贡献者在对周围历史了解不足时，可以犯下完全相同的错误。 LLMs主要减少某人需要的上下文量，然后才能产生出看起来可信的东西。
扶养同样依赖上下文。 合并后六个月，重要的问题是是否有人理解为何存在一行。
新的维护者呢？
开源捐款也培养了未来的维护者。
小问题有用，部分原因是捐助者必须努力解决这些问题。 一位评论员解释了显而易见的解决方案为何失败，贡献者学习了系统的另一部分，经过足够的迭代，最终可能会审查其他人的工作。
Loris Cro在解释Zig的政策时称这个贡献者为扑克。 维护者时间是一种投资，而Zig更喜欢花在可能留在项目上的人身上，而不是花在用LLM便宜出品的行走补丁上。
LLVM取狭义的同位相去。 其政策不允许AI工具解决好的第一问题任务，因为这些任务旨在向人们介绍项目。
当产生的补丁取代其他贡献者或消耗相当一部分审查者注意力时，这就会成为一个真正的问题。 我们今天在GHC没有看到多少这方面的证据。 这个项目的评审员短缺，但并没有大量质量低劣的LLM提交书与大量人类贡献者争夺同一张门票。
如果政策开始实行，可以加强。 今天，全面禁止将针对一个全球健康中心尚未发现的规模问题。
禁令对警察来说很难
OpenJDK采取了更严格的路线。 它的临时AI政策排除了全部或部分由LLMs生成的贡献材料，同时仍然允许私人用于代码理解，研究，调试和审查。
OpenJDK也承认执行问题：可靠地区分生成的内容和人文内容一般是不可能的。
该规则仍然可以达到目的。 一个项目可能需要明确的规范，或可能存在法律和出处方面的关切，因而有理由划定更严格的边界。 实际奖励不太整齐：公布模型用途的缴款人可以立即被拒绝，而私下使用同一工具的另一缴款人和称可能没有什么是无法区分的。
GHC采取不同的路线。 披露提供了审查人员的背景，但并不自动取消缴款的资格。
其他项目作出了不同的选择。 海合会拒绝含有或来源于所生成材料的有法律意义的贡献，同时允许大赦国际进行调查和审查。 当人检查结果并承担责任时，LLVM接受辅助贡献。 GraalVM期望提交者能够很好地理解变化，从而对审查者做出回答，并在事后维持。
Linux内核对编码助理有明确的指导。 允许AI协助捐款。 人类贡献者审查该守则，承担其责任并认证DCO；援助用辅助标记记录。
功能语言项目也存在分歧。 OCaml允许AI在条件下协助捐款，并要求当很大一部分捐款产生时予以披露。 克洛珠拒绝LLM生成的代码。 阿格达就全面禁止募捐的问题进行了辩论，但该提案未获通过而结束。
GHC没有既定的社区标准可以复制。
某些更严格的立场是出于法律考虑。 海合会将捐款划入 " 有法律意义 " 的范畴，因为FSF的许可声称取决于明确的出处。 OpenJDK也指出了关于贡献材料所有权的出资协议要求。 全球健康中心的讨论于8月达成同一问题，当时一个捐款方要求哈斯凯尔基金会为关于模式提供者放弃内容权利是否会拖延的法律咨询意见提供资金。 委员会拒绝，认为这个问题不是Haskell特有问题，尚未在法庭上得到充分检验。
拥有版权转让或贡献协议的项目有更强烈的理由在这里保守。 GHC使用不同的许可模式，并选择了不同的平衡。
政策年龄
与目前模型质量密切相关的规则可能很快被淘汰。
QEMU是一个有用的例子。 其公布的政策仍然拒绝AI产生的贡献，但保罗·邦齐尼一直致力于更换。 5月，他辩称，LLM输出若不进行实质性重写，则禁用就比较容易说明理由。 至9月，该提案已扩展为更广泛的政策，其中包括对在储存库内运作的AI agents的指示。
接班人还在讨论中，布
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
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, bu
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.