Ground Truth.
AI, checked against the source.

News · 2026-10-18

Torvalds rejects AI tool bans as Linux debates an assistance tag

Linus Torvalds rejected blanket rules against using artificial intelligence in an October 13 Linux kernel mailing-list reply, during a debate over removing an AI-assistance disclosure tag. His remarks defend judging contributors by their understanding and work, while the published kernel guide still calls for human review and responsibility. The exchange does not establish that the disclosure guidance has already been removed.

Key facts

Two arguments have been compressed into one headline

Torvalds wrote: “I don't understand this whole idiotic concept of ‘don't use AI for X’.” He compared prohibitions on using tools with absurd restrictions on compilers and editors, then argued that contributors should understand what they are doing regardless of the tools involved.

The forceful wording made an obvious headline. The surrounding discussion is more useful than a simple declaration that Linux accepts or rejects machine-written code. Maintainers were debating whether the project should continue asking contributors to identify AI assistance with a specific tag. A disclosure request and a prohibition on using a tool are different policies.

The October 9 proposal, discussed in contemporaneous mailing-list correspondence, said a Maintainers Summit consensus favored deprecating the tag. The proposal was real, and so was the disagreement. The kernel documentation available during dossier verification still contained the guidance, however, so the debate cannot be reported as a completed policy removal.

What the existing guide actually asks

The AI Coding Assistants guide assigns responsibility to the human submitter. Contributors must review generated code, ensure licensing compliance, sign off on their contribution, and take responsibility for it. The assistance tag is part of that accountability discussion, rather than a license to submit unexamined output.

A useful analogy is an engineering drawing prepared with design software. The tool can accelerate the drawing, but the engineer’s signature remains a statement about the work. A separate question is whether reviewers benefit from a note identifying which software helped. Torvalds’s argument emphasizes the first obligation; the disclosure debate asks how useful the extra note is.

This distinction becomes more important as assistance spreads across a workflow. A developer might use a model to explain an error, compare possible designs, draft a test, or write a patch. A tag that originally appeared to describe code generation may begin to cover a much broader set of activities. That creates a legitimate policy question about where disclosure should begin and what a reviewer can infer from it.

Maintainers disagree about the value of the signal

Kees Cook argued that broad use of language models in development could turn the tag into automatic boilerplate. Laurent Pinchart argued that disclosure could still help in intermediate cases. Their exchange presents the strongest competing positions: a ubiquitous label may convey little, while a reviewer may still need context about how a contribution was produced.

Other replies focused on the quality of submitted work. Mark Brown’s response distinguished questionable contributions with an AI-like character from every use of AI. Miguel Ojeda’s reply supported the proposal and discussed the tag’s practical frequency. Those messages establish disagreement among actual contributors, rather than an inferred consensus from social-media reactions.

Ground Truth previously covered Torvalds’s July position against an anti-AI stance. The October development adds a concrete documentation dispute. It should not be treated as the first time he has expressed a permissive view of the tools.

Responsibility remains the durable issue

For open-source projects, the operational question is how to preserve review quality when producing a plausible patch becomes easier. A label can help only if it changes what reviewers know or do. Removing a label can simplify process, but it does not remove the need for contributors to understand and defend their changes.

The strongest counterargument to a purely tool-neutral policy is that different production methods can create different review risks, including confidently presented mistakes and uncertain provenance. The strongest argument against broad disclosure requirements is that widespread assistance makes an undifferentiated label increasingly uninformative. The verified exchange exposes that tradeoff; it does not resolve it for every project, nor confirm that Linux’s published guidance has changed.


Primary source, verified: read the paper →

Key questions

Did Torvalds make the remark at a conference?

No. The verified remark is in an October 13 Linux kernel mailing-list reply.

Has Linux already removed Assisted-by guidance?

The dossier does not establish completed removal. The published coding-assistant guide reviewed still says contributions should include the tag.

Does using AI remove the contributor’s responsibility?

No. The kernel guide assigns human review, licensing compliance, sign-off, and responsibility to the submitter.
Cite this

APA

Ground Truth. (2026, October 18). Torvalds rejects AI tool bans as Linux debates an assistance tag. Ground Truth. https://groundtruth.day/news/torvalds-ai-tool-ban-assisted-by-disclosure-debate.html

BibTeX

@misc{groundtruth:torvalds-ai-tool-ban-assisted-by-disclosure-debate,
  title  = {Torvalds rejects AI tool bans as Linux debates an assistance tag},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {oct},
  url    = {https://groundtruth.day/news/torvalds-ai-tool-ban-assisted-by-disclosure-debate.html}
}

Topics: ai-coding · open-source · linux · governance

Comments are replies to this story on Bluesky — reply with any Bluesky account to join in.