19.000 Zeilen Claude Code haben eine Unterschriftensammlung von hunderten Personen für ein "Boykott" ausgelöst. Kernmitglieder von Node.js haben einen Antrag gestellt: Die AI-unterstützte Entwicklung sollte im Projekt verboten werden.

Bei der Verwendung von KI für das Codieren hat die Kontroverse nie wirklich aufgehört. Diesmal hat sich der Streit auf eine der zentralsten Infrastrukturen ausgeweitet – Node.js.

In letzter Zeit hat eine Petition an den Node.js Technical Steering Committee (TSC) breite Aufmerksamkeit erregt. Innerhalb weniger Tage haben sich bereits über hundert Open-Source-Entwickler, Frontend-Engineer und Programmierer unterzeichnet. Sie fordern, dass "die Node.js-Community den Zugang von KI-generiertem Code in das Kern-Repository verbieten sollte", was die internen Differenzen in der Community endgültig ans Licht bringt.

Was diese Kontroverse angeht, halten einige es für eine Haltung, die auf die Qualität des Codes setzt, während andere es als panische Reaktion auf technologischen Fortschritt betrachten.

Ein PR mit 19.000 Zeilen Code, generiert von Claude Code

Wenn man sich die Entstehung des Ereignisses anschaut, beginnt alles mit einem Code-Eintrag im Januar 2026.

Matteo Collina, Mitglied des Node.js Technical Steering Committee (TSC) und Betreuer des Fastify-Frameworks, hat damals, um die von der Community lange erwartete Funktion des virtuellen Dateisystems (VFS) für Node.js hinzuzufügen, einen Pull Request (PR) mit etwa 19.000 Zeilen Code eingereicht, der etwa 80 Dateien umfasst.

Dafür hat er auch einen ausführlichen Artikel namens "Warum Node.js ein VFS benötigt" veröffentlicht, in dem er ausführlich auf die Probleme eingeht, die Node.js ohne ein virtuelles Dateisystem hat. Beispielsweise müssen bei der Verpackung einer Anwendung als einzelne ausführbare Datei viele zusätzliche Ressourcen beigefügt werden, es ist nicht möglich, ein konsistentes Speicherdateisystem wie im Modulsystem in Tests zu erhalten, die Isolation in einem Multi-Tenant-Umfeld hängt von fehleranfälligen Pfadprüfungen ab, und die dynamische Laden von generiertem Code zur Laufzeit kann nur über temporäre Dateien erfolgen.

Aktuell können bestehende Lösungen wie memfs und unionfs das Dateisystem (fs) nur wie mit einem "Band-Aid" simulieren und können nicht wirklich in den Modulauflösungsprozess integriert werden, was dazu führt, dass Aufrufe wie import() das VFS umgehen.

Nach Meinung von Matteo Collina hat die Community diese Anforderung bereits klar formuliert, aber es fehlt bisher an einer tatsächlichen Umsetzung.

Unter diesen Umständen hat er seit Weihnachten letzten Jahres mit der Entwicklung der VFS-Implementierung begonnen und im Januar diesen PR mit 19.000 Zeilen Code eingereicht.

Normalerweise hätte dies ein Grund zur Freude sein sollen, aber er hat in der PR-Beschreibung eine Haftungsausschlusserklärung hinzugefügt, die die Kontroverse entfacht hat:

Ich habe eine große Anzahl von Claude Code-Tokens verwendet, um diesen PR zu erstellen. Alle Änderungen wurden von mir persönlich überprüft.

Außerdem schrieb Matteo Collina in seinem Blog:

Was ursprünglich nur ein Urlaubsexperiment war, hat sich schließlich zu PR #61478 entwickelt: ein node:vfs-Modul für Node.js, das 66 Dateien umfasst und fast 14.000 Zeilen Code hat.

