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

Sashiko and AI code reviews in general have gained a lot of traction in
the kernel community over the last few months. I think it is fair to say
that at this point there are no more questions about the usefulness of
AI code review in general. However, there are many questions about how
to improve current workflows and better integrate them into the kernel
development process.

Some specific topics I propose we discuss:
* Review of LTS patches and kernel releases.
Currently, Sashiko reviews only publicly proposed changes, and it is
completely up to individual maintainers whether to take the findings
into account. By starting to review kernel releases and LTS backports,
we can likely significantly improve security and minimize the number of
regressions. However, this adds to the workload of maintainers, and we
need to agree on a specific process. For example, we could agree to
bring up only critical and high-severity issues and expect the authors
of corresponding changes to provide a fix-up or explain why it is not an
issue.

* How to maintain the long-term stability of Sashiko?
Several kernel engineers and maintainers have rightfully expressed
concerns about relying on infrastructure provided by a single company
without clear formal guarantees. It would be great to discuss what a
more sustainable model could realistically look like and how we might
get there.

* Handling of pre-existing bugs.
Currently, Sashiko reports pre-existing bugs alongside new issues
(while trying hard to highlight that these issues were not introduced by
the proposed change). This approach comes with significant pros (a
steady stream of bug fixes) and cons (additional noise and workload for
maintainers). I am considering a database of pre-existing issues to
ensure they are reported only once (or once per year), with an option
for the respective maintainers to flag them as false positives. This
will also provide maintainers an access to a deduplicated and ranked
list of potential issues in their subsystem’s codebase.

* Prompt development and testing.
Currently, prompts are maintained in two GitHub repositories and are
changed manually or with the help of AI coding agents. However, there is
no established practice for testing them, especially across various LLM
models. At the last LSFMMBPF conference, there was a discussion about
moving them into the kernel tree. I see some pros and cons to this
approach, but the ownership and testing models are not entirely clear.

* Interactive mode.
Many engineers have asked for some sort of interactive mode where they
can ask additional questions or follow up on the initial feedback from
Sashiko. I plan to add this to the local review mode, but for the
central public instance, it is problematic from both security and token
cost perspectives. Sashiko could analyze false-positive cases reported by
engineers, attempt to verify them, and automatically suggest specific
prompt adjustments. However, there is a non-trivial number of cases
where people are wrong to dismiss AI findings. How should we treat these
cases?

Thanks!