Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin <sashal@kernel.org>]

On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>The use of LLMs in the development process appears to be a clear theme for
>the upcoming summit.  On top of what others have already suggested, I think
>we may want to consider these questions:
>
>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
>  put something more generic?  I *think* that this thread:
>
>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
>
>  reached a consensus that "Assisted-by: LLM" was better than what we
>  require now, but it might be good to ratify that in this setting.

So originally I've added the full name of the tool and LLM because there was
interest in a later audit of the tools to determine how useful (or useless)
some of the tools are.

If those folks aren't interested in doing so anymore, then sure - we can drop
it.

But... I find it difficult to see the point of having the tag if we do that.

>- There is a lot of LLM-generated code that lacks an Assisted-by
>  disclosure.  Often, that seems to be the result of ignorance of the
>  rules; those contributors will start adding the tags when informed of the
>  requirement.  But others just lie about it.  A rule that is widely
>  ignored does not help anybody.  Can we come up with a way to get better
>  compliance, or should we just drop the tag entirely?

Similarily, I think that one of the bigger reasons for the tag was fear of the
unknown. We figured that we can tag those commits, and if we ever needed to do
something about it (revert commits because of copyright issues, broken tools,
UMN v2, etc) it would make our job easier.

I think that there's room to improve the machinery here (AGENTS.md in the root,
for example).

>- There are many first-time contributors coming in with LLM-generated
>  patches.  At times, I could swear that every one of them is focused on
>  documentation typos, but the truth of the matter is that they are
>  reaching into subsystems all over the kernel.  We have some brand-new
>  contributors making significant changes to dozens of subsystems.  An
>  experienced developer would be hard-put to truly understand what those
>  changes are doing; a newcomer is unlikely to have that understanding,
>  and is unlikely to be around to fix eventual problems.
>
>  Our maintainers are not scaling to handle this new flood, and I fear we
>  are going to see some unfortunate things merged.  One LLM-driven newcomer
>  recently nearly succeeded in establishing himself as the maintainer of
>  lib/.  How do we hold the line against this stuff while remaining open to
>  new developers?

Shouldn't it be a merits question rather than a tools question?

If the commits are correct, does it matter if they were written with an LLM? we
can insist more on supplying tests and demonstrating correctness, something we
seem to be doing quite rarely right now.

>- Our process is becoming increasingly dependent on proprietary tools.  We
>  have done that before and, in 2005, it went pretty badly for us - and
>  could have been worse.  How do we prepare for the inevitable rugpull?  I
>  raised this last year, and it was largely brushed off, but I still think
>  it's something we should be concerned about.

Are we dependent on them, or do we just find them very useful? If
Claude/Codex/etc goes away next month, will it stall any of our processes?

We have AI reviews, we have many AI tools that help both authors and
maintainers, but I don't think that any of them play an integral part of our
process.

-- 
Thanks,
Sasha