Ehrlich gesagt würde ein so großer PR normalerweise mehrere Monate Vollzeitarbeit erfordern. Dass ich ihn in den Ferien fertigstellen konnte, liegt daran, dass ich Claude Code verwendet habe. Ich habe die KI eingesetzt, um die langweiligen und repetitiven Teile zu bearbeiten – diese Arbeit hat es möglich gemacht, einen PR mit 14.000 Zeilen zu erstellen, aber niemand möchte das manuell schreiben: die Implementierung der verschiedenen Varianten jeder fs-Methode (synchron, Callback, Promise), die Einbindung in die Testabdeckung und die Generierung von Dokumentationen. Ich habe mich auf die Architekturplanung, die API-Entwicklung konzentriert und jede Zeile Code überprüft.

Ohne KI hätte dieses Urlaubs-Side-Project gar nicht möglich gewesen – es wäre einfach nicht passiert.

Es ist bekannt, dass Claude Code ein von Anthropic entwickeltes KI-Programmierungstool ist, das ein riesiges Kontextfenster von 200.000 Tokens hat und in der Lage ist, komplexe Logiken über mehrere Dateien hinweg zu generieren und sogar Code-Refactoring durchzuführen. Aber in einem Kernprojekt wie Node.js, das auf Millionen von Servern weltweit läuft, berührt KI-generierter Code offensichtlich die Grenzen vieler erfahrener Entwickler.

Für viele Entwickler ist das Problem nicht nur, dass Matteo Collina "KI verwendet hat", sondern auch, dass dieser PR sehr umfangreich ist, Kernmodule ändert, die Generierungsmethode undurchsichtig ist und es Fragen rund um die Urheberschaft des Codes gibt.

Deshalb hat dieser PR in den folgenden zwei Monaten bereits 128 Prüfungsversuche und 108 Kommentare erfahren, und seine Größe hat fast den normalen Peer-Review-Prozess lahmgelegt.

Stand 26. März 2026 wurde dieser PR noch nicht in die Hauptbranch integriert.

Von einem PR zu einer Diskussion über die "Verbietung von KI"

Die Eskalation dieser Kontroverse stammt von einer öffentlichen Petition, die Fedor Indutny, der Hauptautor des Node.js TLS-Moduls und ehemaliges Mitglied des TSC, auf GitHub gestartet hat: "Petition an den Node.js TSC: Verbieten Sie die Verwendung von KI im Kerncode."

In kurzer Zeit haben sich über 100 Kernentwickler, darunter Kyle Simpson, der Autor von YDKJS, und Andrew Kelley, der Vorsitzende der Zig Software Foundation, unterzeichnet.

Diese Petition besagt:

Node.js ist eine kritische Infrastruktur auf Millionen von Servern weltweit und unterstützt gleichzeitig die Befehlszeilentools, die Entwickler täglich nutzen. Die Verdünnung des über Jahre hinweg sorgfältig ausgearbeiteten Kerncodes mit KI-generiertem Code widerspricht der Mission und den Werten des Projekts und kann das auf öffentlichen Beiträgen gegründete Ansehen zerstören, das Node.js seinen heutigen Status und gesellschaftlichen Wert verschafft hat.

Zusätzlich listet diese Petition drei Kerngründe gegen KI-generierten Code auf:

Ethik: Hauptsächlich eingesetzte große Sprachmodellunternehmen verwenden bei der Trainingszeit unethische Datenquellen, darunter urheberrechtlich geschützte Werke und Open-Source-Code unter verschiedenen Lizenzen ohne Nennung der Quelle.

Bildung: Es gibt Beweise dafür, dass die Verwendung von großen Sprachmodellen den Lernprozess behindern kann. Da Open-Source-Projekte oft neue Mitwirkende aufnehmen, kann die Absenkung der Codequalitätsanforderungen die Einsicht in den Node.js-Kern schwächen und somit die langfristige Nachhaltigkeit des Projekts beeinträchtigen.

