I wrote this essay for English 101 and I received an A+. The essay prompt was for an argument essay, and I decided why not do an essay on the recent Linux AI drama. Since it is technology related, I have decided to include it on my website. It is important to note though, I targeted a good grade rather than having good argument strength or factual correctedness. It could be correct and logically sound, but the goal of the argument essay was to take a stance on an issue so ultimately it is my opinion, even if it sounds like fact. There is a lot of important kernel information missing, I had to make the essay legible to the professor and other students. I could have expanded on more issues and brought in more examples, but it made it hard to stay on topic, which the professor strongly recommended to do.

Moore

Ian Moore

Professor [Redacted]

ENGL [101]

31 July 2026

AI Has Only a Specific Role in Linux Kernel Development

Artificial Intelligence (AI) has become a prominent tool in many fields, but one place it doesn’t belong is writing the programs behind our technical infrastructure. Specifically, the core programs running on computer servers that serve a valuable purpose in business, stock trading, communication, and entertainment. Even more so, the technology behind most people’s phones and some of their computers and laptops (Watkins). It wouldn’t be right if a new technology trying to shift the human-led landscape like AI should be writing the core programs that have been written and vetted by humans for the entirety of their existence. The Linux Kernel is one of those core programs (kernels) currently being threatened by the AI takeover. AI has no place within the Linux Kernel except for assisting human contributors with classifying, debugging (troubleshooting errors), and creating documentation.

Since kernels — the core programs like the Linux Kernel as mentioned before — are such core components of computers, they have very specific requirements. Those computers include servers, phones, personal computers, networking equipment, and more. The kernel runs many intrinsic properties of devices and computers that many times go completely unnoticed, including the fact a kernel exists on a device at all. Due to this, the kernel orchestrates the hidden functions of a device such as hardware, files and what files the users can access, networking, as well as giving time for programs to function. Since these functions are so vital to a computer system a kernel must have performance in mind. Performance specifically means software engineers — those who write the computer programs — must keep in mind that they have direct access to a computer’s memory, hardware, and running programs. Failure to write a bug-free kernel may result in security vulnerabilities, stability issues, and system crashes (kernel panic). This is a big contrast to software engineers who write programs for web development and desktop programs (userspace programs), where the same faults (bugs) will not crash the computer itself; which is the major difference in stakes between a kernel and userspace. In fact, the kernel’s primary goal is to allow userspace programs to fail gracefully (Torvalds, “Re: Userspace Breakage”).

Understanding the importance of a kernel gives an idea as to why the Linux Kernel’s creator and lead developer Linus Torvalds leads the project in an authoritarian way. He has been developing the Linux Kernel since 1991, and the controversies began just as early. The first major controversy was the Tanenbaum–Torvalds debate in 1992, where computer science professor Andrew S. Tanenbaum and the computer science student began a heated discussion over kernel architecture and design, where Torvalds had to defend his kernel design against another well-regarded kernel developer who claimed that “Linux is obsolete” (Dibona et al. 102-22). This is one of the great debates he has been in, but controversies continued as he had to make decisions about source control that maintains a history of written code and holds contributors accountable, and decisions about other programming languages interacting with the kernel. Torvalds is no stranger to heated debates about the direction he leads the project in and he must take an all-or-nothing stance to maintain credibility over the Linux Kernel.

The controversy facing Torvalds and Linux Kernel today is the use of AI, specifically the use of Large Language Models (LLMs) which produce machine-generated text and by extension machine-generated code. Torvalds is known to be a very pragmatic engineer who believes in tools that assist people in getting something done. Even as technology has changed, he has had a progressive stance about technology, which keeps the Linux Kernel competitive with other kernels like the Windows NT kernel used in Microsoft operating systems (OSes) and the X is Not Unix (XNU) kernel used in macOS operating systems. AI tools can assist programmers in many ways, they can write code, review code (static analysis), find bugs, provide context, write documentation, and write summaries for patch reports used in source control programs. These tools have positives and negatives when used to write programs, it can be very efficient to have entire programs or repeated code (boilerplate) generated for a developer, but that comes at the cost of code-attribution and unintended bugs.

Torvalds has addressed the concerns of AI-use for contributors and maintainers of the project, and declared his stance publicly:

Yes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area

where I'm willing to absolutely put my foot down as the top-level

maintainer.

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. (Torvalds, “Re: Linking Patchwork with Sashiko?”)

