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

[Arnaldo Melo <arnaldo.melo@gmail.com>]

On July 17, 2026 10:17:18 PM GMT-03:00, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Fri, 17 Jul 2026 at 18:09, Laurent Pinchart
><laurent.pinchart@ideasonboard.com> 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.
>>
>> It has caused and still causes friction, but I wouldn't dismiss it
>> entirely. I have seen multiple maintainers, including myself, ask for
>> yak shaving in ways that worked reasonably well. 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.
>
>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.
>
>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.

Agreed

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

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 files 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. 

It would be waste if I didn't track that free work Sashiko did for me, I can't address them all straight away, but saving them for later consideration is what seems sensible to do.

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. ;-)

acme@number:~/git/perf-tools-next$ ls -la tools/perf/TODO.*
-rw-r--r--. 1 acme acme   3647 May 24 00:35 tools/perf/TODO.arm64-test-gaps
-rw-r--r--. 1 acme acme   5151 Jun 16 15:55 tools/perf/TODO.cleanup
-rw-r--r--. 1 acme acme   2113 May 23 23:13 tools/perf/TODO.data-type-profiling-perf
-rw-r--r--. 1 acme acme   1386 Jun 13 15:06 tools/perf/TODO.flaky-perf-tests
-rw-r--r--. 1 acme acme 106401 Jun 18 17:08 tools/perf/TODO.hardening
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.

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

https://github.com/masoncl/kres

Kernel code RESearch agent — an LLM-driven multi-agent REPL for reviewing, auditing, and finding bugs in C source trees. The Linux kernel is the primary target; any large C codebase with source-level tooling works too.

-----

More specifically:

https://github.com/masoncl/kres/blob/main/docs/generating-fixes.md

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

-------
Research Before Editing 

The first phase is not patch generation. It is an audit.

Research reads the finding/prose, current source, relevant callers, and enough local history to decide whether the report is actionable. 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.

Only confirmed reaches patch writing. invalid and unconfirmed stop before edits. For finding-directory runs, kres writes status artifacts such as invalidation.md or partial-invalidation.md when appropriate.

Research is also responsible for deciding whether the finding is one commit or a series.
-------

- Arnaldo