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

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/[email protected]/
> 
>   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.
> 
> - 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?
> 
> - 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?
> 
> - 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.
> 
> That's probably enough :)
> 
> jon

Hi Jonathan,

Paul McKenney made me aware that this list is in fact public, so I
wasn't aware of this discussion. I thought only the commitee members had
access to that email; maybe that is something that should be more clear
in the announcement. Ah well... it was proposed in good faith :)

Best,
Jori.