This is a discussion thread for rust-lang/rust's new LLM policy, which has been merged in rust-forge#1040. You can find more information about that policy in the blog post. Please comment here, not on the Forge or blog PRs.
Please remember to respect the Code of Conduct at all times.
You disclosed the secret of git diff --check! Now we'll have to find another signal 
So does this ban writing code (or other text) using speech to text with an LLM to help correct misheard (which is a thing these days)? If so that is highly problematic from an accessibility point of view.
Similarly, what about "smarter tab complete" style AI, which helps reduce the number of keystrokes, but doesn't really go off and do it's own slop thing (unlike agentic AI)? Again, this is an accessibility concern for me as I have RSI in both wrists.
The policy does not directly say anything about speech-to-text. I would consider that to be allowed without disclosure.
what about "smarter tab complete" style AI, which helps reduce the number of keystrokes, but doesn't really go off and do it's own slop thing (unlike agentic AI)
the policy says this:
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.
and this:
...
All uses under “
...
“Trivial” code or prose changes.
Changes are trivial if there is no other way to write them, or the other ways to write them are nearly identical. For example, the following are all trivial:
- Typo fixes
- Markdown links
- Changing a word to a synonym
- Type signatures for a trait implementation
I think the disclosure requirement here is probably overboard and would be open to making that less restrictive.
The way I use tab completion AI is very similar to old style intellisense: I know exactly what I want to write, the computer shows some suggestion, and sometimes I can press tab instead of writing the words by myself. There is really no room for slop there, but it saves my wrists.
On the other hand, I have seen even tab completion style AI able to answer some things I don't know myself, such as writing a bash style comment describing what I want and getting an obscure ffmpg command line on the next line.[1]
Interestingly, AI tends to be far worse at generating working sed expressions, those I have to write myself, but I also know sed syntax by heart. ↩︎
Something entirely different, as a Rust user who only watched this: Huge thanks to @jyn for writing the policy and blog post, going through the long-winded review process, moderating a tight corridor between frustration and hostility, coming to the merge, then thinking of and creating dedicated avenues like this one, while being transparent and open during the entire period. That is highly impressive and commendable!
A modefully similar thank-you extends to other contributors on rust-forge#1040! I truly believe that the policy you all came out with is a solid transient optimum between {actionability,clarity,complexity,length,malleability} until we can come up with a project-scoped policy. :3
the main issue with discussing "smarter tab complete" is that it is very broad (and i don't use LLMs at all so idk what the current trend among implementations as tab completion is), it could mean
LLM companies generally want 2 or 1.
1 depends very heavily on context (e.g. is the output an entire function from 5 words or if let Some(x) = foo() { return x } in response to foo().ret_some)
2 sounds like a nigthmare
3 would likely be allowed as its trivial,
4 technically doesn't generate new code, so it'd likely be allowed
5 would also not be generating any code, so it'd likely be allowed
thank you so much <3 i’m still kind of amazed this actually happened
GH copilot's tab completion does a lot of different things.
My impression is (purely based on use) is that it is stateful - it sees what you just edited - and essentially suggesting diffs within the current file and the size and scope of those diffs varies a lot. It also reads adjacent comments. It might also be looking at LSP errors and trying to offer fixes for that, not sure.
Personally I find that its nonsense output rate to be fairly high, both on simple and complex changes. It's also using an older model compared to the chat stuff. Often its changes are trivial, but sometimes when it vomits out larger blocks those can be almost right yet subtly wrong.
So unfortunately its range is wide enough that I wouldn't write it off as always-insignificant.
I fully sympathize with all the reviewers who are inundated with low-quality work submitted by clueless developers. The Rust project has always stood for well-thought out design and quality, and must take a strong stance against that. However, I believe the new policy and its framing don't strike the right balance, at all.
The current policy and its framing create a presumption of inferiority around LLM-assisted contributions, as opposed to judging contributions on their merits. I am a long-time Rust community member since before 1.0. I have over 100 high-quality PRs to the Rust repository to my name over the course of more than a decade. I have silver “good share” and “gives back” badges on this forum. I can continue talking about my credentials but I think the picture is clear. I can confidently say that when I submit a contribution for review to the Rust project that it is of the highest quality possible for me to create without peer review. I dare say that using LLM tools actually allows me to produce contributions of higher quality than previously possible. Yet, because of this new policy, the community feels justified to automatically relegate my contribution to the “slop” queue. My Zulip request for review is moved to the “#llm-mentoring” channel; I don't need mentoring, thank you very much. This is all extremely patronizing, bordering on insulting. It should be abundantly clear to everyone by now that LLM-assisted software development is here to stay. I urge the community to urgently change the policy by looking towards the future instead of holding on to the past.
This post was written with a computerized text editor without using a dictionary, spell-checker or LLM. I create the “ character by typing Shift+AltGr+[. Thank you.
I understand how this sucks. Maybe it helps that the ones who didn't want anything to do with LLMs also had a bad last 12 months and aren't suddenly cheering in unrestrained happiness with the policy either.
As you said, you've been doing this for over a decade, meaning not having LLMs hasn't stopped you before. While we're figuring out if, when, and how LLM contribs can be allowed again, please refrain from using LLMs to create until then. There are explicit experiments going on that will allow us to refine our policy in the future. There will also be a survey for maintainers and recent contributors to gauge the general community sentiments in more fine grained ways than "yes/no to the entire concept of LLMs"
If it's genuinely transcribing your words (using context at most to make sure it doesn't mishear, or to disambiguate identically pronounced things like whether "foo bar" means "foo_bar" or "FooBar"), rather than interpreting your intent (e.g. you probably meant this other variable which definitely isn't what you said), I would not expect that to be in the same category as using a voice-enabled LLM to give the LLM instructions to write code for you.