Rust 컴파일러, LLM 기여에 대한 공식 정책 수립

rust-lang / rust-forge Public Notifications You must be signed in to change notification settings Fork 233 Star 538 Conversation Copy link Copy Markdown Member jyn514 commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page . FCP link this comment Summary This document establishes a policy for how LLMs can be used when contributing to rust-lang/rust . Subtrees, submodules, and dependencies from crates.io are not in scope. Other repositories in the rust-lang organization are not in scope. This policy is intended to live in Forge as a living document, not as a dead RFC. It will be linked from CONTRIBUTING.md in rust-lang/rust as well as from the rustc- and std-dev-guides. Moderation guidelines This PR is preceded by an enormous amount of discussion on Zulip . Almost every conceivable angle has been discussed to death; there have been upwards of 3000 messages, not even counting discussion on GitHub. We initially doubted whether we could reach consensus at all. Therefore, we ask to bound the scope of this PR specifically to the policy itself. In particular, we mark several topics as out of scope below. We still consider these topics to be important, we simply do not believe this is the right place to discuss them. No comment on this PR may mention the following topics: Long-term social or economic impact of LLMs The environmental impact of LLMs Anything to do with the copyright status of LLM output Moral judgements about people who use LLMs We have asked the moderation team to help us enforce these rules. Feedback guidelines We are aware that parts of this policy will make some people very unhappy. As you are reading, we ask you to consider the following. Can you think of a concrete improvement to the policy that addresses your concern? Consider: Whether your change will make the policy harder to moderate Whether your change will make it harder to come to a consensus Does your concern need to be addressed before merging or can it be addressed in a follow-up? Keep in mind the cost of not creating a policy. If your concern is for yourself or for your team What are the specific parts of your workflow that will be disrupted? In particular we are only interested in workflows involving rust-lang/rust . Other repositories are not affected by this policy and are therefore not in scope. Can you live with the disruption? Is it worth blocking the policy over? Previous versions of this document were discussed on Zulip, and we have made edits in responses to suggestions there. Motivation Many people find LLM-generated code and writing deeply unpleasant to read or review. Many people find LLMs to be a significant aid to learning and discovery. rust-lang/rust is currently dealing with a deluge of low-effort "slop" PRs primarily authored by LLMs. Having a policy makes these easier to moderate, without having to take every single instance on a case-by-case basis. This policy is not intended as a debate over whether LLMs are a good or bad idea, nor over the long-term impact of LLMs. It is only intended to set out the future policy of rust-lang/rust itself. Drawbacks This bans some valid usages of LLMs. We intentionally err on the side of banning too much rather than too little in order to make the policy easy to understand and moderate. This intentionally does not address the moral, social, and environmental impacts of LLMs. These topics have been extensively discussed on Zulip without reaching consensus, but this policy is relevant regardless of the outcome of these discussions. This intentionally does not attempt to set a project-wide policy. We have attempted to come to a consensus for upwards of a month without significant progress. We are cutting our losses so we can have something rather than adhoc moderation decisions. This intentionally does not apply to subtrees of rust-lang/rust. We don't have the same moderation issues there, so we don't have time pressure to set a policy in the same way. Rationale and alternatives We could create a project-wide policy, rather than scoping it to rust-lang/rust . This has the advantage that everyone knows what the policy is everywhere, and that it's easy to make things part of the mono-repo at a later date. It has the disadvantage that we think it is nigh-impossible to get everyone to agree. There are also reasons for teams to have different policies; for example, the standard for correctness is much higher within the compiler than within Clippy. We could have different standards for people in the Rust project than for new contributors. That would make moderation much easier, and allow us to experiment with additional LLM use. However, it reinforces existing power structures, creates more of a gap between authors and reviewers, and feels "unfriendly" to new contributors. We could have a more lenient policy that allows "responsible and appropriate" use of LLMs. This raises the question of what "responsible and appropriate" means. The usual suggestion is "self-review, and judging the change by the same standard as any other change"; but this neglects the reputational and social harm of work that "feels" LLM generated. It also makes our moderation policy much harder to understand, and increases the likelihood of re-litigating each moderation decision. We could have a more strict policy that removes the threshold of originality condition. This has the advantage that our policy becomes easier to moderate and understand. It has the disadvantage that it becomes easy for people to intend to follow the policy, but be put in a position where their only choices are to either discard the PR altogether, rewrite it from scratch, or tell "white lies" about whether an LLM was involved. We could have a more strict policy that bans LLMs altogether. It seems unlikely we will be able to agree on this, and we believe attempting it will cause many people to leave the project. Prior art This prior art section is taken almost entirely from Jane Lusby's summary of her research , although we have taken the liberty of moving the Rust project's prior art to the top. We thank her for her help. Rust Moderation team's spam policy Compiler team's "burdensome PRs" policy Other organizations These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly. full ban postmarketOS - also explicitly bans encouraging others to use AI for solving problems related to postmarketOS - multi point ethics based rational with citations included zig philosophical, cites Profession (novella) rooted in concerns around the construction and origins of original thought servo more pragmatic, directly lists concerns around ai, fairly concise qemu pragmatic, focuses on copyright and licensing concerns explicitly allows AI for exploring api, debugging, and other non generative assistance, other policies do not explicitly ban this or mention it in any way allowed with supervision, human is ultimately responsible scipy strict attribution policy including name of model llvm blender linux kernel quite concise but otherwise seems the same as many in this category mesa framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors. Understand the code you write at least well enough to be able to explain why your changes are beneficial to the project. forgejo bans AI for review, does not explicitly require contributors to understand code generated by ai. One could interpret the "accountability for contribution lies with contributor even if AI is used" line as implying this requirement, though their version seems poorly worded imo. firefox ghostty pro-AI but views "bad users" as the source of issues with it and the only reason for what ghostty considers a "strict AI policy" fedora clearly inspired and is cited