Rust has topped Stack Overflow's most-admired language survey for nine consecutive years. It's also become an increasingly attractive target for LLM-assisted development. The borrow checker and strict compiler that make Rust appealing for safety-critical systems also give LLMs an immediate feedback loop that other languages don't. The compiler catches errors the LLM introduces, which makes AI-assisted Rust development more reliable than in permissive languages where bad output can silently compile and ship.

That dynamic puts rust-lang/rust in an uncomfortable position. The same compiler strictness that makes Rust a compelling target for AI-assisted development is drawing a wave of low-effort LLM-generated PRs to the project's own repository, and the maintainers are dealing with the cost of reviewing them.

The Rust project is moving toward a formal policy on LLM use in rust-lang/rust contributions, following more than a month of internal debate that generated upwards of 3,000 messages on Zulip before culminating in a public GitHub pull request.

The proposed policy, submitted to rust-forge by contributor Jynn Nelson, is under active discussion in a pull request. It takes a deliberately conservative position: LLMs are fine for reading, analyzing, and learning from code, but not for creating it. The distinction the policy draws is between using LLMs as a thinking aid versus using them to generate output that gets committed to the repository.

The allowed list includes asking an LLM questions about the codebase, having it summarize issues or PRs for your own use, using it to privately review your own code before posting, and generating possible solutions to study before writing your own implementation from scratch. Writing dev tools for personal use is also permitted, as long as they don't get merged upstream.

The banned list is shorter but covers the most common problem areas: comments or PR descriptions written by an LLM, documentation and compiler diagnostics originally authored by an LLM, and any workflow where an LLM review is treated as sufficient grounds to merge or reject a change.

A middle category, disclosed, case-by-case use, includes machine translation, trivial code changes that don't meet a threshold of originality, and LLM-powered review bots. Review bots are allowed with significant constraints: they must operate from a separate GitHub account, must be blockable by individual users, cannot post verbatim LLM output on a personal account, and their comments cannot be blocking without explicit endorsement from the human reviewer.

The policy also includes an experimental exception for LLM-authored code, under strict conditions. The PR must be solicited by a reviewer in advance, the change must not touch safety-critical components like the trait system or MIR building, it must be well-tested and well-reviewed, and both author and reviewer must be able to fully explain the code. Such PRs would be tagged with an ai-assisted label and posted to a private Zulip channel to track whether the experiment is producing useful contributions.

The "slop" problem driving urgency#

The authors give three reasons for the policy:

• 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.

The compiler team had already addressed this partially with a separate proposal to empower reviewers to reject burdensome PRs, defined as PRs that are needlessly verbose, internally incoherent, or demonstrate misunderstanding of the code, without having to defend that decision extensively.

The LLM Usage Policy is explicit that enforcing it shouldn't become its own burden:

"The optimal amount of fraud is not zero." Don't try to be the police for whether someone has used an LLM. If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on.

Lying about LLM use, however, is treated seriously and it's classified as a code of conduct violation rather than a policy violation, which carries different consequences.

Project Leadership Pushes Back on Scope and Precedent#

The discussion surfaced disagreement at the leadership level. Niko Matsakis, one of Rust's most prominent contributors and a principal architect of the modern language, contends the proposal does more damage than having nothing in place:

I do think this is worse than no policy at all, because it sets a precedent that I think will harm potential contributors and set the project on what I consider to be an overall negative trajectory.

His concern is that future contributors will be people who use LLMs as a standard part of their workflow, and a restrictive policy now forecloses the conversation before the project has enough data to make that call. He also argued the policy is too complicated: "I think people are going to read it and just be overwhelmed." On the list of conditions for the experimental exception, he commented: "To me, the list of conditions is overkill and kind of insulting. It signals a lack of trust in your fellow team members to be able to review code."

Jack Huey, types team co-lead and compiler team maintainer, pushed for the policy to be treated as a starting point: "I said it in one of my review comments, but regardless of what gets merged here, I don't want us to point to this and think 'it's the end' of the discussion. I think it's more than just this policy 'not just being set in stone', but rather I want us to think of it as 'just a step' to more discussion and data."

Rust contributor Diggory Blake questioned the policy's framing, noting that it targets how code is created rather than whether it's good:

I very much sympathise with the maintainers who have to deal with slop PRs, but I think this is coming at it the wrong way?

If someone opens a concise, easily reviewable change that's a clear positive improvement, but marks it as AI generated, does the policy compel maintainers to reject it? Seems like cutting your nose off to spite your face... Shouldn't the policy focus on giving more flexibility to the maintainers while setting expectations for contributors?

His suggestion was to frame the policy around what maintainers are obligated to review rather than what contributors are permitted to produce, avoiding what he called inevitable fairness disputes when similar PRs get treated differently.

Open Source Projects Range from Full Ban to Permissive on LLM Contributions#

The PR includes a survey of how other major open source projects have handled this, organized along a spectrum from full ban to permissive. Full bans are in place at postmarketOS, Zig, Servo, and QEMU. Zig's policy is rooted in concerns about the construction of original thought and cites a 1957 Asimov short story.

QEMU's is more pragmatic, focused on copyright and licensing, and notably carves out non-generative uses like using an LLM to explore an API or debug. Projects that allow LLM use with human oversight and disclosure requirements include LLVM, the Linux kernel, Mesa, Firefox, and Ghostty. NixOS has a draft policy under community review but no policy yet.

The Rust project's policy is scoped only to rust-lang/rust. Other repositories in the rust-lang organization are not covered, and the PR explicitly acknowledges that extending it project-wide was attempted and failed to reach consensus.

The PR was still open as of publication, with consensus expected to take the form of a joint Final Comment Period across four teams.