this post was submitted on 01 Oct 2026
544 points (97.7% liked)
Linux
15106 readers
415 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Honestly, there are a few thoughts about this (and yes, some will be unpopular what I say).
I'd argue it isn't actually a good thing necessarily to ban using it as a tool entirely from senior devs.
The biggest issue at the moment are arrogant junior cryptobros who are too lazy to learn to code, and just want to throw money at the issue. And that wastes everyone's time.
What we really need is a ethical AI model that only uses completely open code, pays people for their code (instead of just stealing it). and a way to ensure it is only used by developers who can use it properly. Ideally, only allow that code to be used for open source too
I actually wouldn't want to see Gnome/System76 completely ban it. What I would want to see is for it to be permitted for approved devs with VERY specific guidelines dictating how it can be used.
The issue for now is LLM generation of code, not code auditing.
And no, I don't give a fuck whether some genius in theory could paint s new Mona Lisa with it. The issue us how it is used in practice, most of the time, today. At $WORK, I have a severely ai-pilled Senior Embedded Software Architect which hasnt managed in one and a half year to set up a working driver for a RS232-controlled stepper motor, from a port of previously working code. A thing that should take a week at most. I had to educate him that in C++ drivers, you need to use locks or mutexes to access variables that are concurrently changed and read from several threads. AI enables catastrophic levels of incompetence.
And FOSS projects need to protect themselves against that.
Yeah.. LLM Generation I agree is the biggest issue by far.
On the Kernel side, code review though apparently has been a big factor apparently, because people are testing kernel modules in seriously dumb tests that would never happen in practice, and then submitting some of the dumbest patches to protect against faults that won't happen in reality
Oh man, the insane defensive code that it wants to generate. Yes, a decent principle, but when the stack has checked the same thing like 4 times, it's a bit much.