eyk19 (u/eyk19) - Readit News

eyk19 commented on Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy gitlab.redox-os.org/redox... · Posted by u/pjmlp

defmacr0 · 12 hours 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 · 11 hours 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

eyk19 commented on Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy gitlab.redox-os.org/redox... · Posted by u/pjmlp

ChadNauseam · 12 hours 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 · 11 hours 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

eyk19 commented on Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy gitlab.redox-os.org/redox... · Posted by u/pjmlp

ptnpzwqd · 12 hours 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.

eyk19 · 12 hours 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.

eyk19 commented on Migrating from AWS to Hetzner digitalsociety.coop/posts... · Posted by u/pingoo101010

eyk19 · 5 months ago

We've experienced something similar: for compute-heavy rendering tasks, AWS just wasn't good enough. EC2 machines with the same spec perform much worse than Hetzner machines