{"slug": "debating-the-role-of-large-language-models-in-the-kernel-community", "title": "Debating the role of large language models in the kernel community", "summary": "The Linux kernel community is debating the role of large language models (LLMs) in development, with over 1,200 commits carrying Assisted-by tags as of 7.2-rc4, but many developers question the tag's value and compliance. Christian Brauner proposed simplifying the tag to 'Assisted-by: LLM' or removing disclosure requirements entirely, while Jeff Layton submitted a patch to remove the attribution requirement, and networking maintainer Jakub Kicinski said he removes the tags from patches he applies.", "body_md": "# Debating the role of large language models in the kernel community\n\nLike 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\n\n[this page]to join up and keep LWN on the net.\n\n#### Reconsidering Assisted-by\n\nThe kernel community's guidance regarding LLM-generated code was [added to the kernel](https://git.kernel.org/linus/78d979db6cef), at the\nend of 2025 for the 7.0 release, after long discussions in the Linux\nFoundation's Technical Advisory Board (TAB) and on the mailing lists. The\n[ coding-assistants.rst](https://docs.kernel.org/process/coding-assistants.html)\nfile states that, when a code submission has been partially or entirely\ngenerated by an LLM, the patch should carry an Assisted-by tag in this\nformat:\n\n```\n    Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]\n```\n\nThe 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.\n\nSince 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.\n\nThis discussion came to the fore at the beginning of July when Christian\nBrauner [suggested](/ml/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org)\nremoving the tag or, at least, removing the name of the specific model\nused:\n\nI 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\n\n```\n    Assisted-by: LLM\n```\n\nJeff Layton later followed this up with [a separate\npatch](/ml/all/20260702-aidoc-v1-1-735572dfb995@kernel.org) removing the attribution requirement entirely. Some developers\nwere clearly in favor of that; networking maintainer Jakub Kicinski [let it be known](/ml/all/20260701115302.29c66401@kernel.org) that\nhe simply removes those tags from patches he applies, essentially\nundermining the previous decision made by the TAB and the community.\nOthers have not taken that step, but expressed little love for the tag.\n\nThere are developers, though, who would like to see its use continue. Greg\nKroah-Hartman [described](/ml/all/2026070224-unholy-commode-cf45@gregkh) it as a\nsignal that an LLM was involved in the creation of a patch, and that the\nresult should be reviewed more closely. Lorenzo Stoakes [characterized](/ml/all/akYz2aMIco1fbD-t@lucifer) the current\npolicy as being \"about empowering maintainers to push back\n\n\". This\ncontingent would like to see the Assisted-by requirement stay in force,\nperhaps with better enforcement if possible.\n\nIn the end, there appeared to be enough support for keeping the tag to\nprevent its outright removal, but nobody was willing to defend requiring\ndisclosure of the specific tool used. So the consensus *seemed* to be\nto go with Brauner's initial suggestion, perhaps with a more focused\nchangelog. A new revision has not yet appeared, though, and it may well be\nthat a final decision on this policy will not be made until the Maintainers\nSummit in October.\n\n#### Dependence and sustainability\n\nWhile the use of LLMs to write code is clearly on the increase in the\ncommunity, LLMs are still much more widely used for the review of patches\nrather than their creation. The [Sashiko\nreview tool](/Articles/1064830/), in particular, has seen extensive adoption by many\nsubsystems, and maintainers increasingly expect developers to respond to\nthe reviews it emits. But these tools depend heavily on the willingness of\ncorporations to fund their use, which drives a couple of concerns: will\nthat generosity continue in the future, and will the community become so\ndependent on those tools that a future rugpull could substantially hurt the\ndevelopment process?\n\nRoman Gushchin, the most active developer behind Sashiko, raised this\nconcern in his [proposal](/ml/all/7ia4qzl45h20.fsf@castle.c.googlers.com) for a\nMaintainers Summit discussion:\n\nSeveral 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.\n\nI have also [brought this\nissue up](/ml/all/87wluv7yzc.fsf@trenco.lwn.net) in the community more than once. Two decades ago, the\ncommunity's reliance on BitKeeper led to a major shock when access to that\nproprietary tool [was suddenly withdrawn](/Articles/130746/).\nDepending on another proprietary tool now risks a similar shock, and this\ntime the community may not be able to depend on Torvalds creating a\nreplacement over a long weekend.\n\nMany of the responses to this question have leaned on the idea that, while\nLLM-based tools help the community to be more productive, there is no real\nrisk of becoming dependent on them. Sasha Levin, for example, [said](/ml/all/alo3tBAc_tBNgtg0@laps): \"if AI suddenly goes away\ntomorrow it'll suck for me, but I'll just go back to writing my tools\nmanually like I did before\n\n\". The earlier part of that email, though,\nread:\n\nIn 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.\n\nOr consider [the words of another\nlong-time kernel developer](/ml/all/alltqTAwLLMcJfzG@dread), Dave Chinner, in an entirely different\nconversation:\n\nI 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.\n\nThe 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.\n\nTed Ts'o [said](/ml/all/allGeaXQ6DFv1M14@mit.edu) that Sashiko\nfinds problems that human reviewers might not notice, but that it is not a\nsubstitute for human review: \"I agree that if reviewers stop doing this,\nwe would be in a world of hurt\n\n\". He also [said](/ml/all/alfBvhZkAelq5RVf@mit.edu), in a different\ndiscussion, that \"one of the things that really excites me about Sashiko\nis that it reduces my workload\n\n\". How maintainers will respond to\nLLM-based reviews in the long term remains to be seen, but it seems almost\ncertain that they will take advantage of that workload reduction and stop\nlooking for the sorts of problems that tools like Sashiko tend to find\nanyway. It is hard to imagine that the skills needed to do that kind of\nreview would not atrophy over the long term in such a scenario.\n\nIf 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.\n\nThere are some developers looking into ways of running tools like Sashiko\nlocally, using open-weight models; [Mauro Carvalho Chehab](/ml/all/20260719110103.04896f34@foz.lan)\nand [Takashi Iwai](/ml/all/87o6g4sl6k.wl-tiwai@suse.de) have\nmentioned such efforts. According to Iwai, the results are not yet the\nsame: \"Yes, there are definitely many false-positives, and they don't\nalways follow the recent changes. Also they cover much less changes than\nSashiko\n\n\". But, presumably, these efforts will make progress over time,\nreducing the level of dependency on the resources supplied by companies.\n\n#### Email from Sashiko\n\nTo what extent should contributors be required to use — or, at least, to\ninteract with — LLM-based tools? The [2026 Media\nSummit](/ml/all/40b6589d-ef42-48d0-9853-341dc196fd18@kernel.org/), held in May, discussed the use of Sashiko for media patches.\nSome of the outcome of that discussion can be seen in [this email from Chehab](/ml/all/20260710083845.23c753ca@foz.lan)\n(the maintainer of the media subsystem), who said that a separate email\nlist had been set up to receive Sashiko emails to keep them off the main\nmedia mailing list. He also said that there is a desire for individual\ncontributors to be able to opt out of receiving Sashiko reviews of their\npatches. That led to a rather lengthy discussion.\n\nGushchin [responded](/ml/all/87wlv2jq4t.fsf@linux.dev) that an\nopt-out capability seemed like a strange request, like asking to be able to\nopt out of unit tests. Chehab [agreed](/ml/all/20260713095538.3d5e86f1@foz.lan) with him, saying\nthat community etiquette called for always copying the author on replies,\nbut that there are members of the community who see things differently.\nLaurent Pinchart [answered](/ml/all/20260713094120.GD1127719@killaraus.ideasonboard.com/)\nthat etiquette called for an explicit request before signing somebody up\nfor a new mailing list. When Gushchin [asked](/ml/all/7ia4mrvtrxjl.fsf@castle.c.googlers.com) whether\neven a \"critical issue\n\n\" found by Sashiko should not be sent to a\npatch author, Pinchart [responded](/ml/all/20260715005909.GF1656185@killaraus.ideasonboard.com):\n\"I expect maintainers who want to act on sashiko reviews to triage and\nverify them first before bothering authors\n\n\".\n\nIt is fair to say that the idea of expecting maintainers to review\nSashiko's reviews before sending them to contributors was not entirely\npopular with maintainers. Ts'o [refused](/ml/all/alcBvuIMEGSjAD1R@mit.edu) that duty and said,\ninstead, that he feels no need to accept patches from contributors who\nrefuse to look at Sashiko reviews. Ihor Solodrai [said](/ml/all/00a244f8-5be6-4ee7-b5b1-e4cbdcd4fc77@linux.dev) that\nit is the contributor's job to make a patch good enough to be merged and,\nin the current environment, that includes addressing bugs found by\nLLM-based tools. Gushchin [pointed out](/ml/all/7ia47bmw0xls.fsf@castle.c.googlers.com) that\nattackers are using these tools even if contributors reject them. James\nBottomley [added](/ml/all/460bb8002edc009194dcc0ad68a0538e5df6bfb5.camel@HansenPartnership.com)\nthat \"the contributor doesn't get to approve the tools the maintainer\nuses to assess and apply patches\n\n\".\n\nPinchart pushed back, though, [saying](/ml/all/20260715174138.GI1778116@killaraus.ideasonboard.com)\nthat, since maintainers are forcing the change toward these tools, it is up\nto them to use the time the tools are saving to triage the reviews instead.\nTo require dealing with Sashiko, he [said](/ml/all/20260715163921.GH1778116@killaraus.ideasonboard.com/),\nis to \"force contributors to constantly justify their value against a\nmachine that is known to produce a non-negligible quantity of\nnonsense\n\n\". Having to respond to unchecked reviews from LLMs, he [said](/ml/all/20260715161111.GC1778116@killaraus.ideasonboard.com),\nis equivalent to maintainers being forced to read LLM-generated patches\nfrom contributors who have not checked them. He also [referred\nback](/ml/all/20260715190654.GK1778116@killaraus.ideasonboard.com) to the Media-Summit discussion about sending machine-generated\nreviews to newer developers:\n\nThis 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.\n\nA 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.\n\nAs Torvalds [noted](/ml/all/CAHk-=wjCcHUr=-Ycsey0khWnn68O6D=ZN-bE+8Sq4NetXpFuPA@mail.gmail.com),\nthe tendency of some maintainers to expect contributors to fix unrelated\nproblems has been a pain point in the past. It doesn't work, and should\nnot be done with bugs found by LLMs either. He had a somewhat eye-opening\nsuggestion that, perhaps, an LLM could create its own fixes for at least\nsome of those bugs and maintain a tree of its own patches. \"That would\nseem to be the obvious 'next step' from just doing patch review. Trivial\npatches that the AI has high confidence in, and we have high confidence in\nthe group running the AI\n\n\".\nThere was no immediate clamor of support for that idea. Instead,\ndevelopers talked mostly about trying to somehow maintain a separate list\nof pre-existing bugs that need attention when somebody has the time to do\nso.\n\n#### Forking and ethics\n\nReturning to the media discussion; Gushchin had [responded](/ml/all/4928C919-7999-4E76-ADCB-F8643FED105B@linux.dev)\nto the request for a per-developer opt-out capability by describing the\nrequest as \"a very anti-LLM position in general\n\n\" and something that\nwould defeat the purpose of helping maintainers. That led to [the\nTorvalds response](/ml/all/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com) reported on around the world:\n\nLinux 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.\n\nAI is a tool, just like other tools we use. And it's clearly a useful one.\n\nLyude Paul's [response](/ml/all/3a5d891b536588e8e4fc84d60a5c8af72091d852.camel@redhat.com)\nto Torvalds is worth reading in its entirety. She points out that many\ndevelopers need their paychecks and are not in a position either to fork\nthe kernel or to walk away from it. Developers are currently under heavy\npressure to use LLM-based tools, to the detriment of the quality of the\ncode produced:\n\nMany, 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.\n\nFor 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.\n\nThis pressure from employers has also arguably had the result of making\nmany developers unwilling to argue publicly against their use, leaving\nPinchart as one of the few willing to do so. He [made his\nposition clear](/ml/all/20260715185141.GJ1778116@killaraus.ideasonboard.com) on the topic: \"I consider that, today, there's no\nethical justification for the use of generative AI in FOSS\ndevelopment\n\n\". Torvalds was quick to [shut\ndown](/ml/all/CAHk-=wi7KN9_DYdmaE2chC92EhTrO=Wtx1bPBER-EQfAZ8FREg@mail.gmail.com) any discussion along those lines: \"So keep your ethics where\nthey belong - in your personal life. Don't try to enforce your ethics on\nothers\n\n\".\n\nThis 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.\n\nWhether or not one agrees (or cares) about these concerns, there is no\ndoubt that they exist. But, according to Torvalds, that entire discussion\nis off limits; the only aspect of the problem that can be talked about is\n\"technical reasons\n\n\" and whether the tools are useful. Clearly, the\nkernel community is not in a position to fix any of those problems. It is\nalso clear that the community cannot pretend that these tools do not exist.\nBut neither can the community pretend that the ethical issues around LLM\nuse do not exist, at least, not without the risk of alienating the\ndevelopers who do care about these things.\n\nAs anybody who has made it to the end of this overly long article will have\nlong since realized, there are a lot of open questions regarding the use of\nLLM technology in the kernel community. Many developers and maintainers\nare clearly quite supportive of that use, and it seems clear that the role\nof LLMs in kernel development is set to grow. This community has muddled\nthrough numerous debates over the years about its direction and, yes, about\nits ethics. The result has generally been a stronger and larger community\ngoing forward. Hopefully, the community will find ways to reach that sort\nof outcome this time as well.\n\n| Index entries for this article | |\n|---|---|\n|", "url": "https://wpnews.pro/news/debating-the-role-of-large-language-models-in-the-kernel-community", "canonical_source": "https://lwn.net/Articles/1083275/", "published_at": "2026-08-18 07:34:42+00:00", "updated_at": "2026-08-18 08:11:17.804781+00:00", "lang": "en", "topics": ["large-language-models", "ai-policy", "ai-ethics", "developer-tools"], "entities": ["Linus Torvalds", "Linux Foundation", "Christian Brauner", "Jeff Layton", "Jakub Kicinski", "Greg Kroah-Hartman", "LWN.net"], "alternates": {"html": "https://wpnews.pro/news/debating-the-role-of-large-language-models-in-the-kernel-community", "markdown": "https://wpnews.pro/news/debating-the-role-of-large-language-models-in-the-kernel-community.md", "text": "https://wpnews.pro/news/debating-the-role-of-large-language-models-in-the-kernel-community.txt", "jsonld": "https://wpnews.pro/news/debating-the-role-of-large-language-models-in-the-kernel-community.jsonld"}}