The Rust project has implemented a formal LLM policy, which pushes people to use LLMs to analyze/think through code, not write it.

With how it is written right now, the policy only covers the core code repo for Rust. It lays out many rules around what's restricted, what's allowed, and a circuit breaker that pauses AI-authored merges once they cross half of all merges in a six-week window.

Just so you know, the core repo hosts the compiler and standard library for the entire language. Every Rust program depends on code that lives here, which makes it a very important repo to moderate.

It's no surprise they banned LLM use the way they did.

An LLM can't write your comments, issues, or PR descriptions under your name. Documentation, safety comments, and compiler diagnostics are all off-limits too. And an LLM review can never substitute for a human one or for reviewing your own code before you post it.

What's allowed is private use. Asking an LLM questions about the codebase needs no disclosure, and neither does privately reviewing your own code, summarizing a PR for yourself, or building personal dev tools with one.

Apart from that, there are a few things that reside in a gray area. Machine translation, trivial fixes made with an LLM, and self-verified bug hunting all sit here, and each one needs to be disclosed.

AI-written code gets the strictest treatment of all. It has to be pre-arranged with a reviewer, unlikely to introduce a bug that breaks Rust's safety guarantees, fully tested, and understood on both sides before it earns the new ai-assisted label.

Jynn Nelson, who wrote up the original policy that the project has now adopted, concluded the announcement by stating that:

This is not the end of the story. One of the goals of the policy is to help us gather data: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? The answers to those questions will help us determine how the policy changes in the future.

A similar move elsewhere

NetworkManager, the default network daemon on most mainstream Linux distributions, has picked up an AI coding assistants policy of its own, recently merging a new section to its CONTRIBUTING.md file.

It reads as follows:

Authors are responsible for 100% of the code they submit. Do not send a patch you cannot explain, and do not send one you have not built and tested yourself. Write your own commit messages and Merge Request descriptions.

Those explain why you are making the change, which is the part a tool cannot know. Respond to review comments yourself. If you cannot discuss your own patch with a reviewer, it will not be merged.

Everything in the Legal section applies unchanged. You are the one certifying that the contribution can be released under LGPL-2.1-or-later. A tool cannot certify that for you.

Large machine-generated Merge Requests that no human has reviewed line by line will be closed.

Josephine Pfeiffer of Red Hat wrote the change and merged it herself on August 7, after maintainer approval. If you read the above, then you can see NetworkManager's version is quite simpler than Rust's tiered system. Right now, it is closer to the human-in-the-loop approach that we have already seen in LLVM's policy.

We are constantly seeing such moves. For instance, Codeberg's members recently voted to ban projects built mostly from AI-generated code, citing server strain and climbing hardware costs.

Time and again, we're getting more evidence that AI use can quickly degrade maintenance-focused work and infrastructure if left unchecked. As usual, the open source ecosystem will continue evolving according to what the use of AI dictates.

Enjoyed this update? Support independent Linux news coverage

It's FOSS has been helping people use Linux for the past 14 years. Help us stay independent from big tech. Become a Plus member, enjoy ad-free reading and get 5 eBooks.