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

On Wed, 15 Jul 2026 at 14:21, Roman Gushchin <[email protected]> wrote:
>
> Jason Gunthorpe <[email protected]> writes:
> >
> > I would really like a syzkaller like dashboard of all these
> > pre-existing issues and a nag/summary email so they actually get
> > fixed.

I'd actually be willing to go even a bit further - because I suspect
we will need to at some point.

> > I've gone and fixed a bunch on my own, mostly out of fear that they
> > will just disappear and be lost, but it is an annoying urgency. I'd
> > rather have as a giant todo list (that maybe other people could help
> > with too)
> >
> > Often alot of tokens are spent to find these things, it feels wrong
> > that they are effectively lost in the endless stream of reviews..

I think this ends up being one of those things that easily frustrates
maintainers: low-grade constant noise from an AI that adds extra
overhead and another thing people feel they need to look at.

(Or feel they really don't have time or interest to look at, and then
just the knowledge that there's that nagging thing that you don't
really care about adds stress and frustration).

I think AI code review typically fits fairly well into the pattern we
already have when people post a patch to the proper list, and then you
have automation that reacts to it. And whether that automation is
something we've been doing for years like the 0day bot or Sashiko is
then almost incidental.

However, I think that "pre-existing issues" ends up being a pain point
because it's just a _separate_ thing.

And honestly, it's been a pain-point long before AI. This is very much
not a new thing. We've had this discussion at several maintainer
summits:  some maintainers finding pre-existing issues - whether
outright bugs or just ugly interfaces - when some patch series is
posted, and then some trying to make that part of the whole "in order
to get this patch series accepted, you should fix these pre-existing
issues that I noticed".

And that really doesn't work, and has caused friction.

Developers who do some patch series for X and find that interesting -
or get paid for that - are *not* necessarily then just going to do Y
just because the maintainer notices it.

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.

This whole "Sashiko found a pre-existing issue when looking at a
patch" very much smells like the same pattern.

And I don't really think that "we'll have a database of it" is going
to fix it. Sure, at least things won't get duplicate reports due to
it, and maybe it won't get forgotten, but it's still going to result
in the same kind of friction and stress, I feel.

Which is why I would actually like to at least explore taking the AI
patch review further:

> A minor problem is that for prompts there is no point to stick to the
> kernel release schedule (merge window, etc), which will only slow down
> things. So it requires Linus being onboard with the idea to accept these
> pull requests all the time.

Yeah, I don't want that, but what *would* be interesting is if an AI
tool that we trust(*) might even build up some kind of "trivial tree"
for issues and patches it finds as part of the review.

(*) IMPORTANT NOTE: I do not believe in "trusting the AI tool". The
reason we'd trust the tool is not because we trust the AI, but because
we'd trust the person or group who is orchestrating the tool!

Possibly as just patch series on the mailing list (for "b4 am"), but
possibly even as a git tree. Very much a "let's get this unrelated
fixed next merge window".

We've tried trivial trees before, and they have been mind-numbingly
boring, and they've never really succeeded at them because of that.
It requires human effort and tracking, and it's a lot of work, and
it's by definition not really very interesting - so people start doing
it because it feels worthwhile, but it's just not motivational for
anybody.

That would seem to be the obvious "next step" from just doing patch
review. Trivial patches that the AI has high confidence in, and we
have high confidence in the group running the AI.

Because I think it would reduce stress if we had some sane workflow
for the trivial noise that is just incidental to the patch review.

(And again: this would only be for simple and straightforward patches
with high confidence, and we'd probably have maintainer Ack
requirements, but the point is that I think it would be good to have
the AI not just point out problems, but also actively get them fixed.
At least eventually).

                Linus