Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process

On 7/22/26 23:50, Mauro Carvalho Chehab wrote:
> On Sat, 18 Jul 2026 07:14:02 -0700
> Guenter Roeck <[email protected]> wrote:
> 
>> On 7/17/26 18:17, Linus Torvalds wrote:
> ...
>>> And I think that when there is AI review, people are less likely to
>>> see it as a positive thing when the AI then points out pre-existing
>>> problems.
>>>    
>>
>> I agree, and I have seen that pattern.
>>
>> I do not expect patch authors to fix pre-existing issues in my
>> scope of responsibility, though I appreciate it if they do it.
>> I actually asked Roman if it would be possible to add a per-subsystem
>> prompt to Sashiko's reply. That would let me inform authors that
>> I do not mandate fixing such issues.
> 
> IMO, instead of using a prompt to add per-subsystem instructions
> is a token waste and it is prone to errors, as LLMs might fall
> adding it or and modifying it.
> 

I meant to say configuration, not prompt. Sorry for the confusion.
This would be outside LLM and deterministic.

> A much simpler approach would be to have something like this:
> 
> 	https://github.com/sashiko-dev/sashiko/pull/364
> 	(build-tested only)
> 

For hwmon and watchdog subsystems, no, it is not fine to ignore the
Sashiko review entirely, and this is not what I tried to suggest above.

Last night I got a patch submission of a ~350 LOC driver. Sashiko reported
9 issues with it. No, it is not ok for the author to ignore Sashiko's feedback,
and I am not even going to look at the code myself until the reported issues
are either fixed or the author explains why they don't apply.

It is fine (I would say acceptable) to ignore _pre-existing_ issues reported
by Sashiko, but I do expect patch authors to address new issues, or to explain
why they are false positives or don't apply.

If you want to give patch authors the option to ignore Sashiko's feedback
entirely, fine with me, but please do it on a per-subsystem basis.

Thanks,
Guenter