Rust’s LLM Policy: What AI-Assisted Contributors Must Change Before the Next Pull Request

Last updated: August 7, 2026

An LLM usage policy is a project rule governing how large language models may be used in contributions. On August 5, 2026, five Rust teams ratified one for the rust-lang/rust monorepo. It permits private AI assistance and admits a narrow class of LLM-created code under a named experiment, subject to reviewer agreement, disclosure, human authorship of specific artifacts, and a higher testing bar.

Rust has not banned AI-assisted contribution. It has added conditions that code quality alone does not satisfy, and the conditions are split across documents that carry different authority.

What the policy covers

The policy applies to the rust-lang/rust monorepo and, within it, to the teams that ratified it: compiler, libs, types, rustdoc, bootstrap, and their subteams. Its appendix names what sits outside. Other repositories in the rust-lang organization are out of scope. So are submodules, subtrees, and crates.io dependencies. So are teams that did not ratify it, with lang and edition given as examples. The appendix also excludes specific artifacts, including T-lang tracking issues and proposals, language documentation, the style guide, and the names of compiler lints. Diagnostic messages remain covered even where lint names are not.

The announcement explains why the policy exists in operational terms. It identifies a shortage of review capacity that easier code generation makes worse, reports 1,281 open pull requests on the repository at the time of writing, and describes mechanical copy-pasting between a reviewer and a model as wasted effort for both. On the signal problem it is blunt: “Polished PRs no longer indicate effort”.

Anyone summarizing this as a Rust-wide ban on AI-generated code is wrong on three counts at once. It is one repository, five teams, and a conditional permission rather than a prohibition. The appendix settles all three in about a minute of reading.

Sources: Inside Rust Blog, 5 August 2026 · Rust Forge, LLM usage policy, Appendix: Scope, retrieved 6 August 2026

Four surfaces, one canonical

Four public documents describe these rules. They do not carry equal weight, and the difference changes what a given sentence obligates.

The dev-guide states the ordering itself. Its landing page describes the section as a list of guidelines and a summary of the moderation policy, says it is not the policy, and adds: “If the two conflict, Forge is canonical.”

That ordering is not an academic point. The two surfaces express different standards on the same question, which is the subject of section five.

Sources: Rust Compiler Development Guide, Working with LLMs, retrieved 6 August 2026 · Rust Forge, LLM usage policy, retrieved 6 August 2026 · GitHub, rust-lang/rust pull request 155424, merged 5 August 2026

What changes before the next PR

For a team already using coding agents, the following is what the published documents require. Each row states whether the requirement is canonical policy or subordinate guidance.

Authority column reflects which document states the requirement. Where the two differ, the canonical policy controls.

Sources: Rust Compiler Development Guide, Writing LLM-created code, retrieved 6 August 2026 · Rust Forge, LLM usage policy, Experiment section, retrieved 6 August 2026 · GitHub, rust-lang/rust pull request 155424, merged 5 August 2026

Quality is required and does not erase origin

Some coverage frames this policy as a shift from judging output to judging process. That framing does not survive contact with the text.

The experiment admits LLM-created code changes only when they are pre-arranged, non-critical, high-quality, well-tested, and well-reviewed. Both author and reviewer are expected to understand the code. The policy sets a higher testing expectation for LLM-created PRs than for human-created ones, on the stated reasoning that models make tests cheaper to produce, and the guidance adds that untested LLM PRs will not be merged. Technical quality is a hard requirement.

What the policy adds is a second axis that quality does not move. The appendix defines the phrase originally created by an LLM as text generated by an LLM and possibly edited afterward by a human, then states: “No amount of editing can change how it was originally created”. The policy also records that it draws no distinction between output from a chat interface and output from editor auto-completion.

The result is an admission test with several independent parts. Is the code technically acceptable and tested? Does the contributor understand it well enough to defend it? Was a reviewer secured? Was the LLM involvement disclosed in the required form? A patch can clear the first two and fail the rest.

On the reviewer side, the guidance names three currently banned areas. All user-facing diagnostics must be human-written. All public doc-comments and all // SAFETY comments must be human-written. For code that affects soundness, if the author is not an organization member who is experienced in the domain, the reviewer is required to close the pull request.

The guidance is candid that the soundness boundary is imprecise. It notes the phrase is both broader and narrower than it sounds, since almost all of the compiler bears on soundness while much of rust-lang/rust is not the compiler, listing library, bootstrap, compiletest, rustdoc, and CI. Where a reviewer is uncertain, it suggests withholding LLM-generated code from “parts of the compiler where wrong code does not look wrong”, and then states that the decision is the reviewer’s judgment.

Sources: Rust Forge, LLM usage policy, Rules and Appendix, retrieved 6 August 2026 · Rust Compiler Development Guide, Reviewing with LLMs, retrieved 6 August 2026 · Rust Compiler Development Guide, Writing LLM-created code, retrieved 6 August 2026

