Linus Torvalds considers AI-generated code legitimate when the contributor knows how to read it. His reported position shifts the test away from whether an AI tool participated and towards whether a person can understand the resulting contribution, according to Next INpact’s account of the Linux kernel debate.
For SME leaders buying software or approving AI coding tools, that distinction addresses a precise need: deciding what evidence makes an AI-assisted change reviewable. A disclosure label identifies tool involvement. It does not establish that the developer understands the code, that a reviewer has examined its behaviour or that the change works as intended.
AI labels track disclosure, not readability
The Linux discussion initially focused on marking contributions produced with large language models. Sash Levin, an NVIDIA developer and co-maintainer of long-term-support kernel releases, proposed a Co-developed-by label in July 2025; the wording later became Assisted-by, as reported by Next INpact.
The proposal gained support and was adopted at the Maintainers Summit in 2025. Guidance on coding assistants subsequently entered the documentation for Linux 7.0, while Torvalds questioned whether the kernel documentation should take a position on the practice, according to the same report.
These two mechanisms answer different questions. Assisted-by records declared assistance. Reading the code tests whether a contributor can examine the actual output. A label therefore provides provenance information, but it cannot serve as evidence of comprehension or quality on its own.
Conceptual illustration: an assistance label records declared provenance without demonstrating readability.
Torvalds puts comprehension at the centre
Torvalds’ position, as characterised by Next INpact, is not a blanket rejection of AI-generated code. He has also said that maintainers generally regard AI as useful when applied correctly and did not want automated reports rejected solely because of their origin. At the same time, he criticised the volume of low-quality bug reports produced by automated tools, the report explains.
The mechanism is straightforward: the generated patch still has to become intelligible human work. A developer who can follow its control flow, dependencies and failure conditions can discuss it with a reviewer and revise it. Merely naming the generating tool does none of those things.
This is distinct from demonstrating that AI improves development. Torvalds’ reported acceptance defines a condition for considering a contribution; it does not measure productivity, defect rates or maintenance costs. Nextis AI’s earlier examination of bounded AI coding workflows addresses a related distinction between showing that an agent can modify code and proving that the workflow performs reliably.
Conceptual illustration: reviewability depends on understanding the resulting code, not merely identifying its generator.
Kernel figures reveal the disclosure gap
The label also provides an incomplete count of AI involvement. Jonathan Corbet’s account of a Maintainers Summit, relayed by Next INpact, states that Linux 7.3 contained 18,533 changes at that point and that 10% of patches carried the Assisted-by mention. Corbet added that the real number of LLM-assisted patches was surely higher.
That gap limits what the visible label can establish. It identifies declared cases, not the full population of assisted work. It also groups together contributions without showing how the model was used: generating an initial patch, suggesting a correction, explaining existing code or editing documentation are materially different activities.
The source provides no comparison between labelled and unlabelled patches. It reports neither acceptance rates nor defect outcomes for either group. The figures therefore show adoption of a disclosure convention and its incomplete coverage, not the quality of AI-assisted contributions.
Make readable output the procurement test
For an SME evaluating an AI coding tool, the directly supported lesson is narrower than a general endorsement. Require the person submitting a change to explain what it does, identify the affected components and respond to review questions. Those actions test the condition at the centre of Torvalds’ position without treating the presence or absence of a label as a quality score.
Consider a hypothetical internal pricing automation. If an AI assistant rewrites its discount logic, recording AI assistance documents provenance. The operational decision still depends on whether the developer can trace how customer inputs produce a price, explain exceptional paths and revise the change when a reviewer finds an error.
The announcement does not establish that AI-written code is safer, faster or cheaper. It establishes a more precise boundary: generation method is not, by itself, a reason to exclude a contribution, while human readability remains essential. The next evidence to watch is a comparison of review outcomes for assisted and non-assisted patches; the current source provides no such result.
