[CGamesPlay]

I make a lot of drive-by contributions, and I use AI coding tools. I submitted my first PR that is a cross between those two recently. It's somewhere between "vibe-coded" and "vibe-engineered", where I definitely read the resulting code, had the agent make multiple revisions, and deployed the result on my own infrastructure before submitting a PR. In the PR I clearly stated that it was done by a coding agent.

I can't imagine that any policy against LLM code would allow this sort of thing, but I also imagine that if I don't say "this was made by a coding agent", that no one would ever know. So, should I just stop contributing, or start lying?

[append] Getting a lot of hate for this, which I guess is a pretty clear answer. I guess the reason I'm not receiving the "fuck off" clearly is because when I see these threads of people complaining about AI content, it's really clearly low-quality crap that (for example) doesn't even compile, and wastes everyone's time.

I feel different from those cases because I did spend my time to resolve the issue for myself, did review the code, did test it, and do stand by what I'm putting under my name. Hmm.

[TingPing]

I think it’s disrespectful of others to throw generated code their way. They become responsible for it and often donate their time.

[CGamesPlay]

I think it's disrespectful to throw bad code on somebody else, regardless of its provenance. And (as a professional who uses AI coding agents) I understand that LLM code is often bad code. But the OP isn't complaining about the deluge of bad code being submitted as PRs, they're complaining about LLM code being submitted as PRs.

I've also been on the other side of this, receiving some spammy LLM-generated irrelevant "security vulnerabilities", so I also get the desire for some filtering. I hope projects don't adopt blanket hard-line "no AI" policies, which will only be selectively enforced against new contributors where the code "smells like" LLM code, but that's what I'm afraid will happen.

[cyphar]

(OP here.)

Well, we don't receive that many low-quality PRs in general (I opened this issue to discuss solutions before it becomes a real problem). Speaking personally, when it does happen I try to help mentor the person to improve their code or (in the case where the person isn't responsive) I sit down and make the improvements I would've made and explain why they were made as a comment in the PR.

When it comes to LLM-generated code, I am now going to be going back-and-forth with someone who is probably just going to copy-paste my comments into an LLM (probably not even bothering to read them). It just feels disrespectful.

> I hope projects don't adopt blanket hard-line "no AI" policies, which will only be selectively enforced against new contributors where the code "smells like" LLM code, but that's what I'm afraid will happen.

Well, this is a two-way street -- all of the LLM-generated PRs and issues I've seen so far do not say that they are LLM-generated, in a way that I am tempted to describe as "dishonest". If every LLM-generated PR was tagged as such, I might have a different outlook on the situation (and might instead be willing to reviewing these issues but with lower priority).

[CGamesPlay]

Thanks for the response here. I also read your follow-up on the Github issue. I definitely agree with you on the mentorship point. The "CPU quota allocation mismatch" issue felt particularly agitating to read from the point of view as a maintainer. Human being acting as a proxy for ChatGPT. Have you considered putting an "LLM usage disclosure" question on the issue/PR templates? Something like "To what extent were AI tools used to create this issue/PR? What validation steps did you perform to ensure accuracy?"

The "hard-line policy" would then shift from being "used LLM tools" to "lied on the LLM usage disclosure", and it feels a lot less like selective enforcement (from my perspective). Obviously it won't stop these spammy issues/PRs, but neither will a hard-line policy against all AI.

[cyphar]

I've been thinking about this a bit over the past few days, and I think this is a fairly reasonable middle ground (and also allows maintainers to decide how they wish to engage with LLM-generated work).

[grayhatter]

Hope you can forgive this tangent, I considered posting this in the GH thread, but you asked nicely not to... So hopefully this is a middle ground, you can excuse or ignore

First, my original comment was going to ask if you're looked at what any other reputable repos are doing. Specifically popular FOSS projects that are not backed by a company looking to sell AI. Do any of them have a positive Policy, or positions that you want to include?

Second, if I was forced to take a stand on AI, I would duplicate the policy from Zig. I feel their policy hits the exact ethos FOSS should strive for. They even ban AI for translations, because the reader is just as capable a participant. And importantly, asking the author to do their best (without AI), and trust the reader to also try their best encourages human communication. It also gives the reader control and knowledge over the exact amount of uncertainty introduced by the LLM, which is critically important to understanding a poor quality bug report from a helpful users who is honestly trying to help. Lobste.rs github disallows AI contribution for an entirely different reason I haven't seen covered in your GH thread yet