Where the floor and the workflow diverge

The canonical policy sets an admissibility floor. The subordinate guidance describes the workflow that keeps a contributor from doing work that gets discarded. On three questions these two produce different answers, and the difference is where engineering time is lost.

Reviewer timing. The canonical requirement attaches to the pull request: a reviewer must have agreed in advance to review an LLM-created PR, and must be the one assigned. Nothing in the canonical text requires that agreement before code is written, with one exception the policy states explicitly, that new contributors cannot use an LLM unless they first talk with that reviewer. The guidance takes a stricter line for everyone, telling authors to find a volunteer reviewer before anything else. A contributor who follows only the floor may write a patch and then discover that no reviewer will take it.

Disclosure. The canonical requirement is that LLM use be disclosed. The merged template implements that as a two-option checkbox. The guidance defines what an adequate disclosure contains: the extent and purpose of the use, written by the contributor, describing whether the model implemented an idea, proposed one, reviewed the patch, or performed some narrower task. The guidance states plainly that model identity is not the information wanted.

Testing. The canonical requirement is well-tested code with an explicitly higher bar for LLM-created PRs. The guidance converts that into an operational rule, stating that untested LLM PRs will not be merged and that the author is expected to verify the tests fail before the change and pass after it.

Reading only the canonical policy produces a defensible legal position and an unreliable workflow. Reading only the guidance produces a workable habit and an inaccurate account of what is actually mandatory. Teams writing an internal contribution checklist need both, and need to record which is which, because the canonical document controls if the two ever conflict.

The separation described in this section is FSR’s reading of the two documents. Neither document characterizes itself as a floor.

Sources: Rust Forge, LLM usage policy, Experiment section, retrieved 6 August 2026 · Rust Compiler Development Guide, Writing LLM-created code, retrieved 6 August 2026 · GitHub, rust-lang/rust pull request 155424, merged 5 August 2026

Tool attribution and the disclosure

The guidance lists two examples of inadequate disclosure. One is a generated-with product line. The other is a co-author trailer naming a model. Neither string is false. Neither states what the model did.

That intersects with what coding tools currently document as their defaults.

Vendor documentation retrieved 6 August 2026. Setting names and defaults change between releases. Verify against current documentation before acting on this table.

The Claude Code documentation gives the default pull request attribution as 🤖 Generated with Claude Code, which renders as the same line the guidance lists as inadequate. Its documentation also states that the model name in the commit trailer reflects the session’s active model, so the specific model named in the guidance example will age out while the shape of the string does not. Qwen Code documents its commit setting as adding a “Add a Co-authored-by trailer to git commit messages” behavior, defaulting to on. The GitHub Copilot CLI documentation states that “Copilot follows it when generating the pull request title and description” where the referent is a repository pull request template, which is the surface now holding Rust’s LLM question.

Three limits on what this table supports.

The policy governs contributors. Nothing here establishes that any product is noncompliant with anything, and a default that omits extent and purpose is not a defect in a feature that was never designed to carry them.

Disabling generic attribution removes an inadequate string. It does not produce the disclosure the guidance asks for. That remains a per-pull-request piece of human writing, and no configuration change substitutes for it.

FSR did not install, run, or configure any of these tools. Every statement in the table is what the vendor’s documentation said on the date shown.

Sources: Claude Code Docs, Attribution settings, retrieved 6 August 2026 · Qwen Code Docs, Configuration, retrieved 6 August 2026 · GitHub Docs, Managing pull requests with the /pr command, retrieved 6 August 2026 · Rust Compiler Development Guide, Writing LLM-created code, retrieved 6 August 2026

The aggregate volume limit

The policy includes a mechanism it calls a circuit breaker. If more than half of the pull requests merged in a six-week window are LLM-created, merging of new LLM-created PRs is disallowed until the share falls back below fifty percent, with a minimum cooldown of ten days. The policy states the six-week window aligns with the release cycle and that the cooldown period aligns with the Final Comment Period process, with the stated purpose of avoiding rapid switching between allowed and disallowed.

This creates two planning problems for a team that contributes regularly.

It operates on aggregate volume rather than on any individual submission, so a compliant, tested, pre-arranged pull request can wait on the merge behavior of contributions it has no relationship to. And the policy strongly suggests that the mechanism be automated, which is a recommendation rather than a statement that automation exists. The policy page does not identify where a current ratio is published, so a team planning around the threshold cannot check proximity to it from that document.

Sources: Rust Forge, LLM usage policy, Circuit breaker, retrieved 6 August 2026

One organization, two disclosure rules

Two months before the monorepo policy was ratified, the crates.io team adopted a different one. A pull request merged on June 5, 2026 brought the CPython developer guide’s AI tools policy into crates.io as docs/AI-TOOLS.md, with one Python-specific sentence removed, linked from CONTRIBUTING.md and AGENTS.md. That policy places responsibility for content on the submitter and requires contributors to be able to explain their changes. On disclosure it lands differently from the monorepo policy: appreciated, but not required.