Darüber hinaus ist der Code-Review nicht nur dazu da, Bugs zu finden, Sicherheitslücken zu beheben und sicherzustellen, dass der Code den Stil und der Architektur des Projekts entspricht, sondern auch ein wichtiger Schritt, um die Mitwirkenden zu helfen, zu lernen und zu wachsen. Allerdings lernt das große Sprachmodell selbst nicht, was bedeutet, dass die Zeit, die für den Review aufgewendet wird, nicht in eine Verbesserung der Fähigkeiten der Mitwirkenden umgesetzt werden kann und somit immer wieder "verschwendet" wird.

Privileg: Die Verwendung von großen Sprachmodellen erfordert normalerweise ein bezahltes Abonnement oder die Investition in umfangreiche Hardware-Ressourcen für die lokale Ausführung (und die Qualität der Ausgabe ist oft schlechter). Daher sollte der generierte Code, der eingereicht wird, von den Reviewern reproduzierbar sein, und es sollte nicht erforderlich sein, dass sie Abonnement-Grenzen überwinden müssen, um die Ergebnisse zu überprüfen.

Gegensätzliche Ansichten

Sobald diese Petition veröffentlicht wurde, zeigten viele Internetnutzer ihre Unterstützung: "Die manuelle Prüfung von 19.000 Zeilen Code ist enorm anstrengend. Die Unterstützung durch KI kann die Anzahl und Größe der PRs vergrößern und schließlich das auf Freiwilligen basierende Review-System überlasten."

Es gibt auch viele Entwickler, die eine andere Meinung vertreten. James Snell, Mitglied des TSC, sagte: Das einzige Kriterium für die Beurteilung von Code sollte die Qualität sein, nicht das Entwicklungstool.

Matteo Collina, der Betroffene, hat in seinem Blog einen ausführlichen Artikel geschrieben, um hartnäckig zu antworten. Er hat die "Nudelmaschinen-Theorie" verwendet, um zu argumentieren: Meine Großmutter hat mit einer Nudelmaschine namens "Nonna Papera" Pasta gemacht – fast jede italienische Familie hat eine. Aber niemand würde deshalb sagen, dass es nicht ihre Pasta ist. Sie hat das Mehl, die Eier ausgewählt und die Dicke und Form entschieden. Das Werkzeug hat ihr nur geholfen, die Pasta zu machen. Genauso habe ich die Architektur entschieden, die API entworfen und jede Zeile Code überprüft. Dieser Code gehört mir.

Er betonte weiter: Das DCO (Developer Certificate of Origin) hat nie darauf geachtet, wie der Code geschrieben wurde, sondern nur darauf, ob der Mitwirkende das Recht hat, ihn einzureichen und die Verantwortung zu übernehmen. Dies unterscheidet sich nicht von der Annahme von jedem Open-Source-Beitrag.

Was die nächsten Schritte angeht, sagte Matteo Collina: "Der Node.js TSC wird bald über die Offenlegung und Namensnennung von KI-unterstützten Beiträgen abstimmen. Die Gemeinschaft ist sich einig: Die verantwortungsvolle Aufnahme von KI-unterstützten Beiträgen kann die Entwicklung von Open-Source-Projekten beschleunigen; die bloße Verbietung von KI-Tools wird nur die Anzahl der Mitwirkenden einschränken. Die wichtigste Rolle in der Softwareentwicklung hat sich nie geändert – es ist nicht derjenige, der den Code schreibt, oder das Tool, sondern derjenige, der den Code versteht, überprüft und für ihn verantwortlich zeichnet."

Deutlicher Kontrast: Der KI-Sieg im Linux-Kernel, "Müll"-Berichte werden über Nacht zu "Gold"

Interessanterweise, während Node.js wegen KI-generiertem Code in die Diskussion gerät, erlebt die Linux-Kernel-Community ihren "Wow-Moment" mit KI.