Torvalds makes it clear that being pro-AI is his stance going forward with the project, allowing AI to be used all throughout the project such as code generation and use of AI tools. He states that those who are against AI-use should “fork” it, which means that other developers will take Torvalds’ kernel and try to maintain it themselves without his guidance. This is a definitive stance he takes but doesn’t address the fragmentation of open-source projects nor the issues of AI-use within his own project. Fragmentation is where open-source projects are forked and may become new projects themselves, fragmenting effort of developers between projects that have different ideals but seek to reach the same goal. Forking is good for software freedom, but distributed effort among developers harms progress in the fast-paced technological world.

        Open-source guidelines from other projects and foundations have already chosen a different role for AI-use in their projects. Kate Holterhoff compares the policies of eighty-eight organizations and found that only five out of the eighty-eight do not have a current policy on AI-use. Clearly setting a policy on AI-use is important, but forty-eight of those companies take a permissive stance on AI whereas only twenty ban AI-use outright. Of those forty-eight that enacted a policy, only thirteen do not require AI-use to be disclosed. However, of the companies that disclose a concern over how AI is used, very few have low concern over the copyright and licensing issues that may arise. Copyright and attributing AI-use should be a greater concern to these companies, but especially so for the Linux Kernel.

Code-attribution is crucial to legal liability in open-source projects such as the Linux Kernel. Open-source means the code can be viewed and contributed to by the general public, which means the code could be used for other projects. Due to this, there are a multitude of licenses for open-source projects, which can extend beyond code and target creative works like 3D models, videos, images, and more. These licenses can grant usage rights, relicensing, commercialization, and attribution requirements (Free Software Foundation). Code-attribution is specifically important when including third-party code in the kernel. Generally this is not a big deal when a license is included in software a developer intends to re-use, but ultimately bad when an LLM is trained on sections of licensed code available online where no attribution can be attached to code the LLM eventually generates. This is a major downside to AI-assisted code generation, as a license conflict can stall the project until the violation is removed, stalling projects and their progress.

Someone who is for AI code generation might argue that since code follows a strict syntax (grammar), AI-generated code can be impossible to detect and may be used by contributors anyway. It is true that AI-generated code can be difficult to identify, but not having guidelines restricting AI-use to tools may open the project to legal consequences if the generated code doesn’t have an attribution. One case of these software license violations involving a large lawsuit was Entr’ouvert v. Orange S.A., where European telecommunications company Orange S.A. had to pay the software company Entr’ouvert over €900,000, which is more than $1,000,000 (as of July 2026) due to a violation of the General Public License version 2 (GPL-2.0) (Stevenson and Lee). This is the same license the Linux Kernel uses which exposes the kernel to similar legal risks (The Kernel Development Community). Therefore, it is important to hold contributors accountable regardless if they do or do not use machine-generated code, as anyone can make a contribution, anyone can mis-attribute code which could lead to a situation where the Linux Kernel Organization is sued. The organization would not be able to handle such a large lawsuit, as the organization is a 501(c)(3) non-profit (The Linux Foundation). However, a credible maintainer who utilizes code-generation tools may end up generating code that lacks an attribution making it difficult to maintain credibility. The Linux Kernel has a guideline to address “the evolving role of AI in the development process,” which uses the “Assisted-by” tag to attribute AI-generated code (“AI Coding Assistants”).

There is a problem with machine-generated code and it goes beyond code-attribution, it is the “AI slop” phenomenon. AI has a large pitfall when it comes to understanding abstract concepts like a software engineer can, where AI confidently assumes it understands what it is writing when it can be wrong. These abstract concepts such as multithreaded locking, system architecture, global reasoning, and object ownership are some concepts that AI can struggle to understand, they are similar to orchestrating shipping and freight in logistics (Osborn). This is how AI may be able to generate code that appears correct and passes tests, but causes a difficult to pinpoint issue when the program is run. If the software runs, the code may present a security vulnerability that may not be found by the contributors until a security researcher uncovers the issue, or even worse a malicious hacker discovers and exploits the issue on existing systems. This primarily refers to the higher quality AI contributions, but lower quality contributions exist that consume the time of low-paid or volunteer kernel contributors.

On the upside, there are positive reasons to have AI-tools assist developers, and those tools help with reviewing code. This is because these tools don’t add code to the project, they produce output separate to the kernel and assist developers in understanding and checking code. These tools are able to read and match up the thousands of source code files in the project files (source tree), giving out useful summaries and documenting where a line of code leads and what output it produces from the inputs given. Although AI may produce deceptively accurate code, they are still able to review newly-written code and offer advice on modifications and changes to make. A software engineer must still take the LLMs’ output and decide whether or not to go forward with modifications suggested, rather than to blindly generate code from scratch.