The pull request discussion records that this was argued rather than assumed. Reviewers pressed for mandatory disclosure on two grounds, accounting for contribution origin and review practicalities, and proposed a lightweight trailer as the minimum form. Others argued that mandating disclosure carries its own costs, citing published findings that disclosure can reduce trust, the risk of false accusations once readers are primed to look, and the enforcement burden a mandatory rule creates. The proposal merged without a disclosure requirement.

One line from that discussion bears on the previous section. Arguing against a mandatory trailer, the author noted that “getting that tooling to reliably add trailers is a whole separate problem”.

Later in the thread, a contributor asked what would happen if the monorepo policy were proposed project-wide, observing that adopting it would mean withdrawing things crates.io currently permits. The response was that the monorepo policy is scoped to one repository and that extending it would require an RFC with buy-in from all teams.

Both policies keep human responsibility and permit AI assistance. They differ on whether disclosure is mandatory. For a team contributing across the organization, the operational conclusion is that the unit of AI-governance compliance is the repository, not the tool and not the parent organization.

Sources: GitHub, rust-lang/crates.io pull request 13726, merged 5 June 2026

What the documents do not establish

Sources: Rust Forge, LLM usage policy, retrieved 6 August 2026 · GitHub, rust-lang/rust pull request 155424, merged 5 August 2026

FAQ

Sources: Rust Forge, LLM usage policy, retrieved 6 August 2026 · Rust Compiler Development Guide, Writing LLM-created code, retrieved 6 August 2026 · Rust Compiler Development Guide, Reviewing with LLMs, retrieved 6 August 2026 · GitHub, rust-lang/crates.io pull request 13726, merged 5 June 2026

Methodology

This is a Tier C briefing: document-first, with no hands-on testing. The subject is a governance document, so no product was run and no account was opened.

Every source cited was opened and read directly on August 6, 2026. Publication dates are shown where a document displays one; otherwise the retrieval date is recorded. The LLM usage policy on Rust Forge is canonical. The two rustc-dev-guide pages are subordinate guidance containing mandatory wording, and the guide states that Forge controls where the two conflict. Each source caption identifies which layer a requirement comes from.

Coding-tool behavior was read from each vendor’s own current documentation on August 6, 2026. FSR did not install, run, or configure any of these tools and did not observe their output. Those statements are official vendor claims, they are date-locked, and the defaults are configurable and subject to change between releases. The Rust documents name one product in their disclosure examples; the second product was identified by FSR from vendor documentation, not from any Rust source.

FSR used AI assistance for source discovery, extraction, and adversarial review of this argument. Every cited source was then opened and read before any claim was written, and one research output was discarded in full after asserting the existence of a policy section that does not exist. A human accepted editorial responsibility for the final text. Given that this briefing examines automated attribution, disclosing FSR’s own process is a requirement rather than a courtesy.

Commercial relationships: FSR holds paid subscriptions to Claude Code, Qwen Code, and GitHub Copilot, and used them in its own work. FSR has no affiliate arrangement or sponsorship with any named vendor, and this article contains no affiliate links. No named vendor was contacted before publication.

Corrections are published with a dated note rather than applied silently.

Full source list: Inside Rust Blog, 5 August 2026 · Rust Forge, LLM usage policy · rustc-dev-guide, Working with LLMs · rustc-dev-guide, Writing LLM-created code · rustc-dev-guide, Reviewing with LLMs · GitHub, rust-lang/rust PR 155424 · GitHub, rust-lang/crates.io PR 13726 · Claude Code Docs, Settings · Qwen Code Docs, Configuration · GitHub Docs, Copilot CLI pull requests

Verdict

Keep the tool. Change the workflow, and write the checklist against the canonical policy while following the guidance.

Rust has not made AI-assisted contribution impossible. A disciplined contributor can comply using the tools they already have, provided the team secures a reviewer before the pull request exists, keeps commit messages, pull request prose, documentation, diagnostics, and the disclosure in human hands, understands the patch well enough to defend it, and supplies tests. Nothing in the policy stops that.

What changes is where the failure modes sit. Technical quality remains mandatory and now sits alongside conditions it cannot satisfy: an agreed reviewer, an accurate account of what the model did, and a category boundary that a reviewer decides. A team that treats generic tool attribution as the upstream project’s required disclosure has satisfied a checkbox and not the standard behind it.

The practical instruction is narrow. Treat upstream AI policy as repository configuration rather than as a tool-wide permission, write a per-repository contribution checklist that marks which rules are canonical, and check the policy again before each material submission. The rules differ between rust-lang/rust and crates.io today, and a project-wide reconciliation has been raised without being settled.