Re: [PATCH RFC] coding-assistants: simplify attribution

[Lorenzo Stoakes <ljs@kernel.org>]

On Thu, Jul 02, 2026 at 09:09:05AM -0400, Brian Foster wrote:
> On Thu, Jul 02, 2026 at 01:18:06PM +0100, Lorenzo Stoakes wrote:
> > On Thu, Jul 02, 2026 at 07:57:45AM -0400, Brian Foster wrote:
> > > On Thu, Jul 02, 2026 at 10:44:09AM +0100, Lorenzo Stoakes wrote:
> > > > On Thu, Jul 02, 2026 at 12:38:44PM +0300, Laurent Pinchart wrote:
> > > > > On Thu, Jul 02, 2026 at 10:44:34AM +0200, Vlastimil Babka (SUSE) wrote:
> > > > > > On 7/2/26 10:12, Jori Koolstra wrote:
> > > > > > > Ah, I still reigniting this discussion again :)
> > > > > > >
> > > > > > > What about a combination of what David and Jeff say? The whole point
> > > > > > > seems to me that the salient information is not that an LLM was used (or
> > > > > > > are we going to tag Sashiko as well or any other LLM-based code review
> > > > > > > tool?), but what is was used to do. This information may be relevant for
> > > > > > > how the review is approached. The latter should perhaps only be in the
> > > > > > > cover letter and then we can drop the assisted-by tags altogether.
> > > > > > >
> > > > > > > The question about enforcement remains.
> > > > > >
> > > > > > It's not possible to enforce it. People can deny it if the tag is missing
> > > > > > and you confront them and even though the submission has many signs of being
> > > > > > obviously LLM, there is no definite proof. We've seen (likely, as there's no
> > > > > > proof!) that happen in mm.
> > > > > >
> > > > > > Such situation then penalizes those who disclose so obviously they won't.
> > > > >
> > > > > I think there's also a penality for those who don't disclose when
> > > > > they're told they should: it will lower trust. Kernel development is
> > > > > largely based on a trust model. If a contributor decides to adopt a
> > > > > deceiptful behaviour, they can expect maintainers to raise the bar for
> > > > > accepting patches, when not rejecting them outright.
> > > >
> > > > Yes, I explicitly said this in response to somebody for whom there was
> > > > overwhelming evidence they were submitting AI slop, and that they'd need to
> > > > build it back up again.
> > > >
> > > > It's precisely the issue as I see it.
> > > >
> > > > But others within the community disagreed with me, so it turned into a very
> > > > long and draining discussion that I don't particularly wish to repeat.
> > > >
> > > > So we really need clarity on it being OK to do this (I remember saying this
> > > > last year when I made an ultimately unsuccessful submission to the
> > > > maintainer's summit about all this :)
> > > >
> > > > What matters overall is being able to _quickly_ dismiss AI slop so that
> > > > asymmetry between LLM generation + maintainer time isn't exploited.
> > > >
> > > > And ultimately I think the trust model will end up being 'newcomes have 0,
> > > > now build it up'.
> > > >
> > > > Which sucks but this issue is simply existential for open source.
> > > >
> > >
> > > Has anybody tried throwing any of the obvious LLM slop submissions we
> > > have seen into one of these LLM detector things? To be clear, I've never
> > > tried those so I'm certainly no authority on if they even work reliably,
> > > but if so I wonder if something like that is a potential solution for
> > > elminating the worst cases..
> > >
> > > I.e., suppose we had some Sashiko type LLM/bot whose job was mainly to
> > > detect purely LLM generated content based on some minimum level of
> > > confidence and reply with a loud and clear message to the thread. Maybe
> > > that would be a clear enough signal to maintainers and reviewers that
> > > something is not worth prioritizing for review.. Maybe also some "slop
> > > detected" feedback would help disincentivize flinging slop onto the
> > > lists. At the very least that could be something that is more easily
> > > configured/enabled per-subsystem without having to use per-subsystem
> > > commit tags.
> >
> > Yup I thought of this, have done this on series and they do detect it
> > reliably.
> >
>
> Interesting.
>
> > But then it becomes an arms race. People will get AI to try to defeat AI
> > detection. So I'm not sure it's a safe road to go down.
> >
>
> Yeah that's fair, but my thinking is the goal would be more to detect
> slop content as opposed to just LLM usage. The trend of these
> discussions has been that we generally don't care too much about LLM use
> in general when it's used properly as a tool, but rather as you stated
> earlier we want to be able to quickly dismiss slop to avoid wasting
> maintainer and reviewer time.
>
> It seems like we're generally able to sniff out pure LLM generated
> content in most cases. That suggests we should be able document some
> common patterns that tend to describe slop such that an LLM bot could
> detect and flag it. For example, "Slop bot has detected comments have
> LLM prose and just repeat what the code does," "Slop bot has detected
> unnecessary code volume and duplication," etc. etc.

Yep it might be helpful.

But it turns out this is more contentious than you might think, and it might be
a hard sell.

>
> So the idea with that would be that defeating the slop bot is the point.
> Consider it a sort of informal/minimal goal before a submitter is
> entitled to human review. But yeah, I guess it's still just a handwavy
> theory that you'd be able to reliably disentagle detection of general
> LLM code generation from something that more qualifies as LLM slop. Just
> thinking out loud.

Yeah tbh it'd not be perfect but I wouldn't mind if we did this.

Some information > no information.

>
> Brian
>
> > >
> > > Brian
> > >
> >
> > Thanks, Lorenzo
> >
>

Thanks, Lorenzo