Rust 프로젝트, LLM 기여 정책 도입

Aug. 5, 2026 · Jynn Nelson Recently, five teams in the Rust project adopted a policy that I originally authored, governing how Large Language Models can be used when contributing to the rust-lang/rust monorepo. Notably, the new policy is not an official stance on LLMs, and does not apply everywhere in the Rust project. I wrote it for a very specific purpose, described below. This post talks about why we created that policy, what it says, and how this will affect contributors. The policy affects the following groups of people: People who review or moderate PRs on rust-lang/rust . People who author PRs with LLM-generated code on rust-lang/rust . People who discover issues using LLMs and post them on rust-lang/rust . People who write issues or comments that directly quote an LLM on rust-lang/rust . If you are not in one of those groups, you don't have to change anything about how you work. Why was this policy created? While the Rust project is a collection of technical artifacts, it is also a community of people who work together to build, maintain, and extend those artifacts. When we talk about "contributing to the Rust project", we partly mean work on those artifacts, but we also mean joining that community and collaborating with the people already there. Even before this policy was created, people were using LLMs to contribute to rust-lang/rust . Some of those uses respected our community: translating messages to English so people could draft them in their native language; finding poor diagnostics for code snippets that new contributors to Rust might write; analyzing RFCs to see if they were missing a discussion of other parts of the language that could affect the design. Some of those uses, sometimes unintentionally, did not. I've seen LLMs causing three main issues for our community: Polished technical products no longer indicate effort and understanding. Making code easier to write exacerbates our existing issues with review bandwidth. People mechanically copy-pasting to and from an LLM is a waste of our time. As time went on, these issues grew and grew, until we had to create dedicated channels and moderation policy for how to deal with them. However, those channels work against our goals of being transparent and welcoming, because new contributors have no idea what the rules are. The new policy formalizes those rules publicly, so that new contributors know how to join our community without getting their PRs closed for reasons they don't understand, and so that existing reviewers can easily point to the rules as an actionable reason when closing PRs that don't follow them. Technical products no longer indicate effort It used to be that if an open source project got a polished, well-tested, detailed PR, that indicated that there was someone on the other end who had put time, effort, and understanding into the PR. That influenced Rust's culture in several ways: We are generally reluctant to close PRs, since they represent someone else's hard work. Our process emphasizes incremental discussions, where PRs are allowed to change existing design if we discover new facts during creation or review. We treat PRs as an indication that someone is interested in joining our community and being mentored to work on future PRs. With LLMs, none of these signals are reliable. Polished PRs no longer indicate effort; authors of polished PRs no longer necessarily understand their code—and in the case of autonomous agents, there is no longer someone on the other end at all; and because it's become so much easier to write code, a polished PR no longer indicates that someone is likely to stick around for the long term. Making code easier to write causes review issues At the time of writing, there are 1,281 open PRs to rust-lang/rust . This represents a staggering amount of time invested by both authors and reviewers. We have long had the problem that there are more people who want to write code than people willing to review it. With the advent of LLMs, this problem only gets worse. Most of the work of reviewing is not simply catching bugs. A great deal of it is deciding whether this direction is a good approach , whether the PR is a good idea at all. In other words, reviewing is made of decisions . "Shotgunning" PRs at reviewers incurs a high mental cost for them. I think most authors of LLM PRs believe that they are sincerely helping, but from our perspective, the code itself is the smallest and in some ways least important part of the change. We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like. The code itself cannot help with any of those. Mechanically copy-pasting LLM output is a waste of time We will often get people who respond to review comments by copy-pasting them into their LLM, then copy-pasting its response back onto GitHub. Bluntly: this is a waste of everyone's time . If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine's. Moreover, this is a breach of trust between the reviewer and the author. Our assumption when we review is that we're talking to a real person who wants to do their best work. Pasting LLM text creates suspicion: does the author actually care? Is there a person here at all? So why a policy? Before this policy, we had a "wild west" approach to moderation. We had dozens of LLM PRs; no disclosure rules; people trying to add risky MIR optimizations as their first PR; and people posting "Verification: git diff --check " in their PR description as if that did something. While we had something for moderators to point to in the form of "Empower reviewers to reject burdensome PRs" , our enforcement was inconsistent and our rules were not published anywhere. In practice, the rule was "anything goes, as long as it's not obviously horrible". Compared to the previous situation, the new policy is both much more strict and much more clear. Regardless of your opinions on whether LLMs are good, bad, or a secret third thing, they can no longer be ignored . Our choices are not "no policy" or "policy". Our choice is whether to have the policy be an unofficial list of moderation notes or something we stand by publicly. Why not ban LLMs altogether, or allow any use of LLMs that we think are pro-social? Because Rust governance doesn't work that way. We do not have a benevolent dictator who can say "No LLM-generated content, whether it be code or prose." or "AI is a tool, just like other tools we use" . Rust operates by consensus. As the policy says: There is not a consensus within the Rust project—and likely never will be—about when/how/where it is acceptable to use AI-based tools. Many members of the Rust project and community find value in AI; many others feel that its negative impact on society and the climate are severe enough that no use is acceptable. Still others are working out their opinion. Despite these differences, there are many values we all share: Building a community of deep experts in our collective projects. Building an inclusive community where all feel welcome and respected. We want it to be possible to change the policy in the future. The policy has several provisions that make it easier to change than it was to originally adopt. The leadership council is also considering creating a sub-team that would handle LLM policy so we have fewer "nightmare" 30-person approval requirements. I do not think every rule in this policy is wholly good. I do think that writing our rules down is better than not writing them down, and that having a policy that everyone kinda dislikes pushes us to improve our governance structures. What does the policy say? The policy summarizes itself this way: It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create . Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second categor