On August 5, 2026, five teams in the Rust project adopted a formal policy governing how large language models can be used when contributing to the rust-lang/rust monorepo. The policy was authored by Jynn Nelson and adopted after months of internal debate that generated over 3,000 messages on Zulip.

The line it draws is one sentence: It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

This is the most carefully worded AI governance policy any major FOSS project has published. The care is the point. And the problem it addresses — maintainer time as the scarcest resource in open source — is the same problem every community infrastructure project faces when someone volunteers enthusiasm instead of understanding.

What the Policy Says

The policy applies to five teams in the rust-lang/rust monorepo. Not the Rust ecosystem broadly. Not crates.io. Not your company's Rust codebase. Five teams, one repository. The scope is deliberately narrow because Rust governs by consensus, and there is no consensus on LLMs across the entire project. The policy acknowledges this directly: "There is not a consensus within the Rust project—and likely never will be—about when/how/where it is acceptable to use AI-based tools."

What the policy allows, sometimes requiring disclosure:

  • Analysis and review. Using LLMs to analyze code, find bugs, check your work, review other people's code. Disclosure required for bug reports discovered via LLM.
  • Refinement. Using LLMs to distill, refine, and suggest improvements. Fine for private use. If posted publicly, must be disclosed.
  • Machine translation. Posting in your native language and using an LLM to translate. Disclosure required. The policy explicitly welcomes non-English contributions.
  • Trivial changes. Pre-arranged, non-critical, well-tested, well-reviewed code changes that are LLM-generated are allowed with disclosure. Held to a higher bar than human-authored code — tests required, full stop.

What the policy prohibits:

  • Undisclosed LLM-generated content in public docs, PR descriptions, or GitHub comments. You can post LLM content, or you can not post it. You cannot hide its origin.
  • LLM-generated code without disclosure and comprehension. The author must understand the code, be able to explain it, and take accountability for it. "I asked the AI and pasted the result" is not a contribution.
  • Soundness-critical changes generated by LLMs unless the author is already a domain expert. Even then, strongly discouraged.
  • Copy-pasting LLM responses to review comments. The policy is blunt: "If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine's."
  • Harassment of people for using LLMs, regardless of whether their use is policy-compliant.

The enforcement model is practical. Reviewers can close non-compliant PRs with no questions asked. Authors are responsible for disclosing LLM use — reviewers are not responsible for detecting it. Style is not evidence. The policy explicitly says not to accuse people of using an LLM based on how their code reads. Some parts are acknowledged as unenforceable, and that's treated as a feature, not a bug: the goal is a bright-line rule based on actions (did you disclose?), not intent (did you mean to deceive?).

Why It Was Written

The blog post from Nelson is worth reading in full because it describes a problem every FOSS project is now facing. Three issues drove the policy:

Polished work no longer indicates effort. Before LLMs, a well-structured, well-tested PR meant someone spent time understanding the codebase. That signal is gone. A polished PR might be the output of a 30-second prompt. The cultural practices built on that signal — reluctance to close PRs, treating PRs as mentoring opportunities, assuming the author will stick around — no longer hold.

Review bandwidth is the bottleneck. At the time of writing, rust-lang/rust had 1,281 open PRs. The problem predates LLMs: there have always been more people who want to write code than people willing to review it. LLMs make this worse because they make it trivially easy to generate code that looks plausible but requires a human to read, understand, and evaluate. The review work — deciding whether an approach is sound, whether the PR is a good idea at all — cannot be automated by the same tool that created the need for it.

Mechanical copy-paste wastes maintainer time. Contributors who paste review comments into an LLM and paste the response back are not contributing. They're outsourcing the part of the process that matters — the thinking — and keeping the part that doesn't — the typing. The policy calls this a breach of trust between reviewer and author, and it is.

The Spectrum: Zig Went the Other Way

The Rust policy exists on one end of a spectrum. The other end is Zig, which adopted a strict no-LLM, no-AI policy in its Code of Conduct. Zig's rule is a flat ban:

  • No LLM-generated content, code or prose.
  • No paraphrasing LLM-generated content.
  • No LLMs for editing, including spelling and grammar fixes.
  • No LLMs for translation.
  • No LLMs for brainstorming if you share the results.
  • No LLMs for finding bugs.
  • No talking about use of chatbot/LLM services.

Zig's policy is enforced by two paid core team members who remove people swiftly. The community is decentralized — the rules only apply to the Zig project's own spaces (Codeberg, IRC, Zulip). Anyone is free to start a Zig community with different rules.

