Rendered at 11:58:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ptnpzwqd 1 days 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.
stabbles 1 days ago [-]
For well-intended open source contributions using GenAI, my current rules of thumb are:
* 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.
zozbot234 1 days ago [-]
Unfortunately, LLMs generate useless word salad and nonsense even when working on issues text, you absolutely have to reword the writing from scratch otherwise it's just an annoyance and a complete waste of time. Even a good prompt doesn't help this all that much since it's just how the tool works under the hood: it doesn't have a goal of saying anything specific in the clearest possible way and inwardly rewording it until it does, it just writes stuff out that will hopefully end up seeming at least half-coherent. And their code is orders of magnitude worse than even their terrible English prose.
GorbachevyChase 21 hours ago [-]
I don’t think you’re being serious. Claude and GPT regularly write programs that are way better than what I would’ve written. Maybe you haven’t used a decent harness or a model released in the last year? It’s usually verbose, whereas I would try the simplest thing that could possibly work. However, it can knock out but would have taken me multiple weekends in a few minutes. The value proposition isn’t even close.
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.
notpachet 21 hours ago [-]
> Claude and GPT regularly write programs that are way better than what I would’ve written
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.
est31 10 hours ago [-]
Have you tried the latest models at best settings?
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.
notpachet 12 minutes ago [-]
I feel like we're talking about different things. You seem to be describing a mode of working that produces output that's good enough to warrant the token cost. That's fine, and I have use cases where I do the same. My gripe was with the parent poster's quote:
> 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.
zozbot234 4 hours ago [-]
> I am talking about Opus 4.6 and Codex 5.3 here, at high+ effort settings
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.
als0 4 hours ago [-]
You really do need to try the latest ones. You can’t extrapolate from your previous experiences.
BoredomIsFun 2 hours ago [-]
I do not think they are impartial - all I can see is lots of angst.
h3lp 19 hours ago [-]
A lot of computer users are domain experts in something like chemistry or physics or material science. Computing to them is just a tool in their field, e.g. simulating molecular dynamics, or radiation transfer. They dot every i and cross every t _in_their_competency_domain_, but the underlying code may be a horrible FORTRAN mess. LLMs potentially can help them write modern code using modern libraries and tooling.
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.
Terr_ 15 hours ago [-]
The difference is that compilers involve rules we can enumerate, adjust, etc.
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.)
h3lp 13 hours ago [-]
The compilers used to be unreliable too, e.g. at higher optimizations and such. People worked on them and they got better.
I think LLMs will get better, as well.
foxes 10 hours ago [-]
But thats the point, an llm is a vastly different object to a calculator. Its a new type of tool for better or worse based on probabilities, distributions.
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.
aaronbrethorst 14 hours ago [-]
nice. 3x.
torginus 20 hours ago [-]
It can certainly be true for several reasons. Even in domains I'm familiar with, often making a change is costly in terms of coding effort.
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.
notpachet 20 hours ago [-]
I can agree with that. So essentially: "Claude and GPT regularly write programs that are way better than what I would’ve written given the amount of time I was willing to spend."
zozbot234 15 hours ago [-]
How much time and effort are you willing to spend on maintaining that code though? The AI can't do it on its own, and the code quality is terrible enough.
dnautics 16 hours ago [-]
no. I'm a pretty skilled programmer and I definitely have to intervene and fix an architectural problem here and there, or gently chastise the LLM for doing something dumb. But there are also many cases where the LLM has seen something that i completely missed or just hammered away at a problem enough to get a solution that is correct that I would have just given up on earlier.
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.
xyzsparetimexyz 17 hours ago [-]
The verboseness is the key issue as to why LLMed PRs are bad.
skeeter2020 19 hours ago [-]
let me translate this for the GP: "you're doing it wrong".
zozbot234 20 hours ago [-]
> The value proposition isn’t even close.
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.
fireflash38 19 hours ago [-]
Having reviewed a lot of Ai-written python code, I think it's absolute nonsense.
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.
skeeter2020 19 hours ago [-]
if it wasn't so maddening it would be funny when you literally have to tell it to slow down, focus and think. My tinfoil hat suggests this is intentional to make me treat it like a real, live junior dev!
mech422 16 hours ago [-]
"you literally have to tell it to slow down, focus and think" - This soo much! When I get an unexpected result from claude, I ask it why - what caused it to do such-and-such. After one back and forth session like this putting up tons of guardrails on a prompt, claude literally said "you shouldn't have to teach me to think every session" !!
heavyset_go 15 hours ago [-]
> When I get an unexpected result from claude, I ask it why - what caused it to do such-and-such.
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.
hananova 20 hours ago [-]
> Claude and GPT regularly write programs that are way better than what I would’ve written.
I’m sorry but this says more about you than about the models. It is certainly not the case for me!
emperorxanu 22 hours ago [-]
I feel like every person stating things of this nature are literally not able to communicate effectively (though this is not a barrier anymore, you can get a dog to vibe code games with the right workflow, which to me seems like quite an intellectual thing to be able to do.
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.
recursive 17 hours ago [-]
Copilot isn't a model. Currently it's giving me a choice of 15 different models. By all evidence, AI is nowhere close to replacing me, but to hear other people tell it, it is weeks or maybe months away.
I'll just wait and see.
calvinmorrison 17 hours ago [-]
> If an AI can replace you at your job, you are not a very good programmer.
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.
ethbr1 17 hours ago [-]
> no I dont know how O(n) is calculated when reading a function
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)"
calvinmorrison 16 hours ago [-]
O(no idea)
torginus 4 hours ago [-]
I suspect the value you bring to the table is that you are good enough a programmer to translate the problems of the people you work with into working code.
LLMs can do it somewhat, but it can probably leetcode better than even most of the the people who went to MIT.
integralid 16 hours ago [-]
>no I dont know how O(n) is calculated when reading a function
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.
calvinmorrison 12 hours ago [-]
its not hard. Accounting isnt that hard either. I just know more business crap than programming
skydhash 22 hours ago [-]
It does generate word salad (and usefulness depends on the person reading it). If both the writer and the reader share a common context, there's a lot that can be left out (the extreme version is military signal). An SOS over the radio says the same thing as "I'm in a dangerous situation, please help me if you can" but the former is way more efficient. LLMs tend to prefer the latter.
cyanydeez 13 hours ago [-]
So many people and systems have some how merged into just a slathering of spam to everyones senses. It's no longer about truth statements, but just, is this attention-worthy, and most of the internet, it's social media and "people" are going into the no-bin.
hijnksforall956 23 hours ago [-]
[flagged]
UqWBcuFx6NV4r 1 days ago [-]
[flagged]
jacquesm 1 days ago [-]
My rules of thumb is much shorter: don't.
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.
sillysaurusx 24 hours ago [-]
Suppose almost all work in the future is done via LLMs, just like almost all transportation is done today via cars instead of horses.
Do you think your worldview is still a reasonable one under those conditions?
lkjdsklf 23 hours ago [-]
But all work isn't done by LLMs at the moment and we can't be sure that it will be so the question is ridiculous.
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.
ndriscoll 21 hours ago [-]
Basically all of my actual programming work has been done by LLMs since January. My team actually demoed a PoC last week to hook up Codex to our Slack channel to become our first level on-call, and in the case of a defect (e.g. a pagerduty alert, or a question that suggests something is broken), go debug, push a fix for review, and suggest any mitigations. Prior to that, I basically pushed for my team to do the same with copy/paste to a prompt so we could iterate on building its debugging skills.
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.
ipaddr 17 hours ago [-]
Sounds like a company on the verge of creating a mess that will require a rewrite in a year or so. Maybe an llm can do it.
coderenegade 10 hours ago [-]
I suspect this is more true than most people think. Today's bad code will be cleaned up by tomorrow's agents.
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.
ndriscoll 9 hours ago [-]
> 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
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.
joquarky 13 hours ago [-]
> It's clear that doing it by hand would mostly be because you enjoy the process.
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.
notpachet 21 hours ago [-]
> It's clear that doing it by hand would mostly be because you enjoy the process.
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.
devonkelley 19 hours ago [-]
[dead]
ndriscoll 18 hours ago [-]
Ultimately you always have to trust people to be judicious, but that's why it doesn't make any changes itself. Only suggests mitigations (and my team knows what actions are safe, has context for recent changes, etc). It's not entirely a black box though. e.g. I've prompted it to collect and provide a concrete evidence chain (relevant commands+output, code paths) along with competing hypotheses as it works. Same as humans should be doing as they debug (e.g. don't just say "it's this"; paste your evidence as you go and be precise about what you know vs what you believe).
jacquesm 19 hours ago [-]
That's sounds like the perfect recipe for turning a small problem into a much larger one. 'on call' is where you want your quality people, not your silicon slop generator.
logicprog 23 hours ago [-]
I say let people hold this stance. We, agentic coders, can easily enough fork their project and add whatever the features or refinements we wanted, and use that fork for ourselves, but also make it available for others in case other people want to use it for the extra features and polish as well. With AI, it's very easy to form a good architectural understanding of a large code base and figure out how to modify it in a sane, solid way that matches the existing patterns. And it's also very easy to resolve conflicts when you rebase your changes on top of whatever is new from upstream. So, maintaining a fork is really not that serious of and endeavor anymore. I'm actually maintaining a fork of Zed with several additional features (Claude Code style skills and slash commands, as well as a global agents.md file, instead of the annoying rules library system, which I removed, as well as the ability to choose models for sub-agents instead of always inheriting the model from the parent thread; and yes, master branch Zed has subagents! and another tool, jjdag)
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.
officeplant 22 hours ago [-]
Well at least you, agentic coders, already understand they need to fork off.
Saves the rest of us from having to tell you.
skeeter2020 19 hours ago [-]
>> but also make it available for others in case other people want to use it for the extra features and polish as well.
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?
logicprog 16 hours ago [-]
I've been able to make very clear, modular, well put together architectural foundations for my greenfield projects with AI. We don't have studies, of course, so it is only your anecdote versus mine.
short_sells_poo 22 hours ago [-]
> We, agentic coders, can easily enough fork their project
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.
sanderjd 21 hours ago [-]
Maybe! Or maybe there is really a competitive advantage to "artisanal" coding.
Personally, I would not currently expect a fork of RedoxOS that is AI-implemented to become more popular than RedoxOS itself.
logicprog 16 hours ago [-]
Indeed, maybe there is. I'm interested to see how it plays out.
geoffmunn 20 hours ago [-]
"make their own fork which nobody else is interested in because it is personalized to them"
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.
short_sells_poo 20 hours ago [-]
For a human to be able to do any customization, they have to dive into the code and work with it, understand it, gain intuition for it. Engage with the maintainers and community. In the process, there's a good chance that they'll be encouraged to contribute improvements upstream even if they have their own fork.
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.
coderenegade 10 hours ago [-]
I think that in the long run, AI assisted coding will turn out to be better than handcrafted code. When you pay for every token, and code generation is quick, a clean, low entropy codebase with good test coverage gets you a lot more for your dollar than a dog's breakfast. It's also much easier to fix bad decisions made early on in a project's life, because the machine is doing all of the heavy lifting.
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.
logicprog 15 hours ago [-]
> 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.
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.
Qwertious 14 hours ago [-]
Okay, but you don't have to - and "efficient" coders won't bother, thus starving the commons.
logicprog 13 hours ago [-]
Well, I would argue that if I didn't spend that time, then even a personal fork that I vibe coded would be worse, even for me personally. It would be incompatible with upstream changes, more likely to crash or have bugs, more difficult to modify in the future (and cause drift in the model's own output) etc.
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.
logicprog 16 hours ago [-]
I mean, I do open PRs for most of my changes upstream if they allow AI, once I've been using the feature for a few weeks and have fixed the bugs and gone over the code a few times to make sure it's good quality. Also, I'm going to be using the damn thing, I don't want it to be constantly broken either, and I don't want the code to get hacky and thus incompatible with upstream or cause the LLMs to drift, so I usually spend a good amount of time making sure the code is high quality — integrates with the existing architecture and model of the world in the code, follows best practices, covers edge cases, has tests, is easy to read so that I can review it easily.
But if a project bans AI then yeah, they'll be run out of town because I won't bother trying to contribute.
FridgeSeal 15 hours ago [-]
> We, agentic coders, can easily enough fork their project and add whatever the features
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.
logicprog 15 hours ago [-]
Since when is maintaining a personal patch set / fork parasitic? And in what way does it harm them, such that they should move to spaces where it doesn't happen, as a result? Also, isn't the entire point of open source precisely to enable people to make and use modifications of code if they want even if they don't want to hand code over? Also, that would be essentially making code closed source — do you think OSS is just going to die completely? Or would people make alternative projects? Additionally, this assumes coders who are fine with AI can't make anything new themselves, when if anything we've seen the opposite (see the phenomenon of reimplementing other projects that's been going around).
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.
hunterpayne 14 hours ago [-]
Its only parasitic if you are tricking users into thinking you are the original or providing something better. You could be providing something different (which would be valuable) but if you are not, you are just scamming users for your own benefit.
logicprog 13 hours ago [-]
I have no intention of tricking anyone into thinking I'm the original! I do think I offer improvements in some cases, so in cases where the project is something I intend for other people to ever see/use, I do explain why I think it is better, but I also will always put the original prominently to make sure people can find their way back to that if they want to. For example, the only time I've done this so far:
> just like almost all transportation is done today via cars instead of horses.
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.
sanderjd 21 hours ago [-]
As someone who enjoys working with AI tools, I honestly think the best approach here might be bifurcation.
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.
skeeter2020 19 hours ago [-]
even if this was true or someday will be (big IF), is it worth looking for valid counter workflows? example: in many parts of the US and Canada the Mennonites are incredibly productive farmers and massive adopters of technology while also keeping very strict limits on where/how and when it is used. If we had the same motivations and discipline in software could we walk a line that both benefited from and controlled AI? I don't know the answer.
jacquesm 19 hours ago [-]
Good one, I had not made the connection, but yes. Tech is here to serve, at our pleasure, not to be forcibly consumed.
bandrami 23 hours ago [-]
That would only be a world where the copyright and other IP uncertainties around the output (and training!) of LLMs were a solved and known question. So that's not the world we currently live in.
gehdhffh 21 hours ago [-]
The ruling capital class has decided that it is in their best interest for copyright to not be an obstacle, so it will not be. It is delusional to pretend that there is even a legal question here, because America is no longer a country of laws, to the extent that it ever was. I would bet you at odds of 10,000 to 1 that there will never be any significant intellectual property obstacles to the progress of generative AI. They might need to pay some fines here and there, but never anything that actually threatens their businesses in the slightest.
There clearly should be, but that is not the world we live in.
timando 14 hours ago [-]
I don't see any cars racing in the Melbourne Cup.
23 hours ago [-]
olmo23 24 hours ago [-]
Another great take I found online: "Don't send us a PR, send us the prompt you used to generate the PR."
duskdozer 23 hours ago [-]
What I've been begging for every time someone wants me to read their AI "edited" wall of text.
ChrisMarshallNY 1 days ago [-]
That's a pretty good framework!
Prompts from issue text makes a lot of sense.
adjfasn47573 23 hours ago [-]
> 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
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.
chownie 22 hours ago [-]
> Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?
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.
connicpu 22 hours ago [-]
A couple weeks ago someone on my team tried using the experimental "vibe-lint" that someone else had added to our CI system and the results were hilariously bad. It left 10 plausible sounding review comments, but was anywhere from subtly to hilariously wrong about what's going on in 9/10 of them. If a human were leaving comments of that quality consistently they certainly wouldn't receive maintainer privileges here until they improved _significantly_.
ptnpzwqd 22 hours ago [-]
It was maybe not quite clear enough in my comment, but this is more of a hypothetical future scenario - not at all where I assess LLMs are today or will get to in the foreseable future.
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.
Jnr 22 hours ago [-]
You can not trust the code or reviews it generates. You still have to review it manually.
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.
short_sells_poo 22 hours ago [-]
This is not even about capabilities but responsibility. In an open source context where the maintainers take no responsibility for the code, it's perhaps easier. In a professional context, ultimately it's the human who is responsible, and the human has to make the call whether they trust the LLM enough.
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.
darkwater 24 hours ago [-]
The problem was already there with lazy bug reports and inflammatory feature requests. Now there is a lazy (or inflammatory) accompanying code.
But there were also well-written bug reports with no code attached due to lack of time/skills that now can potentially become useful PRs if handled with application and engineering knowledge and good faith and will.
andrewchambers 1 days ago [-]
Isn't the obvious solution to not accept drive by changes?
oytis 1 days ago [-]
That's eliminating of an important part of open source culture.
swiftcoder 1 days ago [-]
I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.
ckolkey 1 days ago [-]
I've gotta disagree with you here - it's not uncommon for me to be diving into a library I'm using at work, find a small issue or something that could be improved (measurably, not stylistically), and open a PR to fix it. No big rewrites or anything crazy, but it would definitely fit the definition of "drive by change" that _thus far_ has been welcomed.
duskdozer 24 hours ago [-]
>find a small issue
>No big rewrites or anything crazy
I think those are the key points why they've been welcomed.
oytis 1 days ago [-]
How to differentiate between a drive-by contribution and a first contribution from a potentially long-time contrubutor.
And I would say especially for operating systems if it gets any adoption irregular contributions are pretty legit. E.g. when someone wants just one specific piece of hardware supported that no one else has or needs without being employed by the vendor.
Muromec 1 days ago [-]
This sounds complicated in theory, but it's easier in practice.
Potential long time contributor is somebody who was already asking annoying questions in the irc channel for a few months and helped with other stuff before shooting off th e PR. If the PR is the first time you hear from a person -- that's pretty drive-by ish.
DrewADesign 1 days ago [-]
Sounds like a better way to make sure you have to be part of a clique to get your changed reviewed. I’ve been a long-time bug fixer in a few projects over the years without participating in IRC. I like the software and want it you work, but have no interest in conversing about it at that level, especially when I was conversing about software constantly at work.
I always provided well-documented PRs with a narrow scope and an obvious purpose.
MadameMinty 1 days ago [-]
Why would I ask annoying questions when I can identify, reproduce, pinpoint the bug, locate it in code, and fix it? Doing it alone should make it clear I don't need to ask to understand it. And why would I be interested in small talk? Doubt many people are when they patch up their work tools. It's a dispassionate kind of kindness.
Not to mention LLMs can be annoying, too. Demand this, and you'll only be inviting bots to pester devs on IRC.
swiftcoder 23 hours ago [-]
> Why would I ask annoying questions when I can identify, reproduce, pinpoint the bug, locate it in code, and fix it?
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
CorrectHorseBat 22 hours ago [-]
If the maintainers are already bandwidth limited, how is first asking annoying questions not also a drain on that bandwidth?
duskdozer 24 hours ago [-]
Because you may misinterpret the correct fix or not know that your implementation doesn't fit the project's plans. Worse if it's LLM-generated.
FridgeSeal 11 hours ago [-]
“Why would I ever want to talk to other humans about things? Especially anyone who might have some kind of extra understanding on the project that I’m not currently privy to!”
junon 1 days ago [-]
Hard disagree. Drive by's were the easiest to deal with, and the most welcome. Especially when the community tilted more to the side of non-amateurs and passionate people.
DrewADesign 11 hours ago [-]
Low effort drive-bys were easy to spot because the amount of code was minimal, documentation was nonexistent, they didn’t use the idioms and existing code effectively, etc. Low-skill drive-bys were easy to spot because the structure was a mess, the docs explain language features while ignoring important structural information, and other newbie gaffes.
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.
cindyllm 11 hours ago [-]
[dead]
CorrectHorseBat 1 days ago [-]
I can understand drive-by features can be a net burden, but what is wrong with a drive-by bugfix?
pmarreck 1 days ago [-]
how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?
swiftcoder 1 days ago [-]
Mostly by whether they check in first to see if the fix is actually welcome?
Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction
kpcyrd 23 hours ago [-]
Your open source experience is very different from my open source experience.
hunterpayne 13 hours ago [-]
I've seen both ways. Sometimes the contributors let their ego prevent improvements to the architecture. Recently, I tried to get rid of a bug farm in a library I use. A single function was reduced to 1 line that depended on far more reliable method. And the maintainers put it back in later on (breaking my app yet again, sigh). In all fairness, those maintainers are academics who work for the French government so probably not the best representation of the community but still.
mcherm 15 hours ago [-]
I'm all in favor of not accepting "drive-by changes". But every contributor to the project had to make their first contribution at some point in time. What's the process for inviting in new contributors?
ptnpzwqd 1 days ago [-]
Sure - and I suspect we will see that soon enough. But it has downsides too, and finding the right way to vet potential contributors is tricky.
ketzu 1 days ago [-]
> 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.
Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.
ptnpzwqd 1 days ago [-]
Yes, I agree. It was just me playing with a hypothetical (but in my view not imminent) future where vibe-coding without review would somehow be good enough.
NitpickLawyer 1 days ago [-]
Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one.
That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. 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.
ptnpzwqd 1 days ago [-]
At the moment verification at scale is an unsolved problem, though. As mentioned, I think this will act as a rough filter for now, but probably not work forever - and denying contributions from non-vetted contributors will likely end up being the new default.
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.
mapcars 1 days ago [-]
> Or if the code is a mess. Or if it doesn't follow conventions.
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.
ZaoLahma 1 days ago [-]
I've recently worked extensively with "prompt coding", and the model we're using is very good at following such instructions early on. However after deep reasoning around problems, it tends to focus more on solving the problem at hand than following established guidelines.
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."
UqWBcuFx6NV4r 1 days ago [-]
A separate pre-planning step, so the context window doesn’t get too full too early on.
Off the shelf agentic coding tools should be doing this for you.
lkjdsklf 23 hours ago [-]
They do not.
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.
bandrami 23 hours ago [-]
Until the copyright questions surrounding LLM output is solved it's not "vibes" to reject them but simply "legal caution".
rswail 23 hours ago [-]
The entire basis of the OSS is licensing.
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.
majewsky 20 hours ago [-]
> It is very unclear whether the output of an AI tool is subject to copyright.
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.
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.)
mathw 1 days ago [-]
Your analogy with CI/CD is flawed because while not all were convinced of the merits of CI/CD, it's also not technology built on vast energy use and copyright violation at a scale unseen in all of history, which has upended the hardware market, shaken the idea of job security for developers to its very foundation and done it while offering no really obvious benefits to groups wishing to produce really solid software. Maybe that comes eventually, but not at this level of maturity.
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.
ckolkey 1 days ago [-]
owing "nothing to no one" means you are allowed to be unreasonable...
surgical_fire 1 days ago [-]
> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.
To outright accept LLM contributions would be as much "pure vibes" as banning it.
The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is not.
If you dislike it, you are free to fork it and make a "LLM's welcome" fork. If, as you imply, the LLM contributions are invaluable, your fork should eventually become the better choice.
Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.
ApolloFortyNine 23 hours ago [-]
>Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.
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.
surgical_fire 22 hours ago [-]
> Using an LLM to assist in development does not instantly make the whole work 'low effort'.
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.
UqWBcuFx6NV4r 1 days ago [-]
Your reply is based on a 100% bad-faith, intellectually dishonest interpretation of the comment to which you’re replying. You know that.
Nobody claimed that LLM code should be outright accepted.
Also, nobody claimed that open source maintainers have the right to accept or decline based on whichever criteria they choose. To always come back to this point is so…American. It’s a cop-out. It’s a thought-terminating cliche. If you aren’t interested in discussing the merits of the decision, don’t bother joining the conversation. The world doesn’t need you to explain what consent is.
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.
surgical_fire 24 hours ago [-]
> Nobody claimed that LLM code should be outright accepted
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.
keybored 1 days ago [-]
> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.
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.
2 hours ago [-]
devonkelley 19 hours ago [-]
[dead]
advancespace 24 hours ago [-]
[flagged]
r_lee 23 hours ago [-]
did you write this with an LLM?
rob 22 hours ago [-]
It's a bot that posted a link to its "Runframe.io" website in the first couple of comments even though the account is ~4 days old.
Dan said yesterday he was "restricting" Show HN to new accounts:
That doesn't make too much sense to me, or he hasn't actually implemented this yet.
baq 23 hours ago [-]
You’re talking to someone’s clanker
short_sells_poo 22 hours ago [-]
I find the fact that people can't even be bothered to put their own thoughts into text and communicate via an LLM to be the most grotesque and dystopian aspect of this new AI era.
It looks like we are going to have large numbers of people whose entire personality is projected via an AI rather than their own mind. Surely this will have an (likely deleterious) effect on people's emotional and social intelligence, no? People's language centers will atrophy because the AI does the heavy lifting of transforming their thoughts into text, and even worse, I'm not sure it'll be avoidable to have the AIs biases and start to leak into the text that people like this generate.
baq 21 hours ago [-]
These aren't even their thoughts, it's just a bot let loose.
I remember the first time I suspected someone using an LLM to answer on HN shortly after chatgpt's first release. In a few short years the tables turned and it's increasingly more difficult to read actual people's thoughts (and this has been predicted, and the predictions for the next few years are far worse).
rcruzeiro 23 hours ago [-]
The hyphen instead of an em dash suggests a human (though one could simply replace em dashes with hyphens to make the text more “human-like”).
rob 22 hours ago [-]
No it doesn't. That bot's comment and every comment under its profile 100% reads like an LLM to anybody that has seen enough of them. I already knew that one was a bot before even clicking the profile. See enough of them and the uncanny valley feeling immediately pops out. Even the ones that try to trick you by typing in all lowercase.
An em-dash might have been a good indicator when LLMs were first introduced, but that shouldn't be used as a reliable indicator now.
I'm more concerned that they keep fooling everybody on here to the point where people start questioning them and sticking up for them a lot of times.
petcat 23 hours ago [-]
I've seen skills on the various skillz marketplaces that specifically instruct the LLM-generated text to replace emdashes with hyphens (or double-hyphens), and never to use the "it's not just <thing>, it's <other thing>" phrasing.
Also to, intentionally introduce random innoccuous punctuation and speling errors.
rcruzeiro 21 hours ago [-]
I do wonder if the way people speak is starting to change because of LLMs. The “it’s not just” thing (I forgot the name for it) is something that used to be a giveaway, but I am now seeing more and more people use it IRL. Perhaps I am just more vigilant towards this specific sentence construction that I notice it more?
AlecSchueler 22 hours ago [-]
> The build was never the expensive part. The review, the edge cases, the ongoing maintenance
But everything up to that hyphen was pure slop.
23 hours ago [-]
amelius 23 hours ago [-]
> It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers.
But the maintainers can use AI too, for their reviewing.
ptnpzwqd 23 hours ago [-]
Yes, but LLM-based reviews are not nearly a compensation for human review, so it doesn't change much.
eyk19 1 days 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 1 days 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.
eyk19 1 days ago [-]
Definitely, but that's kind of my point: the maintainers are still going to be way better at all of that than some random contributor who just wants a feature, vibe codes it, and barely tests it. The maintainers already know the codebase, they understand the implications of changes, and they can write much better plans for the agent to follow, which they can verify against. Having a great plan written down that you can verify against drastically lowers the risk of LLM-generated code
ChadNauseam 18 hours ago [-]
You can do all the steps I mentioned as a random contributor. I've done it before. But I agree that donations are better than just prompting claude "implement this feature, make no mistakes" and hoping it one-shots it. Honestly, even carefully thought-out feature requests are much more valuable than that. At least if the maintainer vibe-codes it they don't have to worry that you deliberately introduced a security vulnerability or back door.
eloisius 1 days ago [-]
Or even more efficient: the model we already have. Donate money and let the maintainer decide whether to convert it into tokens or mash the keys themself.
oytis 1 days ago [-]
Who reviews the correctness of the second agents' review?
advancespace 24 hours ago [-]
[dead]
defmacr0 1 days ago [-]
So your proposed solution to AI slop PRs is to "donate" compute, so the maintainers can waste their time by generating the AI slop themselves?
eyk19 1 days ago [-]
The point isn't that agent output is magically better; it's that reviewing your own agent's output is way cheaper (intellectually) than reviewing a stranger's, because you've written the plan by yourself. And 'slop' is mostly what you get when you don't have a clear plan to verify against. Maintainers writing detailed specs for their own agents is a very different thing from someone vibe coding a feature request
layer8 1 days ago [-]
You’re assuming that maintainers have a desire to use agentic coding in the first place.
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.
oytis 1 days ago [-]
Open-source maintainers have no investors to placate, no competition to outrun, why would they want to use agentic coding in the first place?
eatonphil 23 hours 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.
Thanks. Now I know which software to avoid: the ones that ban legitimate tool use. I have no respect for this protectionist prohibition. These people would insist on driving horse carriages 125 years ago because people were still getting used to driving automobiles.
aerhardt 23 hours 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.
edelbitter 11 hours ago [-]
To complete your analogy:
To this day there are humans who have never in their life exceeded 300km/h outside of an airplane. Mostly people in places that had become used to driving. Used to subpar travel times, safety, efficiency and cost. In hindsight, those that saw the horses swapped for electric ones with the carriages mostly unchanged should have been more protective in their transport planning. Could have saved us from the 110 year detour that scarred almost all urban centers.
cptroot 20 hours ago [-]
I think you'll find the luddites to be a more informative historical analogy. A new tool arrives in an industry staffed by craftsmen, providing capital a lever to raise profits at the expense of quality. Is it surprising that worker co-ops would choose not to pull that lever?
Gud 2 hours ago [-]
Why do you believe the quality will go down?
cmrdporcupine 19 hours ago [-]
The mistake here with both the Luddites and this is to mistake the tool for the actual problem (depending on where you sit), which is mechanization and automation and ultimately capitalism itself.
Opposing the machine does/did nothing.
Political organizing around unions, state regulations of the labour market, agitational political parties did (and can again).
filleduchaos 13 hours ago [-]
Political organizing around unions, state regulations of the labour market, and agitational political parties did nothing to prevent the severe decline of clothing quality that was the Luddites were advocating against. But of course, propaganda has very successfully reduced their entire platform to "worker's pay" alone, which is an even easier line to feed to people that over the decades have become accustomed to literal slop as apparel. And I mean that very literally - clothes that straight-up lose their structural integrity after a handful of laundry cycles.
Of course, there's definitely absolutely nothing about the state of the garment industry that's applicable to the current discussions about AI re: software quality and worker compensation. It's not as if this industry has not already seen its fair share of quality going to the dogs with only a small handful of people still knowing and caring enough to call it out while most others cheer for the Productivity™.
joelthelion 23 hours ago [-]
How about picking software based on how well it works?
flammafex 10 hours 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.
ddtaylor 17 hours 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.
23 hours ago [-]
mfru 20 hours ago [-]
One's legitimate tool is the other's slop machine
Copyrightest 19 hours ago [-]
NetBSD has a very reasonable stance:
If you commit code that was not written by yourself, double check that the license on that code permits import into the NetBSD source repository, and permits free distribution. Check with the author(s) of the code, make sure that they were the sole author of the code and verify with them that they did not copy any other code.
Code generated by a large language model or similar technology, such as GitHub/Microsoft's Copilot, OpenAI's ChatGPT, or Facebook/Meta's Code Llama, is presumed to be tainted code, and must not be committed without prior written approval by core.
No, it is not reasonable to presume code generated by any large language model is "tainted code." What does that even mean? It sounds like a Weird Al parody of the song "Tainted Love."
eschaton 9 hours ago [-]
“Taint” has been a term of art in Open Source for decades. That you don’t know this reveals your ignorance, not any sort of cleverness.
LLMs regurgitate their training data. If they’re generating code, they’re not modeling the syntax of a language to solve a problem, they’re reproducing code they ingested, code that is covered by copyright. Just regurgitating that code via an LLM rather than directly from your editor’s clipboard does not somehow remove that copyright.
It’s clear you think you should be allowed to use LLMs to do whatever you want. Fortunately there are smarter people than you out there who recognize that there are situations where their use is not advised.
flammafex 2 hours ago [-]
No constitution. No copyright.
We're clearly not doing that anymore.
Have fun being smart or whatever.
eschaton 2 hours ago [-]
Another sociopath outs themselves as if there couldn’t possibly be any consequences to doing so.
Copyrightest 9 hours ago [-]
[dead]
lukaslalinsky 1 days 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.
konschubert 1 days 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.
lukaslalinsky 24 hours ago [-]
I still think there is value in external contributors solving problems using LLMs, assuming they do the research and know what they are doing. Getting a well written and tested solution from LLM is not as easy as writing a good prompt, it's a much longer/iterative process.
lkjdsklf 23 hours ago [-]
> assuming they do the research and know what they are doing.
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.
advancespace 24 hours ago [-]
[flagged]
ZaoLahma 22 hours ago [-]
Some months back I would have agreed with you without any "but", but it really does help even if it only takes over "typing code".
Once you do understand the problem deep enough to know exactly what to ask for without ambiguity, the AI will produce the code that exactly solves your problem a heck of a lot quicker than you. And the time you don't spend on figuring out language syntax, you can instead spend on tweaking the code on a higher architecture level. Spend time where you, as a human, are better than the AI.
naasking 23 hours ago [-]
I don't know, I've had good experiences getting LLMs to understand and follow architecture and style guidelines. It may depend on how modular your codebase already is, because that by itself would focus/minimize any changes.
mixedbit 1 days ago [-]
If an author of a PR just generated code with an LLM, the GitHub PR becomes an incredibly inefficient interface between a repository owner and the LLM. A much better use of the owner time would be to interact with LLM directly instead of responding to LLM generated PR, waiting for updates, responding again, etc.
lukaslalinsky 24 hours ago [-]
As a project maintainer, I don't want to interact with someone's LLM. If a person submits a PR, using LLM or not, the person is responsible for any problems with it. How they respond to review is a good indicator if they actually understand the code. And if they used a bot to submit the PR, I'd simply consider it a spam.
silverwind 24 hours ago [-]
Yep, the indirection through the PR author is almost always inefficient and error-prone unless the author is really knowledgable about the code (many aren't).
bandrami 23 hours ago [-]
And in general a lot more people want to use LLMs to generate things than want to consume the things LLMs generate. Some of the more bullish people should think harder about this pretty clear trend.
mfld 1 days 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 1 days 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.
zhangchen 24 hours ago [-]
that's already happening tbh. the real issue isn't hypocrisy though, it's that maintainers reviewing their own LLM output have full context on what they asked for and can verify it against their mental model of the codebase. a random contributor's LLM output is basically unverifiable, you don't know what prompt produced it or whether the person even understood the code they're submitting.
hijnksforall956 23 hours ago [-]
How is that different than before LLMs? You have no idea how the person came up with it, or whether they really understood.
We are inventing problems here. Fact is, an LLM writes better code than 95% of developers out there today. Yes, yes this is Lake Wobegone, everyone here is in the 1%. But for the world at large, I bet code quality goes up.
duskdozer 22 hours ago [-]
It's a lot harder for someone who has no clue what they're doing to write a lot of plausible-but-wrong code.
riffraff 23 hours ago [-]
some projects (I came across Mastodon's policy[0] which they say was inspired by ghostty and others) which have a more relaxed policy of basically "LLMs are ok so long as you understand what they did, and you own it".
But I think different projects have different needs.
Some sort of LLM audit trail is needed (containing prompts used, model identifier and marking all code written by LLM). It could be even signed by LLM providers (but that wouldn't work with local models). Append only standard format that is required to be included in PR. It wouldn't be perfect (e.g. deleting the log completely), but it might help with code reviews.
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.
chatmasta 1 days ago [-]
This would be a useful feature to bake into the commits generated by agents. Heck you don’t even need to wait — just change your prompt to tell it to include more context in its commit messages and to sign them as Claude rather than yourself…
pjc50 1 days ago [-]
The GPL talks about "the preferred form for modification of the software", and I'm starting to think that anything which involves any kind of LLM agent should be including all the text that the user gave to it as well. Prompts, etc.
Of course, even then it's not reproducible and requires proprietary software!
est31 11 hours ago [-]
I still think the source code is the preferred form for modification because it is what you point the AI at when you want it to make a change.
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.
rswail 23 hours ago [-]
Except the GPL is dependent on the author having copyright over the original software but the output of an LLM may not be covered by copyright as a derivative work.
That breaks "copyleft" entirely.
dlillard0 1 days ago [-]
I think guiding the LLM to write code is easy for them to write code by themselves.
pydry 1 days ago [-]
The "interesting situation" is that maintainers are unable to cheaply distinguish slop from good contributions so they will simply stop accepting outside contributions.
This will cut off one of the genuine entry points to the industry where all you really needed was raw talent.
throwaway2037 1 days 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.
layer8 1 days ago [-]
> What about submarine LLM submissions?
That would constitute an attempt to circumvent their policy, with the consequence of being banned from the project. In other words, it makes not clearly labeling any LLM use a bannable offense.
wang_li 15 hours ago [-]
It should be a litigable offense.
oytis 1 days ago [-]
Don't ask don't tell looks like a reasonable policy. If no one can tell that your code was written by an LLM and you claim authorship, then whether you have actually written it is a matter of your conscience.
BlackLotus89 1 days ago [-]
I read that as benefit of the doubt, which is a reasonable stance.
1 days ago [-]
eesmith 1 days 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... .
pjc50 1 days ago [-]
People who talk about "virtue signalling" are usually engaging in vice signalling.
subjectsigma 1 days 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.
eesmith 23 hours ago [-]
It's not a useful phrase because a "we accept AI-generated contributions" is also virtue signalling.
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.
khalic 1 days 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?
BlackFly 1 days 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 1 days 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 1 days 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 1 days 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.
joaohaas 1 days ago [-]
It follows the same reasoning as when someone purposefully copies code from a codebase into another where the license doesn't allow.
Yes it might be the only viable solution, and most likely no one will ever know you copied it, but if you get found out most maintainers will not merge your PR.
pm215 1 days 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.
ranger_danger 11 hours ago [-]
The trick is getting people to believe you.
pmarreck 1 days ago [-]
You not realizing how ridiculous this is, is exactly why half of all devs are about to get left behind.
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.
bigstrat2003 21 hours ago [-]
> 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.
pmarreck 11 hours ago [-]
Sorry, but this is user error.
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.
notpachet 20 hours ago [-]
> 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.
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.
ralferoo 1 days ago [-]
The problem is that even if the code is clear and easy to understand AND it fixes a problem, it still might not be suitable as a pull request. Perhaps it changes the code in a way that would complicate other work in progress or planned and wouldn't just be a simple merge. Perhaps it creates a vulnerability somewhere else or additional cognitive load to understand the change. Perhaps it adds a feature the project maintainer specifically doesn't want to add. Perhaps it just simply takes up too much of their time to look at.
There are plenty of good reasons why somebody might not want your PR, independent of how good or useful to you your change is.
pjc50 1 days ago [-]
How would you tell that it's LLM-generated in that case?
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".
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.
rswail 23 hours ago [-]
I think you need to read the report from the US Copyright office that specifically says that it's *not* (c) copyright of the operator.
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".
hparadiz 22 hours ago [-]
You may as well be the MPAA right now throwing threats around sharing MP3s. We're past the point of caring and the laws will catch up with reality eventually. The US copyright office says things that get turned over in court all the time.
eschaton 9 hours ago [-]
Tell me, how have laws “caught up with” “the [RIAA…] throwing threats around sharing MP3s?” So far as I know that’s still considered copyright infringement and the person doing it, if caught, can be liable for very substantial statutory damages.
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.
rswail 6 hours ago [-]
lol, ask the software industry whether or not their "past the point of caring" about the licenses on their software.
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.
hparadiz 46 minutes ago [-]
The entire industry is right now encouraging LLM use all day everyday at big corps including mine. If your argument is the code we are producing isn't copyright of our employers you won't get very far. Call it the realpolitik of tech if you want.
pmarreck 1 days ago [-]
This is where most reasonable people would say “OK, fine”
CLEARLY, a lot of developers are not reasonable
eschaton 9 hours ago [-]
It is entirely reasonable for a project to require you to attest that the thing you are contributing is your own work.
The unreasonable ones are the ones with the oppositional-defiant “You can’t tell me I can’t use an LLM!” reaction.
repelsteeltje 1 days ago [-]
I think the bigger point about enforcement is not whether you're able to detect "content submitted that is clearly labelled as LLM-generated", but that banning presumes you can identify the origin. Ie.: any individual contributor must be known to have (at most) one identity.
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.
hrmtst93837 16 hours ago [-]
You can slap on any punishment clause you want but verifying LLM-origin content without some kind of confession is shaky at best outside obvious cases like ChatGPT meta-fingerprints or copy-paste gaffes. Realistically, it boils down to vibes and suspicion unless you force everyone to record their keystrokes while coding which only works if you want surveillance. If the project ever matters at scale people will start discussing how enforceability degrades as outputs get more human-like.
eschaton 9 hours ago [-]
There’s this thing called “honor” where if you tell someone that they need to affirm their contribution is their own work and not created with an LLM, most people most of the time will tell the truth—especially if the “no LLMs” requirement is clearly stated up front.
You’re basically saying that a “no-LLMs” rule doesn’t matter, because dishonorable people exist. That’s not how most people work, and that’s not how rules work.
When we encounter a sociopath or liar, we point them out and run them out of our communities before they can do more damage, we don’t just give up and tolerate or even welcome them.
khalic 22 hours ago [-]
Unenforceable means they can't actually enforce it since they can't discriminate high quality LLM code from hand typed
eschaton 9 hours ago [-]
This is the dream of the sociopathic slopmonger.
Real people in the real world understand that rules don’t simply cease to exist because there’s no technical means of guaranteeing their obedience. You simply ask people to follow them, and to affirm that they’re following them whether explicitly or implicitly, and then mete out severe social consequences for being a filthy fucking liar.
khalic 3 hours ago [-]
Keep wishing, in the meantime some people have to deal with the real world and plan accordingly
ptnpzwqd 1 days 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.
bonesss 1 days 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”.
buzzardbait 1 days ago [-]
Probably just an attempt to stop low effort LLM copy pasta.
Ekaros 1 days 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.
1 days ago [-]
scuff3d 18 hours ago [-]
Speed limits are unenforceable. You'll never catch everyone speeding so why even bother trying.
anonnon 1 days 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 1 days 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.
duskdozer 24 hours ago [-]
The chardet debacle is probably one of the most recent and egregious.
anonnon 1 days 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.c...
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
kuschku 3 hours ago [-]
You have to go through all the dependencies anyway, to roughly judge their quality, and the activity of their maintainers. Quickly looking at the license doesn't take any more effort.
khalic 3 hours ago [-]
Totally realistic expectation
kuschku 1 hours ago [-]
Considering you have to list all used open source software, their authors, and their licenses in your UI anyway, sure.
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.
anonnon 13 hours ago [-]
> ... you think It was good time?
Yes, as do, probably, most people who remember it.
khalic 23 hours ago [-]
Sarcasm? Nobody will be contributing with a complexe signing process like that, and it doesn't guarantee anything in the end, it's like a high tech pinky swear
anonnon 13 hours ago [-]
Lots of projects have had requirements like this for years, usually to prevent infection by (A)GPL's virality, or in the case of the FSF, so they can sue on your behalf, or less scrupulously, so the project can re-license itself or dual license itself in the future should the maintainers opt to. (This last part was traditionally the only part that elicited objections to CLAs.)
> 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 .
Yep, that’s why my forks of all their libraries with bugs fixed such as 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.
So does that mean they contradicted their own no LLM policy?
ptx 23 hours ago [-]
The PR doesn't disclose that "an LLM did it", so maybe the project allowed a violation of their policy by mistake. I guess they could revert the commit if they happen to see the submitter's HN comment.
TacticalCoder 23 hours ago [-]
Dunno but a commenter already noted that some begins to say: "No LLM generated PR, but we'll accept your prompt" and another person answered he saw that too.
It makes lots of sense to me.
conradludgate 21 hours ago [-]
I've never had a one-shot prompt ever work. It's always an interactive session to eventually get to the working solution.
il-b 22 hours ago [-]
> Also, this is dumb because anyone who wants fixes like this will have to find a fork like mine with them
Or a human will provide the fix?
laweijfmvo 20 hours ago [-]
a human who looks at the AI generated fix but ‘types it out, the old fashioned way’?
justin66 20 hours ago [-]
Because it's inconceivable that a human could look at a bug report and actually fix a bug.
lpcvoid 1 days 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 1 days ago [-]
Any thoughts on why you have that preference?
lpcvoid 23 hours 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.
hijnksforall956 23 hours ago [-]
[flagged]
foresterre 22 hours ago [-]
That's a rather unkind comment.
For the parent there's immaterial value knowing that is written by a human. From what I read in your comment, you see code more as a means to an end. I think I understand where the parent is coming from. Writing code myself, and accomplishing what I set out to build sometimes feels like a form of art, and knowing that I build it, gives me a sense of accomplishment. And gives me energy. Writing code solely as a means to an end, or letting it be generated by some model, doesn't give that same energy.
This thinking has nothing to do with not caring about being a good teammate or the business. I've no idea why you put that on the same pile.
hijnksforall956 20 hours ago [-]
Some people like to do wood working with old tools, or build their house themselves. Wonderful. We are not taking about that.
Code is a means to an end.
CoastalCoder 22 hours ago [-]
Friendly suggestion: your post contains a mix of interesting points and ad hominim attacks.
People will be more likely to engage with your main assertion if you leave out the insults.
hijnksforall956 21 hours ago [-]
Is that like when "respected poster" jascuqesm implied I'm an asshole?
CoastalCoder 21 hours ago [-]
I'm not trying to police the whole website.
I noticed your account was new, so I thought you might appreciate a likely explanation for why your post was being downvoted.
Meneth 24 hours ago [-]
I agree.
TiredOfLife 22 hours ago [-]
Racism has always been a popular opinion.
mekael 21 hours ago [-]
A desire to engage with humans instead of matrix multiplication isn’t, and is incapable of being, racist.
The underlying data that said matrices compute upon, can be racist though.
I will admit that I may be missing some context though.
orf 1 days ago [-]
just like... don't tell them a LLM did it?
jacquesm 1 days ago [-]
That's a dick move because you are opening up an open source project to claims of infringement without recourse.
Why on earth would you force stuff on a party that has said they don't want that?
orf 24 hours ago [-]
Sure, but back in reality no you’re not? No more than any other contributor?
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.
jacquesm 24 hours ago [-]
No, you can't. See, that's where you are just wrong: when you don't respect the boundaries an open source project sets that you want to contribute to then you are a net negative.
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.
orf 23 hours ago [-]
They are asking me to author my contributions in a way that they approve of. The essence of the request is the same as asking someone to author them whilst standing on their head.
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.
eschaton 9 hours ago [-]
If you’re going to lie and say there was no LLM involved, what else are you going to lie about? Copying code from another codebase with incompatible license terms, perhaps?
I would say people should be wary of any contributions whatsoever from a filthy fucking liar.
orf 8 hours ago [-]
> what else are you going to lie about?
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.
kuschku 3 hours ago [-]
> 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”?
At that point you've proven intention, meaning you'll get the chance to argue your viewpoint in front of a judge.
orf 2 hours ago [-]
> 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.
orf 54 minutes ago [-]
I’m really struggling to understand why you think any of this means anything?
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.
eschaton 8 hours ago [-]
Wow, you sound like exactly the kind of sociopathic piece of shit who would do something that. Do the world a favor and remove yourself from it. Go be a hermit or something.
9 hours ago [-]
duskdozer 23 hours ago [-]
So, "might makes right", essentially?
orf 23 hours ago [-]
No, just a normal reaction to someone trying to force their beliefs on you.
duskdozer 22 hours ago [-]
You can choose not to contribute instead of intentionally violating their boundaries.
orf 22 hours ago [-]
Their boundaries. If they don’t want to accept the code, cool. Nobody is forcing them to, and I respect that.
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.
jacquesm 20 hours ago [-]
I'll make this blunt: if you're a guy then half the population is not capable of 'enforcing their boundaries' against you, more so if you count children. The problem you seem to have is to think that if someone is not capable of enforcing their boundaries that they are not allowed to have those boundaries and that it is your god given right to do whatever the F* you want just because you can. That's not how the world works, nor is it how it should work.
Boundaries - of all kinds - are not unenforceable nonsense, they are rights that you willingly and knowingly violate.
orf 19 hours ago [-]
[flagged]
jacquesm 19 hours ago [-]
You're on the wrong side of that discussion. And you are now also on my blocklist, goodbye.
orf 19 hours ago [-]
[flagged]
duskdozer 22 hours ago [-]
So we're back to might makes right then: "you can't stop me, so I'll do whatever I want to you."
orf 22 hours ago [-]
What a reductive argument. Is this your first day on planet earth? If so, here’s what you need to know:
- 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.
hananova 20 hours ago [-]
You are literally being the cliché of “Techbros don’t understand consent.” Don’t be that way.
jacquesm 20 hours ago [-]
I was holding back from writing precisely that, thank you.
orf 20 hours ago [-]
[flagged]
hijnksforall956 23 hours ago [-]
I am authoring my contributions, using Clause Code as a tool. It doesn't make me an asshole.
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.
justin66 20 hours ago [-]
Forking the code can be perfectly reasonable, with this or any other disagreement about policy. The main point of contention in this thread is whether you ought to lie about having used an LLM. I agree with Jacques: doing something like that would make you an asshole.
flykespice 18 hours ago [-]
Wow this tells alot about you.
You're so much a law abiding citizent aren't you?
Tell me how many times did you lie on your tax returns?
Or how many times you submitted PR with code you don't own to your peers?
orf 16 hours ago [-]
Never? That would be tax avoidance and theft, both crimes.
kuschku 3 hours ago [-]
So is fraudulently claiming your code has a different author & copyright (you) than it actually has (whether that's someone else's code, or LLM-generated code).
orf 2 hours ago [-]
Ok so you’re saying that if I make a PR on GitHub and say that it’s not LLM generated when it is, I’ll get arrested by the police?
If you know there's a bug, why not just properly fix it and get it merged, instead of outsourcing that fix?
KingMob 24 hours ago [-]
Even before AI, getting a fix into an open source project required a certain level of time and effort. If you prefer to spend your time on other things, and you assume it will eventually get fixed by someone else, using an LLM to fix it just for yourself makes sense.
dakolli 1 days ago [-]
If you rely on llms, you're simply not going to make it. The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator. Now how do we think things are going to turn out for the person that doesn't even think they need to learn how to use a calculator.
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.
electrosphere 1 days ago [-]
I went into software because I like building things and coming up with solid solutions to business problems that are of use to society. I would not describe myself with "love to code". It's a means to an end to pay bills and have a meaningful career. I think of myself more like a carpenter or craftsman.
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
jacquesm 24 hours ago [-]
> I think of myself more like a carpenter or craftsman.
> 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.
mwigdahl 20 hours ago [-]
What term would you use for that "opposite"?
jplusequalt 14 hours ago [-]
The commissioner? You don't actually possess the knowledge that went into the code, as you did not write it.
jacquesm 20 hours ago [-]
Plumber?
dakolli 8 hours ago [-]
Yeah could you imagine a project manager saying they are like a carpenter or a craftsman lmfao
wccrawford 24 hours ago [-]
I went into software because I love to code.
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.
dakolli 8 hours ago [-]
Cool you had it do something for you, this isn't building or learning no matter what you tell yourself. Your brain is going to atrophy. The process of building can be frustrating, so what, so is training for a marathon or anything rewarding in life.
slibhb 22 hours ago [-]
> The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator
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.
kuschku 3 hours ago [-]
> 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.
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.
jplusequalt 14 hours ago [-]
>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 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.
dakolli 8 hours ago [-]
Yeah, I agree. However, people use llms for the same reason people drive 3 blocks to a store rather than walk. Laziness and convenience. They simply don't care if their leg muscles atrophy. However, I think people aren't taking into account how much more important your thinking "muscles" are and its way more consequential to let those atrophy.
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.
iSnow 21 hours ago [-]
>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 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.
duskdozer 23 hours ago [-]
I agree but only in the very long term. I think short-medium term, it's not going to matter as the MBA types get so caught up in the mania that results matter even less than they normally do.
laweijfmvo 20 hours ago [-]
when i was in school we were graded (yes, actually given a letter grade) on our handwriting. mine was pretty terrible. i think i’m doing alright now.
dakolli 8 hours ago [-]
lmao, this response kinda proves my point.. Have you already lost your ability to think brother?
oerdier 23 hours ago [-]
One doesn't exclude the other. I still program myself; I actually have more time to do so because the LLM I pay some billionaire for is taking care of the mundane stuff. Before I had to do the mundane stuff myself. What I pay the billionaire is a laughable fraction compared to the time and energy I now have extra to spend on meaningful innovation.
0xbadcafebee 22 hours 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 19 hours 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 3 hours 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.
tkel 1 days ago [-]
Glad to see they are applying some rigor. I've started removing AI-heavy projects from my dependency tree.
butILoveLife 23 hours 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.
decidu0us9034 14 hours ago [-]
It's an operating system, not a website.
hananova 16 hours 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 12 hours ago [-]
This is like 2 months outdated.
eschaton 9 hours ago [-]
Or you aren’t the judge of quality and skill that you think you are.
stuaxo 1 days 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 1 days 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 1 days ago [-]
I don't think the licensing issues are the main problem, but the spam.
rswail 23 hours ago [-]
It is not clear that copyright continues on the LLM output, that is, the output is not necessarily a derivative work.
So "copyleft" doesn't work on any of the output. Therefore no GPL applies.
andy12_ 1 days 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 23 hours 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_comp...
A model that contains no GPL code makes sense so that people using non-GPL licenses don't violate it.
flykespice 18 hours ago [-]
Doesn't Richard Stallman opposes AI use?
duskdozer 1 days ago [-]
Rather, LLMs that do NOT contain GPL code.
hparadiz 1 days ago [-]
I am 100% certain that code that Redox OS relies on in upstream already has LLM code in it.
akimbostrawman 1 days ago [-]
Yes, but that is there choice and burden to maintain.
flykespice 17 hours 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?
munk-a 16 hours 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.
inder1 19 hours 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.
sbcorvus 21 hours 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.
steve-chavez 22 hours 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.
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 20 hours ago [-]
It’s also a sign to point to when the fraud is uncovered.
jacquesm 1 days 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.
The-Ludwig 1 days ago [-]
Hm, wondering how to enforce this rule.
Rules without any means to enforce them can put the honest people into a disadvantage.
goku12 1 days 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 20 hours 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.
qsera 1 days 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.
BirAdam 1 days 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.
aleph_minus_one 1 days 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?
VorpalWay 1 days 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.
miningape 24 hours ago [-]
> and post the original along with the translation
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.
cpburns2009 23 hours ago [-]
> What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task?
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.
duskdozer 23 hours ago [-]
>What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task?
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.
aleph_minus_one 23 hours ago [-]
Translation software does not solve the problem that the tone that you have to use in English is often very different from the tone in your native language. What I would write in German would sometimes not be socially acceptable for English speakers.
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.
duskdozer 22 hours ago [-]
I'd be interested to see examples of this where the translated text is not editorializing and behaves like other machine translators, just better. I expect there to be some missed nuance when translating languages, but I also expect LLMs to clobber it.
hypeatei 1 days 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.
singularity2001 20 hours ago [-]
That's a shame. We used claude to migrate redox very successfully to pure rust cranlift on mac: https://github.com/pannous/redox (but then got stuck on multi-cpu assembly):
14 hours ago [-]
ethin 15 hours 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 2 hours 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.
17 hours ago [-]
hagen8 1 days ago [-]
They will sooner or later change that policy or get very slow in keeping up.
sheepscreek 21 hours 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.
algoth1 1 days ago [-]
What would constitute "clearly llm generated" though
nananana9 1 days 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:
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.
The-Ludwig 1 days ago [-]
Peak comedy
1 days ago [-]
cpburns2009 23 hours ago [-]
The clearly LLM PRs I receive are formatted similarly to:
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 17 hours ago [-]
Don't you use the dialectic?
gtirloni 13 hours ago [-]
I wish them good luck but they will become even more of a niche project.
dana321 1 days 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 23 hours 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.
scotty79 1 days 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.
decidu0us9034 14 hours 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...
dgacmu 22 hours 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 22 hours ago [-]
Yeah, but what can you do if you need a thing done and now there's an option to have it done.
dgacmu 22 hours 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)
estsauver 1 days 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.
VLM 17 hours 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 16 hours ago [-]
Hi. No, the purpose of a ban is to ban the behavior. I hope this helps.
oliver_dr 17 hours ago [-]
[dead]
cardanome 1 days ago [-]
[flagged]
999900000999 1 days 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
Anonyneko 1 days 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 1 days 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.
butILoveLife 23 hours 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.
hananova 20 hours 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.
aerhardt 23 hours 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.
emperorxanu 1 days ago [-]
[flagged]
flanked-evergl 1 days ago [-]
Spiritually Amish
api 1 days 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.
menaerus 1 days 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.
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.
13 hours ago [-]
duskdozer 23 hours ago [-]
Wouldn't expect anything else from big data collectors.
stingraycharles 1 days 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 1 days 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 1 days 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 23 hours ago [-]
Their profile generally comes up here on HN very often with Dunning-Kruger effect like comments so it makes me believe it is no AI. AI would do a better analysis, for the better or worse.
stingraycharles 1 days ago [-]
Obviously not, I skimmed through the first two, and it’s not difficult to assess that it’s just fluff that sounds interesting but is actually not.
menaerus 23 hours ago [-]
Implementing a Redis and Kafka rewrite (in Rust) but with workload-aware and self-balancing JIT-like engine deployed at Datadog-scale is no fluff. You obviously have no idea what you're talking about.
13 hours ago [-]
subjectsigma 1 days ago [-]
> The industry is being redefined as we speak and everyone doing the push-back are pushing against themselves really.
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.
baq 1 days 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.
ptnpzwqd 1 days 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.
holyra 1 days ago [-]
People can choose not to use AI. This is because they think it is inevitable that they will eventually use LLMs.
dev_l1x_be 1 days 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.
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.
ptnpzwqd 1 days ago [-]
The problem is the increasing review burden - with LLMs it is possible to create superficially valid looking (but potentially incorrect) code without much effort, which will still take a lot of effort to review. So outright rejecting code that can identified as LLM-generated at a glance, is a rough filter to remove the lowest effort PRs.
Over time this might not be enough, though, so I suspect we will see default deny policies popping up soon enough.
duskdozer 1 days 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 1 days 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.
lpcvoid 1 days ago [-]
>Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.
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.
holyra 1 days ago [-]
The LLM has brainwashed so many devs that they now think they are nothing without it.
vladms 1 days ago [-]
That's an optimistic view. Maybe they really are 10x slower on any task without a LLM.
usrbinbash 1 days 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 1 days 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.
usrbinbash 20 hours ago [-]
> The submitter is supposed to be the good programmer;
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.
duskdozer 1 days ago [-]
Well, assuming you care about verification, of course. If it's got that green checkmark emoji, it ships!
1 days ago [-]
usrbinbash 1 days ago [-]
> Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.
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.
There are only 4 successful general purpose production OSes (GNU/Linux, Android/Linux, Windows, OS X/iOS) and only one of those made by the open source community (GNU/Linux).
And a new OS needs to be significantly better than those to overcome the switching costs.
swiftcoder 1 days ago [-]
> There are only 4 successful general purpose production OSes
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...
eschaton 9 hours ago [-]
What about IBM i and z/OS, and Stratus VOS, and Burroughs MCP, and Tandem GUARDIAN, and VxWorks and OS-9 and… These all not only still exist but run huge transaction volume (for the mainframe and minicomputer systems) and run a huge amount of embedded systems (for the embedded OSes).
bigstrat2003 21 hours ago [-]
> And a new OS needs to be significantly better than those to overcome the switching costs.
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.
usrbinbash 1 days ago [-]
None of this counters the argument I made above :-)
lifis 1 days ago [-]
Just because they have been made before LLMs doesn't mean it can be done again, since there was just one success (GNU/Linux) and that success makes it much harder for new OSes since they need to better then it
usrbinbash 20 hours ago [-]
> Just because they have been made before LLMs doesn't mean it can be done again
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.
* 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
I’m sorry but this says more about you than about the models. It is certainly not the case for me!
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.
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.
LLMs can do it somewhat, but it can probably leetcode better than even most of the the people who went to MIT.
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.
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?
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.
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.
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.
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.
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?
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.
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.
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.
But if a project bans AI then yeah, they'll be run out of town because I won't bother trying to contribute.
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.
https://github.com/alexispurslane/jjdag
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.
There clearly should be, but that is not the world we live in.
Prompts from issue text makes a lot of sense.
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.
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.
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.
>No big rewrites or anything crazy
I think those are the key points why they've been welcomed.
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
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.
Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction
Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
Dan said yesterday he was "restricting" Show HN to new accounts:
https://news.ycombinator.com/item?id=47300772
I guess he meant that literally and new accounts can still post regular submissions:
https://news.ycombinator.com/submitted?id=advancespace
That doesn't make too much sense to me, or he hasn't actually implemented this yet.
It looks like we are going to have large numbers of people whose entire personality is projected via an AI rather than their own mind. Surely this will have an (likely deleterious) effect on people's emotional and social intelligence, no? People's language centers will atrophy because the AI does the heavy lifting of transforming their thoughts into text, and even worse, I'm not sure it'll be avoidable to have the AIs biases and start to leak into the text that people like this generate.
I remember the first time I suspected someone using an LLM to answer on HN shortly after chatgpt's first release. In a few short years the tables turned and it's increasingly more difficult to read actual people's thoughts (and this has been predicted, and the predictions for the next few years are far worse).
An em-dash might have been a good indicator when LLMs were first introduced, but that shouldn't be used as a reliable indicator now.
I'm more concerned that they keep fooling everybody on here to the point where people start questioning them and sticking up for them a lot of times.
Also to, intentionally introduce random innoccuous punctuation and speling errors.
But everything up to that hyphen was pure slop.
But the maintainers can use AI too, for their reviewing.
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.
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...
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.
Opposing the machine does/did nothing.
Political organizing around unions, state regulations of the labour market, agitational political parties did (and can again).
Of course, there's definitely absolutely nothing about the state of the garment industry that's applicable to the current discussions about AI re: software quality and worker compensation. It's not as if this industry has not already seen its fair share of quality going to the dogs with only a small handful of people still knowing and caring enough to call it out while most others cheer for the Productivity™.
Posted from my software made with AI assistance.
LLMs regurgitate their training data. If they’re generating code, they’re not modeling the syntax of a language to solve a problem, they’re reproducing code they ingested, code that is covered by copyright. Just regurgitating that code via an LLM rather than directly from your editor’s clipboard does not somehow remove that copyright.
It’s clear you think you should be allowed to use LLMs to do whatever you want. Fortunately there are smarter people than you out there who recognize that there are situations where their use is not advised.
We're clearly not doing that anymore.
Have fun being smart or whatever.
* 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.
Once you do understand the problem deep enough to know exactly what to ask for without ambiguity, the AI will produce the code that exactly solves your problem a heck of a lot quicker than you. And the time you don't spend on figuring out language syntax, you can instead spend on tweaking the code on a higher architecture level. Spend time where you, as a human, are better than the AI.
We are inventing problems here. Fact is, an LLM writes better code than 95% of developers out there today. Yes, yes this is Lake Wobegone, everyone here is in the 1%. But for the world at large, I bet code quality goes up.
But I think different projects have different needs.
[0] https://github.com/mastodon/.github/blob/main/AI_POLICY.md
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.
Of course, even then it's not reproducible and requires proprietary software!
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.
That breaks "copyleft" entirely.
This will cut off one of the genuine entry points to the industry where all you really needed was raw talent.
I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.
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.
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.
> 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.
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.
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.
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.
You’re basically saying that a “no-LLMs” rule doesn’t matter, because dishonorable people exist. That’s not how most people work, and that’s not how rules work.
When we encounter a sociopath or liar, we point them out and run them out of our communities before they can do more damage, we don’t just give up and tolerate or even welcome them.
Real people in the real world understand that rules don’t simply cease to exist because there’s no technical means of guaranteeing their obedience. You simply ask people to follow them, and to affirm that they’re following them whether explicitly or implicitly, and then mete out severe social consequences for being a filthy fucking liar.
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”.
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
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.
Yes, as do, probably, most people who remember it.
> 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 .
https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy
https://github.com/zigimg/zigimg/pull/313
It makes lots of sense to me.
Or a human will provide the fix?
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.
For the parent there's immaterial value knowing that is written by a human. From what I read in your comment, you see code more as a means to an end. I think I understand where the parent is coming from. Writing code myself, and accomplishing what I set out to build sometimes feels like a form of art, and knowing that I build it, gives me a sense of accomplishment. And gives me energy. Writing code solely as a means to an end, or letting it be generated by some model, doesn't give that same energy.
This thinking has nothing to do with not caring about being a good teammate or the business. I've no idea why you put that on the same pile.
Code is a means to an end.
People will be more likely to engage with your main assertion if you leave out the insults.
I noticed your account was new, so I thought you might appreciate a likely explanation for why your post was being downvoted.
The underlying data that said matrices compute upon, can be racist though.
I will admit that I may be missing some context though.
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.
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.
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.
Boundaries - of all kinds - are not unenforceable nonsense, they are rights that you willingly and knowingly violate.
- 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.
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.
You're so much a law abiding citizent aren't you?
Tell me how many times did you lie on your tax returns?
Or how many times you submitted PR with code you don't own to your peers?
Oh wow :( :( they must be very busy
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.
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.
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.
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.
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.
So "copyleft" doesn't work on any of the output. Therefore no GPL applies.
>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.
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.
"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?
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.
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.
(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:
(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.
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)
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.
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.
Before this it was junk like spacing changes
Sometimes, I'd guess, it's also because your Github profile has some kind of an advertisement.
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.
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.
Time consuming work can be done quickly at a fraction of the cost or even almost free with open weights LLMs.
[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.
IOW I think this stance is ethically good, but technically irresponsible.
https://www.datadoghq.com/blog/ai/harness-first-agents/
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.
Over time this might not be enough, though, so I suspect we will see default deny policies popping up soon enough.
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.
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.
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.
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.
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.
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
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