What the policy actually says
On August 5, 2026, the Rust project published an LLM usage policy for the rust-lang/rust repository on its Inside Rust blog. The core rule is short enough to fit in one sentence: LLMs may "answer questions, analyze, distill, refine, check, suggest, review," but they may not "create."
In practice, that splits into a few concrete rules. Comments, issue bodies, and pull request descriptions posted from a personal account can't be LLM output if that's all they are. Documentation generated wholesale by an LLM is out, and so are non-trivial source code comments written by a model rather than a person. If you use an LLM anywhere in putting a contribution together, you have to disclose it. Contributions flagged as LLM-assisted face stricter test coverage and narrower scope than normal, and reviewers are allowed to close a non-compliant PR without further explanation.
What the policy doesn't do is ban AI tools outright. Using an LLM privately to understand a piece of code, get a second opinion on an approach, or review your own prose before you post it is explicitly fine. The line Rust is drawing isn't "no AI," it's "no LLM standing in as the author of record."
Why now
This didn't come out of nowhere. The rust-lang/rust repository has been dealing with a rising volume of what maintainers describe as low-effort, LLM-authored pull requests: plausible-looking changes that don't actually understand the codebase, generated fast enough that reviewing and rejecting them has become its own tax on maintainer time. A written policy gives reviewers something to point to instead of relitigating the same argument on every PR.
The framing the project settled on is a rule for professional practice, not a referendum on whether AI is good or bad: use LLMs to write better, the policy says, not to write faster.
Where the pushback is coming from
Not everyone thinks this is the right call. Some developers argue that a large, high-profile project taking a hard line on LLM-generated contributions puts Rust at a disadvantage against languages and ecosystems that don't draw the same boundary, and that newer contributors who lean on AI tools to get oriented in an unfamiliar codebase will simply route around the friction by contributing somewhere else.
On the other side, plenty of maintainers on other large projects have been quietly asking for exactly this kind of policy for a while. A public, written standard is easier to enforce evenly than an unwritten norm that different reviewers apply differently, and it gives new contributors clear expectations instead of finding out the hard way that their AI-assisted PR is unwelcome.
The bigger pattern
Rust is a large, security-sensitive project with a famously high bar for code review, so it's a natural place for this kind of policy to show up first. But the underlying problem, that LLMs can now generate plausible-looking contributions faster than humans can review them, isn't specific to Rust. Expect more open source projects to publish some version of this same distinction between using AI to think and letting AI stand in as the author, especially anywhere maintainer time is the actual bottleneck rather than raw contribution volume.
If you maintain a project of any size and haven't written down where you stand on this, Rust's policy is a reasonable template to start from: LLMs for questions, analysis, and review, yes; LLMs as the credited author of new code or prose, no.
It's also worth watching how the tools people actually use respond. [GitHub Copilot's pricing tiers](https://questloops.com/blog/github-copilot-pricing-2026-free-pro-pro-and-the-new-ai-credits-system) already nudge users toward metered, deliberate usage rather than unlimited generation, and Anthropic's push to get [Claude Cowork running in the cloud](https://questloops.com/blog/claude-cowork-is-moving-to-the-cloud-what-changes-when-your-agent-doesn-t-need-your-laptop) is really a bet that agents need more oversight infrastructure, not less. Policies like Rust's are the human-process side of the same problem.
