Five Rust teams have adopted an LLM contribution policy written by Jynn Nelson, a longtime Rust maintainer and compiler team lead at Ferrous Systems, giving reviewers explicit rules for handling AI-generated code and text in the rust-lang/rust
monorepo.
The compiler, libraries, types, rustdoc and bootstrap teams, along with their subteams, recently approved the rules, Nelson wrote in an Inside Rust post published August 5th. The policy does not govern the entire Rust project. Teams including language and edition remain free to set their own practices, and repositories outside the main Rust monorepo fall outside its scope.
Nelson has spent years working on the parts of Rust where technical decisions and contributor governance collide. Their resume credits them with leading rustdoc and docs.rs, founding Rust's bootstrap team, recruiting maintainers and reducing rustdoc's compile time by a factor of nine. Before joining Ferrous Systems in September 2025, Nelson worked on compilers, databases and network infrastructure at YottaDB, TCDI, Redjack and Cloudflare.
That background shaped a policy focused on maintainership rather than a broad judgment about AI. Nelson's concern is that generated output has weakened signals open-source reviewers once used to decide where to invest their time. A polished pull request may represent days of careful work by an aspiring maintainer. It may also be output that its submitter cannot explain, revise or support after it merges.
Nelson's governance fix
The public announcement arrived on August 5th, but the policy was built over several months. The Rust Forge proposal opened on April 17th after extensive private and public debate. Its discussion record says the preceding Rust Zulip conversations had generated upwards of 3,000 messages, excluding the subsequent GitHub debate.
Nelson framed the work as a response to inconsistent enforcement. Rust reviewers had already encountered dozens of LLM-assisted pull requests, including first-time contributions proposing risky compiler optimizations. Moderators had no common disclosure rule, leaving contributors to discover expectations after a reviewer closed their work.
The published LLM usage policy gives both sides a written standard. Its working summary is concise: "It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create."
Private AI assistance is generally allowed. Contributors can ask a model questions about the codebase, summarize discussions for personal use, privately review their work or generate possible approaches before writing their own solution. The rules also permit contributors to use LLMs to find bugs if a human verifies the result and discloses the model's involvement when reporting it.
Public output faces tighter controls. Contributors cannot submit comments, issue bodies, pull-request descriptions, documentation, compiler diagnostics or substantial source comments originally created by an LLM as their own writing. Clearly marked quotations are permitted when the surrounding contribution stands on its own. Machine translation, trivial edits and AI-assisted reviews are conditionally allowed with disclosure.
The distinction puts responsibility on the contributor. A model may help someone think, inspect or translate. The human still has to make the argument, understand the change and remain accountable to the reviewer.
AI-generated code gets an experimental lane
Rust's rules stop short of banning generated code. They create a controlled experiment with a higher entry bar than the ordinary contribution process.
An LLM-created change must be arranged with a willing reviewer before the pull request is opened. It must avoid soundness-critical areas, meet the codebase's quality standards, include tests and be understood by both its author and reviewer. New contributors cannot submit generated code first and search for a reviewer afterward.
Accepted submissions receive an ai-assisted
label and are posted to a private Zulip channel accessible to members of the Rust organization. That channel is intended to collect evidence about whether contributors are learning, returning with further work and producing changes worth maintaining. Reviewers can decline AI-assisted pull requests, and an LLM review cannot replace human approval or an author's own review.
The policy also contains a numerical circuit breaker. If LLM-created changes exceed 50% of all pull requests merged during a rolling six-week period, Rust will further AI-generated merges until the share falls below that threshold. The cooldown lasts at least 10 days.
That limit is deliberately conservative and may prove largely theoretical. It makes Rust's underlying priority explicit: generated submissions cannot be allowed to consume the codebase or make AI tools a practical requirement for participation.
The scarce resource is reviewer judgment
Nelson reported 1,281 open pull requests in rust-lang/rust
at the time of the announcement. The figure is a snapshot, but it captures the asymmetry driving the policy. AI systems can increase the supply of code far faster than an open-source project can recruit experienced people to evaluate architectural choices, long-term maintenance costs and safety implications.
Review work in a compiler rarely ends with locating a faulty line. Maintainers have to decide whether a proposed direction belongs in Rust, how it interacts with other compiler components and who will understand the change months later. Generated code lowers the cost of presenting a plausible implementation without lowering the cost of making those decisions.
The policy also addresses a more immediate breakdown in collaboration: contributors feeding review comments into an LLM and pasting its response back into GitHub. Nelson argues that reviewers are asking for the author's reasoning. Machine-generated replies leave maintainers unsure whether they are working with someone who understands the patch or merely relaying messages between a reviewer and a model.
Rust's answer is to attach contribution rights to human understanding. The policy does not ask reviewers to detect AI-written code by style, and it warns them against making public accusations based on suspicion. Authors must disclose their use. Suspected dishonesty goes through moderation rather than an argument inside the pull request.
A local compromise, for now
The narrow scope reflects how Rust makes decisions. The project operates through consensus across teams with different responsibilities and views on AI. Nelson wrote that some contributors see practical value in these tools, while others object to their technical, social or environmental costs. The adopted policy works from shared concerns about expertise, inclusion and reviewer capacity.
A project-wide answer remains unsettled. A July 14th program management update said Rust's Leadership Council was discussing an LLM committee that could write and revise broader rules. The proposal called for four or five members representing differing views across the project.
Until that governance work advances, Nelson's policy gives the busiest parts of Rust's central repository a practical operating model. It preserves room for experiments while making the submitter carry the cost of proving that generated work deserves scarce reviewer attention. That trade is likely to become familiar across open source as code generation gets cheaper and maintainership remains stubbornly human.