Technology

hideshow 8 child comments

[–] Fierro@piefed.social 3 points 2 days ago

I expect witch hunts and transparency culture eroding.

parent

[–] tangeli@piefed.social 17 points 3 days ago (1 child)

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.

parent

[–] radioactivefunguy@piefed.ca 5 points 3 days ago (1 child)

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.

parent

[–] tangeli@piefed.social 8 points 3 days ago

I agree as far as responding to questions and issues that arise from the contribution but my understanding is that from a legal, copyright perspective, if AI generated the code then the contributor can't own the copyright, nor assign it. So my preference would be: no AI generated code. Other use of AI tools (e.g. finding vulnerabilities) might be OK but there are still the environmental and ethical issues to be concerned with, so I remain ambivalent. It will be interesting to see the decision of the Debian community.

parent

[–] Quexotic@beehaw.org 6 points 2 days ago (1 child)

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.

parent

[–] naeap@sopuli.xyz 1 point 2 days ago* (last edited 1 day ago) (1 child)

Sounds more like detective work, than a ~~coffee~~ code review
This will cost quite some time for the maintainers :⁠-⁠\

parent

[–] Quexotic@beehaw.org 1 point 2 days ago

I mean, maybe it could be that, but what I think it's going to end up being is more like a reputation thing, like an actual community with standards and basis for trust with vetted individuals that have a reputation of producing good code by hand, and testing it correctly.

Think of it this way. There's already a standard practice for keeping people that suck at coding from trying to write code, right? I trust that the same community norms that got us this far will continue to do well. I also believe that there will be some that have reputation issues because of AI.

parent

[–] irotsoma@piefed.blahaj.zone 1 point 3 days ago* (1 child)

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. It's bland, just like when it tells you to remove colorful phrases or adjectives that add emphasis from your text in an email. Things like that.

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.

parent

[–] Wildmimic@anarchist.nexus 5 points 3 days ago* (1 child)

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) become invisible.

The best policy isn't worth the paper it is written on if you can't detect violations.

parent

[–] irotsoma@piefed.blahaj.zone 3 points 3 days ago* (last edited 3 days ago) (1 child)

Yeah and when teachers or employers use it to reject things outright, it's really dumb. But if it's presented as a probability to the user rather than a binary like most LLM results are presented to users, then it is useful. If something has a high probability of being LLM generated then it can cast suspicion and investigation can happen. Unlike how things like facial recognition are used to prove guilt without any investigation when the probability of a match is low, but no better matches were found and the police aren't told it's low probability because then the product would look useless in solving crimes for them which is what they want in a product, not an investigation tool. That's not what they were sold.

Point being. It's a tool. It's a metric. And used as such it can be helpful if all of a developer's contributions get flagged as high probability, then looking more closely at the code can be warranted. Though if LLMs themselves were configured to tell the user how probable that their answer is correct, it might not even be an issue needing investigation. It's not the malicious ones that they're looking to stop with these policies. It's those unwittingly submitting bad LLM generated code with serious consequences. Like all those destructive things that happened at Amazon (and others I'm sure, just Amazon was in the news) when they started replacing senior developers with cheap contractors armed with LLMs and no experience. Even my company has been doing it. It sucks all that we've lost and how bad things have gotten.

parent

[–] Wildmimic@anarchist.nexus 3 points 3 days ago*

You did not understand. The "percentage based" thing is as good as dead. You could just flip a coin and it would have the same accuracy. There will be no tool able to distinguish between human code and agent code going forward, percentage based or not. Watermark-based solutions have also been proven to be circumventable with minimal effort.

No one is gonna be able to make even an educated guess about the origin of a pull request.