Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content

On Wed, Jan 07, 2026 at 01:37:04PM -0800, Dirk Hohndel wrote:
>
>
> > On Jan 7, 2026, at 13:15, Lorenzo Stoakes <[email protected]> wrote:
> >
> > On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote:
> >> ...
> >>> I know Linus had the cute interpretation of it 'just being another tool'
> >>> but never before have people been able to do this.
> >>
> >> I respect your position here. But I'm not sure how to reconcile:
> >>
> >> 	LLMs are just another tool
> >> and
> >> 	LLMs are not just another tool
> >>
> >> :)
> >
> > Well I'm not asking you to reconcile that, I'm providing my point of view
> > which disagrees with the first position and makes a case for the
> > second. Isn't review about feedback both positive and negative?
> >
> > Obviously if this was intended to simply inform the community of the
> > committee's decision then apologies for misinterpreting it.
> >
> > I would simply argue that LLMs are not another tool on the basis of the
> > drastic negative impact its had in very many areas, for which you need only
> > take a cursory glance at the world to observe.
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> I think Linus' position is based on what the LLM does when it comes to writing
> code. Your position is based on the impact that LLMs have when it comes to
> 'regular' maintainers (since he ignores GitHub PRs and only takes merge requests
> sent directly to him, I don't think he ever sees just how much garbage gets sent
> to maintainers...)

Yes, absolutely.

>
> >> For now, I think the existing rules are holding. We have the luxury of
> >
> > We're noticing a lot more LLM slop than we used to. It is becoming more and
> > more of an issue.
>
> The kernel isn't alone in getting garbage PRs, but I think for the kernel the initial
> hurdle to creating a PR was bigger than for most other projects, so the sudden
> increase in slop is likely felt even more.

Absolutely. This is exactly the problem. And LLMs uniquely enable people to send
these end-to-end. This is why they are different from previous tools.

>
> > And it's not like I'm asking for much, I'm not asking you to rewrite the
> > document, or take an entirely different approach, I'm just saying that we
> > should highlight that :
> >
> > 1. LLMs _allow you to send patches end-to-end without expertise_.
> >
> > 2. As a result, even though the community (rightly) strongly disapproves of
> >   blanket dismissals of series, if we suspect AI slop [I think it's useful
> >   to actually use that term], maintains can reject it out of hand.
> >
> > Point 2 is absolutely a new thing in my view.
>
> And as much as I respect the desire to be open to new tools and to encourage
> new developers, I think this statement is very much on point and useful to
> include.
> (of course, my opinion isn't all that relevant, given how long it has been that
> I have sent kernel merge requests)

Thanks :)

Well I don't send any merge requests to Linus direct myself as a sub-maintainer
in mm ;) so if that were the criteria I'd fail on that also! :)

>
> /D
>

Cheers, Lorenzo