14 ms·

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

• estsauver 8mo ago
  They're certainly welcome to do whatever they're like, and for a microkernel based OS it might make sense--I think there's probably pretty "Meh" output from a lot of LLMs. I think part of the battle is actually just getting people to identify which LLM made it to understand if someones contribution is good or not. A javascript project with contributions from Opus 4.6 will probably be pretty good, but if someone is using Mistral small via the chat app, it's probably just a waste of time.
• khalic 8mo ago
  The LLM ban is unenforceable, they must know this. Is it to scare off the most obvious stuff and have a way to kick people off easily in case of incomplete evidence?
  • buzzardbait 8mo ago
    Probably just an attempt to stop low effort LLM copy pasta.
    • Ekaros 8mo ago
      A sign to point at when you get someone is posting "I asked AI to fix this and got this". You can stop reading and any arguments right there. Saving lot of time and effort.
  • ptnpzwqd 8mo ago
    I suspect this is for now just a rough filter to remove the lowest effort PRs. It likely will not be enough for long, though, so I suspect we will see default deny policies soon enough, and various different approaches to screening potential contributors.
  • deleted 8mo ago
    [deleted]
  • bonesss 8mo ago
    Any sufficiently advanced LLM-slop will be indistinguishable from regular human-slop. But that’s what they are after. This heuristic lets the project flag problematic slop with minimal investment avoiding the cost issues with reviewing low-quality low-effort high-volume contributions, which should be near ideal. Much like banning pornography on an artistic photo site, the perfect application on the borderline of the rule is far less important than filtering power “I know it when I see it” provides to the standard case. Plus, smut peddlers aren’t likely to set an OpenClaw bot-agent swarm loose arguing the point with you for days then posting blogs and medium articles attacking you personally for “discrimination”.
  • BlackFly 8mo ago
    It is enforceable, I think you mean to say that it cannot be prevented since people can attempt to hide their usage? Most rules and laws are like that, you proscribe some behavior but that doesn't prevent people from doing it. Therefore you typically need to also define punishments: > This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.
    • hparadiz 8mo ago
      What happens when the PR is clear, reasonable, short, checked by a human, and clearly fixes, implements, or otherwise improves the code base and has no alternative implementation that is reasonably different from the initially presented version?
      • pm215 8mo ago
        If you're going to set a firm "no AI" policy, then my inclination would be to treat that kind of PR in the same way the US legal system does evidence obtained illegally: you say "sorry, no, we told you the rules and so you've wasted effort -- we will not take this even if it is good and perhaps the only sensible implementation". Perhaps somebody else will eventually re-implement it later without looking at the AI PR.
        • hparadiz 8mo ago
          How funny would it be if the path to actually implement that thing is then cut off because of a PR that was submitted with the exact same patch. I'm honestly sitting here grinning at the absurdity demonstrated here. Some things can only be done a certain way. Especially when you're working with 3rd party libraries and APIs. The name of the function is the name of the function. There's no walking around it.
          • pm215 8mo ago
            That's why I said "somebody else, without looking at it". Clean-room reimplementation, if you like. The functionality is not forever unimplementable, it is only not implementable by merging this AI-generated PR. It's similar to how I can't implement a feature by copying-and-pasting the obvious code from some commercially licensed project. But somebody else could write basically the same thing independently without knowing about the proprietary-license code, and that would be fine.
  • _zagj 8mo ago
    > The LLM ban is unenforceable Just require that the CLA/Certificate of Origin statement be printed out, signed, and mailed with an envelope and stamp, where besides attesting that they appropriately license their contributions ((A)GPL, BSD, MIT, or whatever) and have the authority to do so, that they also attest that they haven't used any LLMs for their contributions. This will strongly deter direct LLM usage. Indirect usage, where people whip up LLM-generated PoCs that they then rewrite, will still probably go on, and go on without detection, but that's less objectionable morally (and legally) than trying to directly commit LLM code. As an aside, I've noticed a huge drop off in license literacy amongst developers, as well as respect for the license choices of other developers/projects. I can't tell if LLMs caused this, but there's a noticeable difference from the way things were 10 years ago.
    • tentacleuno 8mo ago
      > As an aside, I've noticed a huge drop off in license literacy amongst developers What do you mean by this? I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses. I typically had a "fuck it" attitude when it came to the license, and I assume quite a lot of other people shared that sentiment. The code is the fun bit.
      • _zagj 8mo ago
        > I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses No, it wasn't that way in the 2000s, e.g., on platforms like SourceForge, where OSS devs would go out of their way to learn the terms and conditions of the popular licenses and made sure to respect each other's license choices, and usually defaulted to GPL (or LGPL), unless there was a compelling reason not to: https://web.archive.org/web/20160326002305/https://redmonk.com/sogrady/2014/11/14/open-source-licenses/ https://web.archive.org/web/20160326002305/https://redmonk.c... Now the corporate-backed "MIT-EVERYTHING" mindvirus has ruined all of that: https://opensource.org/blog/top-open-source-licenses-in-2025 https://opensource.org/blog/top-open-source-licenses-in-2025
        • 8mo ago
  • scuff3d 8mo ago
    Speed limits are unenforceable. You'll never catch everyone speeding so why even bother trying.
