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

[Troy Benjegerdes]

On Mon, Oct 19, 2026 at 12:32:21PM -0400, lyude@xxxxxxxxxx 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.

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".

If you don't agree with me, that's your choice as an individual. I also
want to point out that it seems like many of the biggest LLM users are
also being funded by large organizations that have well-developed and
important *policy* about both inbound GPL contamination issues, as well
as outbound.

How many maintainers on this list that use LLMs have asked their legal
departments about the risks of including code that does not have settled
case law on copyright? 

How much money would it cost to rip out and clean-room a bunch of code
without the benefit of *any* AI or LLM? 

> The latter has been the case for years, I've seen plenty of subsystems
> that barely have the bandwidth to actually review work and this was
> very much an issue well before the LLM bubble. Is it not even possible
> for us to maybe first consider trying to solve this problem and push
> subsystems towards actually making it a priority to find more
> maintainers? Subsystems like DRM have had this problem solved for ages,
> I consistently see us reviewing work far more consistently then other
> areas of the kernel I've seen - even with the onslaught of LLM
> contributions. Considering how attractive a lot of GPU drivers are for
> LLM contributors, I think that's saying something!
> 

If we are going to solve this problem, my view is we are going to have
to look at how to fund maintainers in a more organized way. If LLM
codegen tools are causing a lot of "noise", then maybe we should explore
how to bill the noise generators.

-- Troy