Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM Policy for Rust Compiler

github.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: LLM Policy for Rust Compiler

#81

Post by staticassertion »

lifthrasiir wrote: post #59
staticassertion wrote: post #41

Earlier quoted context omitted.

> even when the rust-lang/rust repository itself largely forbids vibe coding. This policy does not seem to forbid vibe coding?

It does in the narrower sense of vibe coding (as opposed to more general agentic coding, which is also called vibe coding from time to time...). > Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure. Vibe coding (in its original meaning) would have hard time arguing it's of high quality.

I guess that's the problem with the term. It should likely be left entirely out of a document like this since it's just confusing.

Re: LLM Policy for Rust Compiler

#82

Post by staticassertion »

WCSTombs wrote: post #50
staticassertion wrote: post #39

This policy is straightforward and shouldn't be particularly controversial (I'm sure it will be bikeshedded to death though). It basically bans the obvious stuff ("don't just drop LLM generated comments onto PRs") and allows the important stuff like LLMs writing code so long as you disclose. edit: Wow people did not read the policy. It's literally just "if you use an LLM you are responsible for it, we will reject low…

So...big caveat that this is still under review, so what we're talking about is a moving target, but based on what I can see, it seems considerably more nuanced than that. They basically ban LLM-authored code, with a careful carve-out to run an experiment to try to get only high-quality LLM PRs: > It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create. > We carv…

I think that the only significant caveat here is the need for reviewers to opt in, otherwise it's effectively "you can do it if you are open about it and are responsible for the output". The only notable ask here that's different from other policies is "if it's an LLM, tell reviewers beforehand".

TBH I think that makes no sense ("I have an LLM written PR ready, can I open it?") but yeah the policy is also in draft and has actually already changed since my first comment.

Re: LLM Policy for Rust Compiler

#83

Post by staticassertion »

singularity2001 wrote: post #66
staticassertion wrote: post #39

This policy is straightforward and shouldn't be particularly controversial (I'm sure it will be bikeshedded to death though). It basically bans the obvious stuff ("don't just drop LLM generated comments onto PRs") and allows the important stuff like LLMs writing code so long as you disclose. edit: Wow people did not read the policy. It's literally just "if you use an LLM you are responsible for it, we will reject low…

"allows the important stuff like LLMs writing code so long as you disclose." Are you sure? It says: "It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to *create*."

Yes. The policy is pretty clear on what the rules are for LLM generated code. You need a reviewer to agree to review LLM generated code, you need to read the code yourself, etc.

Re: LLM Policy for Rust Compiler

#84

Post by bcjdjsndon »

bendmorris wrote: post #80
bcjdjsndon wrote: post #79

Earlier quoted context omitted.

> It also doesn't matter what your politics are in the Rust community Largely true, apart from the trans issue. Refuse to agree a man is a woman because he says it's true, and you're a bigot

You don't have to agree to treat people with respect. Using someone's preferred pronouns doesn't hurt you.

[flagged]

Re: LLM Policy for Rust Compiler

#85

Post by cjjrkfokrr »

bcjdjsndon wrote: post #84
bendmorris wrote: post #80

Earlier quoted context omitted.

You don't have to agree to treat people with respect. Using someone's preferred pronouns doesn't hurt you.

[flagged]

You are free to believe what you want.

If you find it that hard to keep those feelings to yourself in the context of contributing to rust, and are too stubborn to make a one character change to pronouns when you’re addressing people, I have to imagine that you’re utterly incapable of working in any professional context, where you’re expected to conform to many more things that make less sense. This seems like a problem with you.

Re: LLM Policy for Rust Compiler

#86

Post by OptionOfT »

I like the 'better, but not faster' phrasing.

I'm not gonna say no to some system that validates my code before I present it as a PR, and if said system (it being static checking, dynamic checking, or LLM), gives me a 'comment', I will interpret the output, validate, and decide whether to take action, and how.

And maybe there I disagree a little with the proposal. It's me, it's my code. I stand behind it. But I get where the authors come from, and I believe it's a fine compromise.

I think more importantly in the world of Software Engineering we're seeing a split.

On one hand, people who go all-in on AI and take the output as 100% correct, copy-paste it as theirs without reviewing, prompt it to create PRs and submit them as-is, and worse, as their own.

Then there is the other side, people who use AI as a tool to validate and go deeper.

The problem with the first group that everywhere they feel entitled to shift the validation onus from themselves to the receipient of what they're sending, it being PR or review comment or message or whatever.

In PRs now the repo maintainer has to do a lot more work, as they cannot rely on the social construct of "OptionOfT wrote this, they have 10+ years of experience in these and these systems, so we can look at the PR through that lens".

Equally, I've been on the receiving end of AI PR comments (the PR was human-authored), but copy-pasted by humans, presenting the comment as their own, without properly (if anything) validating the correctness of the comment, or whether it actually makes sense for the PR. Lots of derailment there. This now increases the workload of the PR author, as above. We need to validate and cannot rely on the social construct. Is the comment even correct? What's the context? Why? Is it a hallucination?

And the downside is that it looks like the first group is now going faster, but the second group is actually slowing down due to the increased burden.

Re: LLM Policy for Rust Compiler

#87

Post by 3836293648 »

bcjdjsndon wrote: post #68
saagarjha wrote: post #49

Earlier quoted context omitted.

The assumption here is that people act in good faith. If you break the rules, this indicates that you are not acting in good faith, and perhaps should no longer be welcome.

Sounds very welcoming. I came here for the code, not to join some social club

Then don't go interact with the social club?

If you want to interact with their project, follow their rules on their terms, otherwise just grab the binaries and don't stir things up.

Re: LLM Policy for Rust Compiler

#88

Post by griffid »

bendmorris wrote: post #80
bcjdjsndon wrote: post #79

Earlier quoted context omitted.

> It also doesn't matter what your politics are in the Rust community Largely true, apart from the trans issue. Refuse to agree a man is a woman because he says it's true, and you're a bigot

You don't have to agree to treat people with respect. Using someone's preferred pronouns doesn't hurt you.

https://fairplayforwomen.com/pronouns

A dissenting view.

Re: LLM Policy for Rust Compiler

#90

Post by jojomodding »

bcjdjsndon wrote: post #70
def13 wrote: post #61

Earlier quoted context omitted.

The point here if you read contributor comments is mainly to allow people to shut a PR down without having claims of “unfairness” because some other PR wasn’t shut down. These are “moderation policies” in the style of old internet forums, their primary purpose is to clear up ambiguity and make maintainer’s (moderators) lives easer. The birth of vibe coding has seen interactions on public FOSS projects increasingly re…

> probably because no maintainer really wants to be a moderator, but thats where its naturally landed unfortunately. Yeah this is autistic bunk. If you run an open source project, dealing with people is part and parcel of it, disagreements as well.

Not sure what is particularly autistic about the observation that "couldn't we just all get along" is unfortunately not how the world works even if we would like it to?
Post reply on HN