Does the policy fix the issue of many low quality PRs being submitted? Unlikely.
Will it fix a related but different problem? Likely.
LLM Policy for Rust Compiler
21–30 of 94 posts
Re: LLM Policy for Rust Compiler
#22Here are the actual policies, not a comment: https://github.com/jyn514/rust-forge/blob/llm-policy/src/pol... It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: > The following are allowed. > Asking an LLM questions about an existing codebase. > Asking an LLM to summarize comments on an issue, PR, or RFC... Like serio…
> Like seriously, what's the point of explicitly allowing this? Imagine the opposite were true, you weren't allowed to do this - what would they do?
Imagine if they just say "LLMs are banned" then there's a lot of ambiguity. So they specifically outlined that generative uses of LLMs are banned, and that non-generative ones are not banned (i.e. "allowed").
I think it's a poor choice of words on their part, but it makes sense (considering what their policy is). It's more of a "we're not disallowing use in these particular scenarios, so you can still use LLMs for these if you want". Remember: it's a big project, and if they don't explicitly state something then people will ask and waste everyone's time.
Re: LLM Policy for Rust Compiler
#23[flagged]
Please do fork Rust and maintain it for the LLM true believers. I’m sure the real rust team would be delighted to see fewer low-effort PRs.
Given what you’ve said above it would be an easy task ‘accelerating quality and features exponentially’, so you’ll soon be able to show them (perhaps within days!), the error of their ways.
Please go do it now, we’ll wait.
Re: LLM Policy for Rust Compiler
#24Here are the actual policies, not a comment: https://github.com/jyn514/rust-forge/blob/llm-policy/src/pol... It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: > The following are allowed. > Asking an LLM questions about an existing codebase. > Asking an LLM to summarize comments on an issue, PR, or RFC... Like serio…
> Like seriously, what's the point of explicitly allowing this? Imagine the opposite were true, you weren't allowed to do this - what would they do? Imagine if they just say "LLMs are banned" then there's a lot of ambiguity. So they specifically outlined that generative uses of LLMs are banned, and that non-generative ones are not banned (i.e. "allowed"). I think it's a poor choice of words on their part, but it make…
If anything, it reads to me as a proactive rebuttal of complaints that they don't allow LLMs; they're definitively stating that they do allow using them for very specific purposes.
Re: LLM Policy for Rust Compiler
#25[flagged]
I feel like I saw phrasing like this pretty often even before LLMs were a thing
Re: LLM Policy for Rust Compiler
#26Here are the actual policies, not a comment: https://github.com/jyn514/rust-forge/blob/llm-policy/src/pol... It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: > The following are allowed. > Asking an LLM questions about an existing codebase. > Asking an LLM to summarize comments on an issue, PR, or RFC... Like serio…
> Like seriously, what's the point of explicitly allowing this?
Explicit permission can be useful to preemptively cut off some questions from well meaning people who, acting in good faith, might otherwise pester for clarification (no matter how silly / "obvious" it might otherwise be), or get agitated by misconstruing an all-banned list as being an overly verbose "no LLMs ever" overreach.
> It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: [...]
Many of us work or have worked in corporate settings where IT takes great pains to help detect and prevent data exfiltration, and have absolutely installed the corporate spyware to detect those kinds of actions when performed on their own closed source codebases. Others rely on the honor system - at least as far as you know - but still ban such actions out of copyright/trade secret concerns. If you're steeped deeply enough in that NDA-preserving culture, a reminder that you've switched contexts might help when common sense proves uncommon.
While nannying can be obnoxious, I'm not sure that having a document one can point to/link/cite, to allay any raised concerns, counts.
Re: LLM Policy for Rust Compiler
#27Earlier quoted context omitted.
Nothing. You can always vibe-code in Rust even when the rust-lang/rust repository itself largely forbids vibe coding.
But one of the reasons they switched was because the compiler upstream for the original language they used, Zig, wouldn't accept slop contributions they wanted to make for Bun perf. What will they do when they need to try to push a slop contribution upstream to rust? At this point they will probably just fork yet again and maintain some vibe compiler.
Huh. I wonder if the original intent was to merge an AI generated PR to a high-profile project like Zig. It makes the headlines and generates hype. But that went embarassingly bad for them so they had "port Bun to Rust" as a backup.
Re: LLM Policy for Rust Compiler
#28Here are the actual policies, not a comment: https://github.com/jyn514/rust-forge/blob/llm-policy/src/pol... It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: > The following are allowed. > Asking an LLM questions about an existing codebase. > Asking an LLM to summarize comments on an issue, PR, or RFC... Like serio…
> Like seriously, what's the point of explicitly allowing this?
I would have LOVED if the university course I took last winter had this. I had to take a very paranoid attitude to what was allowed.
What they're trying to avoid is a lot of unnecessary conflict with zealous anti-AI people calling for your exclusion for admitting to doing these things. There are people who would ban this too.
Re: LLM Policy for Rust Compiler
#29This is highly interesting. It seems clear to me that a lot of thought and work went into this. If I ever were to write a similar document, I'm sure I could learn a lot from this one. Props to the authors and all involved.
Re: LLM Policy for Rust Compiler
#30Earlier quoted context omitted.
Nothing. You can always vibe-code in Rust even when the rust-lang/rust repository itself largely forbids vibe coding.
But one of the reasons they switched was because the compiler upstream for the original language they used, Zig, wouldn't accept slop contributions they wanted to make for Bun perf. What will they do when they need to try to push a slop contribution upstream to rust? At this point they will probably just fork yet again and maintain some vibe compiler.
Is there a citation for this? This was my suspicion but it's quite amazing if this was the actual reason for the bun spectacle