Rust has set new rules for AI programming: it can help you review code, but cannot write code on your behalf, and will even trigger a "circuit breaker" mechanism when overused.
This week, five teams within the Rust project have formally adopted a new guideline for AI programming, which regulates how contributors should use Large Language Models (LLMs) when submitting code to rust-lang/rust.
rust-lang/rust is the main monolithic code repository of the Rust project. Jynn Nelson, the author of this guideline, announced the news on the Inside Rust blog on August 5, 2026.
In short, the core principle of this document can be summed up in one sentence:
LLMs can be used to answer questions, analyze, refine, improve, inspect, put forward suggestions and conduct reviews, but cannot be used for creation.
This guideline has been approved by five teams: the Compiler, Standard Library, Type System, rustdoc, and Bootstrap teams. It replaces the previously unregulated, almost "Wild West" management model described by Nelson with a set of public, written rules.
However, it currently only applies to the rust-lang/rust repository and only binds the teams that have approved this guideline. Within this scope, it draws a very clear line: LLMs are welcome as a thinking tool, but they cannot replace you in thinking.
What Exactly Does Rust Allow AI to Do?
Jynn Nelson introduced this new regulation on the Inside Rust blog:
No one is obliged to read content generated by LLMs unless they choose to do so. Without explicit labeling, LLM outputs must not appear in public documents, PR descriptions or GitHub comments; if reviewers do not want to review PRs generated with LLM involvement, they can directly choose not to review them.
Contributing to rust-lang/rust does not require anyone to use LLMs. All policies must first be written for human readers before being organized into a machine-readable version; LLM review results cannot replace human reviews, let alone the author's own checks.
You can use LLMs privately without disclosure, as long as the generated content is only for your own viewing and will not be published anywhere that requires Rust project members to read or review.
If you use LLMs for machine translation, making "minor modifications", finding bugs, or reviewing others' work, you must disclose the LLM's involvement. Rust also welcomes contributors to communicate directly in their native language, and does not require them to translate content into English before participating in contributions.
In short, the rule is "you can think, you can review, you can translate, but you cannot create". In actual implementation, it can be roughly divided into three levels.
The first category is fully permitted: any private use where only the contributor themselves can see the LLM output. For example, asking LLMs questions related to the code repository, summarizing a discussion thread, or privately asking it to review code you have written.
The second category is permitted but requires disclosure: including machine translation, minor modifications such as fixing spelling errors, using LLMs to find bugs, and using LLM code review bots. For review bots, the guideline also requires that they must run on independent and clearly marked GitHub accounts, so that users who do not want to see such content can block them directly.
The third category is explicitly prohibited: including generating comments, documents and compiler diagnostic information directly via LLMs; any process that must rely on LLMs to run; and deciding to merge or reject a change solely based on the review conclusion given by an LLM.
The truly binding part of this set of guidelines lies in its enforcement method.
If anyone deliberately conceals or misrepresents their use of LLMs, it will be considered a violation of the Rust project's Code of Conduct, at the same severity level as harassment. First-time violations may result in a warning, while repeated violations may lead to account bans.
The document also explicitly acknowledges that many of these rules cannot actually be fully enforced by technical means, and this is intentional. The guideline states: "Our goal is not to catch every single violation... Our goal is to eliminate any room for evasion: people must choose between complying with the guideline and deliberately violating it."
Rust is not the only project that has started to draw boundaries for LLMs, and the comparison between Rust and Zig is quite interesting.
Zig's strict all-out ban on LLMs/AI is far more thorough: it not only prohibits code and text generated by LLMs, but also prohibits rewriting or paraphrasing LLM content, and does not allow the use of AI for editing, translation, brainstorming or bug finding. Zig's solution has low enforcement costs, but high compliance costs for contributors. Rust is the opposite: it requires reviewers to make more judgments, but also allows contributors to continue using the LLM tools they already use.
Excessive AI-generated Content Will Trigger a "Circuit Breaker"
Rust has not completely banned LLM-written code, but restricts such contributions to an experiment with very clearly defined boundaries.
First of all, any changes created by LLMs must be communicated with a clearly designated reviewer in advance; these changes must not involve critical parts such as compiler soundness; they must be fully tested and subject to sufficient human review; and in all cases, the involvement of LLMs must be disclosed.
New contributors are subject to particularly strict restrictions. If you have not previously participated in the project, you cannot directly submit a Pull Request created by an LLM, and you must first find a reviewer who is willing to be responsible for the review. If the part of code you modify does not have an existing test suite, you must add a complete set of tests yourself, otherwise the PR will have to be closed. There are no exceptions.
This experiment even has its own "circuit breaker mechanism".
If in any six-week window, more than half of the merged PRs are created by LLMs, the merging of all LLM-created PRs will be suspended until their proportion drops back below 50%, and there will be a mandatory cooling period of at least 10 days.
The six-week cycle is not chosen arbitrarily, as it exactly aligns with Rust's six-week release cycle.
All such PRs will be tagged with a new ai-assisted label and synchronized to a private Zulip channel. The purpose of this channel is not to set a new review threshold, but to collect data: for example, whether contributors using LLM assistance are actually learning, whether they will continue to participate in the project afterwards, and whether they can consistently produce valuable work in the end.
Nelson mentioned three pressures in the announcement that eventually prompted these teams to shift from the previous informal management approach to explicitly writing down the rules.
The first problem is that a seemingly perfect Pull Request can no longer prove that the author has really put in a lot of effort, nor that the author truly understands the code inside.
In the past, if an open source project received a PR with complete structure, sufficient tests and detailed descriptions, reviewers would usually assume that the person behind it had spent a lot of time and had a certain understanding of what they submitted. But in the LLM era, this signal is no longer valid, and the Rust project's code review culture used to rely heavily on this trust.
The second problem is that after the cost of code generation drops, the already tight review resources become even more strained. Currently, there are 1281 open PRs in the rust-lang/rust repository. The truly scarce resource that the Rust project has long faced is never code, but the judgment and time of reviewers. LLMs allow one person to generate far more code very quickly, but do not correspondingly increase the number of people who can judge whether this code should be incorporated into the project.
The third problem is that some contributors have started to copy reviewers' comments into LLMs, and then copy the LLM's responses back to GitHub. According to Nelson, this practice is "wasting everyone's time". Because if reviewers want to know what an LLM thinks, they can ask it themselves. What code review really needs is the contributor's own judgment and understanding.
This practice also undermines a fundamental assumption in code review: reviewers assume that they are communicating with a real person who is truly working to understand the problem and respond to feedback.
Even Rust's Own Members Cannot Reach a Consensus on Whether AI Should Be Used
There is an important background behind this guideline: there are obvious divergences within the Rust project regarding attitudes towards AI.
Part of the motivation explicitly states that there is currently no consensus within Rust on when and how AI tools should be used, "and it is very likely that a consensus will never be reached".
The positions of project members span a wide spectrum. Some people use AI tools every day, some think any form of AI use is unacceptable, and many others are still in the wait-and-see and thinking stage. Precisely because of this, this guideline is designed to be modifiable from the very beginning. Any major revision in the future requires the re-approval of every team that has already approved the guideline. At the same time, these teams can also choose to abolish this guideline entirely.
In addition, Rust's Leadership Council is currently considering establishing a project-level LLM committee. If this committee is established, the project-level rules it formulates in the future will directly override the current guideline.
However, the actual coverage of this guideline is much narrower than its title suggests.
It does not apply to other code repositories under the rust-lang organization, nor to some work of the language team, such as issue tracking and stability reports.
Rust's style guide is also not bound by this guideline. Teams that have not yet approved the guideline are also not bound, and each team can still formulate its own rules.
There is an exception for internal members of the rust-lang organization: when they use LLMs to create code, they are not restricted by the "no modification of critical code" rule. However, the guideline explicitly states that using this exception is highly discouraged.
In addition, PRs that have already been submitted before the guideline officially takes effect are not bound by this new rule.
It is also worth noting that even if a contributor really violates the LLM usage guideline, other people cannot harass them just because they used an LLM. Harassment itself also violates the Rust project's Code of Conduct.
Six Weeks Later, Rust Will Decide Whether to Continue Allowing LLM Contributions
After the ai-assisted label is officially enabled, Rust will start collecting data on LLM-created PRs through the private Zulip channel.
The first six-week cycle will help these teams judge whether allowing LLM code contributions within a certain scope will further overwhelm the existing merge queue.
At the same time, Rust's Leadership Council is also discussing the establishment of a dedicated LLM committee. If this committee is finally established, the rules it formulates will have higher priority than the current guideline, and the rules may extend from the rust-lang/rust code repository to the entire Rust project.
At that time, chat channels, forums and other code repositories that currently do not have clear AI guidelines may all be included in unified specifications.
Nelson actually supports this direction in her article. In her view, the current guideline is only the first step, not the final answer for how Rust should deal with LLMs.
Reference Links:
https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/#what-does-the-policy-say
This article is from the WeChat official account "InfoQ", author: Tina, published with authorization from 36Kr.