• The-Ludwig 8mo ago
  Hm, wondering how to enforce this rule. Rules without any means to enforce them can put the honest people into a disadvantage.
  • goku12 8mo ago
    > This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project. It sounds serious and strict, but it applies to content that's 'clearly labelled as LLM-generated'. So what about content that isn't as clear? I don't know what to make of it. My guess is that the serious tone is to avoid any possible legal issues that may arise from the inadvertent inclusion of AI-generated code. But the general motivation might be to avoid wasting the maintainers' time on reviewing confusing and sloppy submissions that are made using the lazy use of AI (as opposed finely guided and well reviewed AI code).
    • hananova 8mo ago
      Very next sentence lists the penalty for lying. So you can defraud the project, but only if you can walk the walk and talk the talk well enough for them to never notice you’re using an LLM. At that point it’s more effort than just complying with the policy. That’s the point.
• tkel 8mo ago
  Glad to see they are applying some rigor. I've started removing AI-heavy projects from my dependency tree.
  • butILoveLife 8mo ago
    Are you and Redox just going to fall behind? Projects that used to take months take days or hours. It seems well intentioned, but lots of bad ideas are like this. I was told by my customer they didn't need my help because Claude Code did the program they wanted me to quote. I sheepishly said, 'I can send an intern to work in-house if you don't want to spend internal resources on it.' I can't really imagine what kind of code will be done by hand anymore... Even military level stuff can run large local models.
    • hananova 8mo ago
      Projects that used to take months still take months. LLM’s are only useful for throwaway low-quality slop. Perhaps some times the sloperator will get lucky and the end result isn’t something that will bite them in the ass. But the rest of us foresee a mountain of tech debt that will come knocking one day.
      • butILoveLife 8mo ago
        This is like 2 months outdated.
        • eschaton 8mo ago
          [flagged]
        • spartanatreyu 8mo ago
          This is a fair representation of the slop I'm given throughout each week: https://www.youtube.com/watch?v=JtBI2BvPKBQ https://www.youtube.com/watch?v=JtBI2BvPKBQ
    • decidu0us9034 8mo ago
• emperorxanu 8mo ago
  [flagged]
• ptnpzwqd 8mo ago
  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 generate PRs that might look superficially correct. Effort can still have been out into those PRs, but there is no way to tell without spending time reviewing in more detail. Policies like this help decrease that review burden, by outright rejecting what can be identified as LLM-generated code at a glance. That is probably a fair bit today, but it might get harder over time, though, so I suspect eventually we will see a shift towards more trust-based models, where you cannot submit PRs if you haven't been approved in advance somehow. Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.
  • eyk19 8mo ago
    I feel like the pattern here is donate compute, not code. If agents are writing most of the software anyway, why deal with the overhead of reviewing other people's PRs? You're basically reviewing someone else's agent output when you could just run your own. Maintainers could just accept feature requests, point their own agents at them using donated compute, and skip the whole review dance. You get code that actually matches the project's style and conventions, and nobody has to spend time cleaning up after a stranger's slightly-off take on how things should work.
    • ChadNauseam 8mo ago
      Well, it's not quite that easy because someone still has to test the agent's output and make sure it works as expected, which it often doesn't. In many cases, they still need to read the code and make sure that it does what it's supposed to do. Or they may need to spend time coming up with an effective prompt, which can be harder than it sounds for complicated projects where models will fail if you ask them to implement a feature without giving them detailed guidance on how to do so.
