# Debating the role of large language models in the kernel community > Source: > Published: 2026-08-18 07:34:42+00:00 # Debating the role of large language models in the kernel community Like many development communities, the kernel community has been struggling to determine how large language models (LLMs) will be used in its development process. The news has been dominated recently by a strongly worded missive from Linus Torvalds on the subject, but the discussion has been rather more wide-ranging and nuanced than that. Topics that have been considered recently include the LLM attribution requirement, code-review tools, dependence on proprietary tools, and whether there is a place for concerns about the ethics of LLMs.Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit [this page]to join up and keep LWN on the net. #### Reconsidering Assisted-by The kernel community's guidance regarding LLM-generated code was [added to the kernel](https://git.kernel.org/linus/78d979db6cef), at the end of 2025 for the 7.0 release, after long discussions in the Linux Foundation's Technical Advisory Board (TAB) and on the mailing lists. The [ coding-assistants.rst](https://docs.kernel.org/process/coding-assistants.html) file states that, when a code submission has been partially or entirely generated by an LLM, the patch should carry an Assisted-by tag in this format: ``` Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] ``` The purpose of this tag was to document the use of an LLM, and to alert reviewers and maintainers to that fact. It also contains the name of the specific tool used. That information was deemed potentially useful in case a specific LLM turns out to have a tendency toward specific bugs or ends up in copyright-related trouble; it would make it possible for developers to review patches generated by the problematic model and, possibly, modify or remove them. Since then, this tag has not won over all developers. As of 7.2-rc4, over 1,200 commits carry Assisted-by tags. There is, however, clearly a significant stream of machine-generated patches that do not carry that tag; sometimes that is a result of ignorance of the rules, but other times the origin of the code is, seemingly, being deliberately obscured. As a result, the tag's usefulness as an indicator of LLM involvement is unclear at best. Meanwhile, some developers see placing the names of specific LLMs into the kernel's development history as a form of advertising. All told, many wonder whether the tag adds any value at all. This discussion came to the fore at the beginning of July when Christian Brauner [suggested](/ml/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org) removing the tag or, at least, removing the name of the specific model used: I acknowledge that my stance is even more radical: imho we would just stop it with any disclosure requirements completely. It's useless imho. We already see that other than core contributors most people don't care and will just not disclose their usage of AI. I think this is entirely pointless and worse it brings in undefined legal status as well. It's not like recent events of pulling certain models from the face of the earth have made this any less concerning.But fine, if we want to do this can we please just dumb it down to ``` Assisted-by: LLM ``` Jeff Layton later followed this up with [a separate patch](/ml/all/20260702-aidoc-v1-1-735572dfb995@kernel.org) removing the attribution requirement entirely. Some developers were clearly in favor of that; networking maintainer Jakub Kicinski [let it be known](/ml/all/20260701115302.29c66401@kernel.org) that he simply removes those tags from patches he applies, essentially undermining the previous decision made by the TAB and the community. Others have not taken that step, but expressed little love for the tag. There are developers, though, who would like to see its use continue. Greg Kroah-Hartman [described](/ml/all/2026070224-unholy-commode-cf45@gregkh) it as a signal that an LLM was involved in the creation of a patch, and that the result should be reviewed more closely. Lorenzo Stoakes [characterized](/ml/all/akYz2aMIco1fbD-t@lucifer) the current policy as being "about empowering maintainers to push back ". This contingent would like to see the Assisted-by requirement stay in force, perhaps with better enforcement if possible. In the end, there appeared to be enough support for keeping the tag to prevent its outright removal, but nobody was willing to defend requiring disclosure of the specific tool used. So the consensus *seemed* to be to go with Brauner's initial suggestion, perhaps with a more focused changelog. A new revision has not yet appeared, though, and it may well be that a final decision on this policy will not be made until the Maintainers Summit in October. #### Dependence and sustainability While the use of LLMs to write code is clearly on the increase in the community, LLMs are still much more widely used for the review of patches rather than their creation. The [Sashiko review tool](/Articles/1064830/), in particular, has seen extensive adoption by many subsystems, and maintainers increasingly expect developers to respond to the reviews it emits. But these tools depend heavily on the willingness of corporations to fund their use, which drives a couple of concerns: will that generosity continue in the future, and will the community become so dependent on those tools that a future rugpull could substantially hurt the development process? Roman Gushchin, the most active developer behind Sashiko, raised this concern in his [proposal](/ml/all/7ia4qzl45h20.fsf@castle.c.googlers.com) for a Maintainers Summit discussion: Several kernel engineers and maintainers have rightfully expressed concerns about relying on infrastructure provided by a single company without clear formal guarantees. It would be great to discuss what a more sustainable model could realistically look like and how we might get there. I have also [brought this issue up](/ml/all/87wluv7yzc.fsf@trenco.lwn.net) in the community more than once. Two decades ago, the community's reliance on BitKeeper led to a major shock when access to that proprietary tool [was suddenly withdrawn](/Articles/130746/). Depending on another proprietary tool now risks a similar shock, and this time the community may not be able to depend on Torvalds creating a replacement over a long weekend. Many of the responses to this question have leaned on the idea that, while LLM-based tools help the community to be more productive, there is no real risk of becoming dependent on them. Sasha Levin, for example, [said](/ml/all/alo3tBAc_tBNgtg0@laps): "if AI suddenly goes away tomorrow it'll suck for me, but I'll just go back to writing my tools manually like I did before ". The earlier part of that email, though, read: In the past year or two I was able to rewrite most of my ugly scripts, automate so many of the processes I used to do manually, and just improve so many quality of life items thanks to AI. Look even at the CVE process that was created last year: so much of the infrastructure used to drive it was created with AI. Or consider [the words of another long-time kernel developer](/ml/all/alltqTAwLLMcJfzG@dread), Dave Chinner, in an entirely different conversation: I have learnt how to drive LLMs well enough that I don't need to write code anymore. The LLM functions as my code editor that is capable of extremely fancy DWIM predictive text insertion. For someone who hates the process of typing out code, this has been a revelation. The authors of words like that may not feel dependent on these tools, but they have nonetheless clearly given LLM-based tools a major role in how they get their work done. Ted Ts'o [said](/ml/all/allGeaXQ6DFv1M14@mit.edu) that Sashiko finds problems that human reviewers might not notice, but that it is not a substitute for human review: "I agree that if reviewers stop doing this, we would be in a world of hurt ". He also [said](/ml/all/alfBvhZkAelq5RVf@mit.edu), in a different discussion, that "one of the things that really excites me about Sashiko is that it reduces my workload ". How maintainers will respond to LLM-based reviews in the long term remains to be seen, but it seems almost certain that they will take advantage of that workload reduction and stop looking for the sorts of problems that tools like Sashiko tend to find anyway. It is hard to imagine that the skills needed to do that kind of review would not atrophy over the long term in such a scenario. If LLM-based review tools are with us for the long term, the loss of those skills might be no more tragic than the loss of low-level assembly skills. They just will not be needed anymore, and humans can focus on more strategic and long-term-maintenance issues. But if those review tools disappear as the pipeline of money behind the LLM industry constricts, development communities could find themselves regretting that skill loss. Compilers cannot be taken away from us; massive, data-center-based LLMs can. Even if the tools do not disappear entirely, they may become unavailable to developers who do not work for large companies that can pay the bills for their use. There are some developers looking into ways of running tools like Sashiko locally, using open-weight models; [Mauro Carvalho Chehab](/ml/all/20260719110103.04896f34@foz.lan) and [Takashi Iwai](/ml/all/87o6g4sl6k.wl-tiwai@suse.de) have mentioned such efforts. According to Iwai, the results are not yet the same: "Yes, there are definitely many false-positives, and they don't always follow the recent changes. Also they cover much less changes than Sashiko ". But, presumably, these efforts will make progress over time, reducing the level of dependency on the resources supplied by companies. #### Email from Sashiko To what extent should contributors be required to use — or, at least, to interact with — LLM-based tools? The [2026 Media Summit](/ml/all/40b6589d-ef42-48d0-9853-341dc196fd18@kernel.org/), held in May, discussed the use of Sashiko for media patches. Some of the outcome of that discussion can be seen in [this email from Chehab](/ml/all/20260710083845.23c753ca@foz.lan) (the maintainer of the media subsystem), who said that a separate email list had been set up to receive Sashiko emails to keep them off the main media mailing list. He also said that there is a desire for individual contributors to be able to opt out of receiving Sashiko reviews of their patches. That led to a rather lengthy discussion. Gushchin [responded](/ml/all/87wlv2jq4t.fsf@linux.dev) that an opt-out capability seemed like a strange request, like asking to be able to opt out of unit tests. Chehab [agreed](/ml/all/20260713095538.3d5e86f1@foz.lan) with him, saying that community etiquette called for always copying the author on replies, but that there are members of the community who see things differently. Laurent Pinchart [answered](/ml/all/20260713094120.GD1127719@killaraus.ideasonboard.com/) that etiquette called for an explicit request before signing somebody up for a new mailing list. When Gushchin [asked](/ml/all/7ia4mrvtrxjl.fsf@castle.c.googlers.com) whether even a "critical issue " found by Sashiko should not be sent to a patch author, Pinchart [responded](/ml/all/20260715005909.GF1656185@killaraus.ideasonboard.com): "I expect maintainers who want to act on sashiko reviews to triage and verify them first before bothering authors ". It is fair to say that the idea of expecting maintainers to review Sashiko's reviews before sending them to contributors was not entirely popular with maintainers. Ts'o [refused](/ml/all/alcBvuIMEGSjAD1R@mit.edu) that duty and said, instead, that he feels no need to accept patches from contributors who refuse to look at Sashiko reviews. Ihor Solodrai [said](/ml/all/00a244f8-5be6-4ee7-b5b1-e4cbdcd4fc77@linux.dev) that it is the contributor's job to make a patch good enough to be merged and, in the current environment, that includes addressing bugs found by LLM-based tools. Gushchin [pointed out](/ml/all/7ia47bmw0xls.fsf@castle.c.googlers.com) that attackers are using these tools even if contributors reject them. James Bottomley [added](/ml/all/460bb8002edc009194dcc0ad68a0538e5df6bfb5.camel@HansenPartnership.com) that "the contributor doesn't get to approve the tools the maintainer uses to assess and apply patches ". Pinchart pushed back, though, [saying](/ml/all/20260715174138.GI1778116@killaraus.ideasonboard.com) that, since maintainers are forcing the change toward these tools, it is up to them to use the time the tools are saving to triage the reviews instead. To require dealing with Sashiko, he [said](/ml/all/20260715163921.GH1778116@killaraus.ideasonboard.com/), is to "force contributors to constantly justify their value against a machine that is known to produce a non-negligible quantity of nonsense ". Having to respond to unchecked reviews from LLMs, he [said](/ml/all/20260715161111.GC1778116@killaraus.ideasonboard.com), is equivalent to maintainers being forced to read LLM-generated patches from contributors who have not checked them. He also [referred back](/ml/all/20260715190654.GK1778116@killaraus.ideasonboard.com) to the Media-Summit discussion about sending machine-generated reviews to newer developers: This came from a consideration on the impact of false positives and other hallucinations on junior developers. They may have the best context of the work, but they are also most at risk of not questioning the validity of the reviews. A related area of concern, raised by a number of developers (including Gushchin in his proposal for the Maintainers Summit) is that of pre-existing issues. As Sashiko reviews a patch, it also finds bugs that already exist in the code being changed. Surprisingly, it would seem that the current kernel code base still contains no shortage of errors. Nobody seems to think that these bugs should not be reported, but many see them as noise that the developer of the patch being reviewed should not have to work through. It would be nice, certainly, if the developer would fix all of those bugs, but it is generally not considered reasonable to require developers to do that extra work. As Torvalds [noted](/ml/all/CAHk-=wjCcHUr=-Ycsey0khWnn68O6D=ZN-bE+8Sq4NetXpFuPA@mail.gmail.com), the tendency of some maintainers to expect contributors to fix unrelated problems has been a pain point in the past. It doesn't work, and should not be done with bugs found by LLMs either. He had a somewhat eye-opening suggestion that, perhaps, an LLM could create its own fixes for at least some of those bugs and maintain a tree of its own patches. "That would seem to be the obvious 'next step' from just doing patch review. Trivial patches that the AI has high confidence in, and we have high confidence in the group running the AI ". There was no immediate clamor of support for that idea. Instead, developers talked mostly about trying to somehow maintain a separate list of pre-existing bugs that need attention when somebody has the time to do so. #### Forking and ethics Returning to the media discussion; Gushchin had [responded](/ml/all/4928C919-7999-4E76-ADCB-F8643FED105B@linux.dev) to the request for a per-developer opt-out capability by describing the request as "a very anti-LLM position in general " and something that would defeat the purpose of helping maintainers. That led to [the Torvalds response](/ml/all/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com) reported on around the world: Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.Or just walk away. AI is a tool, just like other tools we use. And it's clearly a useful one. Lyude Paul's [response](/ml/all/3a5d891b536588e8e4fc84d60a5c8af72091d852.camel@redhat.com) to Torvalds is worth reading in its entirety. She points out that many developers need their paychecks and are not in a position either to fork the kernel or to walk away from it. Developers are currently under heavy pressure to use LLM-based tools, to the detriment of the quality of the code produced: Many, many of our employers are explicitly trying to force these tools on people with the expected result being a magical 10x productivity boost that just isn't compatible with oversight. It is being used in a LOT of workplaces as an excuse to throw any notion of actual review or code quality out the window. While we've been dealing with slop for decades in the kernel already: I think it is very worthwhile to point out that a tool that dramatically lowers the bar required to generate huge amounts of sniff-test passing slop is in fact, not like other tools. For developers who are working to maintain the quality of the kernel's code, Paul said, guidelines on LLM use within the kernel may be the only tool those developers have to push back safely on their employers. This pressure from employers has also arguably had the result of making many developers unwilling to argue publicly against their use, leaving Pinchart as one of the few willing to do so. He [made his position clear](/ml/all/20260715185141.GJ1778116@killaraus.ideasonboard.com) on the topic: "I consider that, today, there's no ethical justification for the use of generative AI in FOSS development ". Torvalds was quick to [shut down](/ml/all/CAHk-=wi7KN9_DYdmaE2chC92EhTrO=Wtx1bPBER-EQfAZ8FREg@mail.gmail.com) any discussion along those lines: "So keep your ethics where they belong - in your personal life. Don't try to enforce your ethics on others ". This position is worth reflecting upon for a moment. Developers will, given a chance, describe a number of ethical misgivings about these tools. They will talk about the industry's decision to ignore copyright and the possibility that LLM output violates copyrights. They may mention the environmental costs of untold gigawatts of computing power being directed toward these models, or the effects of data-center construction on the communities around them. Developers may express concerns about how these models are controlled by oligarchs, or about the systemic economic risk posed by the huge portion of the economy being pulled into this industry. They might even spare a moment to commiserate with web-site operators who are struggling to contend with scraping by bot networks. Whether or not one agrees (or cares) about these concerns, there is no doubt that they exist. But, according to Torvalds, that entire discussion is off limits; the only aspect of the problem that can be talked about is "technical reasons " and whether the tools are useful. Clearly, the kernel community is not in a position to fix any of those problems. It is also clear that the community cannot pretend that these tools do not exist. But neither can the community pretend that the ethical issues around LLM use do not exist, at least, not without the risk of alienating the developers who do care about these things. As anybody who has made it to the end of this overly long article will have long since realized, there are a lot of open questions regarding the use of LLM technology in the kernel community. Many developers and maintainers are clearly quite supportive of that use, and it seems clear that the role of LLMs in kernel development is set to grow. This community has muddled through numerous debates over the years about its direction and, yes, about its ethics. The result has generally been a stronger and larger community going forward. Hopefully, the community will find ways to reach that sort of outcome this time as well. | Index entries for this article | | |---|---| |