@bagder i feel like “pretty please don’t use LLMs” is not too bad a policy imo:

though, maybe being more explicit about the goals rather than “pretty please don’t use LLMs” may be better!

@bagder This is a good question and you raised an important point. Ultimately I agree with Ell1e's suggestion.

Perhaps it's not wholly enforceable or wholly definable in easy to colour in lines.

But i think it is necessary.
If i were to hazard an answer to your question, I would say LLM is code generated by a large language model, even if modified.

There might be concerns on when contribution from LLMs is meaningful to matter, but I think the problem is larger than the output 1/2

@bagder
how about
"If you send a PR, it's your responsibility to ensure no plagiarism. By the way, here are all the reasons to think that it's impossible to do when using an LLM."
?

I guess it's more CYA-ish than you'd like, but I think it'd discourage use of LLMs without having to define what use of LLMs is.

@bagder > I don't think anyone questions that LLMs can produce a lot of junk.

Oh, but they do! I promise you there are people who think LLMs are infallible. The creator of OpenClaw claimed to make 600 unreviewed commits a day and that none of them were slop. Which is a level of bananas delusion on par with AI psychosis (another group of people who don’t think LLMs produce junk). Also, did you know there are people “dating” their chatbot?

> Before this, we had people copying bad code suggestions from stackoverflow and the ever present "just confused" people. There are many ways to get bad code.

With the very important difference that LLMs produce bad code *at scale*. But you know this. It’s only because of LLMs that you had to scrap the bug bounty.

@bagder to respect not weighing in on a project I have not participated in development on before, here's what I would have replied on the issue:

I think there are generally three issues raised with contributions (notice I did not say code) that involve the use of an LLM:

Although point 1 is often the most talked about, it is the simplest to deal with. LLMs can introduce errors, but they can also spot them. The code review process is meant to find these errors and as time goes on if it is deficient then the review process is amended. A balance for quality will eventually be found.

Point 2 is also alarming, but mostly follows point 1 - the code review process should involve a component of trying to identify re-use of prior art or plagarism. Good faith efforts go a long way for open source projects, especially ones as well-run as curl. However, if the project does not require attestation from the submitter of the PR that they did not use illegal content or content they do not have the rights to contribute then the project takes that risk on themselves. I think asking contributors to attest that their submission is original and they can legally contribute it to the project is a simple way to reduce the risk of legal issues.

Point 3 is the big question mark. Some jurisdictions have created a legal environment where it's not clear LLM output can be copyrighted which has implications as to whether LLM output can even be licensed or if one can enforce any kind of software license for a project with LLM output. This landscape might change drastically and/or rapidly and makes including LLM output a risk, one that I don't see a sufficient mitigation for except to bar submissions that used LLMs and ask contributors to attest that LLMs did not produce the output or meaningfully contribute. I would say using an LLM for reference material or syntax help might be safe, but even with this example, there's no certainty that this would be safe usage.