In May 2026, reports emerged that Linux kernel maintainers were struggling with a new kind of workload: a flood of AI-generated bug reports sent to the kernel’s private security mailing list. Linus Torvalds was quoted as saying the list had become “almost entirely unmanageable.”
The issue soon grew beyond the quality of individual reports. Developers began debating whether Linux should prohibit AI-generated code from entering the kernel at all. After months of argument, Torvalds offered a characteristically practical answer: AI is not something the project needs to oppose on principle. It is a tool, and the code still has to survive review.
When automated bug hunting becomes a maintenance problem
Several research teams have been using AI tools to scan the Linux kernel for possible vulnerabilities. The results were then submitted to the security mailing list, often without enough filtering or refinement beforehand.
The problem was not simply that some reports were wrong. Many were duplicates. Different teams, sometimes using different models, repeatedly identified the same code or raised the same suspicion about a possible flaw. Maintainers were left to sort through a large volume of reports with widely varying levels of quality, looking for the small number that might actually matter.
That kind of material is often described in English as AI slop. The term refers to content produced in bulk, with little checking or editorial effort. It is not quite the same as spam: spam usually implies deliberate abuse, while slop can be generated carelessly or in good faith. The practical result, however, can be similar. People are overwhelmed by material they did not ask to process.
The security-list problem was therefore a question of signal quality and maintainer time. It did not, by itself, prove that AI-generated code should be banned. But it created the conditions for a much broader argument.
Should Linux ban AI-written code?
Once people began discussing AI-generated bug reports, the next question was almost inevitable: if AI output is so unreliable, should the kernel simply reject code written with AI assistance?
The arguments in favor of a ban were straightforward. AI systems can produce incorrect code, invent functions or APIs that do not exist, and conceal serious mistakes behind plausible-looking explanations. This phenomenon, commonly called hallucination, would appear to create extra work for maintainers. A blanket prohibition might seem like the simplest way to avoid the problem.
Opponents saw a different risk. A rule against AI-generated code would mainly affect developers who honestly disclosed that they had used such tools. Anyone determined to disguise AI-produced code as human-written could simply conceal its origin. The result could be a policy that punishes transparency while doing little to stop bad-faith behavior.
That split exposed the real disagreement. Was the origin of a patch the important thing, or was its technical quality?
Torvalds’ answer: use it, fork it, or leave
Torvalds’ comments, as reported publicly over several months, amounted to a rejection of the idea that Linux should become an anti-AI project. He did not argue that AI output should receive special treatment or automatic approval. Instead, he pushed reviewers back toward the project’s existing standard: examine the code and decide whether it is good enough.
In that view, reviewers should not spend their energy trying to determine whether every line was written by a person, generated by a model, or produced through a mixture of both. The relevant questions are whether the patch solves a real problem, whether the implementation is sound, and whether it has been properly reviewed.
The most memorable formulation was aimed at critics of the project’s direction: “use it, fork it, or leave.” Linux is open source. If someone dislikes the way the project is being developed, they can use the existing code, create a fork, or walk away. The phrase was not a technical policy for accepting bad patches. It was a blunt statement about how an open-source project sets its boundaries.
The broader message was that AI is simply another tool. Its existence does not remove the need for standards, and it does not justify creating a new category of code that is judged before anyone examines what it actually does.
Why that pragmatism makes sense
Torvalds’ strongest argument against an AI-code ban is also the most practical: rules mainly constrain people who are willing to follow them. Developers who openly say they used AI could be blocked or burdened by the policy, while developers who want to smuggle unreviewed AI output into the project would have an incentive to hide that fact.
That would produce a particularly bad outcome. The people acting transparently would face additional penalties, while the people trying to evade scrutiny would continue as before.
There is also a deeper reason to keep the focus on the patch itself. Open-source development has spent decades building systems designed to evaluate code rather than the identity or motives of the person who wrote it. A patch is accepted because it addresses a genuine problem, fits the architecture, is maintainable, and has received serious review. It is rejected when it fails those tests, regardless of whether the author used an editor, a script, a search engine, or an AI assistant.
That does not make the review process easy. In fact, AI may make it more demanding. When producing plausible code becomes faster and cheaper, the amount of code that needs to be evaluated can rise sharply. The answer is not to weaken review, nor to let a model make the final decision. It is to preserve the authority of review and apply it more carefully.
The same trap appears in developer communities elsewhere
The debate has a familiar shape in Chinese-speaking developer circles as well. Attitudes toward AI-assisted programming have swung between two extremes. One treats AI as a near-total replacement for ordinary development work. The other treats AI involvement as a kind of original sin, assuming that code created with model assistance is automatically inferior and that its author deserves less trust.
Although these positions appear opposed, they share the same mistake: they focus too heavily on how the code was produced and too little on whether it works.
A more useful approach is less dramatic. Put the code through the same technical review as everything else. Keep what is correct and maintainable; reject what is broken, confused, or poorly justified. This approach does not require blind faith in AI, and it does not allow dislike of AI to replace engineering judgment.
The production tool changes; the standard does not
AI affects the production side of software. It can make code appear quickly and reduce the cost of generating possible implementations. But speed is not the same as quality, and volume is not evidence of correctness.
The decisive question remains whether a change deserves to enter the project. That depends on the strength of the review culture: whether maintainers have the time and authority to examine patches, whether contributors respect that process, and whether technical standards remain more important than the novelty of the tool involved.
This is what Torvalds is ultimately defending. The threat is not that AI exists. The threat would be allowing fear of AI to weaken review, or allowing enthusiasm for AI to let models make decisions that belong to maintainers and developers.
The tools used to produce software have changed repeatedly—from patches exchanged through mailing lists, to Git-based workflows, to systems that can generate code on demand. The underlying rule has remained much more stable: code has to be examined before anyone can know whether it is good enough.