Rust draws a line for LLM contributions: assistance is allowed, responsibility is not outsourced

Rust’s new rule can be reduced to one sentence: an LLM may answer, analyze, distill, check, and suggest, but it should not “create” a contribution on your behalf. The important point is not that Rust said no to AI. It is that the project has made a cost that is easy to ignore visible: generating code is getting cheaper, while human review is not.

On August 5, the Inside Rust Blog explained that five teams in the rust-lang/rust monorepo had adopted an LLM usage policy. It covers authors of LLM-generated pull requests, issue reporters, reviewers, and people who place model output directly into issues, PR descriptions, or GitHub comments. It is not an official stance for the entire Rust project and does not apply to every repository; its scope is limited to the teams and subteams that ratified it. The original explanation and the full policy are available at Inside Rust Blog and Rust Forge.

The target is review debt, not the tool

Jynn Nelson’s explanation is concrete. At the time of writing, rust-lang/rust had 1,281 open pull requests. The project already faced a persistent imbalance: more people wanted to write code than people were willing to review it. LLMs make it easier to produce a PR that looks complete, tested, and polished, but they do not solve the harder questions of direction, long-term maintenance, or whether the author actually understands the code.

The policy therefore separates private assistance from public contribution. Model output seen only by the user is generally allowed: asking questions about a codebase, summarizing discussions, privately reviewing code, or learning from a possible solution before writing the change in one’s own way. Public LLM text must be disclosed. LLM-created PR descriptions, GitHub comments, public documentation, diagnostics, and policies that make an LLM review a substitute for human judgment are banned. Machine translation, trivial changes, bug discovery, and review bots may be used under conditions, with disclosure.

The sharpest point is this: authors cannot force other people to pay the cost of reading model output. Reviewers may decline to look at an LLM-generated PR. An LLM review can only be advisory, never sufficient by itself to merge or reject a change. Authors still have to self-review and remain responsible for the contribution.

Generated code is not banned outright, but the bar is higher

Rust keeps an experimental path. Code originally generated by an LLM may enter review only when several conditions are met: a project member has agreed in advance to review it, the change is non-critical, the code is high quality, testing is thorough, the author and reviewer understand the change, and model use is disclosed. Such pull requests also receive an ai-assisted label.

The testing requirement is stricter than ordinary expectations. If an area has no existing test suite, the author must add one or close the PR; “the tests are hard to write” is not an exception. Soundness-related areas, public documentation, and diagnostics must be written by humans. The Rust compiler development guide also asks contributors to write their own PR descriptions, comments, commit messages, and LLM disclosures, and to reread the whole diff before opening a PR rather than relying on the conversation with an agent.

The policy includes a circuit breaker. If more than half of merged pull requests in a six-week window are LLM-created, new LLM-created PRs are paused until the share falls below 50%, with a cooldown of at least ten days. This is not a benchmark of model intelligence; it is a guard on the community’s review capacity.

My take: the bottleneck is shifting from writing to accountability

Rust has neither treated LLMs as a simple productivity plug-in nor imposed a blanket ban. It breaks the problem into operational questions: who saw the model output, who made the consequential judgment, and who can explain the result when something goes wrong. That is more useful than debating whether AI-written code “counts” as code.

For a large open-source project, code is only one part of a contribution. Direction, evidence, tests, explanation, and future maintenance are where reviewers spend their time. A model can increase the number of submissions while moving the cost of understanding onto a small group of maintainers. Rust’s answer is clear: tools may improve quality, but they may not dilute responsibility.

When generation is no longer scarce, the scarce resource is the person willing to sign their name to the code.