Background: 1,281 Open PRs and a flagship open-source project drawing its first LLM boundary

On the Inside Rust blog, the Rust language team formally announced that the rust-lang/rust main repository is adopting an LLM policy, authored by Jynn Nelson and ratified by five teams. This is the first time a flagship systems-language project has written "what LLMs can and cannot do in contributions" into an official rule. The policy is published at https://forge.rust-lang.org/policies/llm-usage.html and went live on August 5, 2026.

The direct trigger for the policy is the repo's actual state: at time of writing, rust-lang/rust has 1,281 open PRs. Nelson puts the number on the table directly in the post and writes that "people who want to write code" have long outnumbered "people willing to review it," and LLMs have made that imbalance worse.

The core: answers, distillation, checks yes — "create" no

Nelson summarizes the policy in one sentence:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

The policy distinguishes two categories accordingly.

First category (allowed, sometimes requires disclosure):

  • Use LLMs to answer questions, analyze code, distill ideas, refine drafts, check results, suggest, review
  • Use LLMs for machine translation, e.g. drafting an issue in one's native language
  • "Trivial" changes, bug discovery, and assisting in reviewing other people's PRs — all require flagging LLM involvement

Second category (heavily restricted; pre-arranged + non-critical + tested + disclosed):

  • Code changes originally produced by an LLM must be pre-arranged with maintainers, and only in non-critical areas
  • LLM PRs must include tests, regardless of difficulty
  • Soundness-critical changes cannot be LLM-generated unless the author is already a domain expert (and even then, "strongly discouraged")
  • LLM-generated text in public docs, PR descriptions, and GitHub comments must be clearly marked

Three reasons Nelson names explicitly

Nelson writes three direct reasons for the policy:

  1. "Polished technical artifacts no longer indicate effort and understanding." In the past, a polished, well-tested PR implied the author had spent real time on it, which shaped Rust's culture — reluctance to close PRs outright, willingness to evolve designs during review, treating PRs as onboarding into the community. With LLMs, none of those signals are reliable.

  2. "Making code easier to write causes review issues." Most of the work of reviewing is not catching bugs, but deciding whether a direction is a good idea. When LLMs make PRs cheap to produce, the reviewer-side judgment cost goes up.

  3. "Mechanically copy-pasting LLM output is a waste of everyone's time." Nelson writes bluntly: "If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine's."

Governance detail: don't catch every violation, draw a clear line

Nelson is explicit that the policy's "goal is not to catch every violation." Some parts are intentionally unenforceable — the goal is a bright-line disclosure rule so moderators can identify violations by actions, not intent, and only consider intent when deciding how to respond.

Operational rules:

  • Reviewers may close non-compliant PRs without explanation, but must point the author to the #llm-mentoring channel
  • Reviewers are not responsible for determining whether a PR was LLM-generated — that is the author's responsibility. A new PR template will ask authors whether their code is LLM-generated
  • If a reviewer is unsure, they may report privately to moderators — but they cannot accuse authors based on style

The contrast: two extremes Rust refuses to pick

Nelson doesn't dodge Rust's governance reality: Rust is not a benevolent-dictator project, so the policy does not say "no LLM-generated content" (which is what Zig's code of conduct says) nor "AI is a tool, like other tools" (which is Greg Kroah-Hartman's framing on linux-media). Rust instead writes the rules down, publishes the controversy, and includes modification clauses so the policy can be revised as data comes in.

Why this matters for the broader LLM conversation

Compared with earlier scattered statements ("we don't take LLM PRs" or "AI is just a tool"), Rust's move sets a new bar:

  • It turns LLM into a governance object, not a per-moderator judgment call
  • It mandates disclosure rather than blanket prohibition, leaving a legitimate lane for LLM-assisted contribution
  • It imposes a higher bar on LLM-written code (tests required) than on human-written code, which feeds back into model-evaluation and developer habits
  • The "create vs analyze" split becomes a template other large monorepos can adopt

This is a clear signal that "LLM writing code" has moved from "individual productivity tool" to "infrastructure that needs to be governed by the project itself."

Sources