Linus Torvalds's first LLM-assisted patch series
A leading Linux kernel maintainer has used an LLM coding assistant to draft a performance‑oriented patch series, prompting debate over how AI‑generated code fits into long‑standing norms around code review, copyright, and open source licensing. Commenters weigh the practical gains in productivity and code exploration against concerns about quality, overreliance on proprietary AI services, environmental and societal impacts, and the long‑term maintainability of critical infrastructure increasingly touched by machine‑generated code.
Overall reaction to LLM-assisted kernel patches
- Many are unsurprised that a highly pragmatic maintainer would adopt LLMs, given a shift toward review/management over hands‑on coding.
- Others are surprised, seeing this as a break from a perceived “old school” image and prior hostility to things like C++ in the kernel.
- Some worry this will be misused as “if it’s good enough for the kernel, it’s good enough anywhere,” ignoring the expertise and review behind it.
Quality, reliability, and review
- Strong emphasis that LLM output is acceptable only with expert review, tests, and small, understandable patches.
- Commenters note that LLMs often produce code that appears correct but contains subtle bugs (e.g., race conditions).
- Distinction is drawn between using AI as a coding assistant vs. delegating entire complex programs and doing only superficial review.
Copyright and licensing questions
- One line of argument: machine‑written code is uncopyrightable, therefore cannot be “open source” and should be excluded from the kernel.
- Counterarguments:
- Public domain or CC0 content can legally coexist with copyleft licenses.
- Small amounts of uncopyrightable or PD code are common and not inherently “poisonous.”
- A separate thread cites pre‑LLM case law and US Copyright Office positions that only humans can hold copyright, reinforcing the “human in the loop” requirement.
- Long‑term concern: if too much of a codebase is effectively uncopyrightable, its legal status might become murky.
Closed vs open models
- Some are disappointed that a flagship FOSS project used a proprietary assistant rather than open‑weights models.
- Others argue current open models are still notably weaker for complex systems programming.
- The prevailing justification is strict pragmatism: pick the tool that works best, regardless of openness.
Broader attitudes toward AI in software
- Supporters: see rapid improvements, real productivity gains, and view AI‑assistance in critical infrastructure as inevitable.
- Skeptics:
- Worry about “slopware,” environmental impact, data‑center expansion, and long‑term societal effects (jobs, surveillance, deepfakes).
- Some discuss boycotting AI‑assisted projects or seeking “AI‑free” OSes.
- Several comments reject culture‑war framing, distinguishing between using AI responsibly and abusing it.