Both approaches are defensible. Zig's is simpler: no judgment calls, no disclosure requirements, no edge cases. One rule, one enforcement mechanism. It treats LLM output as categorically unwelcome in the project's spaces.

Rust's is more nuanced: it recognizes that LLMs are tools people are already using, governs their use with specific rules, and creates a framework that can evolve as the project learns what works. It treats LLM output as sometimes useful but always requiring accountability.

The difference is governance philosophy. Zig has a benevolent dictator who can say "no LLMs, full stop." Rust operates by consensus across teams with different cultures and tolerances. The Rust policy couldn't be a flat ban because a flat ban wouldn't have achieved consensus. It also couldn't be "anything goes" because that was already burning out reviewers. The policy is the overlap: the set of rules that enough people could agree on to make enforceable.

What This Means for Community Infrastructure Projects

The Rust policy is not directly applicable to a fire hall running Nextcloud, a town office deploying Matrix, or a community center setting up Keycloak. Those projects are operators, not language compilers. But the governance problem is the same shape, and the policy is a template worth studying.

Maintainer time is the constraint. Whether you're reviewing PRs to a compiler or maintaining a Proxmox cluster for a community organization, the person who understands the system is the bottleneck. LLMs make it easy to generate plausible-looking work that requires the expert to evaluate. If your community infrastructure project accepts outside contributions — patches, configs, documentation — you need a rule about LLM-generated content before you need it, not after.

Disclosure is the minimum viable policy. You don't have to ban LLMs. You don't have to allow them. You have to know when they're being used. "Did you write this, or did you generate it?" is a question every community project should be able to ask and expect an honest answer to. The Rust policy makes disclosure the bright line — not detection, not style analysis, not accusations. Just: tell us.

Accountability doesn't scale with automation. The Rust policy's core principle is that the person who submits work is accountable for it, regardless of how the work was produced. An LLM-generated config that breaks your community's Matrix server is the submitter's responsibility, not the LLM's. This is obvious when stated. It is less obvious in practice, when the submitter may not understand the config they submitted.

The sustainability angle. One of kryptonwolf's core values is self-sufficiency — working ourselves out of a job, on purpose. LLM-generated contributions work against this if they substitute for human understanding. A volunteer who uses an LLM to generate a Keycloak config they can't explain hasn't learned anything. When they leave, nobody can maintain what they submitted. The Rust policy addresses this directly: LLM-generated code is held to a higher bar than human-authored code, because the author needs to demonstrate understanding that the code itself no longer proves.

The FOSS Governance Precedent

The Rust policy is the first formal LLM contribution governance document from a major FOSS project that I'm aware of. It won't be the last. The blog post says so: "This is not the first LLM policy published by teams in the Rust project, and hopefully it will not be the last."

The policy text is reusable. It's MIT-licensed in spirit (the Rust project's materials are under Apache 2.0 / MIT). Other projects can adapt it. The structure — allowed uses with disclosure, prohibited uses, enforcement by closure, reviewer protection — is portable. A community infrastructure project could adopt a simplified version in three lines:

  1. If you used an LLM to generate any part of your contribution, say so.
  2. You are responsible for everything you submit, regardless of how it was produced.
  3. We may close contributions that don't follow these rules, no questions asked.

That's the Rust policy stripped to its load-bearing walls. It's enough. It doesn't require detecting LLM use. It doesn't require style analysis. It requires honesty and accountability, which are the same things every FOSS project already requires of its contributors.

What to Watch

The Rust policy includes provisions that make it easier to change than to originally adopt, and the leadership council is considering a sub-team to handle LLM policy going forward. The explicit goal is to gather data: are people doing useful things with LLMs? Are they learning? Are they making repeat contributions? The answers will shape the next version.

Watch for other large FOSS projects adopting similar policies. The Linux kernel, which Linus Torvalds has said is "fine" with AI-assisted contributions as long as the code is good, has not formalized anything. The big Linux Foundation projects — Debian, Kubernetes, the CNCF ecosystem — are the likely next movers. When they do, the Rust policy is the text they'll start from.

For community infrastructure operators specifically: if your project has a contribution guide, add a line about LLM-generated content now. Not because it's a crisis, but because the question is coming, and having an answer before the first LLM-generated PR arrives is easier than writing one after.

The full policy is at forge.rust-lang.org/policies/llm-usage.html. The announcement post is at blog.rust-lang.org. Read both. Then decide where your project's line is.