Should Legacy Open‑Source Projects Embrace AI‑Generated Code?

Zero tolerance for AI

Drew DeVault, a long‑time Vim user and Wayland ecosystem contributor, published a blog post titled “Vim’s Obituary” in which he declared the Vim project “dead” because of the growing amount of AI‑generated code he calls “slop”. He argues that AI‑generated contributions pollute Vim not only technically but also environmentally, ethically, and politically: data centers consume about 1.5% of global energy, chip demand raises mortality risk for African miners, and AI‑generated misinformation fuels fascism.

DeVault therefore created a fork called Vim Classic , based on Vim 8.2.0148 (the last version before Vim 9 Script). The project’s CONTRIBUTING.md contains a strict rule: no AI‑generated code is accepted . He hosts the code on SourceHut, back‑ports a few CVE patches, and welcomes human‑written patches only.

Similar bans have been adopted by other small projects: Redox OS (a Rust‑based microkernel) announced a prohibition on LLM‑generated code and introduced a Developer Certificate of Origin (DCO) mechanism; the SDL library explicitly rejects AI code, citing insufficient traceability, unclear licensing, and uncontrolled review costs. Earlier, projects such as NetBSD, GIMP, Zig, and QEMU also announced comparable policies.

Pragmatism above all

In contrast, a survey by researcher Phil Eaton in March 2026 examined 112 major open‑source projects and found that roughly 63% already accept AI‑assisted contributions when they are clearly labeled. Notable examples include the Linux kernel, Chromium, and Kubernetes. The Linux community, in particular, endured a lengthy internal debate before reaching a consensus on AI contributions.

In late 2025, Nvidia engineer Sasha Levin submitted a patch to Linux 6.15 where the code, commit message, and test cases were all generated by an AI. Levin performed the review and testing himself but did not disclose the AI involvement. When maintainers discovered the undisclosed AI origin, the Linux Kernel Mailing List (LKML) erupted in controversy.

Policy experiment’s unexpected conclusions

In January 2026, the LKML debate intensified. Intel’s Dave Hansen and Oracle’s Lorenzo Stoakes clashed over how the kernel should regulate AI tools. The core issue extended beyond “whether to allow” to a legal dilemma: the DCO requires contributors to certify that they have the right to submit the code, yet LLMs are trained on massive corpora that include licensed open‑source code, making it impossible for a user of tools like Copilot to guarantee clean provenance.

Red Hat’s analysis warned that ignoring this issue could lead the kernel community to unintentionally violate open‑source licenses and undermine the DCO framework.

On 12 April 2026, Linus Torvalds concluded the debate by merging the first AI‑code contribution policy document coding-assistants.rst, which codifies three core rules:

Signed‑off‑by must be a human : AI agents cannot use this legally binding tag.

Assisted‑by annotation required : contributors must specify the model and tool, e.g. Assisted-by: Claude:claude-3-opus sparse.

Human bears full legal responsibility : including review duties, license compliance, and liability for any bugs or security issues.

Linus emphasized that AI should be treated merely as a tool, likening bans on specific AI tools to bans on a particular brand of keyboard—meaningless in practice.

Scale brings responsibility

Anthropic researcher Nicholas Carlini conducted an experiment using Claude Code to scan the entire Linux kernel source tree for vulnerabilities. In 90 minutes, the AI identified five remotely exploitable kernel bugs, four of which were previously unknown. One critical bug lay in the NFS v4.0 driver: the kernel attempted to copy a 1056‑byte Owner ID field into a 112‑byte static buffer, causing a heap overflow.

Carlini’s workflow perfectly matched the new Linux policy: AI generated the findings, humans performed the review, and the contribution was marked with an Assisted‑by tag. However, the result raises a provocative question—if AI can uncover decades‑old vulnerabilities in minutes, how much protection does human review actually provide? Carlini suggests that the value of review may lie more in assuming responsibility for discovered bugs than in detecting them.

He also notes that hundreds of potential vulnerabilities are now being catalogued by AI, awaiting human verification and assignment. This could turn human review into a largely ceremonial task rather than an effective security barrier.

The differing stances ultimately reflect project scale and governance structure. Small projects like Vim Classic or Redox can enforce strict bans because a single maintainer can bear the cost. Large projects such as Linux, Chromium, or Kubernetes, with millions of lines of code and thousands of contributors, cannot realistically revert to a “no‑AI” stance without jeopardizing development velocity and community growth.

Thus, the open‑source community’s split over AI‑generated code is fundamentally a question of scale and the extent to which a project is willing to assume responsibility for the consequences of AI‑assisted contributions.