Well put, thank you :)

True, but its still not enough to handle all slop. The number of maintainers have also grown though dramatically.. Also, don't forget that LLM's can also be used to identify bugs in patches more quickly too.. So, more are getting submitted, but, lots of bad patches are being rejected faster too, with less effort (that required human intervention in the past).

This might be true, but that is not a reason to accept or normalize slop. Define Slop..

The difference to before is, that nowadays its easier and faster to write (or generate) slop in mass that looks legit. Finding out its bad code or wrong can suck up huge amount of time of maintainers, which would have worked on something more productive instead. We've all spent hours doing that though on our own code. Again, the buck stops with maintainers. One thing that Maintainers are going to do though, is get them to prove the code first and test the code in other trees first, before even trying to push to main

There's always been code that has been bad, like Linus never liked the Con Kalivas performance patches, or Reiser4.

It is also finding a lot of security issues and bugs faster too though

I've actually written optimisations for code that I thought would be faster, and turned out to be a waste of time in production

For you maybe, but there are issues using Ai regardless of how the code looks. Both sets of code need the same level of examination by humans anyway. In fact, in some cases, the AI code I've seen has been better than the code i wrote

I mean stuff like how the LLM was trained on in example, and if the licensing will become an issue one day. That is true, and I agree with that. That's the one point that does stand out, but doesn't have anything to do with the claim by certain people in the community about the Linux Kernel being overrun with bad code.

What I would like to see is a LLM that's developed exclusively using Open source compatibility licences with FULL traceability to sources uses, and a way to specify licencing allowed (or something similar).

There is one issue with AI that you didn't mention however. The biggest problem with AI is that it adversely benefits closed source companies via Open source code. Because closed source code isn't easily accessed by the AI for training, but Open source is. The other issue is that hackers won't avoid LLM's based on the ethical issues, so, unfortunately, it forces developers to use them to keep up with the cat and mouse game.

As a developer, am I happy about AI? For code review yes, but, it makes my job suck and not fun. And no, I'm not happy about the ethics.. There are a lot of things that sh** me, like AI companies SHOULD be forced to pay royalties to everyone they stole info from.

However, what sucks, is that we can't pretend it's not a thing, and if Linux wants to remain competitive, it does need to use it.

The best thing we can do though, is petition to tax AI companies and pay producers of the information. That would make AI unprofitable immediately and kill the industry

The ethics sucks, but that's an entirely different conversation. AI companies should be taxed and forced to pay royalties to creators imho (and yes, that would instantly kill the industry).. And, it should be Opt in specifically.

But, that's not what people are arguing about when calling the kernel "AI Slop". The bad information I've seen is that standards have dropped and even claims that kernel patches aren't being reviewed properly. Some are even suggesting that the only review that happens is AI.

Bad AI patches are no different to Bad human patches.. And the process has always been to identify bad patches specifically. The process doesn't need to change

If anything, the standards have actually been raised because initial code reviews with AI are possibly better at identifying code that doesn't follow coding standards, identifying common bugs (or similar patch attempts that were tried in the past but don't work), or obvious bugs