Finally, you posted the Issue as an RFC. but then explicitly excluded, HN from commenting on the issue. I think that was a fantastic decision, and expertly written. (I also appreciate that lesson in tactfulness :) ) That said, if you're actually interested in requesting comments or thoughts you wouldn't have considered, I would encourage you to make a top level RFC comment this thread. There will likely be a lot of human slop to wade through, but occasionally I'll uncover a genuinely great comment on HN that improves my understanding. Here I think the smart pro-AI crowd that might have an argument I want to consider, but would be unlikely to on my own because of my bias on the quality of AI. Such a comment might would be likely to appear on HN, but the smart people who I'd want to learn from, would never comment on the GH thread now, and I appreciate it when smart people I disagree with, contribute to my understanding.

PS Thanks for working on opencontainers, and caring enough to keep trying to make it better, and healthier! I like having good quality software to work with :)

[cyphar]

> I considered posting this in the GH thread, but you asked nicely not to... [...] you posted the Issue as an RFC. but then explicitly excluded, HN from commenting on the issue. I think that was a fantastic decision, and expertly written. (I also appreciate that lesson in tactfulness :) ) That said, if you're actually interested in requesting comments or thoughts you wouldn't have considered, I would encourage you to make a top level RFC comment this thread.

Well, I posted this as an RFC for other runc maintainers and contributors, I didn't expect it to get posted to Hacker News. I don't particularly mind hearing outsiders' opinions but it's very easy for things to get sidetracked / spammy if people with no stake in the game start leaving comments. My goal with the comment about "don't be spammy" was exactly that -- you're free to leave a comment, just think about whether it's adding to conversation or just looks like spam.

> Specifically popular FOSS projects that are not backed by a company looking to sell AI. Do any of them have a positive Policy, or positions that you want to include?

I haven't taken a very deep look, but from what I've seen, the most common setups are "blanket ban" and "blanket approval". After thinking about this for a few days, I'm starting to lean more towards:

  1. LLM use must be marked as such (upfront) so maintainers know what they are dealing with, and possibly to (de)prioritise it if they wish.
  2. Users are expected to (in the case of code contributions) have verified that their code is reasonable and they understand what it does, and/or (in the case of PRs) to have verified that the description is actually accurate.

Though if we end up with such a policy we will need to add AGENTS.md files to try to force this to happen, and we will probably need to have very harsh punishments for people who try to skirt the requirements.

> Lobste.rs github disallows AI contribution for an entirely different reason I haven't seen covered in your GH thread yet

AFAICS, it's because of copyright concerns? I did mention it in my initial comment, but I think that far too much of our industry is turning a blind eye to that issue that focusing on that is just going to lead to drawn out arguments with people cosplaying as lawyers (badly). I think that even absent of the obvious copyright issues, it is not possible to honestly sign the Developer Certificate of Origin[1] (a requirement to contribute to most Linux Foundation projects) so AI PRs should probably be rejected on that basis alone.

But again, everyone wants to discuss the utility of AI so I thought that was the simplest thing to start the discussion with. Also the recent court decisions in the Meta and Anthropic cases[2] (while not acting as precedent) are a bit disheartening for those of us with the view that LLMs are obviously industrial-grade copyright infringement machines.

[1]: https://developercertificate.org/ [2]: https://observer.com/2025/06/meta-anthropic-fair-use-wins-ai...

[grayhatter]

> it's because of copyright concerns?

Nominatively, yes. But I think I would describe it as risk tolerance. I'm going to be one of those bad cosplayers and assert that the two rulings mentioned even if they were precedent setting, don't actually apply to the risks themselves. Could you win a case is much less important than if you could survive the court costs. There's no doubt some value in LLM based code generation to many individuals. But does it's value outweigh the risks to a community?

> and we will probably need to have very harsh punishments for people who try to skirt the requirements.

I would need to spend hours of time to articulate exactly how uncomfortable this would make me if I was working along side you. So please forgive this abbreviated abstract. One of the worst things you can do to a community, is put it on rails towards an adversarial relationship. There's going to be a lot of administrative overhead to enabling this, it will be incredibly difficult to get the fairness correct the first time, and I assume (possibly without cause?) it's unlikely to feel fair to everyone if you ever need to enforce it. Is that effort and attention and time best spent there?

I believe that no matter what you decide, blanket acceptance, vs blanket denial, vs some middle ground, you're going to have to spend some of the reputation of the project on making the new rule.

