Rust Says AI Can Review Code but Not Write It: Inside the New LLM Policy

On August 5, 2026 the Rust Inside Rust blog announced that the five teams responsible for the compiler, standard library, type system, rustdoc, and bootstrap have jointly adopted a concrete policy governing the use of large language models (LLMs) in the rust‑lang/rust repository. The policy is not a statement of Rust’s overall stance on AI and does not apply to other repositories in the rust‑lang organization.

Why the policy was needed

The policy emerged from three worsening problems: (1) polished pull requests no longer guarantee that the author truly understands the code; (2) AI makes code writing easier while review capacity has not increased; and (3) mechanically copying reviewer comments into an LLM and pasting the LLM’s reply back wastes everyone’s time.

Problem 1 – Polished PRs no longer signal understanding

Historically, a well‑crafted, fully tested PR in Rust signaled significant author effort and community trust, leading reviewers to engage in gradual, fact‑driven discussion. LLM‑generated contributions can break this signal because the PR may be produced without any human deeply involved, undermining the cultural expectation that a PR reflects a contributor’s commitment.

Problem 2 – Easier code creation strains limited review resources

At the time of writing the rust‑lang/rust repository held 1,281 open PRs, consuming massive reviewer time. Reviewers focus not on bug hunting but on assessing the direction, feasibility, and long‑term impact of changes. When PRs are generated en masse, reviewers are forced to evaluate code they cannot trust to reflect the author’s intent, increasing psychological load and diluting the core purpose of review.

Problem 3 – Mechanical copy‑paste wastes time

Teams often copy reviewer feedback into an LLM, then paste the LLM’s response verbatim into GitHub. This practice discards the reviewer’s own reasoning and erodes trust, because reviewers expect a genuine human dialogue, not a machine‑generated echo.

What the policy actually says

The policy can be summed up in one sentence: LLMs may be used to ask questions, analyze, refine, check, suggest, and review, but they may not be used to "create" code. Allowed uses require disclosure; prohibited uses are strictly limited.

No one is forced to read LLM output unless they choose to; undisclosed LLM content may not appear in public documentation, PR descriptions, or GitHub comments, and reviewers are not obligated to examine AI‑generated PRs.

No one is forced to use LLMs for contributions ; the policy is written for humans first, with a machine‑focused version derived later, and LLM review cannot replace human review.

Private, non‑public LLM output does not need disclosure.

Disclosure is mandatory for machine translation, minor edits, bug discovery via LLM, and LLM‑assisted review; contributors may write in their native language without mandatory English translation.

LLM‑generated code changes must meet higher standards than human submissions: prior communication, non‑critical path, thorough testing, full review records, and explicit source disclosure. Soundness‑critical changes are strongly discouraged from using LLMs, even for experts.

Two red lines are enforced at review time: (1) LLM participation must be disclosed, and (2) harassment of anyone using LLMs is prohibited, regardless of policy compliance.

Impact on different roles

Issue reporters must disclose any LLM‑generated content in the report and label it clearly.

Authors submitting LLM‑generated code may use LLMs for questioning, analysis, refinement, checking, suggestion, and review, but not for creating new code; detailed guidance is available in the policy’s "allowed" section and the rustc‑dev‑guide.

Reviewers can close non‑compliant PRs without extensive explanation, directing authors to the dedicated LLM‑assistance channel. Reviewers must not rely on code style alone as evidence of AI authorship; if they voluntarily evaluate LLM‑generated changes, they must verify that the changes do not touch prohibited areas such as documentation, diagnostic messages, or soundness‑related code.

Why a policy instead of a ban?

Rust lacks a "benevolent dictator" who can unilaterally decide; consensus‑based governance leads to a policy that can evolve. The policy deliberately leaves room for future modification and even proposes a sub‑team to manage LLM policy, avoiding the nightmare of requiring thirty signatures for every change.

Comparison with other projects

Go’s core team recently rejected AI co‑authorship, insisting on human accountability for code.

Zig’s code of conduct explicitly bans any LLM‑generated content.

The Linux kernel adopts a more permissive stance, treating AI as just another tool, but still emphasizes that responsibility and understanding must rest with a specific person.

All three projects share the core concern that while tools can accelerate code production, comprehension and accountability must remain human.

Takeaways

The Rust policy turns an informal, ad‑hoc set of expectations into a publicly referenceable document, enabling transparent discussion and future data‑driven adjustments. The team will monitor whether AI actually contributes valuable, lasting work and will let those metrics guide future policy evolution.