Zig verbannt LLMs komplett: Warum das Open-Source-Projekt Contributor-Poker spielt

Das Zig-Projekt setzt bewusst auf eine der strengsten Anti-LLM-Richtlinien im Open-Source-Umfeld, die im offiziellen Code of Conduct fest verankert ist und die Nutzung von LLMs für Issues, Pull Requests und Kommentare im Bug Tracker – einschließlich maschineller Übersetzungen – explizit verbietet. Diese Haltung ist kein Purismus, sondern Ausdruck einer präzisen strategischen Überlegung, wie Loris Cro, VP of Community der Zig Software Foundation, in seinem Blogpost "Contributor Poker and Zig's AI Ban" erläutert. Er beschreibt es als "Contributor Poker", bei dem es im Review-Prozess nicht primär um den Code selbst, sondern um die dahinterstehende Person geht. Jeder neue Contributor wird als Investition betrachtet, wobei das Team Zeit in Review und Feedback investiert, um langfristig vertrauenswürdige und produktive Mitarbeiter zu entwickeln, anstatt nur neuen Code zu integrieren.

LLM-generierte Beiträge untergraben diesen Ansatz, da ein perfekter, KI-erstellter Pull Request zwar Team-Ressourcen im Review-Prozess beansprucht, aber keine persönliche Entwicklung des Contributors fördert. Die Person lernt und wächst nicht, wird nicht aktiver Teil der Community, und das Review-Team erhält keine strategische Rendite für seine investierte Zeit. Cro argumentiert, dass, wenn ein PR hauptsächlich von einem LLM verfasst wurde, es für einen Maintainer effizienter wäre, selbst ein LLM zur Problemlösung einzusetzen, anstatt Zeit in die Diskussion eines KI-generierten Beitrags zu investieren. Dies verdeutlicht die Kernproblematik: Das Team möchte menschliche Mitarbeiter fördern und keine unpersönlichen, KI-generierten Beiträge, die keinen nachhaltigen Wert für den Community-Aufbau liefern.

Die Konsequenzen dieser Politik zeigen sich am Beispiel von Bun, einer JavaScript-Runtime, die selbst auf Zig basiert und im Dezember 2025 von Anthropic übernommen wurde. Bun erzielte erhebliche Leistungssteigerungen im Compile-Prozess durch eigene Entwicklungen in einem Zig-Fork. Trotz dieser substanziellen technischen Errungenschaft wird der Code nicht ins offizielle Zig-Projekt übernommen. Das Bun-Team bestätigt, dass Zigs striktes Verbot KI-generierter Beiträge ein Hindernis für ein Upstream-Merging darstellt. Dies bedeutet, dass ein signifikanter Performance-Patch in einem Fork bleibt und dem Hauptprojekt nicht zugutekommt. Für das Zig-Team ist dieser Preis offensichtlich akzeptabel, da die Einhaltung der Policy als wichtiger erachtet wird als die unmittelbare Integration von performancesteigerndem Code, der möglicherweise nicht dem Community-Aufbau dient.

Zig ist nicht isoliert in seiner Haltung; die Open-Source-Community erleben eine breitere Gegenbewegung gegen unkontrollierte KI-Beiträge. Projekte wie Ghostty haben ebenfalls eine Null-Toleranz-Politik eingeführt, und Daniel Stenberg stellte das cURL Bug-Bounty-Programm Ende Januar 2026 offiziell ein, nachdem KI-generierter 'Slop' die Review-Kapazitäten massiv belastete. Das zugrunde liegende Problem ist in all diesen Fällen dasselbe: begrenzte Review-Kapazitäten von Freiwilligen werden durch minderwertige KI-Beiträge unnötig belastet, ohne einen entsprechenden Mehrwert zu schaffen. Was Zig von anderen unterscheidet, ist die explizite und konsequente Natur seiner Regelung. Es gibt keine Grauzonen oder Aufforderungen zur Kennzeichnung; stattdessen wird ein klares Nein artikuliert, basierend auf dem strategischen Wert des Community-Aufbaus als Ressource und nicht nur auf der Code-Qualität.

Für Unternehmen und Maintainer im DACH-Raum bietet die Zig-Strategie eine relevante Überlegung: Die Akzeptanz von KI-generierten Beiträgen sollte hinterfragt werden im Hinblick darauf, ob sie tatsächlich das Contributor-Wachstum fördern oder lediglich das Code-Volumen erhöhen. Beides sind unterschiedliche Ziele, und Zig hat sich bewusst für den Community-Aufbau als wertvollere Währung entschieden. Diese Haltung zwingt dazu, die langfristigen Auswirkungen der Integration von KI-Beiträgen auf die Entwicklung und das soziale Gefüge eines Open-Source-Projekts kritisch zu bewerten und gegebenenfalls eigene, ähnlich konsequente Richtlinien zu formulieren.