13
Replies
0
Boosts
@lauren
So you're ditching Linux completely?
Since there's AI assisted code in every modern kernel, by your own definition every Linux distro is now slop.
@ChampersBE Details matter. For example, Debian has made an enormous mistake by permitting
AI code to be included without labeling it as such. This can come back to bite them in very serious ways, including litigation risks. As these problems become more obvious, course corrections are possible. The regulatory hammer hasn't even begun to fall on AI yet. When it does, it will be quite a show.
@lauren
We'll have to see what happens when that happens.
Debian has explicitly stated that all contributions, especially those that are AI assisted, must comply to all legal requirements.
So there are safety markers set.
@ChampersBE Easy for them to say, almost impossible to do. Because with AI generated code, unless the dev announces this explicitly, there's no way to know stolen code was used until (for example) the actual owner of purloined code that was used by the AI comes around in a very bad mood.
@lauren
Stolen code isn't even strictly AI related.
And in software, who is responsible?
The organization that packages a program?
Or the developer who contributes said program?
@ChampersBE But code consumed by LLMs without permission may be considered stolen in some cases, and then be regurgitated in some form. Who's responsible? Probably the firm of concern would go after everybody involved and let the courts figure it out.
@lauren
That is a valid point that is not explicitly covered by the chosen option, but the ambiguity *is* explicitly mentioned as a problem to tackle.
The winning resolution is surprisingly detailed, while also acknowledging some things will need further discussion and investigation.
It's far from the "Fuck it, all safeties off, YOLO" scenario some people picture it to be.
https://www.fosslinux.com/160593/debian-votes-to-allow-ai-what-the-new-policy-actually-means.htm
@lauren A lot of people I respect, such as yourself, seem to be much more worried about this than I am, which makes me think I'm missing something.
I fully get the concerns about AI-review-blindness: maintainers could just start accepting loads of AI-produced stuff they shouldn't. But *assuming* that's not an issue -- assuming they maintain high standards, and yes, we need to keep a sharp eye on that -- what do you care about *how* the code was produced? What am I missing?
@marsroverdriver This really requires a more detailed discussion that is really practical here on Mastodon, and I'd be happy to continue it by email or Signal. However, briefly ...
First, the word "assuming" is doing a lot of heavy lifting there. My view is that in the general case there is no reason to assume that diligence will be maintained in terms of assuring quality of generated code. In fact, studies suggest that when it comes to LLM outputs of any kind no matter how diligently outputs are initially reviewed, over time this slacks off. This has already been demonstrated dramatically with LLM-assisted police and medical reports as LLM hallucinations and errors increasingly have appeared, and there's no obvious reason to anticipate a different situation with code over time. This is just human nature. Obviously this will vary from org to org. I haven't been inside G since years before the deployment of Goose, so I don't have any insight into current code review processes since I last was internal. I'll assume G is doing a pretty good job with this. But there's no reason to expect a similar level of care from other random firms or individual developers, particularly where (as in the Debian case) the decision was made not to require AI-generated or assisted code to be labeled as such!
Then of course there's the whole category of liability issues. Again in the general case, there's no obvious way of knowing what AI-generated code is based on, and whether or not a given LLM lifted proprietary code without permission and stirred it into its output. Similarly to what I mentioned above, this may be controllable by an org like G, but much less likely to be the case with many other orgs and developers.
Obviously, the potential negative operational and legal consequences of a codebase being "contaminated" either by faulty and/or proprietary code, especially over time and not quickly discovered, could be enormous.
Be glad to discuss this further ...
L
Are any forks safe and slop free?
@ralfmaximus Who the hell knows? Once you open the door the slop can flow into everything, especially since Debian says devs don't have to even admit
they're using AI.
