According to the Rust project blog, five teams within the rust‑lang/rust monorepo have adopted a policy that governs how large language models may be used when contributing to the codebase. The policy was originally authored by a contributor and is not an official project‑wide stance; it applies only to specific groups involved with the rust‑lang/rust repository.
The blog post explains that the policy was created because the project observed three main issues stemming from LLM use. First, polished technical contributions no longer reliably signal the author’s effort or understanding, which undermines the project’s culture of treating pull requests as indicators of interest and potential mentorship. Second, the ease of generating code with LLMs exacerbates existing review bandwidth problems, as the project currently has 1,281 open pull requests, representing a substantial workload for both authors and reviewers. Third, the practice of copying review comments into an LLM and pasting the model’s response back onto GitHub is described as a waste of time and a breach of trust, because reviewers expect to engage with a human author.
Prior to the policy, the project relied on an informal, inconsistent approach to moderation, with no public disclosure rules for LLM‑generated content. The new policy formalizes those practices so that newcomers can understand expectations and reviewers can point to a clear standard when closing pull requests that do not comply.
The policy distinguishes between two categories of LLM use. Uses such as answering questions, analyzing code, distilling information, refining suggestions, checking work, and reviewing are allowed, sometimes requiring disclosure. In contrast, using LLMs to create contributions—such as generating code or prose that is submitted directly to the repository—is heavily restricted. The blog notes that the policy does not seek to ban LLMs outright or to permit all pro‑social uses, because Rust governance operates by consensus and there is no universal agreement on the appropriateness of AI‑based tools.
The post emphasizes that the policy is intended to be mutable. It includes provisions designed to make future changes easier, and the project’s leadership council is considering forming a sub‑team to handle LLM policy, thereby reducing the need for large‑group approvals. The author states that while not every rule may be wholly beneficial, having the rules written down is preferable to having none, and that a broadly disliked policy can drive improvements in governance.
Those who do not review or moderate pull requests, author pull requests with LLM‑generated code, discover issues using LLMs and post them, or write issues or comments that directly quote an LLM are not required to change their workflow under the new policy.