Begründung für die Anti-AI-Beitragsrichtlinie des Zig-Projekts
(simonwillison.net)- Zig verfolgt eine strikte Regel, die die Nutzung von LLMs in Issues, Pull Requests, Bugtracker-Kommentaren und Übersetzungen verbietet
- Die Verwendung von Englisch ist nur eine Empfehlung und keine Pflicht; Beitragende können in ihrer Muttersprache schreiben, und andere können den Inhalt mit einem Übersetzungstool ihrer Wahl verstehen
- Bun hat in seinem eigenen Zig-Fork dem LLVM-Backend parallele semantische Analyse und mehrere Codegen-Units hinzugefügt und damit eine 4-fache Leistungssteigerung bei der Bun-Kompilierung erreicht, plant aber derzeit kein Upstreaming, weil LLM-verfasste Beiträge verboten sind
- Zigs Review-Ansatz hilft neuen Beitragenden, merge-fähige Ergebnisse zu erreichen, statt unvollständige PRs einfach abzulehnen, und gewichtet das Wachstum der Beitragenden höher als einzelne Beiträge
- PRs, die überwiegend von LLMs geschrieben wurden, sorgen dafür, dass Review-Zeit nicht mehr dazu dient, die Zahl verlässlicher neuer Beitragender zu erhöhen; außerdem entsteht für Maintainer die Option, statt eines Reviews das gleiche Problem direkt selbst mit einem LLM zu lösen
Konflikt zwischen Richtlinie und Bun-Fork
- Zig erklärt in seinem Code of Conduct ausdrücklich ein Verbot der LLM-Nutzung für Issues, Pull Requests, Bugtracker-Kommentare und Übersetzungen
- Die Verwendung von Englisch ist eine Empfehlung; Beitragende können in ihrer Muttersprache schreiben
- Andere können den Inhalt mit einem Übersetzungstool ihrer Wahl verstehen
- Ein prominentes in Zig geschriebenes Projekt ist die JavaScript-Runtime Bun; Bun wurde im Dezember 2025 von Anthropic übernommen
- Bun betreibt einen eigenen Zig-Fork und hat dem LLVM-Backend „parallel semantic analysis and multiple codegen units“ hinzugefügt, wodurch bei der Bun-Kompilierung eine 4-fache Leistungssteigerung erreicht wurde
- Der zugehörige Code ist im Vergleichslink von oven-sh/zig veröffentlicht
- Bun plant derzeit kein Upstreaming, weil Zig von LLMs verfasste Beiträge strikt verbietet
- Laut einem Zig-Core-Contributor wäre der Patch auch unabhängig von der LLM-Frage schwer zu akzeptieren
- Parallele semantische Analyse ist zwar seit Langem geplant, wirkt sich aber auf die Zig-Sprache selbst aus
Contributor Poker und beitragendenzentriertes Review
- Contributor Poker and Zig's AI Ban verwendet Contributor Poker als zentrale Metapher, um Zigs strikte Verbotsrichtlinie zu verstehen
- Erfolgreiche Open-Source-Projekte erreichen einen Punkt, an dem sie mehr PRs erhalten, als sie verarbeiten können
- Um den ROI zu maximieren, entscheidet sich Zig dafür, neue Beitragende beim Erreichen eines mergebaren Zustands zu unterstützen, statt unvollständige PRs einfach abzulehnen
- Dieser Ansatz gilt nicht nur als „das Richtige“, sondern auch als „das Kluge“
- Zig misst den Beitragenden mehr Bedeutung bei als einzelnen Beiträgen
- Das primäre Ziel von PR-Review und -Annahme ist nicht, neuen Code hereinzunehmen, sondern Menschen zu helfen, die mit der Zeit zu verlässlichen und produktiven Beitragenden heranwachsen können
- Jede beitragende Person wird zu einem Investitionsobjekt des Zig-Core-Teams
- LLM-Unterstützung untergräbt diese Struktur
- Selbst wenn ein LLM beim Schreiben eines perfekten PR hilft, trägt die Review-Zeit des Zig-Teams nicht dazu bei, mehr neue, selbstbewusste und verlässliche Beitragende hervorzubringen
- „Contributor Poker“ ist eine Metapher dafür, dass man dieses Spiel nicht nach den Karten, sondern nach den Menschen spielt
- Gemeint ist eher, dass auf die beitragende Person gewettet wird als auf den Inhalt des ersten PR
- Wenn ein PR überwiegend von einem LLM geschrieben wurde, haben Projekt-Maintainer statt Review und Diskussion dieses PR auch die Option, das gleiche Problem direkt selbst mit einem LLM zu lösen
2 Kommentare
Das liegt daran, dass Menschen der Engpass sind. Wenn man die massenhaft hereinkommenden Müll-PRs erst aufwendig reviewen muss, kann das die Zig-Entwicklung behindern, deshalb gibt es diese Richtlinie als ersten Filter im Voraus.
Hacker-News-Kommentare
Laut https://kristoff.it/blog/contributor-poker-and-ai/ waren LLM-basierte Beiträge überwiegend negativ.
Wertlose Drive-by-PRs erhöhten mit halluziniertem Code das Grundrauschen, kompilierten nicht oder bestanden CI nicht, und es gab sogar Fälle, in denen Erstbeitragende einen 10.000-Zeilen-PR einschickten.
Es gab auch PRs, die oberflächlich solide wirkten und ausdrücklich angaben, kein LLM verwendet zu haben, doch in der anschließenden Diskussion zeigte sich sofort, dass die Autorin oder der Autor heimlich doch ein LLM konsultiert hatte und fehlerhafte Antworten wiederholte.
Für hooks gibt es keinen sauberen Weg, ihre Installation beim Clone zu erzwingen, aber GHA Workflows oder entsprechende Funktionen anderer forge-Systeme könnten das leisten.
Für ein Projekt mit einer gewissen Größe und Popularität sollte so etwas meiner Meinung nach Grundvoraussetzung sein.
Ein erheblicher Teil des Problems „AI kann nicht beitragen“ ließe sich offenbar zumindest teilweise durch bessere automatische Prüfungen und Schutzmechanismen verringern.
Abgesehen davon, dass AI diese neue Art von Spam ermöglicht hat, ist das Wesen des Problems nicht AI.
Auch ohne AI wäre der Effekt derselbe, wenn Leute billige Offshore-Entwicklertruppen anheuern würden, um massenhaft mittelmäßige Drive-by-PRs zu produzieren.
Mit AI kann man auch guten Code erzeugen, aber wie bei jedem anderen Werkzeug muss man sie sorgfältig einsetzen.
Das hier ist kein sorgfältig erstellter Beitrag einer Person, die Projekt und Ziel versteht und das Werkzeug gut nutzt, sondern Spam.
Der Lärm rund um die AI-Policy scheint dadurch entstanden zu sein, dass Bun-Entwickler sagten, sie könnten wegen dieser Policy keine Performance-PRs upstream einbringen.
Der tatsächliche Grund scheint jedoch zu sein, dass der PR-Code selbst in schlechtem Zustand ist und ungesunde Komplexität einführt https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio....
Laut der zitierten Erklärung ist parallele semantische Analyse schon seit Langem ein expliziter Plan des Zig-Compilers und hat auch das Design des self-hosted Zig compiler stark beeinflusst, doch für eine korrekte Implementierung seien Änderungen nicht nur an der Compiler-Implementierung, sondern auch an der Zig-Sprache selbst nötig.
Er kollidiert mit Zigs eigener Roadmap für bessere Ergebnisse und behindert die Richtung, in der die gesamte Sprache weiter verbessert werden soll.
Die Policy verbietet sämtlichen LLM-Code ausdrücklich, also ist diese Policy natürlich der „eigentliche Grund“.
Es wirkt, als gehe Zig den Weg von ZeroMQ https://zguide.zeromq.org/docs/chapter6.
Die Richtung ist, „kollektives Eigentum am Projekt zu erzwingen, die wirtschaftlichen Anreize für Beitragende zu erhöhen und das Risiko einer Übernahme durch feindliche Akteure zu verringern“.
Eine gesunde Contributor-Community ist wichtiger als bloße Code-Performance, Anzahl der Features oder Zeilenzahl.
Die heutige zeromq-„Community“ ist eher dünn, es gibt noch einige großartige aktive Leute, aber Prozesse und Kommunikationskanäle auf menschlicher Ebene sind weder gut definiert noch ausreichend gepflegt.
Da libzmq und die meisten Bindings stabil sind, ist dieser Mangel an menschlicher Aktivität und Interaktion vielleicht bis zu einem gewissen Grad akzeptabel oder zu rechtfertigen, aber Hintjens’ großartige Vision hat zeromq bis hierher gebracht, und seit seinem Verlust wirkt das Projekt etwas orientierungslos.
Ironischerweise scheint man selbst für eine community-zentrierte Vision charismatische und aktive Führung zu brauchen, um eine Community zu gewinnen und zu erhalten, und das sagt wohl mehr über die menschliche Natur als über Softwareentwicklung aus.
Um den Bogen zurück zu Zig zu schlagen: Zig hat keinen Mangel an PRs, daher gibt es die Annahme, dass man no-LLM-Beiträge im Voraus aussortieren kann.
Für sie ist das eine gute Entscheidung, und ich verstehe auch die Idee von „contributor poker“.
Wenn der Zufluss neuer Leute aber nachlässt, ändern sich die Spielregeln, und wenn die Zig-Leute dann immer noch neue Beitragende wollen, müssen sie ihr Netz womöglich weiter auswerfen.
Wenn dieser Zeitpunkt kommt, könnte es allerdings schon zu spät sein, um sich durch das Öffnen für LLM-unterstützte Beiträge noch zu erholen.
Was ich mich bei AI-generierten OSS-Beiträgen frage, ist Folgendes:
Wenn AI die Produktivität von Entwicklerinnen und Entwicklern wirklich so stark steigert, warum sollte ein OSS-Maintainer dann zwischen sich und seinem LLM noch unbekannte Beitragende schalten wollen?
Der Maintainer kann doch einfach selbst Claude Code befragen.
Um einen Kollegen zu zitieren: „Wir brauchen keinen Zwischenhändler, der mit dem AI-Modell spricht, und Coding ist nicht der Flaschenhals.“
Er erzeugt mit AI eine anfänglich schlechte Version, passt die Prompts an, korrigiert manuell, lässt andere Teile überarbeiten, entdeckt zusammenhängende Funktionen und fügt sie hinzu, lässt Benchmarks laufen und entfernt kleine Features oder entscheidet sich zwischen zwei ähnlichen Implementierungen.
Dazu kommen weitere manuelle Korrekturen hier und da, ausführlichere automatisierte Tests, um seltsame Bugs in ungewöhnlichen Konfigurationen zu finden, und wieder Korrekturen mit AI und manuell.
Nach diesen 20 Stunden besteht die Endversion dann vielleicht nur aus 50 Zeilen, und jede Zeile wurde fünfmal umgeschrieben.
Der Maintainer muss dann nur noch die Endversion ungefähr eine Stunde prüfen.
Das ist völlig etwas anderes, als der AI fünf Minuten lang einen Patch schreiben zu lassen und dann 1000 Zeilen, die nicht einmal kompilieren, ungelesen an den Maintainer zu schicken.
„Das ist so einfach, das hätte ich auch gekonnt.“
Stimmt, aber gemacht hast du es nicht.
Aber sie ist nicht die Art von Ding, dem man einfach nur High-Level-Anweisungen hinwirft, wie man es bei Menschen tun würde.
Bei Leuten, die behaupten, AI funktioniere allein mit High-Level-Anweisungen, habe ich oft den Eindruck, dass sie an eher „gedankenlosen“ Projekten arbeiten, bei denen niemand, der in die Details geht, besonders viel nachdenken muss.
Hoffentlich meinst du auch nicht, dass der einzige Vorteil von LLMs darin besteht, Code zu erzeugen, den man nicht selbst tippen möchte.
Die Erklärung „Zig legt mehr Wert auf Beitragende als auf Beiträge. Der Hauptzweck beim Review und Akzeptieren von PRs ist nicht, neuen Code hineinzubekommen, sondern Menschen dabei zu helfen, mit der Zeit zu vertrauenswürdigen und produktiven Beitragenden zu werden. LLM-Unterstützung zerstört das vollständig. Das gilt auch dann, wenn LLMs beim Einreichen perfekter PRs helfen“ ist die beste Begründung, die ich bisher dazu gesehen habe.
Ich unterstütze Zigs Entscheidung voll und ganz und schätze die langfristige Vision sowohl für die Community als auch für das eigentliche Projekt.
Ehrlich gesagt halte ich LLMs auch nicht für besonders gut geeignet für stärker kollaborative Arbeit.
Mal sehen, wie sich das weiterentwickelt, aber wenn ich AI-generierte PRs akzeptiere, muss ich am Ende oft doch alles selbst noch einmal machen, und ironischerweise mache ich es dann erneut mit Hilfe von LLMs, was sich zunehmend widersprüchlich anfühlt.
Trotzdem halte ich die Zig-Policy zumindest für die nächsten fünf Jahre für eine gute Idee.
Ich denke, das ist die am wenigsten feindselige Formulierung, die sie hätten wählen können, und als Entscheidung für ihr eigenes Projekt respektiere ich sie.
Trotzdem fühlt es sich weiterhin so an, als würde das Projekt sich unnötig selbst fesseln.
LLMs sind Werkzeuge und können beim Denken, Recherchieren und Programmieren helfen.
Man kann sie überstrapazieren, aber dort, wo sie nützlich sind, sollte man sie akzeptieren.
Dass man Buns PR aus anderen Gründen nicht annimmt, ist völlig in Ordnung, aber alle von LLMs geschriebenen PRs pauschal zu verbieten, ist unnötig restriktiv.
Man sollte sich einfach auf die Qualität der Arbeit konzentrieren.
Wenn der Maintainer selbst ein LLM für dieselbe Aufgabe nutzt, kann er sie wahrscheinlich mit besserem Design und sorgfältigerem Ansatz umsetzen.
Maintainer sollen ihre Zeit nicht mit Low-Effort-PR-Reviews verbringen, sondern mit Entwicklung.
Die Flut von LLM-Code verschiebt das Gleichgewicht zulasten der Maintainer, und ich kann sehr gut verstehen, warum sie das einfach verbieten wollen.
Mein Gesamteindruck nach einer Weile mit LLMs und Coding Agents ist: Das sind Elektrowerkzeuge oder ein Kran, aber kein Werkzeug zur Entscheidungsfindung.
Menschen in einer Organisation mit starkem konzeptuellem Verständnis und tiefem Engineering-Verständnis erleben einen explosionsartigen Produktivitätsschub.
Umgekehrt produzieren Leute mit wenig Verständnis oder Neueinsteiger bzw. Juniors höllischen Code und denken, alles sei erledigt, solange es irgendwie läuft.
LLMs schaffen innerhalb einer Organisation eine intellektuelle Kluft, und je mehr man sie nutzt, desto größer wird diese Kluft.
Später könnte es sogar passieren, dass man den intern erzeugten Ergebnissen wegen des generierten Codes nicht mehr traut.
AI verstärkt im Allgemeinen den vorhandenen Skillset, sowohl im Guten als auch im Schlechten.
Ein kürzlich wirklich großartiger Anwendungsfall war das Ausarbeiten eines Konzepts für einen authentication daemon.
Ich habe mit Codex gesprochen, Vorschläge ausgewählt, sie mit normaler Websuche gegengeprüft, dann einen finalen Entwurf festgelegt und ihn anschließend mit Kolleginnen und Kollegen besprochen.
Solches interaktive Planning mit integrierter Websuche ist enorm nützlich, und bereits geschriebenen Code mit AI zu reviewen, halte ich ebenfalls für einen klaren Vorteil.
Die zentrale caveat bei AI bleibt aber, dass man am Ende klüger sein muss als das Werkzeug.
Wenn Codex vorschlägt, Tech-Stack X zu verwenden, muss man recherchieren, warum das tatsächlich gut ist, es vollständig verstehen und mit anderen Lösungen vergleichen.
Viele Leute überspringen genau diesen Schritt, deshalb entstehen so viele Probleme, und das ist fatal.
Nach dem Gespräch sollte man klüger sein als die AI und alles, was die AI gesagt hat, vollständig verstehen und kritisieren können.
Sobald die Architektur feststeht, sind LLMs bei der Implementierung ziemlich gut.
Man kann AI oft dazu bringen, großartigen und gut getesteten Code zu erzeugen, der deutlich besser ist, als man ihn allein in derselben Zeit geschafft hätte.
Aber es bleibt eine Herausforderung, beim Wissen über alles, was die AI erzeugt hat, dauerhaft mitzuhalten.
Die Logik „Wenn ein PR größtenteils von einem LLM geschrieben wurde, warum sollte ein Maintainer die Zeit für Review und Diskussion aufwenden, statt einfach sein eigenes LLM anzuschalten und dasselbe Problem zu lösen?“ lässt sich auch auf Open Source selbst anwenden.
Warum das Projekt anderer Leute verwenden, wenn der Roboter es direkt selbst schreiben kann?
Besonders dann, wenn dieses Open-Source-Projekt vibe coded wurde.
AI und Technologie insgesamt machen Personalisierung billig und einfach.
Früher musste man Massenware nutzen, die für alle so halbwegs passte, jetzt gibt es die Hoffnung auf etwas, das nur für mich hervorragend ist.
Außerdem wird die Arbeitsökonomie dadurch verändert, dass verschiedene Leute Open-Source-Projekte an vielen Stellen mit LLMs neu bauen.
LLMs können so etwas in wenigen Minuten ausspucken.
Was ich am meisten will, ist eine Nutzungsgeschichte.
Ich möchte Software benutzen, die andere Menschen vor mir schon eingesetzt haben, und ich möchte, dass sie dabei Bugs und scharfe Kanten gefunden und abgeschliffen haben.
Wer würde noch Dinge kaufen, wenn man zu Hause einfach Modelle herunterladen, ausdrucken und endlos anpassen kann?
Der Grund, warum wir Zivilisation haben, ist, dass wir den größten Teil unseres Lebens zu den Problemen anderer Leute machen und uns selbst darauf konzentrieren können, eine Sache gut zu beherrschen.
Wenn du Zahnarzt bist oder eine muffler shop betreibst, ist deine Zeit am Tag begrenzt, und wahrscheinlich zahlst du lieber einen SaaS vendor, als vibecoding zu lernen und einen seltsamen, betreuungsintensiven Untergebenen zu beaufsichtigen.
Es gibt Ausnahmen, aber es bleiben eben Ausnahmen.
Wenn ein vendor ein vernünftiges und kompetentes Produkt baut, zahle ich gern dafür.
Für Open Source gilt dasselbe.
Selbst wenn ein LLM von Grund auf ein stabiles neues Betriebssystem bauen könnte: Würde ich das wirklich wollen?
Ich will kein Betriebssystem warten, ich will niemanden managen, der ein Betriebssystem wartet, und ich glaube auch nicht, dass ich überhaupt eine konsistente Vision für ein Betriebssystem habe.
Jenseits eines gewissen Grads an Komplexität ist kaum zu erwarten, dass der Roboter meine Wünsche so gut errät, dass er ein hochwertiges Ergebnis liefert, das „nur für mich“ hervorragend ist.
Das Zig-Projekt liegt offensichtlich weit außerhalb dieses Fähigkeitsbereichs.
Manche können sich die Kosten nicht leisten, und selbst wer Zugang hat, erlebt oft oder dauerhaft Probleme wie Ausfälle bei Claude oder eine mit der Zeit allgemein sinkende Leistung.
Als ich Claude vor einigen Monaten gerade intensiv zu nutzen begann, machte ich innerhalb einer Woche in mehreren Projekten leicht Fortschritte, aber inzwischen sehe ich meist nur noch einen spinner, und auch die Codequalität wirkt stark eingebrochen, sodass ich fast nichts mehr damit hinbekomme.
Ich habe ein paar Repositories mit ungefähr 100 Sternen, nichts Großes, aber bis letztes Jahr bekam ich gelegentlich PRs; dieses Jahr bislang fast gar keine.
Meine Hypothese ist, dass LLMs lieber an Mainstream-Projekten hängen.
Da sich viele Entwickler inzwischen stark auf LLMs verlassen, entsteht ein bias dahingehend, den Großteil dessen zu ignorieren, was ich anbiete.
Dass es mit LLMs zu mehr wheel reinvention kommt, liegt auch daran, dass die Kosten des Neuerstellens gesunken sind.
Deshalb ist es einfacher geworden, sich Benötigtes einfach erzeugen zu lassen, statt irgendein obskures GitHub-Projekt zu verwenden, etwa meines.
Dasselbe sehe ich bei meinen Dependency-Entscheidungen.
Wenn es keinen sehr guten Gegengrund gibt, neige ich dazu, einfach das zu nehmen, was ein LLM vorschlägt.
Ich stimme dem teilweise zu, aber nicht vollständig.
Es stimmt, dass das Fördern von Beitragenden die richtige Priorität ist.
Aber ich betrachte AI als Assistenztechnologie.
Ähnlich wie ein screen reader oder eine magnifying glass, auch wenn es natürlich viele Unterschiede gibt.
Man kann es sich wie ein Roboter-Exoskelett vorstellen.
Es wird für schlechte und dumme Dinge genutzt werden, aber es wird auch Menschen, die es vorher nicht konnten, ermöglichen, Gutes zu tun oder kompetenter zu werden.
Für manche Menschen macht AI Coding möglich, das sie vorher nicht leisten konnten; für viele wird sie ein Mittel sein, beim Beobachten dessen, was AI tut, das Programmieren zu lernen; und für andere macht sie das Coden deutlich schneller oder besser.
Bei einigen werden vielleicht bestimmte Fähigkeiten verkümmern, während sich andere weiterentwickeln.
Auch bei einem Exoskelett gäbe es dieselben Probleme, sobald ein brauchbares Produkt auf dem Markt wäre, aber insgesamt wäre es ein befähigendes Werkzeug.
Ich verstehe nicht, warum es schlechter sein soll, Beitragende mit Assistenztechnologie zu fördern, als solche ohne.
Natürlich kann es schwieriger sein.
LLMs sind nicht so intelligent, wie die LLM-Vendoren behauptet haben.
Wären sie das wirklich, wären sie vollständig autonom, und wir würden dieses Gespräch nicht führen.
Menschen sollten wirklich aufhören, blind LLM-generierten Code einzureichen oder die Nutzung nicht offenzulegen.
Das verbleibende Problem ist, dass es trotzdem noch Werkzeuge sind.
Wenn man irgendeinem Entwickler sagt: „Mach Zig mit einem one-shot PR schneller“, wird dabei nichts Gutes herauskommen.
Früher gab es in OSS-Projekten eine Selbstselektion, weil man funktionierenden Code schreiben können musste, und wer so weit war, tat durch das Gelernte über Jahre hinweg meist ungefähr das Richtige und hatte eine gewisse eigene reasoning in Bezug auf Features und Notwendigkeit.
Selbst wenn heutige LLMs perfekt wären und gut reasonen könnten, führen sie letztlich nur die Anweisungen der promptenden Person aus.
Diese Selbstselektion ist also verschwunden.
Für Zig-Entwickler dürfte es ohnehin schwer sein, tatsächlich zu erkennen, welcher Code von LLMs und welcher von Menschen stammt.
Vielleicht ist auch jetzt schon LLM-generierter Code eingeflossen, aber zumindest müssen diese menschlichen Einreichenden den Code noch immer ziemlich gut handhaben können.
Ich frage mich, ob es am Ende auf „Nur Menschen mit vertrauenswürdigem Ehrenabzeichen dürfen committen“ hinausläuft oder auf ein Niveau, bei dem ein LLM genug reasoning hat, um zu sagen: „Nein, verschwinde. Dieses Feature, dieser Plan, diese Idee ist Müll, ich baue das nicht.“
Wenn es keine echte Möglichkeit gibt, ihnen dafür ordentlich eine reinzuwürgen, weiß ich nicht, was sie aufhalten sollte.