Earlier quoted context omitted.
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…
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…
Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
131–140 of 504 posts
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#132Earlier quoted context omitted.
I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.
how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?
Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#133Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#134Earlier quoted context omitted.
> 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.
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."
Off the shelf agentic coding tools should be doing this for you.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#135I 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…
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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#136Earlier 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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#137Zig has a similar stance on no-LLM policy https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy
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,…
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
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#138I 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…
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#139Earlier quoted context omitted.
Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one. That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Th…
> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. To outright accept LLM contributions would be as much "pure vibes" as banning it. The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is n…
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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#140Earlier quoted context omitted.
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?
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 colou…
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.