Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
gitlab.redox-os.org
gitlab.redox-os.org
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.
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.
Secondly, it would seem that such contributions would contribute little value, if the maintainers have to write up the detailed plans by themselves, basically have to do all the work to implement the change by themselves.
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.
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.
I always provided well-documented PRs with a narrow scope and an obvious purpose.
Not to mention LLMs can be annoying, too. Demand this, and you'll only be inviting bots to pester devs on IRC.
Because if the bug is sufficiently simple that an outsider with zero context to fix, there's a non-zero chance that the maintainers know about it and have a reason why it hasn't been addressed yet
i.e. the bug fix may have backwards-compatibility implications for other users which you aren't aware of. Or the maintainers may be bandwidth-limited, and reviewing your PR is an additional drain on that bandwidth that takes away from fixing larger issues
Also feel free to consider the PR itself to be the question, just with said context presented in one go instead of a back and forth. Feels more respectful, too. In the end, if it's not getting merged because of some weird hacky edge case, then my code will still live on in my fork.
Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction
>No big rewrites or anything crazy
I think those are the key points why they've been welcomed.
One latent effect of LLMs in general is multiplying the damage of low-effort contributions. They not only swell the ranks of unknowingly under-qualified contributors, but dramatically increase the effort of filtering them out. And though I see people argue against this assertion all the time, they make more verbose code. Regardless of whether it’s the fault of the software or the people using it, at the end of the day, the effect is more code in front of people that have to revise code, nonetheless. Additionally, by design, it makes these things plausible looking enough to require significantly more investigation.
Now, someone with little experience or little interest in the wellbeing of the code base can spit out 10 modules with hundreds of tests and thousands of words of documentation that all sorta look reasonable at first blush.
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. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance. To simply ban this is ... a choice, I guess. But it's not reasonable, in my book. It's like saying we won't use ci/cd, because it's automated stuff, we're purely manual here.
I think a lot of projects will find ways to adapt. Create good guidelines, help the community to use the best tools for the best tasks, and use automation wherever it makes sense.
At the end of the day slop is slop. You can always refuse to even look at something if you don't like the presentation. Or if the code is a mess. Or if it doesn't follow conventions. Or if a PR is +203323 lines, and so on. But attaching "LLMs aka AI" to the reasoning only invites drama, if anything it makes the effort of distinguishing good content from good looking content even harder, and so on. In the long run it won't be viable. If there's a good way to optimise a piece of code, it won't matter where that optimisation came from, as long as it can be proved it's good.
tl;dr; focus on better verification instead of better identification; prove that a change is good instead of focusing where it came from; test, learn and adapt. Dogma was never good.
In my experience these things are very easily fixable by ai, I just ask it to follow the patterns found and conventions used in the code and it does that pretty well.
Still haven't found a good way to keep it on course other than "Hey, remember that thing that you're required to do? Still do that please."
Off the shelf agentic coding tools should be doing this for you.
At my company, I use them all the time with the fancy models and everything. Preplanning does not solve the problem they're describing.
When claude is doing a complex task, it will regularly lose track of the rules (in either the .rules stuff or CLAUDE.md) and break conventions.
It follows it most of the time, but not all of the time.
But you're right it's probably unenforceable. They will probably end up accepting PRs which were written with LLM assistance, but if they do it will be because it's well-written code that the contributor can explain in a way that doesn't sound to the maintainers like an LLM is answering their questions. And maybe at that point the community as a whole would have less to worry about - if we're still assuming that we're not setting ourselves up for horrible licence violation problems in the future when it turns out an LLM spat out something verbatim from a GPLed project.
Once outside contributions are rejected by default, the maintainers can of course choose whether or not to use LLMs or not.
I do think that it is a misconception that OSS software needs to "viable". OSS maintainers can have many motivations to build something, and just shipping a product might not be at the top of that list at all, and they certainly don't have that obligation. Personally, I use OSS as a way to build and design software with a level of gold plating that is not possible in most work settings, for the feeling that _I_ built something, and the pure joy of coding - using LLMs to write code would work directly against those goals. Whether LLMs are essential in more competitive environments is also something that there are mixed opinions on, but in those cases being dogmatic is certainly more risky.
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.
Most of all, I’m sick of the patronising “don’t forget that you can fork the project!” What’s the point of saying this? We all know. Nobody needs to be reminded. Nobody isn’t aware. You aren’t being clever. You aren’t adding anything to the conversation. You’re being snarky.
Not directly, but that's the implication.
I just did not pretend that was not the implication.
> always come back to this point is so…American
I am not American.
To be frank, this was the most insulting thing someone ever told me online. Congratulations. I feel insulted. You win this one.
> If you aren’t interested in discussing the merits of the decision, don’t bother joining the conversation.
I will join whatever conversation I want, and to my desires I adressed the merits of the discussion perfectly.
You are not the judge here, your opinion is as meaningless as mine.
> Most of all, I’m sick of the patronising “don’t forget that you can fork the project!” What’s the point of saying this?
That sounds like a "you" problem. You will be sick of it until the end of time, because that's the final right answer to any complaints of open source project governance.
> You aren’t adding anything to the conversation. You’re being snarky.
I disagree. In fact, I contributed more than you. I adressed arguments. You went on a whinging session about me.
If you look back and think about what your saying for a minute, it's that low effort PRs are bad.
Using an LLM to assist in development does not instantly make the whole work 'low effort'.
It's also unenforceable and will create AI witch hunts. Someone used an em-dash in a 500 line PR? Oh the horror that's a reject and ban from the project.
2000 line PR where the user launched multiple agents going over the PR for 'AI patterns'? Perfectly acceptable, no AI here.
Instantly? No, of course not.
I do use LLMs for development, and I am very careful with how I use it. I throughly review the code it generated (unless I am asking for throwaway scripts, because then I only care about the immediate output).
But I am not naive. We both know that a lot of people just vibe code the way through, results be damned.
I am not going to fault people devoting their free time on Open Source for not wanting to deal with bullshit. A blanket ban is perfectly acceptable.
The response to a large enough amount of data is always vibes. You cannot analyze it all so you offload it to your intuition.
> It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance.
What’s stopping the maintainers themselves from doing just that? Nothing.
Producing it through their own pipeline means they don’t have to guess at the intentions of someone else.
Maintainers just doing it themselves is just the logical conclusion. Why go through the process of vetting the contribution of some random person who says that they’ve used AI “a little” to check if it was maybe really 90%, whether they have ulterior motives... just do it yourself.
Licensing is dependent on IPR, primarily copyright.
It is very unclear whether the output of an AI tool is subject to copyright.
So if someone uses AI to refactor some code, that refactored code isn't considered a derivative work which means that the refactored source is no longer covered by the copyright, or the license that depends on that.
At least for those here under the jurisdiction of the US Copyright Office, the answer is rather clear. Copyright only applies to the part of a work that was contributed by a human.
See https://www.copyright.gov/ai/Copyright-and-Artificial-Intell...
For example, on page 3 there (PDF page 11): "In February 2022, the Copyright Office’s Review Board issued a final decision affirming the refusal to register a work claimed to be generated with no human involvement. [...] Since [a guidance on the matter] was issued, the Office has registered hundreds of works that incorporate AI-generated material, with the registration covering the human author’s contribution to the work."
(I'm not saying that to mean "therefore this is how it works everywhere". Indeed, I'm less familiar with my own country's jurisprudence here in Germany, but the US Copyright Office has been on my radar from reading tech news.)
Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.
* Prefer an issue over a PR (after iterating on the issue, either you or the maintainer can use it as a prompt)
* Only open a PR if the review effort is less than the implementation effort.
Whether the latter is feasible depends on the project, but in one of the projects I'm involved in it's fairly obvious: it's a package manager where the work is typically verifying dependencies and constraints; links to upstream commits etc are a great shortcut for reviewers.
Prompts from issue text makes a lot of sense.
Despite that, you will make this argument when trying to use copilot to do something, the worst model in the entire industry.
If an AI can replace you at your job, you are not a very good programmer.
I'll just wait and see.
I don't want a Nissan or a BMW. This was provided by my employer, and I've been asked to use it. To be honest, I don't even understand how your car analogy applies to any of this.
Me and millions of other local yokel programmers who work in regional cities at small shops, in house at businesses, etc are absolutely COOKED. No I cant leet code, no I didnt go to MIT, no I dont know how O(n) is calculated when reading a function. I can scrap together a lot of useful business stuff but no I am not a very good programmer.
1. Confidently state "O(n)"
2. If they give you a look, say "O(1) with some tricks"
3. If they still give you a look, say "Just joking! O(nlogn)"This is really, honestly not hard. Spend a few minutes reading about this, or even better, ask a LLM to explain it to you and clear your misconceptions if regular blog posts don't do it for you. This is one of the concepts that sounds scarier than it is.
edit: To be clear there are tough academic cases where complexity is harder to compute, with weird functions in O(sqrt(n)) or O(log(log(n)) or worse, but most real world code complexity is really easy to tell at glance.
LLMs can do it somewhat, but it can probably leetcode better than even most of the the people who went to MIT.
The thing you fear is the thing that you could just use to improve yourself?
Why fear a shovel?
Also, I never claimed to be a good programmer either. Just don't see the point fearing something that makes it infinitely easier and faster to get work done.
It’s fine to write things by hand, in the same way that there’s nothing wrong with making your own clothing with a sewing machine when you could have bought the same thing for a small fraction of the value of your time. Or in the same fashion, spending a whole weekend, modeling and printing apart, you could’ve bought for a few dollars. I think we need to be honest about differentiating between the hobby value of writing programs versus the utility value of programs. Redox is a hobby project, and, while it’s very cool, I’m not sure it has a strong utility proposition. Demanding that code be handwritten makes sense to me for the maintainer because the whole thing is just for fun anyway. There isn’t an urgent need to RIIR Linux. I would not apply this approach to projects where solving the problem is more important than the joy of writing the solution.
Is that really true? Like, if you took the time to plan it carefully, dot every i, cross every t?
The way I think of LLM's is as "median targeters" -- they reliably produce output at the centre of the bell curve from their training set. So if you're working in a language that you're unfamiliar with -- let's say I wanted to make a todo list in COBOL -- then LLM's can be a great help, because the median COBOL developer is better than I am. But for languages I'm actually versed in, the median is significantly worse than what I could produce.
So when I hear people say things like "the clanker produces better programs than me", what I hear is that you're worse than the median developer at producing programs by hand.
For example just recently I updated a component in one of our modules. The work was fairly rote (in this project we are not allowed to use LLMs). While it was absolutely necessary to do the update here, it was beneficial to do it everywhere else. I didn't do it in other places because I couldn't justify spending the effort.
There are two sides to this - with LLMs, housekeeping becomes easy and effortless, but you often err on the side of verbosity because it costs nothing to write.
But much less thought goes into every line of code, and I often am kinda amazed that how compact and rudimentary the (hand-written) logic is behind some of our stuff that I thought would be some sort of magnum opus.
When in fact the opposite should be the case - every piece of functionality you don't need right now, will be trivial to generate in the future, so the principle of YAGNI applies even more.
My go-to analogy is assembly language programming: it used to be an essential skill, but now is essentially delegated to compilers outside of some limited specialized cases. I think LLMs will be seen as the compiler technology of the next wave of computing.
Consider calculators: Their consistency and adherence to requirements was necessary for adoption. Nobody would be using them if they gave unpredictable wrong answers, or where calculations involving 420 and 69 somehow keep yielding 5318008. (To be read upside-down, of course.)
I think LLMs will get better, as well.
If you can internalise that fact and look at it like having a probable answer rather than an exact answer it makes sense.
Calculators cant have a stab at writing an entire c compiler. A lot of people cant either or takes a lot of iteration anyway, no one one shotted complicated code before llms either.
I feel discussion shouldnt be about how they work as the fundamental objection, rather the costs and impacts they have.
The clanker can produce better programs than me because it will just try shit that I would never have tried, and it can fail more times than I can in a given period of time. It has specific advantages over me.
I've been writing software for 20 years. Rust since 10 years. I don't consider myself to be a median coder, but quite above average.
Since the last 2 years or so, I've been trying out changes with AI models every couple months or so, and they have been consistently disappointing. Sure, upon edits and many prompts I could get something useful out of it but often I would have spent the same amount of time or more than I would have spent manually coding.
So yes, while I love technology, I'd been an LLM skeptic for a long time, and for good reason, the models just hadn't been good. While many of my colleagues used AI, I didn't see the appeal of it. It would take more time and I would still have to think just as much, while it be making so many mistakes everywhere and I would have to constantly ask it to correct things.
Now 5 months or so ago, this changed as the models actually figured it out. The February releases of the models sealed things for me.
The models are still making mistakes, but their number and severity is lower, and the output would fit the specific coding patterns in that file or area. It wouldn't import a random library but use the one that was already imported. If I asked it to not do something, it would follow (earlier iterations just ignored me, it was frustrating).
At least for the software development areas I'm touching (writing databases in Rust), LLMs turned into a genuinely useful tool where I now am able to use the fundamental advantages that the technology offers, i.e. write 500 lines of code in 10 minutes, reducing something that would have taken me two to three days before to half a day (as of course I still need to review it and fix mistakes/wrong choices the tool made).
Of course this doesn't mean that I am now 6x faster at all coding tasks, because sometimes I need to figure out the best design or such, but
I am talking about Opus 4.6 and Codex 5.3 here, at high+ effort settings, and not about the tab auto completion or the quick edit features of the IDEs, but the agentic feature where the IDE can actually spend some effort into thinking what I, the user, meant with my less specific prompt.
So you have to burn tokens at the highest available settings to even have a chance of ending up with code that's not completely terrible (and then only in very specific domains), but of course you then have to review it all and fix all the mistakes it made. So where's the gain exactly? The proper goal is for those 500 lines to be almost always truly comparable to what a human would've written, and not turn into an unmaintainable mess. And AI's aren't there yet.
> Claude and GPT regularly write programs that are way better than what I would’ve written
What you're describing doesn't sound "way better" than what you would have written by hand, except possibly in terms of the speed that it was written.
That's correct, because most of the cost of code is not the development but rather the subsequent maintenance, where AI can't help. Verbose, unchecked AI slop becomes a huge liability over time, you're vastly better off spending those few weekends rewriting it from scratch.
I’m sorry but this says more about you than about the models. It is certainly not the case for me!
It never picks a style, it'll alternate between exceptions and then return codes.
It'll massively overcomplicate things. It'll reference things that straight up don't exist.
But boy is it brilliant at a fuzzy find and replace.
No LLM can answer this question for you, it has no insight into how or why it outputted what it outputted. The reasons it gives might sound plausible, but they aren't real.
The open source world has already been ripped off by AI the last thing they need is for AI to pollute the pedigree of the codebase.
Do you think your worldview is still a reasonable one under those conditions?
That seems like a win-win in a sense: let the agentic coders do their thing, and the artisanal coders do their thing, and we'll see who wins in the long run.
And this is why eventually you are likely to run the artisanal coders who tend to do most of the true innovation out of the room.
Because by and large, agentic coders don't contribute, they make their own fork which nobody else is interested in because it is personalized to them and the code quality is questionable at best.
Eventually, I'm sure LLM code quality will catch up, but the ease with which an existing codebase can be forked and slightly tuned, instead of contributing to the original, is a double edged sword.
Personally, I would not currently expect a fork of RedoxOS that is AI-implemented to become more popular than RedoxOS itself.
Isn't that literally how open-source works, and why there's so many Linux distros?
Code quality is a subjective term as well, I feel like everyone dunking on AI coding is a defensive reaction - over time this will become an entirely acceptable concept.
Vibe coders don't have to do any of this. They don't have to understand anything, they can just have their LLMs do some modifications that are completely opaque to the vibe coder.
Perhaps the long term steady state will be a goldilocks renaissance of open source where lots of new ideas and contributors spring up, made capable with AI assistance. But so far what I've seen is the opposite. These people just feed existing work into their LLMs, produce derivative works and never bother to engage with the original authors or community.
I spend time using my agent to better understand existing codebases and their best practices than I'd ever have the time/energy to do before, giving me a broader and more holistic view on whatever I'm changing, before I make a change.
I always find it odd that people say both that vibe coding has obvious and immediate negative consequences in terms of quality and at the same time that nobody could learn or be incentivized to produce better architecture and code quality from vibe coding when they would obviously face those consequences.
This also lines up with the history of automation in many other industries. Modern manufacturing is capable of producing parts that a medieval blacksmith couldn't dream of, for example. Sure, maybe an artisan can produce better code than an llm now, but AI assisted humans will beat them in the near future if they aren't already producing similar quality output at greater speed, and tomorrow's models will fix the bad code written today. The fact that there's even a discussion on automated vs hand written today means that the writing is almost certainly on the wall.
But if a project bans AI then yeah, they'll be run out of town because I won't bother trying to contribute.
Saves the rest of us from having to tell you.
this feels like the place where your approach breaks down. I have had very poor results trying to build a foundation that CAN be polished, or where features don't quickly feel like a jenga tower. I'm wondering if the success we've seen is because AI is building on top of, or we're early days in "foundational" work? Is anyone aware of studies comparing longer term structural aspects? is it too early?
Bold of you to assume that people won’t move (and their code along with it) to spaces where parasitic behaviour like this doesn’t occur, locking you out.
In addition to just being a straight-up rude, disrespectful and parasite position to take, you’re effectively poisoning your own well.
Additionally, if they accept AI contributions, I try, when I have the time and energy, make sure my PRs are high quality, and provide them. If they don't, then I'll go off and do my own thing, because that's literally what they asked me to do, and I wasn't going to contribute otherwise. I fail to see how that's rude or parasitic or disrespectful in any way except my assumption that the more featureful and polished forks might eventually win out.
Maybe one day it will be.. And then people can reevaluate their stance then. Until that time, it's entirely reasonable to hold the position that you just don't
This is especially true with how LLM generated code may affect licensing and other things. There's a lot of unknowns there and it's entirely reasonable to not want to risk your projects license over some contributions.
I use them all the time at work because, rightly or wrongly, my company has decided that's the direction they want to go.
For open source, I'm not going to make that choice for them. If they explicitly allow for LLM generated code, then I'll use it, but if not I'm not going to assume that the project maintainers are willing to deal with the potential issues it creates.
For my own open source projects, I'm not interested in using LLM generated code. I mostly work on open source projects that I enjoy or in a specific area that I want to learn more about. The fact that it's functional software is great, but is only one of many goals of the project. AI generated code runs counter to all the other goals I have.
People might still code by hand as a hobby, but I'd be surprised if nearly all professional coding isn't being done by LLMs within the next year or two. It's clear that doing it by hand would mostly be because you enjoy the process. I expect people that are more focused on the output will adopt LLMs for hobby work as well.
This is gaslighting. We're only a few years into coding agents being a thing. Look at the history of human innovation and tell me that I'm unreasonable for suspecting that there is an iceberg worth of unmitigated externalities lurking beneath the surface that haven't yet been brought to light. In time they might. Like PFAS, ozone holes, global warming.
The other factor that gets glossed over is that llms create a financial incentive to create cleaner code, with tests, because the agent that you pay for will be more efficient when the code is easier to understand, and has clear patterns for extensibility. When I do code with llms, a big part of it is demonstration, i.e. pseudocoding a pattern/structure, asking the model if it understands, and then having it complete the pattern. I've had a lot of success with this approach.
Right, this is the kind of discussion we're having on my team: suddenly all of the already good engineering practices like good observability, clear tests with high coverage, clean design, etc. act as a massive force multiplier and are that much more important. They're also easier to do if you prioritize it. We should be seeing quality go up. It's trivial to explore the solution space with throwaway PoCs, collect real data to drive your design, do all of those "nice to have" cleanups, etc. The people who assume LLM = slop are participating in a bizarre form of cope. Garbage in, garbage out; quality in, quality out. Just accept that coding per se is not going to be a profession for long. Leverage new tools to learn more, do more, etc. This should be an exciting time for programmers.
This will not happen until companies decide to care about quality again. They don't want employees spending time on anything "extra" unless it also makes them significantly more money.
There clearly should be, but that is not the world we live in.
That sounds very Usanian. In the meantime transportation in around me is done on foot, bicycle, bus, tram, metro, train and cars. There are good use cases for each method including the car. If you really want to use an automotive analogy, then sure, LLMs can be like cars. I've seen cities made for cars instead of humans, and they are a horrible place to live.
Signed, a person who totally gets good results from coding with LLMs. Sometimes, maybe even often.
Start new projects using LLM tools, or maybe fork projects where that is acceptable. Don't force the volunteer maintainers of existing projects with existing workflows and cultures to review AI generated code. Create your own projects with workflows and cultures that are supportive of this, from the ground up.
I'm not suggesting this will come without downside, but it seems better to me than expecting maintainers to take on a new burden that they really didn't sign up for.
But the maintainers can use AI too, for their reviewing.
Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?
Often feels to me like the current stance of arguments is missing something.
This assumes that AI capable of writing passable code is also capable of a passable review. It also assumes that you save any time by trusting that review, if it missed something wrong then it's often actually more effort to go back and fix than it would've been to just read it yourself the first time.
I use Claude Code a lot, I generate a ton of changes, and I have to review it all because it makes stupid mistakes. And during reviews it misses stupid things. This review part is now the biggest bottleneck that can't yet be skipped.
An in an open source project many people can generate a lot more code than a few people can review.
Imagine someone vibe codes the code for a radiotherapy machine and it fries a patient (humans have made these errors). The developer won't be able to point to OpenAI and blame them for this, the developer is personally responsible for this (well, their employer is most likely). Ergo, in any setting where there is significant monetary or health risk at stake, humans have to review the code at least to show that they've done their due diligence.
I'm sure we are going to have some epic cases around someone messing up this way.
So it becomes a bit theoretical, but I guess if we had a future where LLMs could consistently write perfect code, it would not be too far fetched to also think it could perfectly review code, true enough. But either way the maintainer would still spend some time ensuring a contribution aligns with their vision and so forth, and there would still be close to zero incentive to allow outside contributors in that scenario. No matter what, that scenario is a bit of a fairytale at this point.
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-proje...
* 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.
This is the assumption that has almost always failed and thus has lead to the banning of AI code altogether in a lot of projects.
This will cut off one of the genuine entry points to the industry where all you really needed was raw talent.
Of course, even then it's not reproducible and requires proprietary software!
That breaks "copyleft" entirely.
Sure there might be md documents that you created that the AI used to implement the software, but maybe those documents themselves have been AI written from prompts (due to how context works in LLMs, it's better for larger projects to first make an md document about them, even if an LLM is used for it in the first place).
As for proprietary software, the chinese models are not far behind the cutting edge of the US models.
This would probably be more useful to help you see what (and how) was written by LLMs. Not really to catch bad actors trying to hide LLM use.
But I think different projects have different needs.
[0] https://github.com/mastodon/.github/blob/main/AI_POLICY.md
> 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.
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... .
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.
You have no doubt heard claims that AI "democratizes" software development. This is an argument that AI use for that case is virtuous.
You have no doubt heard claims that AI "decreases cognition ability." This is an argument that not using AI for software development is virtuous.
Which is correct depends strongly on your cultural views. If both are correct then the term has little or no weight.
From what I've seen, the term "virtue signalling" is almost always used by someone in camp A to disparage the public views of someone in camp B as being dishonest and ulterior to the actual hidden reason, which is to improve in-group social standing.
I therefore regard it as conspiracy theory couched as a sociological observation, unless strong evidence is given to the contrary. As a strawman exaggeration meant only to clarify my point, "all right-thinking people use AI to write code, so these are really just gatekeepers fighting to see who has the longest neckbeard."
Further, I agree with the observation at https://en.wikipedia.org/wiki/Virtue_signalling that "The concept of virtue signalling is most often used by those on the political right to denigrate the behaviour of those on the political left". I see that term as part of "culture war" framing, which makes it hard to use that term in other frames without careful clarification.
In all cases, the implication is that it's worthless to discuss the stated issue (in this case, the rejection of LLM-generated contributions) because the real issue is something else.
I've seen LLM-generated software contain code which was clearly derived from an MIT-licensed code base, and where the generated code did include proper attribution.
The USL v. BSDi lawsuit teaches us that operating system developers must be cautious about copyright attribution.
I see no need to conjecture the existence of some hidden reason, as you seemingly have. In addition, the performative game can go both ways. Eg, "Your comment is performative cover for the slap in the face you feel as a coder who uses a lot of LLM support." But that would be malicious conjecture. IMO, any claim of "performative" without support is just bog-boring flaming.
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.
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”.
> 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'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.
Like, this should be enshrined as the quintessential “they simply, obstinately, perilously, refused to get it” moment.
Shortly, no one is going to care about anyone’s bespoke manual keyboard entry of code if it takes 10 times as long to produce the same functionality with imperceptibly less error.
Well that day doesn't appear to be coming any time soon. Even after years of supposed improvements, LLMs make mistakes so frequently that you can't trust anything they put out, which completely negates any time savings from not writing the code.
1) Most people still don't use TDD, which absolutely solves much of this.
2) Most poople end up leaning too heavily on the LLM, which, well, blows up in their face.
3) Most people don't follow best practices or designs, which the LLM absolutely does NOT know about NOR does it default to.
4) Most people ask it to do too much and then get disappointed when it screws up.
Perfect example:
> you can't trust anything they put out
Yeah, that screams "missing TDD that you vetted" to me. I have yet to see it not try to pass a test correctly that I've vetted (at least in the past 2 months) Learn how to be a good dev first.
No one is going to care about anyone’s painstaking avoidance of chlorofluorocarbons if it takes ten times as long to style your hair with imperceptibly less ozone hole damage.
CLEARLY, a lot of developers are not reasonable
The unreasonable ones are the ones with the oppositional-defiant “You can’t tell me I can’t use an LLM!” reaction.
The simplest refutation of your point of view is, who or what is responsible if the work submission is wrong?
It will always be the person’s, never the computer’s. Conveniently, AI always acts as if it has no skin in the game… because it literally and figuratively doesn’t… so for people to treat it like it does, should be penalized
Who vetted the output?
Who ensured there was adequate test coverage?
Who insisted on a certain design?
Who is to blame if it's bad code? That is the same entity that is responsible, and the same entity that "did it"
tl;dr your stance is full of poop, my dude
That’s what you sound like.
There are a thousand and one ways that I participate when building something with LLM assistance. Everything from ORIGINATING AN IDEA TO BEGIN WITH, to working on a thorough spec for it, to ensuring tests are actually valid, to asking for specific designs like hexagonal design, to specific things like benchmarks... literally ALL OF THE INITIATIVE IS MINE, AND ALL OF THE SUCCESS/FAILURE CONSEQUENCES ARE MINE, AND THAT IS ULTIMATELY ALL THAT MATTERS
Please head towards a different career if you now have a stupid and contrived excuse not to continue working with the machines, because you sound like a whining child
And you're not answering the question, because you know it would end your point: WHO OR WHAT IS RESPONSIBLE IF THE CODE SUCCEEDS OR FAILS?
You sound like someone who’s deeply in denial about exactly how the LLM plagiarism machines work. You really do sound like a student defending themselves against a plagiarism charge by asserting that since they did the work of choosing the text to put into their essay and massaging the grammar so it fit, nobody should care where it came from.
and I’m 53 and well remember Symbolics from freshman year at Cornell, in fact my application essay to it was about fuzzy logic (AI-tangential) and probably got me in, so I too am quite familiar
i’m also quite good at debate. the flaw in your logic is that plagiarism requires accountability and no machine can be accountable, only the human that used it, ergo, it is still the work of the human, because the human values, the human vets, the human initiates, and the human gains or loses based on the combined output, end of story; accelerated thought is still thought, and anyway, if a machine can replicate thought, then it wasn’t particularly original to begin with
human prompting != human production
There are plenty of good reasons why somebody might not want your PR, independent of how good or useful to you your change is.
If the submitter is prepared to explain the code and vouch for its quality then that might reasonably fall under "don't ask, don't tell".
However, if LLM output is either (a) uncopyrightable or (b) considered a derivative work of the source that was used to train the model, then you have a legal problem. And the legal system does care about invisible "bit colour".
For one simple reason. Intention.
Here's some code for example: https://i.imgur.com/dp0QHBp.png
Both sides written by an LLM. Both sides written based on my explicit prompts explaining exactly how I want it to behave, then testing, retesting, and generally doing all the normal software eng due diligence necessary for basic QA. Sometimes the prompts are explicitly "change this variable name" and it ends up changing 2 lines of code no different from a find/replace.
Also I'm watching it reason in real time by running terminal commands to probe runtime data and extrapolate the right code. I've already seen it fix basic bugs because an RFC wasn't adhered to perfectly. Even leaving a nice comment explaining why we're ignoring the RFC in that one spot.
Eventually these arguments are kinda exhausting. People will use it to build stuff and the stuff they build ends up retraining it so we're already hundreds of generations deep on the retraining already and talking about licenses at this point feels absurd to me.
It doesn't matter if the "change this variable name" instruction ends up with the same result as a human operator using a text editor.
There is a big difference between "change this variable name" and "refactor this code base to extract a singleton".
It sounds like you really can’t handle being told “no, you can’t use an LLM for this” by someone else, even if they have every right to do so. You should probably talk to your therapist about that.
Whether it's an OSS license or a commercial license, both are dependent on copyright as the underlying IP Right.
The courts have so far (in the US) agreed with the Copyright office's reasoning.
Use an LLM as a tool, mostly OK.
Use it to create source from scratch, no copyright as the author isn't human.
Use it to modify existing software, the result is only copyright on whatever original remains.
Lots of people try to get away with perfect crimes and sometimes do. That doesn't make the rule unenforceable, it just highlights the limits of human knowledge in the face of a dishonest person. Hence the escalations for trying to destroy evidence of crimes or in this case to work around the AI policy. Here, instead of just closing your PR, they ban you if you try to hide it.
Once identity is guaranteed, privileges basically come down to reputation — which in this case is a binary "you're okay until we detect content that is clearly labelled as LLM-generated".
[Added]
Note that identity (especially avoiding duplicate identity) is not easily solved.
The hope here is the same hope as most laws: that lies eventually catch up to people. That truth comes to light. But sure, in the meanwhile, there are always dishonest people around trying to flout rules to varying degrees of success. Some are caught right away, some live their entire lives without it catching up to them. That doesn't make the rule unenforceable, that just highlights the limits of rules: it requires evidence that can be hard to come by.
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.
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.
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.c...
Now the corporate-backed "MIT-EVERYTHING" mindvirus has ruined all of that: https://opensource.org/blog/top-open-source-licenses-in-2025
Not being able to publish anything without sifting through all the libs licences? Remembering legalese, jurisprudence, edge cases, on top of everything else?
MIT became ubiquitous because it gives us peace of mind
Yes, as do, probably, most people who remember it.
Or how are you handling that?
Sure, sometimes you can automate some of it, but you'll still have to manually check the attributions are correctly done.
> it's like a high tech pinky swear
So is you attesting you didn't contribute any GPL'd code (which, incidentally, you arguably can't do if you're using LLMs trained on GPL'd code), and no one seemed to have issues with that, yet when it's extended to LLMs, the concern trolling starts in earnest. It's also legally binding .
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.
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.
Why on earth would you force stuff on a party that has said they don't want that?
If I want to use an auto-complete then I can, and I will? Restricting that is as regressive as a project trying to specify that I write code from a specific country or… standing on my head.
Sure, if they want me to add a “I’m writing this standing on my head” message in the PR then I will… but I’m not.
Restricting this is their right, and it is not for you to attempt to overrule that right. Besides the fact that you do not oversee the consequences it also makes you an asshole.
They're not asking for you to write standing on your head, they are asking for you to author your contributions yourself.
Except they don’t, won’t and can’t control that: the very request is insulting.
I’ll make a change any way I choose, upright, sideways, using AI. My choice. Not theirs.
Their choice is to accept it or reject it based purely on the change itself, because that’s all there is.
But if they can’t enforce their boundaries, because they can’t tell the difference between AI code and non-AI code without being told, then their boundaries they made up are unenforceable nonsense.
About as nonsense and enforceable as asking me to code upside down.
- people can just say things
- when people say things, you don’t have to listen to them
- not listening to them doesn’t make you superior or more powerful than them
We can practice: I’d like you to always comment in uppercase letters from now on please. It’s my policy.
Boundaries - of all kinds - are not unenforceable nonsense, they are rights that you willingly and knowingly violate.
I would say people should be wary of any contributions whatsoever from a filthy fucking liar.
Nothing? Everything? Does it fucking matter? Assigning trust across a boundary like this is stupid, and that’s my point.
Oh, would you just accept my blatantly, verbatim copied-from-another-codebase-and-relicensed PR just because I said “I solemnly swear this is not blatantly, verbatim copied from another codebase and relicensed”?
That’s on you for stupidly assigning any trust to the author of the change. It’s the internet: nobody knows you’re a dog.
At that point you've proven intention, meaning you'll get the chance to argue your viewpoint in front of a judge.
Sure, put out an international search warrant for xXImADogOnTheInternet86Xx.
Many major projects now require a signed DCO with a real name. That can be a nickname if you have a reasonable online presence under that name, but generally it has to identify you as an individual.
So you wouldn't sign it as "xXImADogOnTheInternet86Xx", but as "Tom Forbes (orf)".
And even if there won't be direct legal consequences, it'd certainly affect your ability to contribute to this or other projects in the future.
Why would I sign it as my real name? Does the DCO require ID verification? No? So it would be “Mr Ima Dog”.
People can lie in the internet, saying “oh but no they can’t because there’s a form they need to fill in!!” is supremely off topic nonsense.
(1) you would lie
(2) you fundamentally don't understand the concept of consent
> "I’ll make a change any way I choose, upright, sideways, using AI. My choice. Not theirs."
The fact that other people would lie is besides the point: those other people would get the exact same treatment if found out. Whether or not they would be found out is moot, it is the act of lying and ignoring consent that makes this what it is: asshole behavior. By extension anybody that practices this behavior is an asshole as well and by extension of that tying your own rep to people that would behave like that makes you an asshole and I highly doubt that that was your intention.
So now you've - over endless comments - shown that you fundamentally don't get this very important concept. Yes, people lie. But there are mechanisms for dealing with liars. Misrepresentation and fraud are serious things. Lawsuits, fines and in an extreme case jail, but on a more immediate level ostracizing. It makes you as a person into an undesirable. It also makes the world as a whole a worse place to live in, which is why such behavior is strongly discouraged, even if it is possible.
That's why we don't structurally go around clubbing old ladies over the head as a revenue model, not because we can't do it or because it would be acted upon by the law (that's for the few who don't get it) but because it is simply a bad thing to do. It is a matter of ethics. That's why if an open source project has a 'No AI' policy you either abide by the policy or you can expect massive backlash.
To think that you could do this and even should do this to make the point is as stupid as walking out and grabbing some old lady's hand bag to prove that it can be done: you are hurting an innocent to prove your point and it will cause a reaction that is at a minimum proportional to what you did and worst case you will be made an example of. This can be the proverbial career ending move. If you are Elon level rich and your inner asshole seeks a way out then yes, you could probably do it. But for normal folks such behavior is highly discouraged. Actions usually have consequences.
Finally: open source is a massive gift to society. The whole reason you can use AI in the first place is because that gift got abused in a way that open source contributors did not anticipate. If you're going around to pollute open source with AI contributions to effectively karma farm you have to wonder why you are so intent on doing that. Is it your purpose to destroy open source? Or is it just because you enjoy destroying stuff in general? I don't see any other options, this is a pathology and it would do you good to introspect on this for a bit instead of to respond with yet another ill conceived reply digging yourself in further. You've gone from 'mildly annoying' to 'wouldn't work with this person for any amount of money because they are a massive liability' in the space of 15 comments. I hope it was worth it to you.
Your comment would be fine without that first bit.
If the maintainers don't want to accept it, fine. Someone will eventually fork and advance and we move on. The Uncles can continue to play in their no AI playground, and show each other how nice their code is.
The world is moving on from the "AI is bad" crowd.
This is such an easily refuted assertion. Tell me, if something is wrong with the submitted code, who or what is responsible? If it's not "the LLM", then your opinion makes zero sense. The responsible party is always a human; therefore the responsible party rightfully deserves the credit whether it succeeds or fails.
It makes lots of sense to me.
Or a human will provide the fix?
Just like when people started losing their ability to navigate without a GPS/Maps app, you will lose your ability to write solid code, solve problems, hell maybe even read well.
I want my brain to be strong in old age, and I actually love to write code unlike 99% in software apparently (like why did you people even start doing this career.. makes no sense to me).
I'm going to keep writing the code myself! Stop paying Billionaires for their thinking machines, its not going to work out well for you.
I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc
> I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc
Then you are the opposite of a carpenter or a craftsman, no matter what you think about it yourself.
And yet, I find a coding agent makes it even more fun. I spend less time working on the boilerplate crap that I hate, and a lot less time searching Google and trying to make sense of a dozen half-arsed StackOverflow posts that don't quite answer my question.
I just went through that yesterday with Unity. I did all the leg work to figure out why something didn't work like I expected. Even Google's search engine agent wasn't answering the question. It was a terrible, energy-draining experience that I don't miss at all. I did figure it out in the end, though.
Prior to yesterday, I was thinking that using AIs to do that was making it harder for me to learn things because it was so easy. But comparing what I remember from yesterday to other things I did with the AI, I don't really think that. The AI lets me do it repeatedly, quickly, and I learn by the repetition, and a lot of it. The slow method has just 1 instance, and it takes forever.
This is certainly an exciting time for coders, no matter why they're in the game.
Sure but once you learn long multiplication/division algorithms by hand there's not much point in using them. By high school everyone is using a calculator.
> Just like when people started losing their ability to navigate without a GPS/Maps app
Are you suggesting people shouldn't use Google Maps? Seems kind of nuts. Similar to calculators, the lesson here is that progress works by obviating the need to think about some thing. Paper maps and compasses work the same way, they render some older skill obsolete. The written word made memorization infinitely less valuable (and writing had its critics).
I don't think "LLMs making us dumber" is a real concern. Yes, people will lose some skills. Before calculators, adults were probably way better at doing arithmetic. But this isn't something worth prioritizing.
However, it is worth teaching people to code by hand, just like we still teach arithmetic and times tables. But ultimately, once we've learned these things, we're going to use tools that supercede them. There's nothig new or scary about this, and it will be a significant net win.
But it's a problem of scale.
Calculators are very specific tools. If you are trying to run a computation of some arithmetic/algebraic expression, then they are a great tool. But they're not going to get you far if you need help understanding how to file your taxes.
LLMs are multi-faceted tools. They can help with math, doing taxes, coding, doing research, writing essays, summarizing text, etc. Basically anything that can be condensed into an embedding that the LLM can work with is fair game.
If you're willing to accept that using a tool slowly erodes the skill that tool was made for, then you should also accept that you will see an erosion of MANY skill you currently have.
So the question is whether this is all worth it? Is an increase in productivity worth eroding a strong foundation of general purpose knowledge? Perhaps even the ability to learn in the first place?
I would argue no a million times over, but I'm starting to think that I'm an outlier.
Everyone is vulnerable to the allure of taking shortcuts in life, but I've learned over the years that there is no free lunch. This is going too be quite an expensive trade off for many.
Along the same lines, AI will necessitate a shift where people intentionally use their extra intellectual leisure time. Reading, writing, chess, learning a new language, etc.
Not everyone will do this. Some people will be the intellectual equivalent of obese. But people will figure it out eventually.
Will they? >50% of US adults are overweight or obese. Is this the example you want to hang your hat on?
Where are the stats backing this claim? Obesity levels have not dropped significantly in recent times. Also, any significant change will require government oversight, and we are increasingly heading towards a direction where private interests overrule whats best for the public at large.
>I see no reason to assume the same thing won't happen with AI.
You have the ability to choose what and much you eat. Will you have the ability to forsake AI if your employer forces it upon you, or if to stay competitive in school you have to rely on it? In the same way it's hard to live in society without a smart phone, it's already becoming hard to operate in society without relying on AI. Now extrapolate this out by a decade.
I suggest you watch the AI Dilemma.
If you want a more recent example, google search is an extremely broad tool that has operated similarly.
I think AI will be another rung in the ladder of abstraction. Something will be lost, but it's worth the trade.
You should ask yourself why you're okay with innovations that happened in the past but not okay with innovations happening now. It could just be reflexive conservativism.
Of course there's no guarantee that AI will be more positive than negative, but I see no compelling reason to believe that. Most of the anti-AI sentiment is just people not liking new things.
Because these innovations are not congruent with our most important biological advantage! We are here precisely because we developed the capacity to think critically about hard problems. To relegate our critical faculties to an activity you engage with during a small window of time each day similar to a muscle you exercise at the gym is asinine in my opinion. I firmly believe in the future, people like you will become a new underclass as they have willingly given up their ability to think.
If people who use AI become an "underclass" then people will adapt and...not use AI. But that won't happen. People will use it to augment rather than replace, just like we use other, similar technologies.
And many lose the ability to do long division by high school, where they'll have to relearn it for polynomial long division, which typical school calculators can't handle easily.
I am old now, and the unfortunate truth is that my brain isn't working as fast or as precise as when I was young. LLMs help me maintain some of my coding abilities.
It's like having a non-judgemental co-coder sitting at your side, you can discuss about the code you wrote and it will point out things you didn't think of.
Or I can tap into the immense knowledge about APIs LLMs have to keep up with change. I wouldn't be able to still read that much documentation and keep all of this.
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.
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.
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.
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.
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.
>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_comp...
A model that contains no GPL code makes sense so that people using non-GPL licenses don't violate it.
So "copyleft" doesn't work on any of the output. Therefore no GPL applies.
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?
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.
[1]: https://github.com/PostgREST/postgrest/blob/main/CONTRIBUTIN...
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).
That’s the point.
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.
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)
"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?
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.
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.
this so many times - it's so incredibly handy to have the original message from the author, for one I may speak or understand parts of that language and so have an easier time understanding the intent of the translated text. For another I can cut and translate specific parts using whatever tools I want, again giving me more context about what is trying to be communicated.
How can you be sure the AI translation is accurately convening what was written by the speaker? The reality is you can't accommodate every hypothetical scenario.
> 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?
Nobody is talking about advanced autocomplete when they want to ban AI code. It's prompt generated code.
Firefox has direct translation built in. One can self-host libretranslate. There are many free sites to paste in language input and get a direct translation sans filler and AI "interpretation". Just write in your native language or your imperfect English.
If the native language is very different from English, this problem gets much worse.
This is a problem that LLM claim to partially mitigate (and is one reason why non-native speakers could be tempted to use them), but hardly any classical translation tool can.
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.
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.
## 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.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.
[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-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.
“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.
No, they’re pushing back against a world full of even more mass surveillance, corporate oligarchy, mass unemployment, wanton spam, and global warming. It is absolutely in your personal best interest to hate AI.
Time consuming work can be done quickly at a fraction of the cost or even almost free with open weights LLMs.
IOW I think this stance is ethically good, but technically irresponsible.
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.
Why not?
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.
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.
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.
And how will that be assured? Everyone can open a PR or submit a bug.
> The problem is the time.
But not the time spent TYPING.
The problem is the time spent THINKING. And that's a task that LLMs, which are nothing other than statistical models trying to guess the next token, really aren't good at.
Humans have been doing this for the better parts of 5 decades now. Don't assume others rely on LLMs as much as you do.
>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.
I highly doubt that. In fact, I'd take a significant pay cut to move to a company that doesn't use LLMs, if I were forced to use them in my current job.
Every single production OS, including the one you use right now, was made before LLMs even existed.
> What makes sense if that of course any LLM-generated code must be reviewed by a good programmer
The time of good programmers, especially ones working for free in their spare time on OSS projects, is a limited resource.
The ability to generate slop using LLMs, is effectively unlimited.
This discrepancy can only be resolved in one way: https://itsfoss.com/news/curl-ai-slop/
And a new OS needs to be significantly better than those to overcome the switching costs.
Erm...no? That's exactly what that means.
Earth-Ovens haven't been in widespread use for hundreds of years. People can still use them to bake bread however: https://www.youtube.com/watch?v=WAJqGVxuJPo
Feel like you are using a very narrow definition of "success" here. Is BSD not successful? It is deployed on 10s of millions of routers/firewalls/etc in addition to being the ancestor of both modern MacOS and PlaystationOS...
Who cares if nobody switches to it as their daily driver? The goal you proposed was "viable", not "widely used". The former is perfectly possible without LLMs (as history has proved), and the latter is unrelated to how you choose to make the OS.
Over time this might not be enough, though, so I suspect we will see default deny policies popping up soon enough.
Perhaps the same way that every other viable OS was made without use of LLMs.
Terry Davis built a full OS with his own editor, compiler and language. I think Redox can survive just fine without LLMs