61–70 of 504 posts
Earlier quoted context omitted.
Isn't the obvious solution to not accept drive by changes?
That's eliminating of an important part of open source culture.
I think this is a reasonable decision (although maybe increasingly insufficient). It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers. In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly g…
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…
Earlier quoted context omitted.
That's eliminating of an important part of open source culture.
I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.
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.
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
None of this counters the argument I made above :-)
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
I think this is a reasonable decision (although maybe increasingly insufficient). It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers. In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly g…
* 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.
I think this is a reasonable decision (although maybe increasingly insufficient). It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers. In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly g…
Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one. That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Th…
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.
Earlier quoted context omitted.
> 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…
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.
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...
Earlier quoted context omitted.
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…
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 implem…