If you ban it, you will turn away some contributions or new contributors, and a small subset of committers may see their velocity decrease. This counts for some value loss (some positive and some negative) But also accounts for decreased time costs... or rather it enables you to spend more time on people and their work instead.

If you allow it, you adopt a large set of new poorly understood risks, and administrative overhead, and time you could have spent working with other people... It will also, turn away contributors.

I'm not going to pretend like there was a chance in hell anyone should believe that I was likely to contribute to runc. It's possible in some hypothetical, but extremely unlikely in the current reality. And, if I cared enough about the diff I wanted to submit upstream, I still would open a PR... but, I saw an AGENTS.md in a different repo that I was considering using, was disappointed and decided not to use that repo. Seeing runc embrace AI code generation would without a doubt, cause me to look for an alternative, I assume a reasonable alt probably doesn't exist, and I would resign myself to the disappointment of using runc. I agree with your argument that it's commercial grade copyright laundering, but that's not my core ethical objection to its use.

> In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.

You're damned if you do, and damned if you don't. So the only real suggestion that I have is make sure you remember to optimize for how you want to spend your time. Calculate not just the expected value of the code within the repo, but the expected value of the people working on the repo.

[zzo38computer]

I would potentially accept it (although you should not lie about it, and if someone says in their policy that they specifically do not want this then you should not send it), although for my own projects, there are reasons (having to do with the way the version control is set up) that I cannot accept direct contributions anyways, and I usually make my own changes to any contributions anyways (but anyone else can make their own copy with their own changes however they want to do, whether or not I accept it). Since it is honest, and that you had reviewed it by yourself before submitting it, and also tested it, and that I would review it again anyways as well, it would be acceptable, although I would still much more prefer to receive contributions that do not use LLM, still the way you do it is much better than the other stuff some by LLM which does not meet the threshold of being acceptable.

[SleekoNiko]

If I were the maintainer, and you specified up front that your PR was largely written by an LLM, I would appreciate it. I may prioritize it lower than other PRs, perhaps, but that's about it.

I think it's also important to disclose how rigorously you tested your changes, too. I would hate to spend my time looking at a change that was never even tested by a human.

It sounds like you do both of these. Judging by the other replies, it seems that other reviewers may take a harsher stance, given the heavily polarized nature of LLMs. Still, if you made the changes and you're up front about your methodology, why not? In the worst case, your PR gets closed and everybody moves on.

[Blackthorn]

They don't want your contribution, so don't disrespect them by trying to make it.

[ack_complete]

> I can't imagine that any policy against LLM code would allow this sort of thing, but I also imagine that if I don't say "this was made by a coding agent", that no one would ever know. So, should I just stop contributing, or start lying?

If a project has a stated policy that code written with an LLM-based aid is not accepted, then it shouldn't be submitted, same as with anything else that might be prohibited. If you attempt to circumvent this by hiding it and it is revealed that you knowingly did so in violation of the policy, then it would be unsurprising for you to receive a harsh reply and/or ban, as well as a revert if the PR was committed. This would be the same as any other prohibition, such as submitting code copied from another project with an incompatible license.

You could argue that such a blanket ban is unwarranted, and you might be right. But the project maintainers have a right to set the submission rules for their project, even if it rules out high-quality LLM assisted submissions. The right way to deal with this is to ask the project maintainers if they would be willing the adjust the policy, not to try to slip such code into the project anyway.

[b00ty4breakfast]

"should I stop doing this thing that people are explicitly saying they don't want me to do or should I keep doing this thing that people are explicitly saying they don't want me to do???"

[alex77456]

As with evertything, there's always nuance. If everyone followed similar midset to the comment you were replying to, likely llm generated pr issues wouldn't be as much of a problem and we wouldn't even be here discussing it

[darkwater]

> [append] Getting a lot of hate for this, which I guess is a pretty clear answer. I guess the reason I'm not receiving the "fuck off" clearly is because when I see these threads of people complaining about AI content, it's really clearly low-quality crap that (for example) doesn't even compile, and wastes everyone's time.

I think you don't deserve the downvotes and, if you really do what you say you do, that's the ONLY way to use LLMs for coding and contributing to opensource software, or to a company's software. Sadly, the vast majority of LLM users don't and will never use it like that. And while they can get fired for being useless monkeys in a real company, they will keep sending PRs to opensource software, so that's clearly a different scenario that needs a different solution.