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

On Wed, 15 Jul 2026 at 22:37, Roman Gushchin <[email protected]> wro=
te:
>
> Miguel Ojeda <[email protected]> writes:
>
> > On Wed, Jul 15, 2026 at 6:55=E2=80=AFPM Roman Gushchin <roman.gushchin@=
linux.dev> wrote:
> >>
> >> * Review of LTS patches and kernel releases.
> >
> > For the backporting case, I think this could help, and there are
> > certain things we could ask for, i.e. custom prompts.
>
> +1
>
> > It may also have less noise, in the sense that the AI has the original
> > commit in mainline as a baseline, i.e. it is not a completely new
> > patch of unknown quality.
> >
> > I imagine Sasha et al. have experience with this.
> >
> >> * How to maintain the long-term stability of Sashiko?
> >
> > How hard do you think it would be to get at least one more AI company
> > to donate some tokens (for their own model)? Could that be a simple
> > start to begin reducing the single-provider issue?
>
> It's hard to say. Technically it's fairly trivial to make Sashiko using
> multiple models for discovery stages 1-7 in parallel, which will almost
> certainly improve the review quality. In such case models will
> effectively cooperate to produce better reviews, which is our goal.
>
> >> * Handling of pre-existing bugs.
> >
> > Do you mean the AI would be able to query that database? Or directly
> > being part of the prompt for that subsystem/file if it is not too big?
>
> Yes, Sashiko can query the database before reporting pre-existing
> issues, e.g. if there is an obvious but not urgent pre-existing bug
> there is no point to report it again and again.

It might be worth noting that in KernelCI we have [1]; we could
include Sashiko to publish issues into this database for public
visibility. Feel free to get in touch, Roman, and we can work together
to make this happen. Currently, these issues come from our build/test
system, but Red Hat submits issues from their CKI system, so we can do
something similar with Sashiko.

Whilst I am at it, we recently added an MCP to [2] This is still
experimental, but allows users to spin up an MCP server locally (we
have plans to get a hosted MCP server up soon) and interact with the
KernelCI API (issues, failures, etc). I'd love any feedback. This is
useful for interacting with all the data inside KernelCI and allows
for you to link it up to your <agent of choice> to drill down builds
failures/flaky tests etc.

I will also be writing a blog post about it soon.

Ben

1: https://dashboard.kernelci.org/issues
2: https://github.com/kernelci/kci-dev/blob/main/docs/mcp.md.

>
> Thanks!
>