Zig-KI-Verbot: Vertrauen der Prüfer statt LLM-Produktivität

Ein Pull Request ist nie einfach nur ein Pull Request. Er ist eine kleine Rechnung, die an Maintainer geschickt wird, zahlbar in Aufmerksamkeit, Kontext und den verfluchten kleinen Stunden nach dem Abendessen, in denen Open Source tatsächlich passiert. Zig hat eine Kategorie von Rechnungen mit einem knallroten Nein abgestempelt: Beiträge mit Unterstützung großer Sprachmodelle sind raus. Das macht das Zig-Projekt zu einer nützlichen Fallstudie für KI- und ML-Entwickler, denn in der Argumentation geht es nicht wirklich darum, ob Code-Assistenten Code erzeugen können. Natürlich können sie das. Das können auch Praktikanten, Stack-Overflow-Archäologie und ein übermüdeter Staff Engineer, der von Flughafenkaffee angetrieben wird. Die Frage ist, wer für die Überprüfung des Ergebnisses bezahlt.

Das Verbot ist laut Simon Willison und Business Insider breiter als Code

Simon Willison beschreibt Zig als eines der großen Open-Source-Projekte mit einer der strengsten Anti-LLM-Richtlinien und zitiert die Projektsprache direkt: „Keine LLMs für Issues.“ Außerdem zitiert er: „Keine LLMs für Pull Requests.“ Dieselbe Richtliniensprache, wie sie von Willison zitiert wird, umfasst Kommentare im Bugtracker, einschließlich Übersetzungen, während Beitragende ermutigt werden, in ihrer Muttersprache zu posten und andere bei Bedarf Übersetzungstools verwenden zu lassen. Business Insider berichtet, dass Zig Beitragenden verbietet, KI zum Coden, Debuggen oder Brainstorming zu verwenden, und die Überschrift zitiert Zig-Präsident Andrew Kelley, der KI-Coding-Beiträge als „ausnahmslos Müll“ bezeichnet. Das scharfe Zitat bringt die Klicks, weil es das natürlich tut, aber der Mechanismus ist wichtiger als die Würze. Zig behandelt Herkunft als Teil der Überprüfbarkeit: Wenn Maintainer nicht darauf vertrauen, wie ein Artefakt entstanden ist, können sie sich entscheiden, keine knappe Review-Zeit darauf zu verwenden, es zu entwirren. Let’s Data Science ergänzt, dass die Regel Code, Bearbeitungen, Übersetzungen, Brainstorming, Fehlersuche und sogar die Erwähnung von LLM-Nutzung in Projektbereichen umfasst. AI Weekly sagt ähnlich, dass das Verbot von LLMs berührte Artefakte einschließlich Issues, Kommentaren und Pull Requests umfasst. Mit anderen Worten: Zig sagt nicht nur: Bitte fügt keinen Chatbot-Code in den Compiler ein. Es sagt, dass der Projektkommunikationskanal selbst eine Anforderung an die Quellenqualität hat, also Governance im Compiler-Hoodie.

Reviewer-Bandbreite ist laut Loris Cro und Let’s Data Science die knappe

Ressource Loris Cro, der aus Erfahrung mit der Zig Software Foundation schreibt, beschreibt Open-Source-Beiträge eher als Tauschgeschäft denn als Geschenkkorb. Er argumentiert, dass Pull Requests selbst zu zusätzlicher Arbeit und Reibung werden können und dass es üblich ist, dass ein Maintainer weniger Aufwand hat, eine Änderung direkt umzusetzen, als einen eingereichten Patch zu überprüfen. Das ist der Teil, um den viele KI-Coding-Debatten höflich herumgehen, wie ein Roomba, der einer Socke ausweicht. Let’s Data Science berichtet, dass Zig ungefähr 200 offene Pull Requests und eine kleine Kern-Gruppe von Reviewern hatte, als die Richtlinie formuliert wurde. Dieser Kontext lässt das Verbot weniger wie ästhetische Reinheit und mehr wie Warteschlangenmanagement wirken. Wenn ein Projekt bereits mehr Review-Nachfrage als Angebot an vertrauenswürdigen Reviewern hat, können generierte Einreichungen sich wie synthetisches Lasttesting für Menschen verhalten, nur dass niemand einen Kapazitätsplan eingereicht hat. AI Weekly sagt, Kelley habe die Richtlinie als Ressourcen-Triage beschrieben und dabei den negativen Review-Wert von KI-Einreichungen angeführt. Dieser Ausdruck ist hier der tragende Balken. Ein generierter Patch kann lokal billig für den Beitragenden und global teuer für die Maintainer sein, was im Grunde die Tragik der Allmende ist, nur mit Autocomplete und mehr YAML.

