The Rust programming language project published a formal LLM policy today that does something most companies are still avoiding: it draws a clear line between what AI tools are for and what they are not for.

Five teams within the rust-lang/rust monorepo have adopted the policy. It applies to contributions to the core repository, not to the broader Rust ecosystem or third-party crates. But the signal it sends matters well beyond Rust itself.

What the Policy Actually Says

The Rust LLM policy does not ban AI tools outright. It separates private use from public contribution.

Permitted with disclosure:

• Using an LLM to answer questions or analyze code for your own understanding
• Machine translation of content
• Trivial code or prose changes
• Bug discovery that a contributor verifies themselves

Prohibited:

• LLM-generated documentation, including doc comments and safety comments
• Multi-paragraph source code comments written by AI
• Compiler diagnostic messages produced by AI
• Non-trivial code generated by LLMs without full contributor understanding and ownership

PR authors must disclose when LLMs were involved. Reviewers can close non-compliant contributions without further explanation.

The philosophy is clear: LLMs may assist, analyze, and suggest, but they may not create. The contributor must own and understand everything they submit.

Why This Is Happening Now

This is not a fringe position. Codeberg, a European open-source hosting platform, banned LLM-generated code projects entirely in July 2026. Many maintainers of major open-source projects have started requiring disclosure of AI tool use in pull requests.

The concern is not that AI tools are useless. It is that AI-generated contributions are creating a volume problem. PRs that look complete on the surface but contain subtle errors, incorrect safety assumptions, or misunderstood invariants are harder to review than obviously rough contributions. The review burden is rising while signal quality drops.

For a language like Rust, where safety guarantees are the entire value proposition, a PR with an AI-hallucinated safety comment is not just wrong, it is actively dangerous.

The Distinction That Matters

The Rust policy articulates something that most AI governance frameworks gloss over: the difference between AI as a tool and AI as an agent.

When you use an LLM to understand a concept, verify an approach, or check your thinking, you are still the author. The AI is a reference tool, like a search engine or a colleague. When you ask an LLM to write the code and submit it with minimal review, you are delegating authorship while retaining liability. That gap is where problems live.

This is not a debate unique to open source. Enterprise software teams are navigating the same territory. A codebase where developers cannot explain the code they committed is a liability, regardless of whether it was written by a junior engineer or a language model.

What This Means for Business

If your team uses AI coding tools, the Rust policy is a useful prompt for a conversation you should already be having.

Do your developers own what they commit? The productivity gains from AI-assisted development are real, but they require a different review process. Code written by AI needs a human who can genuinely verify correctness, not just plausibility.

Are you building governance before you build volume? The biggest risk with AI-generated code is not that it is wrong, it is that it is wrong in ways that are hard to detect at scale. Review processes designed for human-paced contribution do not automatically scale to AI-paced contribution.

Is your documentation trustworthy? AI-generated documentation often sounds authoritative and reads smoothly. It also has a tendency to be subtly incorrect about edge cases. If your engineering team cannot distinguish between documentation they wrote and documentation an LLM wrote, that is a governance problem.

The Broader Pattern

The Rust policy reflects a maturation in how technical communities are thinking about AI tools. The initial wave was adoption. The current wave is calibration.

What is AI good at? Where does it create risk? Where do its outputs need to be verified before they become part of a shared system?

These are not anti-AI questions. They are engineering questions. And they are the same questions that serious businesses should be asking about every part of their AI strategy, from the tools developers use to the agents running in production.

Enterprise DNA’s view is straightforward: AI should make your team more capable, not less accountable. The Rust project is drawing a line in exactly the right place. The contributor is responsible for what they contribute. AI tools are part of how they work, not a substitute for that responsibility.

---

Thinking about how AI fits into your team’s workflow? The distinction between AI as a productivity tool and AI as a replacement for human judgment is one of the most important conversations business leaders need to have right now. Talk to Enterprise DNA about building an AI strategy that makes your team more capable without creating new risks.