AdieuToLogic
5 months ago
Perhaps the most telling portion of their decision is:
Quality concerns. Popular LLMs are really great at
generating plausibly looking, but meaningless content. They
are capable of providing good assistance if you are careful
enough, but we can't really rely on that. At this point,
they pose both the risk of lowering the quality of Gentoo
projects, and of requiring an unfair human effort from
developers and users to review contributions and detect the
mistakes resulting from the use of AI.
The first non-title sentence is the most notable to consider, with the rest providing reasoning difficult to refute.jjmarr
5 months ago
I've been using AI to contribute to LLVM, which has a liberal policy.
The code is of terrible quality and I am at 100+ comments on my latest PR.
That being said, my latest PR is my second-ever to LLVM and is an entire linter check. I am learning far more about compilers at a much faster pace than if I took the "normal route" of tiny bugfixes.
I also try to do review passes on my own code before asking for code review to show I care about quality.
LLMs increase review burden a ton but I would say it can be a fair tradeoff, because I'm learning quicker and can contribute at a level I otherwise couldn't. I feel like I will become a net-positive to the project much earlier than I otherwise would have.
edit: the PR in question. Unfortunately I've been on vacation and haven't touched it recently.
https://github.com/llvm/llvm-project/pull/146970
It's a community's decision whether to accept this tradeoff & I won't submit AI generated code if your project refuses it. I also believe that we can mitigate this tradeoff with strong social norms that a developer is responsible for understanding and explaining their AI-generated code.
bestham
5 months ago
IMO that is not your call to make, it is the reviews call to make. It is the reviewers resources you are spending to learn more quickly. You are consuming a “free” resource for personal gain because you feel that it is justified in your particular case. It would likely not scale and grind many projects to a halt at least temporarily if this was done at scale.
ororroro
5 months ago
The decision is made by llvm https://llvm.org/docs/FAQ.html#id4
user
5 months ago
AdieuToLogic
5 months ago
> I've been using AI to contribute to LLVM, which has a liberal policy.
This is a different decision made by the LLVM project than the one made by Gentoo, which is neither right nor wrong IMHO.
> The code is of terrible quality and I am at 100+ comments on my latest PR.
This may be part of the justification of the published Gentoo policy. I am not a maintainer of same so cannot say for certain. I can say it is implied within their policy:
At this point, they pose both the risk of lowering the
quality of Gentoo projects, and of requiring an unfair
human effort from developers and users to review
contributions ...
> LLMs increase review burden a ton ...Hence the Gentoo policy.
> ... but I would say it can be a fair tradeoff, because I'm learning quicker and can contribute at a level I otherwise couldn't.
I get it. I really do.
I would also ask - of the requested changes reviewers have made, what percentage are due to LLM generated changes? If more than zero, does this corroborate the Gentoo policy position of:
Popular LLMs are really great at generating plausibly
looking, but meaningless content.
If "erroneous" or "invalid" where the adjective used instead of "meaningless"?jjmarr
5 months ago
I would also ask - of the requested changes reviewers have made, what percentage are due to LLM generated changes? If more than zero, does this corroborate the Gentoo policy position of "Popular LLMs are really great at generating plausibly looking, but meaningless content."
I can only speak for my own PR, but most requested changes were related to formatting and other stylistic issues that I didn't fully grasp as a new LLVM contributor. e.g. Not wrapping at 80 characters, forgetting to declare stuff as const, or formatting the documentation incorrectly.Previous codebases I've worked on during internships linted the first two in CI. And the documentation being formatted incorrectly is because I hand-wrote it without AI.
Out of the AI-related issues that I didn't catch, the biggest flaws were redundant comments and the use of string manipulation/parsing instead of AST manipulation. Useless comments are very common and I've gotten better at pruning them. The AI's insistence on hand-rolling stuff with strings was surprising and apparently LLVM-specific.
However, there was plenty of erroneous and invalid behaviour in the original AI-generated code, such as flagging `uint32_t` because the underlying type was an `unsigned int` (which wouldn't make sense as we want to replace `unsigned int` with `uint32_t`).
I prevented most of this from reaching the PR by writing good unit tests and having a clear vision of what the final result should look like. I believe this should be a basic requirement for trying to contribute AI-generated code to an open-source project but other people might not share the same belief.
user
5 months ago
benreesman
5 months ago
I'm a bit later in my career and I've been involved with modern machine learning for a long time which probably affects my views on this, but I can definitely relate to aspects of it.
I think there are a couple of good signals in what you've said but also some stuff (at least by implication/phrashing) that I would be mindful of.
The reason why I think your head is fundamentally in a good place is that you seem to be shooting for an outcome where already high effort stays high, and with the assistance of the tools your ambition can increase. That's very much my aspiration with it, and I think that's been the play for motivated hackers forever: become as capable as possible as quickly as possible by using every effort and resource. Certainly in my lifetime I've seen things like widely distributed source code in the 90s, Google a little later, StackOverflow indexed by Google, the mega-grep when I did the FAANG thing, and now the language models. They're all related (and I think less impressive/concerning to people who remember pre-SEO Google, that was up there with any LLM on "magic box with reasonable code").
But we all have to self-police on this because with any source of code we don't understand, the abstraction almost always leaks, and it's a slippery slope: you get a little tired or busy or lazy, it slips a bit, next thing you know the diff or project or system is jeopardized, and you're throwing long shots that compound.
I'm sure the reviewers can make their own call about whether you're in an ok place in terms of whether you're making a sincere effort or if you've slipped into the low-integrity zone (LLVM people are serious people), just be mindful that if you want the most out of it and to be welcome on projects and teams generally, you have to keep the gap between ability and scope in a band: pushing hard enough to need the tools and reviewers generous with their time is good, it's how you improve, but go too far and everyone loses because you stop learning and they could have prompted the bot themselves.
m463
5 months ago
This comment seems to use "I" a lot.
jlebar
5 months ago
As a former LLVM developer and reviewer, I want to say:
1. Good for you.
2. Ignore the haters in the comments.
> my latest PR is my second-ever to LLVM and is an entire linter check.
That is so awesome.
> The code is of terrible quality and I am at 100+ comments on my latest PR.
The LLVM reviewers are big kids. They know how to ignore a PR if they don't want to review it. Don't feel bad about wasting people's time. They'll let you know.
You might be surprised how many PRs even pre-LLMs had 100+ comments. There's a lot to learn. You clearly want to learn, so you'll get there and will soon be offering a net-positive contribution to this community (or the next one you join), if you aren't already.
Best of luck on your journey.
close04
5 months ago
> They know how to ignore a PR if they don't want to review it
How well does that scale as the number of such contributions increases and the triage process itself becomes a sizable effort?
LLMs can inadvertently create a sort of DDoS even with the best intentions, and mitigating it costs something.
jjmarr
5 months ago
Thanks. I graduated 3 months ago and this has been a huge help.
thesz
5 months ago
> You might be surprised how many PRs even pre-LLMs had 100+ comments
What about percentages?jubalfh
5 months ago
here's to the hope you get banned from contributing to llvm.
JonChesterfield
5 months ago
This is exciting. Thank for for raising the point. I've posted https://discourse.llvm.org/t/our-ai-policy-vs-code-of-conduc... to see what other people think of this. Thank you for your commit, and especially for not mentioning that it's AI generated code that you don't understand in the review, as it makes my point rather more forcefully than otherwise.
perching_aix
5 months ago
graceful...
> and especially for not mentioning that it's AI generated code
https://github.com/llvm/llvm-project/pull/146970#issuecommen...
irony really is dead
totallymike
5 months ago
[flagged]
tomhow
5 months ago
You can't comment like this on Hacker News, no matter what you're replying to. You've been on HN a long time and we've never had to warn you before, but please take a moment to read the guidelines and make an effort to observe them, especially these ones:
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Please don't fulminate. Please don't sneer, including at the rest of the community.
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
0000000000100
5 months ago
Go look at the PR man, it's pretty clear that he hasn't just dumped out LLM garbage and has put serious effort and understanding into the problem he's trying to solve.
It seems a little mean to tell him to stop coding forever when his intentions and efforts seem pretty positive for the health of the project.
jjmarr
5 months ago
I didn't make a decision on the tradeoff, the LLVM community did. I also disclosed it in the PR. I also try to mitigate the code review burden by doing as much review as possible on my end & flagging what I don't understand.
If your project has a policy against AI usage I won't submit AI-generated code because I respect your decision.
noosphr
5 months ago
That's no different to on boarding any new contributor. I cringe at the code I put out when I was 18.
On top of all that every open source project has a gray hair problem.
Telling people excited about a new tech to never contribute makes sure that all projects turn into templeOS when the lead maintainer moves on.
MangoToupe
5 months ago
I think the project and reviewers are both perfectly capable of making their own decisions about the best use of their own time. No need to act like a dick to someone willing to own up to their own behavior.
sethammons
5 months ago
Your final sentence moved me. Moved to flagging the post, that is.
fuoqi
5 months ago
Well, some people just operate under the "some of you may die, but it's a sacrifice I am willing to make" principle...
thrownawayohman
5 months ago
[flagged]
JohnBooty
5 months ago
There are a number of other issues such the ethical and environmental ones. However, this one in isolation...
Popular LLMs are really great at
generating plausibly looking, but meaningless
content. They are capable of providing good
assistance if you are careful enough
I'm struggling to understand this particular angle.Humans are capable of generating extremely poor code. Improperly supervised LLMs are capable of generating extremely poor code.
How is this is an LLM-specific problem?
I believe part of (or perhaps the entire) the argument here is that LLMs certainly enable more unqualified contributors to generate larger quantities of low-quality code than they would have been able to otherwise. Which... is true.
But still I'm not sure that LLMs are the problem here? Nobody should be submitting unexpected, large, hard-to-review quantities of code in the first place, LLM-aided or otherwise. It seems to me that LLMs are, at worst, exposing an existing flaw in the governance process of certain projects?
wodenokoto
5 months ago
It means, if you can’t write it, they don’t trust you to be able to evaluate it either.
As for humans who can’t write code, their code doesn’t tend to look like they can.
user
5 months ago
SAI_Peregrinus
5 months ago
> Nobody should be submitting unexpected, large, hard-to-review quantities of code in the first place,
Without LLMs, people are less likely to submit such PRs. With LLMs they're more likely to do so. This is based on recent increases in such PRs pretty much all projects have seen. Current LLMs are extremely sycophantic & encourage people to think they're brilliant revolutionary thinkers coming up with the best <ideas, code, etc> ever. Combined with the marketing of LLMs as experts it's pretty easy to see why some people fall for the hype & believe they're doing valuable work when they're really just dumping slop on the reviewers.
29athrowaway
5 months ago
LLMs trained on open source make the common mistakes that humans make.
wobfan
5 months ago
> make.
No, made. Which is a very important difference.
perching_aix
5 months ago
[flagged]
AdieuToLogic
5 months ago
[flagged]
johnfn
5 months ago
But it's also difficult to prove it correct by argument or evidence. "Refute" is typically used in a context that suggests that the thing we're refuting has a strong likelihood of being true. This is only difficult to prove incorrect because it's a summary of the author's opinion.
perching_aix
5 months ago
[flagged]
paulcole
5 months ago
How is it telling at all?
It’s just what every other tech bro on here wants to believe, that using LLM code is somehow less pure than using free-range-organic human written code.