Replying to @⁨General_Effort@lemmy.world⁩

OSS projects have already started to recognize that LLM is just a tool and how you use that tool matters a lot more than whether you are using said tool at all. Lets bring StackOverflow for analogy: we didn’t ban browsers for code development because one can navigate to StackOverflow and copy-paste some really crappy code. LLMs are SO on steroids (actually trained on SO topics). So grabbing LLM to get a sense of direction or shape is an OK use in general, but copy-pasting it’s results blindly is silly and dangerous.

There’s a second argument that AI is ruining OSS communities which I believe is true, but refusing to accept AI code is a self-defeating action. Why? Because AI training needs unadulterated source of knowledge, one not tainted with AI and OSS communities rejecting AI would be that source. Also: if OSS community did not use AI it would hardly stop it from continuing it’s growth in Enterprise. So there’s not much of a winning strategy there either.

Which brings us to GrapheneOS decision and given above reasons I think it’s a well-balanced decision.

Replying to @⁨droopy4096@lemmy.ca⁩

Yeah, just one small problem, muchacho. Whenever a language recieves a breaking change you gotta retrain the model again, and a lot of your references are useless now. There is no “improving” it’s just a vicious cycle.

Your argument is that of peer pressure and not compelling.

“Join us or we’ll just steal your code anyway”

Here’s my rebuttal. Garbage in, garbage out. Most projects out there are trash. This tool doesn’t help you build good code, it helps you throw together a pile of trash. An actually helpful LLM would be one trained on the damn language itself and coding best practices. Almost everyone has lost the plot here. You DON’T want a massive LLM, the small specialized ones are good enough. So you can use it as auto complete, like the tech was intended.

Replying to @⁨spicehoarder@lemmy.zip⁩

your points support my statement though: how vs what is the real question here. LLM is fine performing repetitive mundane tasks that we find boring and uninteresting. Like refactoring small chunks of code out or “search and replace” when context matters more than matching string etc. Also, let’s assume someone had enough bitcoin mining gear laying about to repurpose it into LLM training infra and trains his/her small model on stuff they care for, suddenly we lose all the other arguments and use of LLM becomes more acceptable. So blanket ban at this point is not going to achieve any of the goals, really. Consider that majority of developers were mandated to use LLMs for work, consequently their skill shape changed, for project to draw from that pool of developers you need to offer comparable tools.

Context matters too: Graphene has to deal with AOSP, which lost it’s development transparency a while ago and Graphene developers likely have to contend with big (likely LLM-generated) code dumps within mainline AOSP with each new release, so to keep up with that onslaught they either need to expand developer base (and we just said that pool is shrinking) or leverage LLM to cut through that mess. Again “how” tool is used matters a great deal.

en

Replying to @⁨droopy4096@lemmy.ca⁩

When people say they don’t want AI in their codebase, they’re talking about Claude, and GPT. I mean, we’ve had intellisence for ages. To a certain extent, we’re both fighting strawman arguments.

I get your point now, but I’ve personally had about 6 of my projects at work ruined due to AI slop, to the point that I don’t think my company is going to make it. I’m the odd one out, everyone else is loving it, despite our productivity grinding to a hault.