Zig verbietet KI-Tools – Warum das Projekt auf Menschen setzt

Seit April 2026 verfolgt das Open-Source-Projekt Zig eine der strengsten Richtlinien gegen KI-Tools in der gesamten Softwarelandschaft. Die Entscheidung betrifft nicht nur den Code selbst, sondern die Art und Weise, wie Beiträge eingereicht und bewertet werden. Doch warum nimmt ein technisches Projekt eine so klare Haltung ein – und was bedeutet das für die Zukunft von Open Source?

Von Bun zu Zig: Ein Missverständnis mit Folgen

Im Dezember 2025 kündigte der JavaScript-Runtime-Anbieter Bun an, dass er sich dem KI-Infrastrukturanbieter Anthropic anschließt. Nur wenige Monate später, im April 2026, präsentierte das Bun-Team eine beeindruckende Leistungssteigerung: Eine vierfache Beschleunigung der Kompilierungszeit durch Anpassungen an den Zig-Compiler. Doch statt die technischen Details zu feiern, löste die Ankündigung eine kontroverse Diskussion aus. Denn das Bun-Team erklärte explizit, dass ihre Änderungen nicht in den offiziellen Zig-Compiler übernommen würden – nicht wegen technischer Hürden, sondern wegen der strengen KI-Politik von Zig.

Die Begründung sorgte für Verwirrung. Ein Kernmitglied des Zig-Projekts klärte später in einem Forum auf: Die geplante Parallelisierung der semantischen Analyse sei zwar ein langfristiges Ziel des Compilers, doch die tatsächlichen Gründe für die Ablehnung lägen tiefer. Die KI-Politik von Zig sei hier nur eine bequeme Erklärung für eine grundsätzliche Ablehnung gewesen. Doch unabhängig von der Darstellung – die Entscheidung wirft eine zentrale Frage auf: Warum verbietet ein technisches Projekt den Einsatz von KI-Tools in der Entwicklung?

Die KI-Politik von Zig: Mehr als nur ein Verbot

Die Richtlinie von Zig ist im Code of Conduct unter dem Abschnitt Strict No LLM / No AI Policy festgehalten. Die Kernaussage ist klar: Keine KI-Tools dürfen für Issues, Pull Requests oder Kommentare im Bugtracker verwendet werden – selbst nicht für Übersetzungen. Doch hinter dieser scheinbar technischen Regel verbirgt sich eine grundsätzliche Haltung.

Loris Cro, Vizepräsident der Zig Software Foundation und Autor der offiziellen Begründung, erklärt die Policy mit einem prägnanten Bild: „Beim Contributor-Poker setzt man auf den Spieler, nicht auf die Karten.“ Die Metapher verdeutlicht die Philosophie des Projekts: Zig investiert nicht in einzelne Code-Patches, sondern in die Menschen hinter den Beiträgen. Ein KI-generierter Pull Request mag zwar funktionieren, doch die Zeit, die Maintainer in dessen Review stecken, ist nicht in die persönliche Entwicklung des Beitragenden geflossen. Stattdessen wurde sie in die Bewertung einer maschinellen Lösung investiert – und das widerspricht dem Grundgedanken von Open Source.

Die Richtlinie ist keine Qualitätsfrage, sondern eine Frage der Gemeinschaft. Cro verweist auf konkrete Erfahrungen: „LLM-basierte Beiträge haben bei uns vor allem eines gebracht: eine Flut an wertlosen Pull Requests, die nicht einmal kompilieren, geschweige denn Tests bestehen.“ Zudem seien viele vermeintlich gute PRs erst nach eingehender Prüfung als KI-generiert entlarvt worden. Die Ablehnung von KI-Tools sei daher kein Vorwand, sondern eine bewusste Entscheidung, die Gemeinschaft zu schützen.

Wie andere Projekte mit KI umgehen: Von NetBSD bis Apache

Zigs Haltung ist kein Einzelfall. In den letzten Jahren haben mehrere bedeutende Open-Source-Projekte klare Positionen zu KI-generierten Beiträgen bezogen. Die Bandbreite reicht von strikten Verboten bis hin zu pragmatischen Kompromissen.

• NetBSD: Seit Mai 2024 gilt, dass von KI generierter Code als „verunreinigt“ eingestuft wird. Ohne vorherige Genehmigung durch das Kernteam darf er nicht in den Codebase übernommen werden. Die Begründung liegt in Lizenzrisiken: Trainingsdaten könnten mit inkompatiblen Lizenzen wie GPL kontaminiert sein.
• Gentoo: Im April 2024 beschloss das Projekt, Beiträge zu verbieten, die mit natürlicher Sprach-KI erstellt wurden. Die Entscheidung war vorbeugend und basierte auf Bedenken hinsichtlich Urheberrecht, Qualität und Ethik.
• curl: Seit Februar 2026 akzeptiert das Projekt keine KI-generierten Sicherheitsberichte mehr. Daniel Stenberg, der Maintainer, begründet dies mit einer ernüchternden Bilanz: In sechs Jahren waren etwa 20 % aller Sicherheitsmeldungen KI-generiert – doch keine davon enthielt eine tatsächlich verwertbare Schwachstelle.
• Apache Software Foundation: Hier ist der Einsatz von KI-Tools erlaubt, sofern dies transparent kommuniziert wird. Die Richtlinie des Legal Affairs Committee zielt darauf ab, Lizenzen klar zu halten und pragmatisch mit neuen Technologien umzugehen.

Diese unterschiedlichen Ansätze zeigen: Die KI-Debatte im Open Source ist kein technischer, sondern ein kultureller Konflikt. Während einige Projekte die Effizienz von KI betonen, setzen andere auf die menschliche Komponente – und damit auf die langfristige Stabilität ihrer Gemeinschaften.

Blick nach vorn: Was bedeutet das für die Zukunft von Open Source?

Die Entscheidung von Zig ist symptomatisch für eine wachsende Spannung in der Open-Source-Welt. Einerseits bieten KI-Tools wie LLMs die Chance, Einstiegshürden zu senken und neue Beitragende zu gewinnen. Andererseits droht die Gefahr, dass die Qualität der Beiträge leidet – oder schlimmer noch, dass die Gemeinschaft selbst an Bedeutung verliert.

Projekte wie Zig zeigen, dass Open Source mehr ist als nur Code. Es geht um Menschen, die sich engagieren, lernen und wachsen. Eine KI mag Code generieren können, doch sie kann keine Mentoren ersetzen. Die Frage ist daher nicht, ob KI in der Softwareentwicklung eine Rolle spielen wird, sondern wie Projekte sicherstellen, dass menschliche Beiträge weiterhin im Mittelpunkt stehen.

Eines ist sicher: Die Debatte wird weitergehen. Und während einige Projekte ihre Tore für KI-Tools öffnen, wird Zig weiterhin auf den Menschen setzen – und damit auf die Zukunft von Open Source.