Re: [PATCH] docs: remove Assisted-by references

[Laurent Pinchart]

On Wed, Oct 14, 2026 at 02:42:09PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Tue, Oct 13, 2026 at 11:23:53PM -0400, Theodore Tso wrote:
> 
> > I think we're going about this the wrong way.  What we want is high
> > quality contributions.  If they are high quality, who cares if they
> > are AI-generated or not?
> 
> Recently 2 people sent 1,000 patches over 2 hours. Care to check each and
> every patch for 'quality'? :) Only the beginning.

That's the kind of behaviour that should be easy to detect, and I have
absolutely no issue with sending all those patches to /dev/null. This is
script kiddies behaviour, not the work of someone with good intentions.
Ignoring those patches is not "collateral damage".

We could go a step further. There's also an increase in patches from
newcomers who send a few patches only, with the usual signs of not
understanding what they're doing: code changes that give an eerie
feeling, very large comment to code ratios, and commit messages longer
than the three volumes of Lord of the Rings combined. As far as I
understand, those are also the kind of contributions that many
maintainers in this e-mail thread would like to ignore. Perhaps with an
automated reply to tell that the kernel expects submitters to understand
what they're doing and own their code, as this category is less of an
obvious on-purpose DoS attack.

There's some irony there though. I wouldn't be surprised if the
headlines about kernel maintainers loving LLMs made the flood of patches
even worse, and we now have maintainers essentially saying they don't
want to receive most of the LLM-generated patches.

> > If we get a contribution which is sloppy, it could be because the
> 
> Schloppy, not sloppy :) I.e. tells. Turn of phrase, certain 'shapes' in the
> code/commit msgs, newcomer/recently reactivated? Sent a bunch of mails
> across many subsystems? etc.
> 
> To be scaleable the check has to be very quick. In the end it'll sadly
> probably just have to be 'newcomer?'. It sucks but this is existential.
> 
> > This isn't actually a new problem.  In the pre-AI era, we would
> 
> Sorry you're completely wrong, it's entirely a new problem.
> 
> Nobody could drive thousands of at least plausible patches end-to-end with
> little to no input in the past. INCLUDING replies.
> 
> > If AI is making the review problem more challenging, the good news is
> > that there are ways that AI can help.  For example Sashiko can help
> 
> Sashiko only checks if the code is buggy or not, not whether it's worth
> having or is a total mess or not. So completely unhelpful (speaking from
> experience).
> 
> > I also suspect it should be possible to use something like Jev or some
> > other System One LLM to help with an initial prioritization for the
> > patch, and then have that prioritization be set in patchwork.  Each
> 
> Using AI to detect AI right now works, who knows in the future. But that's
> an arms race which we'll eventually lose. Which also costs money...

I'm sure AI companies will disagree with you :-)

> > Using AI-assited priotization may have some collateral damange because
> > it might not get the prioritization correct.  But ultimately, if we
> 
> Any solution will incur collateral damage, sadly inevitable.

-- 
Regards,

Laurent Pinchart