• stuaxo 8mo ago
  We need LLMs that have a certificate of origin. For instance a GPL LLM trained only on GPL code where the source data is all known, and the output is all GPL. It could be done with a distributed effort.
  • ptnpzwqd 8mo ago
    Not necessarily a bad idea, but I think the bigger issue here and now is the increasing assymmetry in effort between code submitter and reviewer, and the unsustainable review burden on the maintainers if nothing is done.
  • nottorp 8mo ago
    I don't think the licensing issues are the main problem, but the spam.
  • duskdozer 8mo ago
    Rather, LLMs that do NOT contain GPL code.
  • andy12_ 8mo ago
    Honestly, given that that GPL model would be far below SOTA in capabilities, what exactly would be its use-case? Why would anyone try to use an inferior LLM if they can get away with using a superior one?
    • duskdozer 8mo ago
      It doesn't make sense, because GPL means only GPL comes out, not only GPL can go in: >Many of the most common free-software licenses, especially the permissive licenses, such as the original MIT/X license, BSD licenses (in the three-clause and two-clause forms, though not the original four-clause form), MPL 2.0, and LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole (but the other license would not so apply). https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility https://en.wikipedia.org/wiki/License_compatibility#GPL_comp... A model that contains no GPL code makes sense so that people using non-GPL licenses don't violate it.
• throwaway2037 8mo ago
  > 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.
  • BlackLotus89 8mo ago
    I read that as benefit of the doubt, which is a reasonable stance.
  • deleted 8mo ago
    [deleted]
  • eesmith 8mo ago
    As a native English speaker I read this as two parts. If it's obvious, the response is immediate and not up for debate. If it's not obvious then it falls in the second part - "any attempt to bypass this policy will result in a ban from the project". A submarine submission, if discovered, will result in a ban. Using the phrase "virtual signaling" long ago became a meaningless term other than to indicate one's views in a culture war. 10 years ago David Shariatmadari wrote "The very act of accusing someone of virtue signalling is an act of virtue signalling in itself", https://www.theguardian.com/commentisfree/2016/jan/20/virtue-signalling-putdown-passed-sell-by-date https://www.theguardian.com/commentisfree/2016/jan/20/virtue... .
    • subjectsigma 8mo ago
      Somewhat off topic, but I can’t believe someone got paid to write that article, what a load of crap. It’s like saying that fallacies don’t exist because sometimes people incorrectly claim the other side is arguing fallaciously. If you go by the literal definition in the article, it’s very clear what OP meant when he said the AI policy is virtue-signaling, and it has absolutely nothing to do with the culture war.
• lifis 8mo ago
  Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense. What makes sense if that of course any LLM-generated code must be reviewed by a good programmer and must be correct and well written, and the AI usage must be precisely disclosed. What they should ban is people posting AI-generated code without mentioning it or replying "I don't know, the AI did it like that" to questions.
  • duskdozer 8mo ago
    >Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense. Why not?
    • lifis 8mo ago
      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 difficult nowadays, especially if they aren't paying them.
      • usrbinbash 8mo ago
        > 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 TO have the necessary skill to write such code themselves. LLMs save time on the typing part of programming. Incidentially that part is the least time consuming.
        • lifis 8mo ago
          The submitter is supposed to be the good programmer; if not, then maintainers may or may not review it themselves depending on the importance of the feature. And yes of course they need to be able to write the code themselves, but that's the easy part: any good developer could write a full production OS by themselves given access to documentation and literature and an enormous amount of time. The problem is the time.
