Why 80+ Node.js Core Developers Are Petitioning to Ban AI-Generated Code

Last week a petition titled “Petition to Node.js TSC: No AI code in Node.js Core” circulated among developers, initiated by former TSC member Fedor Indutny and backed by more than 80 well‑known contributors such as Kyle Simpson and Andrew Kelley. The petition asks the Node.js Technical Steering Committee to prohibit AI‑generated code in the core project.

The controversy began with a pull request (PR) submitted by Matteo Collina, a core maintainer and creator of Fastify and Pino. In January he opened a PR adding a virtual file system (VFS) to Node.js, which contained roughly 19,000 lines of code. Collina openly admitted that he used a large amount of Claude Code tokens to produce the changes.

The sheer size of the PR created a massive review burden. Estimates suggest that a reviewer would need about three months of full‑time review to handle that amount of code. In practice the PR stayed open for over two months, underwent 128 review cycles and generated 108 comments, and has not yet been merged.

Legal uncertainty also surfaced. Contributors to open‑source projects sign a Developer Certificate of Origin (DCO), asserting that the code is either written by them or comes from a properly licensed source. AI‑generated code raises the question of provenance, since large language models are trained on vast amounts of existing code whose copyright status is ambiguous. Although OpenJS Foundation lawyers claim there is no problem, many developers remain skeptical.

Beyond legal and logistical issues, the petition raises a philosophical question about “who is contributing.” Open‑source culture relies on an unwritten social contract: contributors write code, reviewers provide feedback, and both parties learn and build trust. If the code is produced by an LLM, reviewers spend time pointing out problems without gaining any learning benefit, which the petition describes as “repetitive waste.”

Economic barriers are another concern. Using tools like Claude Code incurs costs; if AI‑generated contributions become commonplace, reviewers would need to purchase the same tools to verify and reproduce changes, creating an implicit financial gate that contradicts the open‑source principle of equal participation.

Opponents of the petition argue that code quality, not the tool used, should be the sole criterion. They claim that whether code is written by a human or an AI is irrelevant if the code works and meets standards. Some also point out the practical difficulty of enforcing a ban: without explicit disclosure, it is impossible to detect AI‑generated contributions, rendering any rule ineffective.

James Snell, a TSC member, defended Collina in the PR comments, emphasizing Collina’s long‑term commitment and trustworthiness, and suggesting that the tool used should not diminish the value of his work.

The debate is not limited to Node.js. Similar discussions have emerged in the Linux kernel community, QEMU, Python, and Rust projects, with some projects adding explicit commit messages to signal AI involvement. Collina himself opened an issue in the OpenJS Foundation titled “Is AI‑assisted development allowed?” indicating a desire for clear community consensus.

Another core contributor, Stephen Belanger, posted his own VFS experiment in the same PR, also noting extensive LLM assistance, confirming that AI assistance has been present in the core team for some time, albeit previously undisclosed.

For ordinary developers, the outcome of this discussion could affect how they contribute to open‑source projects. If major projects impose restrictions on AI‑generated code, developers who rely on tools such as GitHub Copilot, Cursor, or Claude Code will need to be more cautious and may face ambiguous boundaries between “assist” and “generate.” Conversely, a lack of restrictions could flood projects with AI‑produced code, dramatically increasing reviewers’ workload and risking burnout.

Rather than a binary “ban or allow” stance, the article suggests a graded approach: require clear labeling of AI‑assisted PRs, limit the amount of code submitted in a single PR, and ensure contributors can explain the intent behind each change. This balances the benefits of AI assistance with the need for transparency and manageable review loads.

Ultimately, the core value of open‑source communities lies not only in the code but also in the collaborative trust between people. AI can accelerate development, but it cannot replace the social relationships that underpin open‑source projects. Finding a balance between efficiency and trust will be a lasting challenge for all open‑source ecosystems.