Spiritually Amish
Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
91–100 of 504 posts
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#92Earlier 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…
> 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."
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#93I 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.
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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#94Zig has a similar stance on no-LLM policy https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy
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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#95I 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.
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.
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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#96What would constitute "clearly llm generated" though
if (foo == true) { // checking foo is true (rocketship emoji) 20 lines of code; } else { the same 20 lines of code with one boolean changed in the middle; } Description: (markdown header) Summary (nerd emoji): This PR fixes a non-existent issue by adding an *if statement** that checks if a variable is true. This has the following benefits: - Improves performance (rocketship emoji) - Increases code maintainability (ri…
Peak comedy
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#97Zig 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, 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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#98AI 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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#99I 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.
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.
Re: Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy
#100Earlier 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 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.