Submitted 1 day ago by sanitation@lemmy.today to technology@beehaw.org
https://www.xda-developers.com/as-ubuntu-embraces-ai-debian-discusses-banning-all-ai-generated-code/
Maybe it’s answered in the article - but I’m just jumping into bed…
How will they differ between AI created code vs “natural” code?
I do know, that there are some give-aways - can’t put my finger on it, but you can see it’s AI generated
But with many contributions, I’m not sure how they would be able to detect it
Or is it about using AI in other ways?
I expect witch hunts and transparency culture eroding.
Even if AI generated code can’t be detected reliably, it is good to have a clear policy to guide projects and contributors. At least those contributors acting in good faith and honestly will do the right thing, and projects will have a basis for rejecting contributions from people that are found to willfully or negligently violate the policy. Blocking all malicious actors will be an ongoing effort, whatever the policy.
For me, if a PR looks good, and I can reach out to the contributor and they can competently discuss their work, then its fine with me if they used AI to code it.
I think a sensible policy would be: use whatever tools you like to contribute, but own the contribution. Obvious slop code is rejected.
I’m just jumping out of bed, but I’ll give you a quick answer. You’re right, in some cases it’ll be impossible to tell that code was AI-generated, but what you’ll have is the reputation of the developer. If any of their other code is AI-developed, then they would be suspect, right? So, I think it’s gonna be something like that, and, like with other things in the open source community, a matter of trust and respect.
Sounds more like detective work, than a coffee review
This will cost quite some time for the maintainers :-\
There are “signatures” that can be detected in code just like universities detect it in student work, online stores detect it in reviews they compensate people for, and some employers detect it in resumes and cover letters.
That said it doesn’t detect it all, and it does rely on the developer to be honest. But it’s also a good indicator when reviewers post questions to the developer and they can’t answer them because they don’t understand the code and things like that. Also, if the developer did not follow coding standards, which LLMs can sometimes have trouble with. And there’s always been malicious code submissions in open source software, so there are other ways.
Anyway, it’s more of a policy discussion at this point, and why LLM generated code is bad. I use them for manipulating data, figuring out syntax, and getting examples, but there are always problems with anything they generate, so I never would allow one to write any production bound code. I see use in the technology, but it’s not creative and it doesn’t understand what it’s writing so it can’t write code with consequences in mind. So it can write Jr level code, but not solid code, at least not without being properly trained on only well written code, and that proper training would be too expensive for an LLM company to actually do it.
This is an approach with a with a time limit that is nearly exhausted. These detection methods already suffer from abysmal false negative AND false positive rates, and the further LLM progresses, the worse these detection algorithms will become at actually identifying anything written by a coding agent. The point where they become completely usekess is approaching fast - mainly because these tools are great for adversarial training - every detection tool that is actually working provides everything needed to make sure that future models (or even the current one slightly updated).
The best policy isn’t worth the paper it is written on if you can’t detect violations.
Corpo executives vs real Developers.
cupcakezealot@piefed.blahaj.zone 5 hours ago
pls take daddy debians side mint