Linux sound subsystem maintainer Takashi Iwai of SUSE began the Linux 7.4 sound pull request by noting that "the AI flood continues" with there continuing to be a lot of new patches coming as a result of AI/LLM agents devising patches as well as uncovering new kernel bugs.
Takashi went on to explain that it was another busy cycle with changes in the sound subsystem from lots of core code hardening to new platforms and codecs as well. The core ALSA code has been hardened against some race conditions, there's a buffer leak fix in the compression offload code, race fixes in the JACK code, and other race conditions and more typical C bug fixes. The OSS sequencer emulation code has also been marked as deprecated for Linux 7.4.
On the hardware side, the Linux 7.4 sound updates include support for compressed audio playback on SOF IPC4 with Intel Tigerlake and newer. There is also AMD ACP 7.0/7.F sound IP support with SoundWire and the PDM controller. The new AMD ACP 7.0/7.F IP appears for upcoming Ryzen Zen 6 platforms.
There are also quirks for many different Intel/AMD laptops from the likes of Lenovo, ASUS, HP, AAcer, HONOR, MSI, and others.
New codec drivers are for the ESS ES9039Q2M, Nuvoton NAU83G60 amplifier, Senary SN624x SoundWire SDCA codec.
Also new is the Qualcomm QAIF driver for their Shikra platform.
More details on the many sound changes for Linux 7.4 via this pull ( https://lore.kernel.org/lkml/87ecdgc246.wl-tiwai@suse.de/ ).
There are issues with AI involving licensing and peoples IP and crediting sources and all that.
It has also massively reduced the barrier of entry for both finding and patching bugs, and producing realistic looking bug reports.
My biggest issue (other than enviromental and social impacts) is the load it puts on developers. They pretty much HAVE to use LLMs to triage and test bug reports... because it takes very little skill to use an LLM to "deep dive this area of the linux kernel and find a bug or RCE/CVE", and the LLM probably will. But the unskilled user might not understand what the exploit/bug actually is. But they get some sort of POC and some sort of write up, and then they dump it on someone elses plate.
If that bug is actually patched/impossible because of something outside of the scope/context that the LLM used, or if its only a bug because of bad config... yeh, its a bug, but it isnt an important one. And it eats up developer resources to confirm/triage/fix that bug.
Also, LLMs are an averaging engine. They work on "most likely" probability evaluations. So, you get average code.
There has to be a human in the loop
For a non-important piece of software, I agree that fixing small bugs is a waste of resources. This is this kernel.
I 100% agree there has to be a human in the loop. That's non-negotiable to me in ANY use of AI. I've personally been stuck reviewing AI code that sucks and have had to send back with a list of reasons... That fucking sucks too. I still appreciate things like finding bugs or users using AI and understanding what they're doing. It technically isn't AI that's the problem in a lot of cases... Its the misuse of a tool without understanding - which you get at. I don't like that sort of thing, but well... Its better than nothing happening IMO. As I mentioned in my original comment, the main problem is when its too much for maintainers. Then yeah. Outright ban it no matter the use-case. Software NEEDS to be engineered well or everyone is in for a rough time down the line.