Bun zeigt laut AI Weekly und Simon Willison das Upstream-Risiko

AI Weekly berichtet, dass das zu Anthropic gehörende Bun, das auf KI-unterstützte Workflows setzt, Zig geforkt hat, nachdem Änderungen nicht upstream eingebracht werden konnten. Simon Willison merkt ebenfalls an, dass Bun einen eigenen Fork von Zig betreibt, und sagt, Bun sei im Dezember 2025 von Anthropic übernommen worden. Für Teams, die kommerzielle Produkte auf Open-Source-Grundlagen bauen, ist das die Governance-Lektion mit Biss. Die übliche Unternehmensfantasie ist, dass Upstream ein freundliches Förderband ist: Verbesserungen beitragen, sie gemergt bekommen, Divergenz reduzieren, alle klatschen sich in einem Konferenzflur ab. Zigs Richtlinie zeigt einen anderen Fehlermodus. Wenn euer Engineering-Workflow von KI-Unterstützung abhängt und ein Upstream-Projekt LLM-verfasste Beiträge ablehnt, müsst ihr möglicherweise einen Fork pflegen, Arbeit manuell neu schreiben oder ändern, wie Beiträge vorbereitet werden. Das macht Zig nicht in irgendeinem kosmischen Sinne produktivitätsfeindlich. Es bedeutet, dass Zig Vertrauen der Maintainer höher optimiert als Contributor-Durchsatz. Beides sind reale Werte, und so zu tun, als würden sie nie in Konflikt geraten, ist der Weg zu einem Backlog, der wie eine geologische Formation geformt ist.

Das ist laut Research Information größer als Zig

Research Information berichtet, dass arXiv Autorinnen und Autoren davor gewarnt hat, dass ihnen eine einjährige Einreichungssperre drohen könnte, wenn ihre Arbeit klare Hinweise auf ungeprüfte Ausgabe großer Sprachmodelle enthält. Das ist nicht dieselbe Domäne wie Compiler-Pull-Requests, aber das Muster reimt sich lautstark. Institutionen bewegen sich von gefühlsbasierter KI-Etikette zu ausdrücklichen Verantwortungsregeln. Für KI-Entwickler ist die praktische Erkenntnis nicht, in Panik zu geraten oder bei Vollmond eine rituelle Chatbot-Verbannung durchzuführen. Sie besteht darin, Beitrags-Workflows zu entwerfen, die Reviews günstiger machen: Tool-Nutzung offenlegen, wo es erlaubt ist, Patches klein halten, Tests bereitstellen, Absicht erklären und bereit sein, jede Zeile zu verantworten, als hätte kein stochastischer Papagei sie ins Dasein geflüstert. Wenn ein Projekt LLM-Unterstützung verbietet, respektiert diese Grenze oder tragt anderswo bei. Als Nächstes ist zu beobachten, ob mehr Open-Source-Projekte Zigs klare Linie kopieren oder weichere Regeln rund um Offenlegung und Verifizierung wählen. So oder so verlassen KI-Coding-Tools die Demo-Phase und betreten die Governance-Tabelle. Es stellt sich heraus: Der schwierigste Teil von generiertem Code sind immer noch die Menschen, die ihm glauben müssen.