Nelson: rust-lang/rust is adopting an LLM policy [LWN.net]

Jynn Nelson describes the Rust language team's new LLM policy on the Inside Rust blog.

No one except the author is required to read LLM output unless they choose to: LLM output isn't allowed in public docs, PR descriptions, or Github comments unless it's clearly marked; reviewers aren't required to look at LLM PRs if they don't want to.
No one is required to use LLMs to contribute to rust-lang/rust: policies must be written first for humans, and only summarized for machines; LLM reviews cannot substitute for human review or self-review.
You are allowed to generate LLM content that only you see, without disclosure, as long as you do not post it anywhere that you expect us to read or review.

to post comments

Balanced

Posted Aug 5, 2026 19:08 UTC (Wed) by josh (subscriber, #17465) [Link] (14 responses)

The most important part of the summary, I think:

> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**.

This seems like a fine position to take.

Balanced

Posted Aug 5, 2026 23:18 UTC (Wed) by bojan (subscriber, #14302) [Link] (13 responses)

Right. So you use an LLM to suggest something, which ends up being a patch. But then you cannot use it to create a change? Okay...

Balanced

Posted Aug 5, 2026 23:58 UTC (Wed) by intelfx (subscriber, #130118) [Link] (12 responses)

Right. So you use an LLM to suggest something, which ends up being a patch. But then you cannot use it to create a change? Okay...

Well, the intention here, most likely, is that in the process of manually converting a suggestion into a patch the contributor would have a better chance of actually understanding his own patch and the problem he is solving (or scrapping it, if LLM’s suggestion turns out to be bogus slop).

It is a reasonable policy (in this part).

Balanced

Posted Aug 6, 2026 9:11 UTC (Thu) by kleptog (subscriber, #1183) [Link] (11 responses)

> Well, the intention here, most likely, is that in the process of manually converting a suggestion into a patch the contributor would have a better chance of actually understanding his own patch and the problem he is solving (or scrapping it, if LLM’s suggestion turns out to be bogus slop).

So if you're coding and the (LLM) autosuggest comes up with the same code as you would have typed, the process of typing exactly the letters you see on the screen improves your understanding of the code? Instead of just hitting Tab to accept the suggestion? Why do we not apply the same criteria for variable name autocompletion or spelling corrections?

I find the AI assistance most helpful in code bases I'm less familiar with. When I ask it to make a change, it will locate all the places that need to be changed and adjusts them as well. It updates database schema, fixes the API documentation, figures out how to run the test cases, creates new ones and fixes issues it finds. By examining the patch that comes out I can quickly learn how the code base is structured and indirectly the quality of the code base.

Asking for me to retype the entire patch again just isn't going to fly then. But it's open source, so I can also just push it to my repo and use it myself and just not submit it. If someone else likes it they can retype it for submission.

Balanced

Posted Aug 6, 2026 9:17 UTC (Thu) by josh (subscriber, #17465) [Link]

In a project that does not accept AI-written code, you shouldn't be having the AI write code for you. And agent instructions in the project can help with that. The point is not to turn you into a typist for the AI.

You can get AI to track things down for you, answer questions for you, find bugs for you, evaluate potential research alternatives for you.

Balanced

Posted Aug 6, 2026 10:01 UTC (Thu) by mb (subscriber, #50428) [Link] (7 responses)

the process of typing exactly the letters you see on the screen improves your understanding of the code? Instead of just hitting Tab to accept the suggestion?

Yes, that is pretty much how our brains work. Actually writing down things makes our brain think about it more than just reading it. The effect is even bigger, if you write it down by hand on paper.

Why do we not apply the same criteria for variable name autocompletion

I think the effect is also there for traditional autocompletion, but much less. AI autocompletion can give you whole sections of code.

When I ask it to make a change, it will locate all the places that need to be changed and adjusts them as well.

For large codebases this doesn't work perfectly and I see parts getting missed frequently. Just because the AI agent does not actually read all the code. It rather navigates by a combination of guessing and grepping. Which works really really well, but not perfect.

Asking for me to retype the entire patch again just isn't going to fly then.

Yeah, well. I think the idea is different from that. I also typically slowly go through generated code and make minor adjustments here and there manually. What happens is that by doing that I frequently find bigger mistakes that actually matter. Cool down, take a step back, take your time, do seemingly nonproductive things like typing and minor changes. That is what improves code quality after AI generation a lot. With an end result much better than what I could typically could have come up with without AI.

While I do not agree to all the rules established here, I think in general it's a good thing to have the biggest no-gos being written down (e.g. Do not generate long PR texts) and to establish guard rails for how to use AI tools correctly.

Balanced

Posted Aug 6, 2026 11:26 UTC (Thu) by kleptog (subscriber, #1183) [Link] (4 responses)

>Yeah, well. I think the idea is different from that. I also typically slowly go through generated code and make minor adjustments here and there manually. What happens is that by doing that I frequently find bigger mistakes that actually matter. Cool down, take a step back, take your time, do seemingly nonproductive things like typing and minor changes. That is what improves code quality after AI generation a lot. With an end result much better than what I could typically could have come up with without AI.

I agree, that's what I do too. It gets the "boring code"-generation[*] step out of the way and lets me get to the meat. Like you read the generated code and think "why did it do this?" and then you realise that there was some case you missed entirely, or it made some incorrect assumption. Revealing hidden assumptions is something they are good at. So you clarify that and let it go again until it gets something that I intended.

The rust-lang/rust project doesn't like this workflow and I agree they have the right to reject it. I just doubt they can enforce it and whether they can hold that line long term.

[*] There is such thing as interesting coding, but stuff like "add this parameter to this API and fix all the places that need to know about this change/add checkbox to modify this field in the database/add support for disabling TLS certificate verification" is for me "boring coding".

Balanced

Posted Aug 6, 2026 12:26 UTC (Thu) by mb (subscriber, #50428) [Link] (3 responses)

>The rust-lang/rust project doesn't like this workflow

Of course the policy leaves much room for interpretation, but I do not read it this way.

>>It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.
>>Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

In my view the process I described it not to *create*. It is *suggest*.
I as a human take this AI suggestion and then create the artifact.

Balanced

Posted Aug 6, 2026 15:08 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (2 responses)

>>It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create. Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

>Of course the policy leaves much room for interpretation, but I do not read it this way In my view the process I described it not to *create*. It is *suggest*. I as a human take this AI suggestion and then create the artifact.

I don't think the policy leaves any room for interpretation, it contains a subsection specifically clarifying that the process you're describing falls under "originally created by an LLM" and is subject to the disclosure restrictions of the policy:

The meaning of “originally created by an LLM”

This document uses the phrase “originally created by an LLM” to mean “text that was generated by an LLM (and then possibly edited by a human)”. No amount of editing can change how it was originally created; the origin sets the initial style, and that style is very hard to change once it’s set.

For more background about analogous reasoning, see “What Colour are your bits?”.

This policy makes no distinction between LLM output that comes from a chat interface and output that comes from editor auto-completion. In most cases the output is “trivial” (see above under ⚠️), but regardless, it is not treated specially by this policy.

Balanced

Posted Aug 6, 2026 15:28 UTC (Thu) by mb (subscriber, #50428) [Link]

Sure. But this doesn't mean that "The rust-lang/rust project doesn't like this workflow".
They just demand it to be disclosed.

Balanced

Posted Aug 6, 2026 23:02 UTC (Thu) by intelfx (subscriber, #130118) [Link]

This policy makes no distinction between LLM output that comes from a chat interface and output that comes from editor auto-completion. In most cases the output is “trivial” (see above under ⚠️), but regardless, it is not treated specially by this policy.

Yeah, okay, I take my "reasonable" assessment back. There is no way in hell I am "disclosing LLM usage" in each and every commit just because the full-line code completion in my editor is technically LLM-powered.

Balanced

Posted Aug 6, 2026 15:07 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

Actually writing down things makes our brain think about it more than just reading it.

100% agreed. And also, I can't tell you how many times I've written code, and then started writing documentation for it (on various levels, from code descriptions meant for programmers all the way to user guides) and in the process of writing the documentation, realized that there were many improvements to be made to the code.

Balanced

Posted Aug 6, 2026 18:35 UTC (Thu) by madscientist (subscriber, #16861) [Link]

If you're like me, at least, "how many times" is "every one of the times" :smile:

Oh, no markdown emojis.

Balanced

Posted Aug 6, 2026 17:16 UTC (Thu) by Wol (subscriber, #4433) [Link]

> So if you're coding and the (LLM) autosuggest comes up with the same code as you would have typed, the process of typing exactly the letters you see on the screen improves your understanding of the code? Instead of just hitting Tab to accept the suggestion? Why do we not apply the same criteria for variable name autocompletion or spelling corrections?

Dangerous assumption! I get where you're coming from, we're perfectly happy with spill-chuckers, why not LLMs if they're merely auto-completing what we would have typed. BUT.

As we move from spelling correction to chunks of code, the clue is in the word "chunks". The bigger the chunks we "tab" accept, the bigger the likelihood we see what we expect/want to see, not what is actually there!

Not that we're necessarily any better at typing in what we meant - the number of times I hit "post", only to quickly realise that part of what I was typing didn't make it from brain to screen via keyboard ...

Cheers,
Wol

Balanced

Posted Aug 6, 2026 21:21 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

My reading of the policy is as follows:

* If you just want to generate patches for your own private use, do whatever you want.
* If you want to submit patches for inclusion in Rust, they should be written from scratch.
* In either case, you can ask an LLM to generate English that explains how the code works and what needs to be changed, and then follow those instructions to write a patch yourself. That still counts as "written from scratch," because the LLM did not create any of the code.