Laut einem Bericht der britischen Website The Register hat Greg Kroah-Hartman, ein Kernbetreuer des Linux-Kernels, auf der KubeCon Europe angegeben, dass die Anwendung von KI im Linux-Kernel in einer Nacht von "Müll" zu "Gold" umgewandelt wurde.

Vor Februar 2026 hatte die Linux-Kernel-Community noch mit "AI Slop" (KI-Müll) zu kämpfen – die von KI generierten Sicherheitsberichte waren voller offensichtlicher Fehler und hatten keinen Bezugswert. Wie Greg sagte, "war es ein bisschen lustig, man muss sich nicht wirklich Sorgen machen".

Dies war auch die Norm in der gesamten Open-Source-Szene damals: Daniel Stenberg, der Schöpfer von cURL, hat einmal gemeckert, dass AI Slop die Effizienz des Bug-Bounty-Programms drastisch gesenkt hat, und schließlich hat er im Januar 2026 dieses seit sechs Jahren laufende Programm direkt gestoppt; Das Ghostty-Projekt hat im selben Monat eine Null-Toleranz-Politik eingeführt, und die Einreichung von KI-Müllcode führt zu einer dauerhaften Sperre.

Aber Februar 2026 war ein entscheidender Wendepunkt für KI. Greg gestand, dass er "nicht weiß, was passiert ist, die Welt hat sich plötzlich verändert": Die einstigen KI-Müllberichte sind über Nacht zu hochwertigen und effektiven Berichten geworden. Nicht nur der Linux-Kernel, sondern alle Open-Source-Projekte erhalten nun "echte Bugs und echte Vorschläge", die von KI generiert wurden.

Noch erstaunlicher ist, dass diese Veränderung kein Einzelfall ist. Nach privaten Gesprächen der Sicherheitsteams verschiedener Open-Source-Projekte haben alle dasselbe KI-Upgrade erlebt, aber niemand kann genau sagen, warum – hat das KI-Tool plötzlich sich verbessert, oder haben die Entwickler effizientere Nutzungsmethoden erlernt?

Gregs eigenes Experiment hat die Stärke von KI bestätigt: Er hat KI mit einem einfachen Hinweis dazu gebracht, den Kernel-Code zu analysieren, und die KI hat sofort 60 Probleme und Lösungsvorschläge ausgegeben. Zwei Drittel der Patches waren direkt einsetzbar, und die verbleibenden Drittel, obwohl fehlerhaft, haben auch echte Probleme aufgedeckt. Diese Patches können mit einfacher manueller Optimierung in den Kernel-Entwicklungsprozess integriert werden, und die Effizienzsteigerung ist augenscheinlich.

Heute ist in der Linux-Kernel-Community die Frage nicht mehr, "ob" KI verwendet werden soll, sondern "wie" sie besser verwendet werden kann. Derzeit übernimmt KI hauptsächlich die Rolle eines Code-Review-Assistenten und ist noch nicht der Hauptautor des Kerncodes, aber die Grenze zwischen beiden verschwimmt: Die Community hat bereits das Label "co-develop" eingeführt, um KI-unterstützte Patches zu kennzeichnen; In einfachen Szenarien wie Fehlersuche und Bedingungsüberprüfung kann KI bereits mehrere einsetzbare Patches generieren und ist somit vollkommen für die grundlegende Entwicklung geeignet.

Abschluss

Ob die Kernentwickler von Node.js eines Tages wie Greg Kroah-Hartman von der Leistung von KI überrascht werden, ist derzeit schwer vorherzusagen.

Eines ist sicher: Fast alle etablierten Open-Source-Projekte werden früher oder später dieselbe Herausforderung haben: Die KI wird nicht stehen bleiben, und die Codeproduktion wird immer schneller werden. Derzeit ist es nicht praktikabel, KI einfach zu verbieten. Der Schlüssel liegt darin, die Codequalität zu kontrollieren und sicherzustellen, dass jeder Codezeile eine zuverlässige manuelle Prüfung zugrunde liegt.

Schließlich: Wie viel von dem Code,