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

[lyude]

On Mon, 2026-10-26 at 09:39 -1000, Linus Torvalds wrote:
> On Mon, 26 Oct 2026 at 09:04, <lyude@xxxxxxxxxx> wrote:
> > 
> > On Wed, 2026-10-21 at 16:07 +0000, Troy Benjegerdes wrote:
> > > 
> > > 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.
> 
> More importantly than that - the whole "deterministic" part is a
> total
> red herring.

I'm going to stop you and say "please read my responses on the rest of
this thread and actually get a sense of where I am arguing from instead
of seeing a anti-AI person and jumping on it immediately". I use LLM
review tools like sashiko, I have merged LLM generated work, I work
with people who regularly use LLMs in their workflow to a much greater
extent then I do. The deterministic bit I mentioned was not meant to be
some ultimate point to shut down the use of LLMs forever, it is to set
people's expectations with how these tools can improve correctly.

Yes - people are also non-deterministic and make mistakes, the goal has
never been to get a "perfect" tool. But I do think it is important
context to bring up because the fact that they're non-deterministic
means we need to take that into account when interacting with and using
these tools in order to use them more effectively and avoid leaving
extra work at maintainer's laps. Especially when you're trying to get
across to people "if you're contributing to a kernel that is being run
all across the globe, you need to learn how to do this job as well
instead of leaning entirely on an LLM for it - otherwise people won't
be happy with you because you're making them do the hard work".

The bigger point that I'm getting at that keeps getting glossed over
here - LLMs can generate a lot of code, a lot faster then a person can.
When someone is submitting code that they've written by hand, at the
very least I have the guarantee that for the most part they've been
following along with the process of making it. It's not perfect, there
will be mistakes, some of those mistakes will bite me years later. And
yes - some people even do move faster then they can think with writing
code by hand. I've had to deal with that very problem in kernel
development a number of times. But honestly, even when that's the case
- I can usually work with the contributor to help change their workflow
into something that produces work that's easier for me to review and
get upstream.

But the amount I have seen people moving way too fast has gone up
significantly since LLMs came onto the scene, and it's been repeatedly
difficult to actually work with many of these contributors. Often times
they don't take feedback or learn from it, in part because they aren't
writing the code and are focusing on just running it. It's also become
dramatically more difficult to encourage people to try to dig further
into troubleshooting issues when I only have so much time available and
am trying to provide contributors ways that they can provide me more
information that lets me properly review their work. I've dealt with a
number of people who, even after explicitly describing the steps to
take to try to investigate something further, end up just asking the
LLM, and then giving up when the LLM can't figure it out again. And
yes, this isn't entirely new - it's happened in the past. But it
happens a LOT more then it used to now.

That is the social contract changing, suddenly someone who moves a
million miles per hour can drop an enormous patch series and either I'm
against LLMs for trying to put a foot down and say "There's no possible
way you generated tens of thousands of lines of code that quickly and
can still guarantee me you've at least tried your best to understand
that code." or I have to do that work myself. Even with reasonable
sized commits, I often am still left doing a hell of a lot more work
trying to get them into shape then I was before. And more often then
not, the person submitting them doesn't actually know how to do
anything beyond just prompting the LLM. This isn't everyone, but
contributors like that used to happen every now and then. It is almost
constant at times now, and it's mostly from people using LLMs.

And there is actually a pretty dramatic difference in the quality of
work I've seen from contributors who use LLMs in their workflow and
don't just copy paste the LLM output verbatim into their mail client
and send it to me. I know plenty of people who use LLMs very heavily
who I've literally never had a problem working with. Often times, they
also tend to be the ones who use the LLM for everything but writing the
code - or at the very least they actually take the time to give their
submission a major face lift before it comes across my desk. The one
thing that's in common with all these workflows - there's a clear,
stark effort to do their best to understand what they are submitting.
again, it's not perfect, but it's something.

> And yes, non-determinism adds a wrinkle to things and it's something
> that needs to be taken into account (and people often add things like
> explicit seeds to avoid it when they need explicit determinism from
> otherwise non-deterministic algorithms). So non-determinism is
> something that should be weighed as a factor against what else the
> tools brings you.
> 
> But it's not actually an argument against LLM's.

No. It's not. And it wasn't meant to be. Please go and actually read my
responses in the future. This is a huge part of the reason these
discussions constantly blow up on the mailing list, no one is allowed
to have nuance with this.

> 
>               Linus