Balanced [LWN.net]

Balanced

Posted Aug 5, 2026 19:08 UTC (Wed) by josh (subscriber, #17465)
Parent article: Nelson: rust-lang/rust is adopting an LLM policy

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.

to post comments

Balanced

Posted Aug 5, 2026 23:18 UTC (Wed) by bojan (subscriber, #14302) [Link] (17 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] (16 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] (15 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] (11 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] (5 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 17, 2026 10:26 UTC (Mon) by taladar (subscriber, #68407) [Link] (3 responses)

Writing down things makes our brain do nothing in particular. That has been a hypothesis of teachers everywhere for decades but I can literally copy some text and forgot the words before the sentence is even over.

Writing it only helps us understand it better if we at the very least understand and rephrase it completely.

Balanced

Posted Aug 17, 2026 12:36 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Agree here. I'm about as likely to remember something I've written down as not. Heck, sometimes I refer to the docs for some sections of code as a coppermind because it is, basically, a distillation of my investigations of the code and that I, myself, couldn't explain again without investigating again.

Balanced

Posted Aug 17, 2026 13:20 UTC (Mon) by kleptog (subscriber, #1183) [Link] (1 responses)

> Writing down things makes our brain do nothing in particular. That has been a hypothesis of teachers everywhere for decades but I can literally copy some text and forgot the words before the sentence is even over.

I think it definitely varies by person. If I read something I remember it. If you tell me verbally I'll forget it almost immediately. I've known people swearing that for them writing makes the difference and I have no reason to doubt them. It wouldn't surprise me if typing and writing by hand work completely differently here.

The trick is to know what works for you. In my case, if someone says something I need to remember I immediately write it down so I can read it. After that I can throw it away.

Different folks, different strokes.

Balanced

Posted Aug 18, 2026 6:49 UTC (Tue) by taladar (subscriber, #68407) [Link]

I think in the teacher situation in particular what usually didn't help is that the teacher isn't transparent and so you are usually writing down what they said a few minutes ago after they moved to the next blackboard while also trying to follow what they are saying now which occupies the same part of your mind that the understanding of what you write would need.

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.