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

[Laurent Pinchart]

On Tue, Oct 13, 2026 at 11:23:53PM -0400, Theodore Tso wrote:
> On Tue, Oct 13, 2026 at 02:29:08PM -0500, Lorenzo Stoakes (ARM) wrote:
> > On Tue, Oct 13, 2026 at 03:12:43PM +0200, Laurent Pinchart wrote:
> > > On Tue, Oct 13, 2026 at 01:59:33PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > > Ignoring is the only workable long-term solution.
> > > How do you decide which patches to ignore ?
> > Anything that looks schloppy. ATM it's very easy to tell.
> 
> 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?

I do.

Nobody disagrees that quality of patches is important, and I also hardly
see anyone seriously saying that the fact that a patch is human-written
or LLM-generated is by itself a good measure of quality. If all you care
is that the code performs as described, we can probably stop this
conversation.

What I think makes the value of the Linux kernel is its contributors. I
want passionate developers who will grow in the community and drive the
kernel forward. I want them to understand what they're doing to
contribute meaningfully to the project, and I want to encourage them to
become reviewers and maintainers. I've long believed that it's the
people who make Linux.

This is ultimately why this discussion saddens me. There is a small
number of very vocal long term maintainers who all of a sudden appear
like they've never really cared about the people making the kernel. That
some show a very strong enthousiasm for LLMs doesn't surprise me. What
does is hearing sudden proposals about AI-assisted reputation ranking
where contributors are called "collateral damage". It's borderline
sickening.

> If we get a contribution which is sloppy, it could be because the
> contributor doesn't know how to drive the LLM, or they are using an
> insufficiently powerful or badly chosen LLM --- or both.
> 
> This isn't actually a new problem.  In the pre-AI era, we would
> sometimes get marginal patches, and there is always a question of
> whether it is the maintainer's time to try to engage with a new
> contributor who might turn into the next valued senior contributor and
> reviewer --- or who might be resistant to education and/or who might
> disappear very shortly.  AI makes the problem worse in that there are
> many more newcomers with new contributions, but it's really not a new
> problem.
> 
> 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
> with the early AI review.  And if a newcomer sends 7 versions of the
> patch set in resposee to Sashiko reviews, I will generally not bother
> looking at it personally until a couple of days go past before I waste
> my limited human review bandwidth.  So it's not a case of permanently
> ignoring a patch --- but I may very well down-prioritize when I do pay
> attention.

What else are you expecting the newcomer to do when maintainers tell
they won't look at the patches before sashiko is happy ?

> 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
> subsystem might have their own criteria which they could encode in
> their prioritization prompt.  For example, if the bug requires root
> privileges and/or a maliciously fuzzed file system, for ext4 it will
> automatically get down-priotized to low priority.
> 
> Using AI-assited priotization may have some collateral damange because
> it might not get the prioritization correct.  But ultimately, if we
> get a flood of patches from newcomers, the choices is either to (a)
> load-shed, or (b) burn out.  And of the two, (a) is the better of two
> bad choices.

-- 
Regards,

Laurent Pinchart