Re: [PATCH] docs: remove Assisted-by references

[lyude@redhat.com]

On Wed, 2026-10-21 at 16:07 +0000, Troy Benjegerdes wrote:
> On Mon, Oct 19, 2026 at 12:32:21PM -0400, lyude@redhat.com wrote:
> > On Tue, 2026-10-13 at 23:23 -0400, Theodore Tso wrote:
> > > 
> > > Using AI-assited priotization may have some collateral damange
> > > because
> > > it might not get the prioritization correct.  But ultimately, if
> > > we
> > > get a flood of patches from newcomers, the choices is either to
> > > (a)
> > > load-shed, or (b) burn out.  And of the two, (a) is the better of
> > > two
> > > bad choices.
> > 
> > Why is there so much talk around trying to automate portions of the
> > review process with non-deterministic tooling (don't get me wrong,
> > things like Sashiko help) and not "we really kind of have a problem
> > not
> > having enough maintainers"?
> 
> It *is* possible to make a deterministic LLM, and this is why I think
> it
> is critical to my personal future to have an LLM that can actually be
> understood by a human instead of a random number generator casino
> that
> sometimes puts "4" in your private key.

I hate to break it to you but that is literally not how large language
models work. Random selection against weights that affect probability
are literally how these systems work. This isn't to say that models
cannot call down to deterministic tools, something that is quite common
for things like Claude to do (less embarrassing miscounts of the letter
r in strawberry). And that can give the impression that suddenly
they're deterministic. But the part that is the model is still
inherently probabilistic.

To fix that would mean abandoning current LLM approaches. It's not a
bug, it's literally how models work - they take input and transform it
to what looks to be the most likely output to follow - in other words
it is predicting tokens. The likelihood of whether one thing is chosen
over another is determined by weights, which by their vary nature are
probabilities.

On top of that, if you were to try to suddenly introduce determinism
into LLMs most of the workflows that people are using them for simply
wouldn't work. It's not at all unusual for LLMs to only end up at the
correct solution for a problem by more or less brute forcing it until
it arrives at an answer that looks correct. If LLMs were not
probabilistic, this approach wouldn't work because it would come up
with the same 'solution' to a problem every time it makes an attempt -
which would mean if it doesn't get the solution right the first time it
simply never will. That's why LLMs are so incredibly resource hungry,
you are basically brute forcing intelligence. 

Someone could do something differently in the future, but right now
every single industry leader is following the same idea of "if we can
keep adding computers infinitely we can do anything" with the idea that
models will simply become perfect by providing them enough training
data.

> 
> What this means for this discussion is a clear process and social
> expectation on the core OS kernel development community that humans
> who
> use this kind of technology for an open source project make a
> machine-
> readable note in the commit message on what proprietary tools have
> been
> used.
> 
> "Assisted by: Claude"
> "Assisted by: GNU/LLM/Linux"
> "Assisted by: <redacted>"
> "Assisted by: Debian"
> 
> All of these tags say way more than a simple binary flag for "LLM was
> used".

From a maintainer standpoint "claude was used for something somewhere
at some part of the process" is not at all a useful piece of
information. It tells me nothing about how the person writing the patch
used the tool to actually create the patch. And outside of that
specific question, there is quite literally no relevance. No
maintainers actually care what operating system patches were written
on, because that doesn't affect the actual output of the code that is
being given to us. The same goes for whether or not it was proprietary
tooling, the kernel has never at any point in its history been 100%
written without proprietary tools. On top of that, it again doesn't
make any practical difference to the code that maintainers receive. In
that regard, I'd even go so far as to say the LLM in question either
doesn't actually make a difference. Regardless of people's opinions on
the quality of the output of one model vs. another, a maintainer still
needs to read the code and understand it to the best of their ability.
Even if one model was more likely to spit out bad code, in theory none
of that is going to matter -if- the person writing it actually did
understand everything in the code that they sent out and looked through
all of it.

In reality, I don't particularly agree with the idea that people can
handle that kind of review. I think it's very easy for us to feel like
we can, but more often then not I regularly see that's not actually the
case with people submitting LLM generated code beyond a certain size.
And this is in part due to the fact that if you did actually review all
of the code the LLM spits out, you wouldn't actually be saving time.
And in addition to the fact that I have always seen a very clear
difference in the understanding I and most maintainers have around code
they've reviewed vs. code that they've actually written. I would be
naive if I said I could understand a reasonably sized patch or patch
series (like, hundreds or thousands of lines of code) at the same level
as a person who wrote it. I can understand the jist of it, and I can
understand most of it, but the portion that reviewers miss is intent -
we have to ask the author why they did X/Y/Z, but the author (usually)
knows that.

This is a big reason I advocated for just clarifying -what- the tool
was actually used for. When I'm getting a patch that was entirely
written by an LLM, I now have to review it with the understanding that
we don't have an author to ask questions or retrieve intent from. I
can't understand what someone was attempting to accomplish if they
don't accomplish it correctly, which can lead to substantially more
review work. But this is only the case with code that is _entirely
written_ by an LLM. I think it's quite different when someone say,
writes a patch by hand while using Claude for answering questions
around the codebase they are working on, or if they used Claude for
finding security vulnerabilties or subtle bugs that lend themselves to
the kind of pattern matching LLMs excel at.

Which was why I suggested "Reported-by", "Co-authored-by", etc. the LLM
model in use might not matter, but how the person interacted with it to
get the work that they sent me does matter quite a lot. I don't get
that information from a simple "Assisted-by".