There appears to be a few bad actors in the Lemmy community spreading ragebait for personal gain
In fact, the same mechanisms added at the beginning to catch bad human written code are the exact same that catch bad AI code
- No, the Linux kernel DOES NOT use AI to automatically approve code for inclusion. As far as I can tell, there are no plans to do so
- The Kernel actually has a huge number of maintainers. As part of the process, all patches are reviewed by a human who provide feedback as part of the process, and patches get bounced back and forth multiple time.
- Patches don’t just magically go straight to master. The maintainers generally have their own branches where it goes to, then it goes to staging trees like Linux-Next. It goes through many eyes, and many tests by the end. The idea that AI code is overrunning the kernel is rediculous
- Maintainers also check that the code meets coding guidelines and is written properly, and solves the problem they are trying to solve. Yes, they also ensure the code isn’t slop
- LLM’s though might be used to identify obvious problems with the code (which they are VERY good at), or even identify code that doesn’t follow coding guidelines.
- The only thing that matters is the human who submitted the code, as they should be checking the code submitted anyway (including LLM generated code)
Writing bad code isn’t something new, and isn’t unique to LLM’s. Coders (and it seems some “journalists”) have been writing slop since computers were invented.
The process hasn’t gotten less stringent (probably even MORE stringent as there is an additional set of robotic eyes that can also check), and the same mechanisms that were put in place to catch badly written code 10 years ago, are still there now… With no changes.
I do not agree to the AI hype, but I doubt that. The vast majority of the kernel code is hardware device drivers because one of the main functions of the kernel is hardware abstraction. Hardware is made by companies and being able to use ai will not reduce, rather increase their willingness to submit open source device drivers. If they do not, LLMs also seem to make it easier to reverse-engineer closed source Windows drivers.
Another thing to keep in mind is that the Linux kernel is quality-wise far above 99.9% of software projects. This means that you cannot apply observations of the effect of GenAI on software in general on the kernel, and also not vice versa.
The average usage of GenAI could totally trash 99% of company code bases within four or five years, and the kernel would still be fine.
Also, the way the kernel allows usage of LLMs is not necessarily a good blueprint for other open source projects, because these have less expertise, resources, and people which are experts in reviewing alien code.
I was speaking to several communities such as decomp.dev disbanding due to AI.
https://www.nacionale.com/en/articles/video-game-reverse-engineering-community-shuts-down-due-to-ai
I see what you mean.
However, we currently don’t whether LLM-generated code is libre software yet. Software Freedom Conservancy currently thinks otherwise, the Free Software Foundation is working on it with their lawyers. Whatever the outcome, it seems there will be a huge impact on licensing and perhaps new threats from proprietary software companies.
Yes, that’s true. In that aspect, it would be better to have an LLM which is trained on GPL code only and which returns copyleft licensed code.
However, I think using LLMs for code analysis is not affected by that. Maybe there will turn out a legal difference between code that is entirely LLM generated and code where humans do most of the editing.
One popular legal position is that LLM generated code itself is not subject to copyright law. That might be re-adjusted if the LLM has actually regurgitated training code.