On Aug. 5, 2026, the Rust project published a formal LLM usage policy for the rust-lang/rust monorepo.
And it does something most dev teams still haven’t: it splits AI use into two buckets with completely different rules. Five Rust teams adopted the policy, authored by contributor Jynn Nelson. And the whole thing collapses to one sentence they wrote themselves: “It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.” Assistive use stays allowed. AI-authored code gets heavily restricted, and disclosure becomes mandatory where it counts. This is the first time a flagship programming-language project has codified where AI may and may not touch its core codebase. And it matters well outside Rust because the same assist-versus-author split maps directly onto the review gate your dev shop or agency should already be running.
Why Rust Wrote The Rules Down
The announcement post names three concrete problems that pushed Rust to formalize a policy instead of leaving it to ad-hoc moderation.
First, a polished pull request used to mean somebody on the other end put in real effort and understanding. And LLMs broke that signal. So a clean diff no longer proves the author even understands the code they shipped. Second, making code easier to write made an existing review-bandwidth problem worse: the post reports 1,281 open PRs against rust-lang/rust at the time of writing. And Rust has long had more people writing code than people willing to review it. Third, contributors copy-pasting review comments into an LLM and pasting the response back is, in the authors’ words, a waste of everyone’s time.
That third point is the one worth sitting with.
The Rust reviewers aren’t annoyed given that the AI answer is wrong, they’re annoyed as the work of reviewing is mostly deciding whether a direction is the right approach.
And a machine can’t make that judgment for them. When a reviewer reads a reply, they assume there’s a person on the other end who actually cares about the outcome. A pasted LLM response breaks that assumption. And once trust is gone the review turns into suspicion on both sides.
The Line: Assist Versus Author
The policy draws its line in a way most teams will find useful to copy.
On the allowed side sits everything assistive: asking an LLM questions, analyzing code, refining text, checking work, suggesting approaches, reviewing. On the restricted side sits creation, meaning letting an LLM author the code that lands in the repo. Disclosure is required where it matters; the blog notes that LLM output isn’t allowed in public docs, PR descriptions, or GitHub comments unless it’s clearly marked. And no reviewer is obligated to read LLM-generated material they didn’t ask for.
Critically, this is not a blanket project-wide ban. The blog is explicit that the policy is not an official stance on LLMs and does not apply everywhere in the Rust project. It governs the rust-lang/rust monorepo and four groups that touch it: people reviewing or moderating PRs, people authoring LLM-generated PRs, people filing LLM-found issues. And people quoting LLM output in comments. If you sit outside those groups, nothing about how you work changes.
The Honest Part Other Projects Will Skip
Two admissions in this policy are more useful than the rules themselves.
First, the policy text states plainly that many of its clauses are unenforceable. And the stated goal isn’t to catch every violation, it’s to remove plausible deniability and force a choice between following the rules and intentionally breaking them. That reframes the whole exercise: the document exists to make the expectation legible, not to build a surveillance apparatus around contributors. Second, the blog is candid that there is no consensus inside Rust about AI. And there likely never will be. Some members find AI genuinely valuable; others consider its climate and social costs severe enough that no use is acceptable. Rust operates by consensus, not by a benevolent dictator. So they couldn’t just copy Zig’s strict no-LLM stance or the Linux kernel’s loose “AI is a tool” position.
The author even says not every rule in the policy is wholly good.
But argues that writing rules down beats leaving them unwritten. And that a policy everyone kinda dislikes is what pushes governance to actually improve. The leadership council is reportedly considering a sub-team to own LLM policy so future changes don’t hit the “nightmare” 30-person approval requirements that adoption faced.
What Small Teams Should Steal
If you run a small dev shop or agency and you haven’t written your own line yet, borrow Rust’s split. Treat AI as a scratchpad, a reviewer, a rubber duck, and let it run free across that surface. Treat AI-authored code as something that hits a stricter review gate than human-authored code, with disclosure expected on every commit that came from a model. The point isn’t to catch liars, it’s to make the expectation explicit so that when someone does ship undisclosed AI code, you have something concrete to point at instead of a vibe.
I run AI-assisted build work for clients.
And the assist-versus-author split is already how I think about it in practice. AI that helps me understand a codebase or sanity-check an approach makes me faster and rarely creates downstream risk. AI that writes the actual code I hand to a client is where I slow down, since the contract, the copyright story. And the debugging responsibility all shift. Rust’s policy is essentially that same instinct encoded into governance.
And it’s a sharper template than the vague “use AI responsibly” line most teams currently have taped to a wiki.
The actionable move is small.
Write one paragraph covering four things: where in your workflow AI assists, where it authors, what disclosure you expect.
And what review bar each category gets.
You don’t need a thirty-person vote to do it, you need ten minutes and the honesty to admit the two buckets aren’t the same risk.
Read the full policy on the Rust Forge and the announcement on the Inside Rust blog, with Socket’s writeup for outside context. Then go write your own line before someone else ships undisclosed model code into your repo and you’re left explaining the policy you never bothered to set.