In fact, there have been recent advances in AI-tools when it comes to security research. “AI compresses what used to take human analysts days or weeks of manual excavation into minutes,” when it comes to sifting through and comparing contributions (Ulac). The contributions are known as patches, while the comparisons between patches are known as diffs or diffing. Patch diffing helps reverse engineer old insecure code and determine how threat vectors are minimized with new code. In the past, reviewing these contributions required manual review of patches, which included following references to other patches, understanding the code, and reading the e-mails sent between contributors (referred to as the mailing list). This manual review took a large amount of time which created friction for security researchers. AI-tools don’t experience these same frictions and can replace the limited human talent available. This automated review is drastically changing the timeframe to perform security research and reveal security vulnerabilities (Ulac).

Nebula Security is an example of a security research team already utilizing AI-tools. They have recently discovered a fifteen-year-old vulnerability affecting nearly all systems using the Linux Kernel that gives an attacker the ability to secure total control over the system. This is one of the many recent examples of AI-tools being used for good contributions to the Linux Kernel. This specific vulnerability exemplifies the difference between code-review and code-contribution, as this vulnerability takes advantage of the system of locks in software. These complex locks display AI’s ability to brute-force and discover a way to exploit a system, but not have the aptitude to develop a vulnerability free code-contribution (Osborn).

Therefore the short-term conveniences of AI-generated code do not outweigh the consequences, contributors must consider sticking to solely human developed code. Doing so will protect the integrity and credibility of the Linux Kernel, otherwise the security vulnerabilities and legal conflicts will have severe consequences for the future of the project. AI-tools on the contrary have already shown how much more beneficial they are in comparison. The Linux Kernel is a trusted and verified software project vital to the global infrastructure, and it is important to keep it one of the leading projects in the forefront of technology to preserve system stability. It will be important to remain cautious of new technology that seeks to replace the trusted software engineers and maintainers that keep the world’s systems going.

Works Cited

“AI Coding Assistants.” Kernel.Org, 2026, https://docs.kernel.org/process/coding-assistants.html. Accessed 27 July 2026.

Dibona, Chris, et al. Open Sources: Voices from the Open Source Revolution. O’Reilly, 1999, pp. 102–22.

Free Software Foundation. “What Is Free Software?” Gnu.Org, 2 Feb. 2021, https://www.gnu.org/philosophy/free-sw.html. Accessed 27 July 2026.

Holterhoff, Kate. “The Generative AI Policy Landscape in Open Source.” RedMonk, 26 Feb. 2026, https://redmonk.com/kholterhoff/2026/02/26/generative-ai-policy-landscape-in-open-source/.

The Kernel Development Community. “Linux Kernel Licensing Rules.” Kernel.Org, 2025, https://docs.kernel.org/process/license-rules.html.

The Linux Foundation. “The Linux Kernel Archives - About.” Www.Kernel.Org, 6 Aug. 2024, https://www.kernel.org/category/about.html. Accessed 28 July 2026.

Nebula Security. “IonStack Part II: GhostLock, a Stack-UAF That Has Existed in ALL Linux Distributions for 15 Years.” Nebusec.Ai, Nebula Security, 7 July 2026, https://nebusec.ai/research/ionstack-part-2/.

Osborn, Jeremy. “AI Didn’t Make Programming Easier. It Just Made It Differently Difficult.” Acm.Org, Communications of the ACM, 14 July 2026, https://cacm.acm.org/opinion/ai-didnt-make-programming-easier-it-just-made-it-differently-difficult/. Op-ed.

Stevenson, Christopher, and Victoria Lee. “Wake-Up Call for Open Source Users: French Court Awards Damages for GPL Violations in Entr’Ouvert V. Orange.” Dlapiper.Com, 5 Mar. 2024, https://www.dlapiper.com/en-us/insights/publications/2024/03/wakeup-call-for-open-source-users-french-court-awards-damages-for-gpl-violations. Accessed 28 July 2026.

Torvalds, Linus. “Re: Linking Patchwork with Sashiko?” Linux Kernel Mailing List, 14 July 2026, https://lore.kernel.org/linux-media/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/.

---. “Re: Userspace Breakage.” Linux Kernel Mailing List, 29 Dec. 2005, https://yarchive.net/comp/linux/gcc_vs_kernel_stability.html.

Ulac, MaK. “How AI Is Shrinking Linux’s Security Patch Window.” Linux Security, 27 July 2026, https://linuxsecurity.com/features/ai-is-shrinking-linux-security-patch-window.

Watkins, Don. “11 Surprising Ways You Use Linux Every Day.” Opensource.Com, 30 Aug. 2019, https://opensource.com/article/19/8/everyday-tech-runs-linux.