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

On July 17, 2026 10:17:18 PM GMT-03:00, Linus Torvalds <torvalds@linux-fou=
ndation=2Eorg> wrote:
>On Fri, 17 Jul 2026 at 18:09, Laurent Pinchart
><laurent=2Epinchart@ideasonboard=2Ecom> wrote:
>>
>> > And then Y doesn't get done, and maybe X doesn't get done _either_,
>> > just because of some unrelated issue was pointed out as part of the
>> > discussion=2E
>>
>> It has caused and still causes friction, but I wouldn't dismiss it
>> entirely=2E I have seen multiple maintainers, including myself, ask for
>> yak shaving in ways that worked reasonably well=2E The key was to judge
>> how much yak shaving is reasonable (and the answer is invariably less
>> than a maintainer would wish for), and not making it mandatory=2E
>
>I agree that it sometimes works, and can even work well - a maintainer
>suggestion of "if you did this, that will clean things up" can even be
>a welcome thing - particularly when it is relevant to the original
>series and not just an incidental tangential thing=2E
>
>But we've also had maintainers that tried to get unrelated work done
>by making it a requirement for the subsystem, and pushed it way too
>hard, and it only resulted in problems=2E

Agreed

>So it *can* work, but as you say, it requires social skills and the
>ability to judge whether it's appropriate=2E
>
>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=2E

At first I disliked these seemingly never ending reporting of preexisting =
issues, but by now I love it, I just ask Claude to collect those in TODO fi=
les by topic, discarding duplicate reports or improving the description of =
the problem if the new report has more details or suggestions of how to fix=
 it=2E=20

It would be waste if I didn't track that free work Sashiko did for me, I c=
an't address them all straight away, but saving them for later consideratio=
n is what seems sensible to do=2E

When I'm bored I go on and work with Claude, or sometimes even alone, like=
 in the old days, fixing what I think is more pressing=2E ;-)

acme@number:~/git/perf-tools-next$ ls -la tools/perf/TODO=2E*
-rw-r--r--=2E 1 acme acme   3647 May 24 00:35 tools/perf/TODO=2Earm64-test=
-gaps
-rw-r--r--=2E 1 acme acme   5151 Jun 16 15:55 tools/perf/TODO=2Ecleanup
-rw-r--r--=2E 1 acme acme   2113 May 23 23:13 tools/perf/TODO=2Edata-type-=
profiling-perf
-rw-r--r--=2E 1 acme acme   1386 Jun 13 15:06 tools/perf/TODO=2Eflaky-perf=
-tests
-rw-r--r--=2E 1 acme acme 106401 Jun 18 17:08 tools/perf/TODO=2Ehardening
acme@number:~/git/perf-tools-next$

>So if the AI then also gives a solution to the problem, I think people
>will appreciate the process more=2E

That would be even better and it's what Chris Mason's kres does:

https://github=2Ecom/masoncl/kres

Kernel code RESearch agent =E2=80=94 an LLM-driven multi-agent REPL for re=
viewing, auditing, and finding bugs in C source trees=2E The Linux kernel i=
s the primary target; any large C codebase with source-level tooling works =
too=2E

-----

More specifically:

https://github=2Ecom/masoncl/kres/blob/main/docs/generating-fixes=2Emd

The document is long, this part should entice reading more:=20

-------
Research Before Editing=20

The first phase is not patch generation=2E It is an audit=2E

Research reads the finding/prose, current source, relevant callers, and en=
ough local history to decide whether the report is actionable=2E The result=
 is structured, not inferred from prose:

- confirmed: the bug and fix contract are proven;
- invalid: source or commit evidence disproves the bug;
- unconfirmed: evidence is insufficient to patch=2E

Only=C2=A0confirmed=C2=A0reaches patch writing=2E=C2=A0invalid=C2=A0and=C2=
=A0unconfirmed=C2=A0stop before edits=2E For finding-directory runs, kres w=
rites status artifacts such as=C2=A0invalidation=2Emd=C2=A0or=C2=A0partial-=
invalidation=2Emd=C2=A0when appropriate=2E

Research is also responsible for deciding whether the finding is one commi=
t or a series=2E
-------

- Arnaldo