Live data from Hacker News

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

gitlab.redox-os.org

81–90 of 504 posts

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#81
post #64

Earlier quoted context omitted.

I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.

How to differentiate between a drive-by contribution and a first contribution from a potentially long-time contrubutor. And I would say especially for operating systems if it gets any adoption irregular contributions are pretty legit. E.g. when someone wants just one specific piece of hardware supported that no one else has or needs without being employed by the vendor.

This sounds complicated in theory, but it's easier in practice.

Potential long time contributor is somebody who was already asking annoying questions in the irc channel for a few months and helped with other stuff before shooting off th e PR. If the PR is the first time you hear from a person -- that's pretty drive-by ish.

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#83

> any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed Note the word "clearly". Weirdly, as a native English speaker this term makes the policy less strict. What about submarine LLM submissions? I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.

> What about submarine LLM submissions?

That would constitute an attempt to circumvent their policy, with the consequence of being banned from the project. In other words, it makes not clearly labeling any LLM use a bannable offense.

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#84
post #71

Earlier quoted context omitted.

So your proposed solution to AI slop PRs is to "donate" compute, so the maintainers can waste their time by generating the AI slop themselves?

The point isn't that agent output is magically better; it's that reviewing your own agent's output is way cheaper (intellectually) than reviewing a stranger's, because you've written the plan by yourself. And 'slop' is mostly what you get when you don't have a clear plan to verify against. Maintainers writing detailed specs for their own agents is a very different thing from someone vibe coding a feature request

Open-source maintainers have no investors to placate, no competition to outrun, why would they want to use agentic coding in the first place?

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#85

Let someone from the Redox team go read [1], [2], and [3]. If they still insist on keeping their position then ... well. The industry is being redefined as we speak and everyone doing the push-back are pushing against themselves really. [1] https://www.datadoghq.com/blog/ai/harness-first-agents/ [2] https://www.datadoghq.com/blog/ai/fully-autonomous-optimizat... [3] https://www.datadoghq.com/blog/engineering/self-opt…

That’s such a silly take.

“Our approach is harness-first engineering: instead of reading every line of agent-generated code, invest in automated checks that can tell us with high confidence, in seconds, whether the code is correct. “

that’s literally what The whole industry has been doing for decades, and spoiler: you still need to review code! it just gives you confidence that you didn’t miss anything.

Also, without understanding the code, it’s difficult to see its failure modes, and how it should be tested accordingly.

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#86
post #25

Earlier quoted context omitted.

Because it takes a massive amount of developer work (perhaps more than anything else), and it's very unlikely they either have the ability to attract enough human developers to be able to do it without LLM assistance. Not to mention that even finding good developers willing to develop without AI (a significant handicap, even more so for coding things like an OS that are well represented in LLM training) seems difficu…

> Because it takes a massive amount of developer work You know what else takes "a massive amount of developer work"? "any LLM-generated code must be reviewed by a good programmer" And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS…

Well, assuming you care about verification, of course. If it's got that green checkmark emoji, it ships!

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#87

Let someone from the Redox team go read [1], [2], and [3]. If they still insist on keeping their position then ... well. The industry is being redefined as we speak and everyone doing the push-back are pushing against themselves really. [1] https://www.datadoghq.com/blog/ai/harness-first-agents/ [2] https://www.datadoghq.com/blog/ai/fully-autonomous-optimizat... [3] https://www.datadoghq.com/blog/engineering/self-opt…

That’s such a silly take. “Our approach is harness-first engineering: instead of reading every line of agent-generated code, invest in automated checks that can tell us with high confidence, in seconds, whether the code is correct. “ that’s literally what The whole industry has been doing for decades, and spoiler: you still need to review code! it just gives you confidence that you didn’t miss anything. Also, without…

So you read the three-part series of blogs that are packed in details in 3 minutes after I shared the link and put yourself into a position of entitled opinion and calling my position a silly take? Sure thing.

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#88

While I am more on the AI-hater side, I don't consider this to be a good idea: "any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed" For example: - What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task? - What about having a plugin in your IDE that rather gives sy…

> What if a non-native English speaker uses the help of an AI model in the formulation of some issue

I've seen this excuse before but in practice the output they copy/paste is extremely verbose and long winded (with the bullet point and heading soup etc.)

Surely non-native speakers can see that structure and tell the LLM to match their natural style instead? No one wants to read a massive wall of text.

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#89
post #56

Earlier quoted context omitted.

That's eliminating of an important part of open source culture.

I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.

how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?

Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

#90
post #6

I think this is a reasonable decision (although maybe increasingly insufficient). It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers. In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly g…

Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one. That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Th…

> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.

To outright accept LLM contributions would be as much "pure vibes" as banning it.

The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is not.

If you dislike it, you are free to fork it and make a "LLM's welcome" fork. If, as you imply, the LLM contributions are invaluable, your fork should eventually become the better choice.

Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.

Post reply on HN