• baq 8mo ago
  While I appreciate the morality and ethics of this choice, the current trend means projects going in this direction are making themselves irrelevant (don't bother quipping at how relevant redox is today, thanks). E.g. top security researches are now using LLMs to find new RCEs and local privilege escalations; no reason why the models couldn't fix these, too - and it's only the security surface. IOW I think this stance is ethically good, but technically irresponsible.
  • holyra 8mo ago
    People can choose not to use AI. This is because they think it is inevitable that they will eventually use LLMs.
  • ptnpzwqd 8mo ago
    Even if we assume that LLMs become good enough for this to be true (some might feel that is the case already - I disagree, but that is beside the point), there is no reason why OSS maintainers should accept such outside contributions that they would need to carefully review, as it comes from an untrusted source, when they could just use the tools themselves directly. Low effort drive-by PRs is a burden with no upside.
• lukaslalinsky 8mo ago
  I think we will be getting into an interesting situation soon, where project maintainers use LLMs because they truly are useful in many cases, but will ban contributors for doing so, because they can't review how well did the user guide the LLM.
  • dlillard0 8mo ago
    I think guiding the LLM to write code is easy for them to write code by themselves.
  • mfld 8mo ago
    Maybe a future direction will be the submission of detailed research, specifications and change plans for feature requests. Something that can be assessed by a human and turned into working code by both slides.
    • konschubert 8mo ago
      I wonder if that is an opportunity to build an Open-Source platform focused on this, replacing GitHub as the collaboration platform of a time where code was valuable.
  • konschubert 8mo ago
    The bottlenecks today are: * understanding the problem * modelling a solution that is consistent with the existing modelling/architecture of the software and moves modelling and architecture in the right direction * verifying that the the implementation of the solution is not introducing accidental complexity These are the things LLMs can't do well yet. That's where contributions will be most appreciated. Producing code won't be it, maintainers have their own LLM subscriptions.
    • advancespace 8mo ago
      [flagged]
      • 8mo ago
• hparadiz 8mo ago
  I am 100% certain that code that Redox OS relies on in upstream already has LLM code in it.
  • akimbostrawman 8mo ago
    Yes, but that is there choice and burden to maintain.
  • flykespice 8mo ago
    So what? You pay taxes to a government using it to wage wars bombing children schools. Will you now live in hut a on the forest because you don't consent to it?
• aleph_minus_one 8mo ago
  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 syntax and small code fragment suggestions ("autocomplete on steroids")? Does this policy mean that the programmers are also restricted on the IDE and plugins that they are allowed to have installed if they want to contribute?
  • hypeatei 8mo ago
    > 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.
  • VorpalWay 8mo ago
    > What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task? Unfortunately, when I have seen this in the context of the Rust project, the result has still been the typical verbose word salad that is typical of chat style LLMs. It is better to use a dedicated translation tool, and post the original along with the translation. > What about having a plugin in your IDE that rather gives syntax and small code fragment suggestions ("autocomplete on steroids")? Very good question, I myself consider this sort of AI usage benign (unlike agent style usage), and is the only style of AI I use myself (since I have RSI it helps having to type less). You could turn the feature off for just this project though. > Does this policy mean that the programmers are also restricted on the IDE and plugins that they are allowed to have installed if they want to contribute? I don't think that follows, but what features you have active in the current project would definitely be affected. From what I have seen all IDEs allow turning AI features on and off as needed.
    • 8mo ago
• hagen8 8mo ago
  They will sooner or later change that policy or get very slow in keeping up.
• algoth1 8mo ago
  What would constitute "clearly llm generated" though
  • nananana9 8mo ago
    if (foo == true) { // checking foo is true (rocketship emoji) 20 lines of code; } else { the same 20 lines of code with one boolean changed in the middle; } Description: (markdown header) Summary (nerd emoji): This PR fixes a non-existent issue by adding an *if statement** that checks if a variable is true. This has the following benefits: - Improves performance (rocketship emoji) - Increases code maintainability (rising bar chart emoji) - Helps prevent future bugs (detective emoji) (markdown header) Conclusion: This PR does not just improve performance, it fundamentally reshapes how we approach performance considerations. This is not just design --- it's architecture. Simple, succinct, yet powerful.
    • deleted 8mo ago
      [deleted]
    • The-Ludwig 8mo ago
      Peak comedy
  • cpburns2009 8mo ago
    The clearly LLM PRs I receive are formatted similarly to: ## Summary ... ## Problem ... ## Solution ... ## Verification ... They're too methodical, and duplicate code when they're longer than a single line fix. I've never received a pull request formatted like that from a human.
    • ok123456 8mo ago
      Don't you use the dialectic?
• scotty79 8mo ago
  I see a lot of oss forks in the future where people just fork to fix their issues with LLMs without going through maintainers. Or even doing full LLM rewrites of smaller stuff.
  • dgacmu 8mo ago
    Probably, but on the other hand, this is almost literally the definition of technical debt -- it's great to get fixes uptreamed precisely so that you don't have to maintain your own fork, keep it in sync, etc. an LLM can likely lower the burden of that but the burden still exists.
    • scotty79 8mo ago
      Yeah, but what can you do if you need a thing done and now there's an option to have it done.
      • dgacmu 8mo ago
        I don't disagree. I assume that most of these purely llm generated unwanted contributions will just end up in dead end forks, because my impression is that a lot of them are just being generated as GitHub activity fodder. But the stuff that really solves a problem for a person - eh, good. Problem solved is problem solved. (Unless it creates new problems)
  • decidu0us9034 8mo ago
    Well it's an operating system. Ideally safety and reliability are prioritized. I think the scope and complexity of an operating system are large enough both to make a lot of changes non-trivial and to trip up LLMs. I think it's fine if you have an unstable release stream or you have bleeding edge forks that move faster than upstream. This is already the case...
• menaerus 8mo ago
  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/ https://www.datadoghq.com/blog/ai/harness-first-agents/ [2] https://www.datadoghq.com/blog/ai/fully-autonomous-optimization/ https://www.datadoghq.com/blog/ai/fully-autonomous-optimizat... [3] https://www.datadoghq.com/blog/engineering/self-optimizing-system/ https://www.datadoghq.com/blog/engineering/self-optimizing-s... P.S. I know this will be downvoted to death but I'll leave it here anyway for folks who want to keep their eyes wide open.
  • stingraycharles 8mo ago
    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.
    • menaerus 8mo ago
      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.
      • grey-area 8mo ago
        They probably used an AI to summarise those blog posts for them and it told them with high confidence, in seconds, whether they were correct.
        • menaerus 8mo ago
• yla92 8mo ago
  Zig has a similar stance on no-LLM policy https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy
  • pmarreck 8mo ago
    Yep, that’s why my forks of all their libraries with bugs fixed such as https://github.com/pmarreck/zigimg/commit/52c4b9a557d38fe1e166ac21c52fcd972af7e1c5 https://github.com/pmarreck/zigimg/commit/52c4b9a557d38fe1e1... will never ever go back to upstream, just because an LLM did it. Lame, but oh well- their loss. Also, this is dumb because anyone who wants fixes like this will have to find a fork like mine with them, which is an increased maintenance burden.
    • lpcvoid 8mo ago
      Hugely unpopular opinion on HN, but I'd rather use code that is flawed while written by a human, versus code that has been generated by a LLM, even if it fixes bugs. I'd gladly take a bug report, sure, but then I'd fix the issues myself. I'd never allow LLM code to be merged.
      • CoastalCoder 8mo ago
        Any thoughts on why you have that preference?
        • lpcvoid 8mo ago
          Because human errors are, well, human. And producing code that contains those errors is a human endeavor. It bases on years, decades of learning. Mistakes were made, experience was gained, skills were improved. Reasoning by humans is relatable. Generating slop using LLMs takes seconds, has no human element, no work goes into it. Mistakes made by an LLM are excused without sincerity, without real learning, without consequence. I hate everything about that.
          • 8mo ago
• flanked-evergl 8mo ago
  Spiritually Amish
• api 8mo ago
  AI has the potential to level the playing field somewhat between open source and commercial software and SaaS that can afford armies of expensive paid developers. Time consuming work can be done quickly at a fraction of the cost or even almost free with open weights LLMs.
• cardanome 8mo ago
  [flagged]
  • Anonyneko 8mo ago
    For one, it makes your Github profile look more attractive to employers (superficially, at least). Sometimes, I'd guess, it's also because your Github profile has some kind of an advertisement.
    • Ekaros 8mo ago
      That is one reason I believe. Being told that you need open source presence to be employed. I think some people also like the feeling of being helpful. And they do not understand reality of LLM outputs. See comments posting AI generated summaries or answers to question. With no verification or critical checking themselves.
  • 999900000999 8mo ago
    You can then list on your profile that you’re a contributor to 1000 FOSS projects. Before this it was junk like spacing changes
  • butILoveLife 8mo ago
    I genuinely feel bad for you. At least it isnt difficult to make the transition to AI Agent coding. Even untrained people are able to do it. At some point your manager is going to force you to AI code. At best you can try to find some healthcare or finance company that is too cheap to buy a machine that can locally run 400B models.
    • aerhardt 8mo ago
      Untrained people are producing utter garbage. I am 100% in on AI coding and haven’t typed into the IDE in months but the craft remains pretty much as challenging as ever.
    • hananova 8mo ago
      My manager can try. I’ll say no, and he’ll be welcome to start the slow process of laying me off, which will end in my employer having to pay me 10 months worth of wages. By the time I’ll be faced with having to find a new job, I’ll be retiring anyway. Using LLMs is not in my job description, and I will not do it.
• dana321 8mo ago
  Generating small chunks of code with llms to save time works well, as long as you can read and understand the code i don't see what the problem is.
  • xmodem 8mo ago
    The problem is that the well you are drinking from has in fact been poisoned. Maybe you think you can tolerate it but some projects are taking a policy decision that any exposure is too dangerous and that is IMO perfectly reasonable.
• BirAdam 8mo ago
  So... my prediction is that they will either have to close off their dev process or start using LLMs to filter contributions in the attempt to detect submissions from LLMs.
• dev_l1x_be 8mo ago
  In my experience with the right set of guardrails LLMs can deliver high quality code. One interesting aspect is doing security reviews and formal verification with agents that is proven to be very useful in practice. https://www.datadoghq.com/blog/ai/harness-first-agents/ https://www.datadoghq.com/blog/ai/harness-first-agents/
• qsera 8mo ago
  I think clients who care about getting good software will eventually require that LLMs are not directly used during the development. I think one way to compare the use of LLMs is that it is like comparing a dynamically typed language with a functional/statically typed one. Functional programming languages with static typing makes it harder to implement the solution without understanding and developing an intuition of the problem. But programming languages with dynamic typing will let you create a (partial) solutions with a lesser understanding the problem. LLMs takes it even more easy to implement an even more partial solutions, without actually understanding even less of the problem (actually zero understanding is required).. If I am a client who wants reliable software, then I want an competent programmer to 1. actually understand the problem, 2. and then come up with a solution. The first part will be really important for me. Using LLM means that I cannot count on 1 being done, so I would not want the contractor to use LLMs.
• jacquesm 8mo ago
  Hiring managers could help here: the only thing that should count as a positive when - if - you feel like someone's open source contributions are important for your hiring decision is to make it plain that you only accept this if someone is a core contributor. Drive-by contributions should not count for anything, even if accepted.
• eatonphil 8mo ago
  If you're curious to see what everyone else is doing, I did a survey of over 100 major source available projects and four of them banned AI assisted commits (NetBSD, GIMP, Zig, and qemu). On the other hand projects with AI assisted commits you can easily find include Linux, curl, io_uring, MariaDB, DuckDB, Elasticsearch, and so on. Of the 112 projects surveyed, 70 of them had AI assisted commits already. https://theconsensus.dev/p/2026/03/02/source-available-projects-and-their-ai-contribution-policies.html https://theconsensus.dev/p/2026/03/02/source-available-proje...
  • flammafex 8mo ago
    [flagged]
    • joelthelion 8mo ago
      How about picking software based on how well it works?
      • ddtaylor 8mo ago
        Then we wouldn't get to virtue signal about the state of the software industry getting rid of all these starving artists. Posted from my software made with AI assistance.
      • flammafex 8mo ago
        How about trusting the review process, and not attempting to regulate the tools used to produce code. We already accept code from IDE autocompletion, StackOverflow, templates, etc. The real control point is review, testing, and license verification.
    • deleted 8mo ago
      [deleted]
    • aerhardt 8mo ago
      Everyone is starting to make AI a moral question one way or another. So your moral view is progress must march on unimpeded by private actors? I find that pretty original. I think progress will march largely unimpeded. I would be wary of unhinged government intervention, but I wouldn’t begrudge private actors for not getting on with the ticket.
• steve-chavez 8mo ago
  One thing that is missing is a standard no-LLM policy, like the "Contributor Covenant Code of Conduct". On PostgREST we recently added a strict no-LLM policy [1], basically linking Gentoo's AI policy, which we found the most apt in lack of a standard. [1]: https://github.com/PostgREST/postgrest/blob/main/CONTRIBUTING.md#ai-policy https://github.com/PostgREST/postgrest/blob/main/CONTRIBUTIN...
• 0xbadcafebee 8mo ago
  Dangerous that all these projects keep going MIT. We wouldn't have an open source community if it weren't for protections against modification without sharing. Almost all software today would be proprietary, as it was before.
  • okanat 8mo ago
    No. People shared code because they wanted to. Open standards are great tools against emerging monopolies. So the losing side used that. IBM lost OS/2 vs NT war. They propped up Linux. Intel wanted to have a second option to Microsoft in server space. AMD wants to gain some developers against Nvidia Cuda monopoly. That's the reason they contribute. Even Linux's own leadership decided against extra freedoms for users; they rejected GPLv3 to keep company contributions going. That's why LLVM gets the first implementations of certain optimizations and architectures, yet being permissive licensed. Quite a bit of the Linux userspace is already permissively licensed. Nobody has built a full-fledged open source alternative yet. Because it is hard to build an ecosystem, it is hard to test thousands of different pieces of hardware. None of that would happen without well-paid engineers contributing.
    • kuschku 8mo ago
      Often times it's the points where free software has to integrate with proprietary hardware that becomes an issue. Yet that's exactly where the GPL shines. As this proprietary hardware still uses linux, these manufacturers–which would never provide their source code willingly–are forced to provide it, and as result, we can build open drivers for them. I usually prefer writing drivers and weird protocols from scratch, but often that's not possible, so I'll have to spend months discussing with some manufacturers' legal teams before I'm able to receive the sources. Without the GPL, sure, you'd still have free software operating systems, but basically no hardware to actually run them on.
      • okanat 8mo ago
        > Often times it's the points where free software has to integrate with proprietary hardware that becomes an issue. Yet that's exactly where the GPL shines. As this proprietary hardware still uses linux, these manufacturers–which would never provide their source code willingly–are forced to provide it, and as result, we can build open drivers for them. How many open drivers released for Adreno GPUs are there from Qualcomm? Does Apple release GPL drivers? How did the FOSS driver project for Nvidia worked out, are there any useable and truly FOSS drivers for Nvidia GPUs as the market leader, were they convinced that they are forced to develop a fully open driver including the user space? > Without the GPL, sure, you'd still have free software operating systems, but basically no hardware to actually run them on. I disagree. If there is enough economic interest to support open ecosystem as a weapon, you'd get open drivers / software like Intel and AMDGPU or Valve's Steam Deck. This is not a benefit nor a result of GPL. The main correlation is the existence of a significant dominant company and smaller not as dominant but still large enough companies that can supply significant resources into an open standard. Linux and other open source projects are used as a means to challenge and overthrow the significant players who almost always keep as many things as secret to not lose their position. If there was no Linux, another OS, most likely a BSD would get the same investments from IBM et al. This has been a proven strategy that worked for many other industries before computers even existed.
• sbcorvus 8mo ago
  I understand the knee-jerk reaction to restrict LLM's, but that feels like a failing prospect. They're going to be doing an incredible amount of heavy lifting on code generation, so why would you intentionally cut out what will likely be 90% or more of potential contributions? Wouldn't it be better to come up with a system that tags the type of contributor, ie. human vs. AI? What about building an Agentic architecture that reduces your review burden? Just a thought.
• ajstars 8mo ago
  The interesting tension here is that "no LLM-generated code" is easy to state but hard to enforce - a developer who uses an LLM to understand a concept and then writes the code themselves is indistinguishable from one who didn't. The policy probably works as a cultural signal more than a technical guarantee, which might be exactly what they want.
  • hananova 8mo ago
    It’s also a sign to point to when the fraud is uncovered.
• sheepscreek 8mo ago
  That’s a shallow way to get people to own up to their code. I haven’t read the original link but going by the title, a blanket no-LLM is bad. Driven by human and supported by AI should be the way.
• singularity2001 8mo ago
  That's a shame. We used claude to migrate redox very successfully to pure rust cranlift on mac: https://github.com/pannous/redox https://github.com/pannous/redox (but then got stuck on multi-cpu assembly):
  • deleted 8mo ago
    [deleted]
• inder1 8mo ago
  the skills that protect against displacement long-term are exactly what vibe coding erodes. an engineer who built with AI but never developed the instincts to spot its mistakes has a gap they don't know they have. this maintainer problem is a preview: when you can't tell the difference between a PR from someone who understood the code and one from someone who just prompted into it, the verification burden doesn't disappear. it shifts to whoever has enough skill to catch the errors.
• oliver_dr 8mo ago
  [dead]
• deleted 8mo ago
  [deleted]
• VLM 8mo ago
  The purpose of a LLM ban is to encourage use of LLMs to submit PRs, not discourage. The longer term effect is to eliminate FOSS competency from the hiring process. It takes some human effort to set up a slop generator. Have the slop generator make 100 buckets of slop, humans will work hard accepting or rejecting the buckets, somewhat less than 100 buckets will be approved, the payoff for the owner of the slop generator is now they have "verified FOSS developer contribution" on their resume which translates directly into job offers and salary. Its a profitable grift, profitable enough that the remaining humans are being flooded out. The ban makes successful submission to Redox even MORE valuable than before. They can expect infinite floods of PRs now that a successful PR "proves" that Redox thinks the human owner of the slop generator did the work and should therefore be offered more jobs, paid more, etc. Technically, they're hiring and paying based on ability to set up a slop generator which is not zero value, but not as valuable as being an Official Redox Contributor. In the long run, this eliminates FOSS competency from the hiring process. Currently FOSS competency and coding experience indicates a certain amount, however minimal, of human skill and ability to work with others. Soon, it'll mean the person claiming to be a contributor has no problem violating orders and rules, such as the ones forbidding AI submissions, and it'll be a strong signal they actively work to subvert teams for their own financial reward and benefit. Which might actually be a hiring bullet point for corporate management in more dysfunctional orgs, but probably not help individual contributors get hired.
  • hananova 8mo ago
    Hi. No, the purpose of a ban is to ban the behavior. I hope this helps.
• munk-a 8mo ago
  A long list of contribution PRs are seen as a resume currency in the modern world. A way to game that system is to autogenerate a whole bunch of PRs and hope some of them are accepted to buff your resume. Our issue is that we've been impressed with volume of PRs and not the quality of PRs. The correction is that we should start caring about the volume of rejected PRs and quality of those accepted PRs (like reviewing merge discussions since they're a close corollary to what can be expected during an internal PR). As long as the volume of PRs is seen as a positive indicator people will try and maximize that number. This is made more complex that the most senior members of organizations tend to be irrationally AI positive - so it's difficult for the hiring layer to push back on a candidate for over reliance on tools even if they fail to demonstrate core skills that those tools can't supplement. The discussion has become too political[1] in most organizations and that's going to be difficult to overcome. 1. In the classic intra-organizational meaning of politics - not the modern national meaning.
• ethin 8mo ago
  This may be an unpopular opinion, but I fully support the no-AI stance. AI-generated code belongs nowhere in an operating system or it's low level/kernel components. Especially considering the shear amount of power the kernel has over the machine. The last thing you want is an AI-generated bug crashing systems because it flipped a bit that is reserved or silently corrupting memory (or worse) because it ran in kernel mode (or similar privileges) and therefore the system didn't prevent it from doing what it was going to do. An OS (of any kind or architecture) and computer firmware is the last place I would ever want AI-generated code.
  • BoredomIsFun 8mo ago
    So many strawmen here - as if HN had deliberately dumbed itself down, just for sake of trendy argument. Of course you should vet the AI generated - who would've thought? Meanwhile I had Gemini find bugs in my AVX-512 code I would never find myself.
• gtirloni 8mo ago
  I wish them good luck but they will become even more of a niche project.
• witx 8mo ago
  Good someone is taking a stance against slopware