Interdiction de Zig AI : la confiance des évaluateurs plutôt que la productivité des LLM

Une pull request n’est jamais seulement une pull request. C’est une minuscule facture envoyée aux mainteneurs, payable en attention, en contexte, et dans ces maudites petites heures après le dîner où l’open source se fait vraiment. Zig a apposé un gros tampon rouge « non » sur une catégorie de facture : les contributions assistées par de grands modèles de langage sont exclues. Cela fait du projet Zig une étude de cas utile pour les créateurs d’IA et de ML, car l’argument ne porte pas vraiment sur la question de savoir si les assistants de code peuvent produire du code. Bien sûr qu’ils le peuvent. Les stagiaires aussi, tout comme l’archéologie de Stack Overflow et un ingénieur senior en manque de sommeil, carburant au café d’aéroport. La question est de savoir qui paie pour vérifier le résultat.

L’interdiction est plus large que le code, selon Simon Willison et Business

Simon Willison décrit Zig comme ayant l’une des politiques anti-LLM les plus strictes parmi les grands projets open source, et cite directement le texte du projet : « Pas de LLM pour les issues. » Il cite aussi : « Pas de LLM pour les pull requests. » Le même texte de politique, tel que cité par Willison, couvre les commentaires du gestionnaire de bugs, y compris la traduction, tout en encourageant les contributeurs à publier dans leur langue maternelle et à laisser les autres utiliser des outils de traduction si nécessaire. Business Insider rapporte que Zig interdit aux contributeurs d’utiliser l’IA pour coder, déboguer ou réfléchir à des idées, et son titre cite Andrew Kelley, président de Zig, qualifiant les contributions de code par IA de « systématiquement nulles ». La citation piquante attire les clics, bien sûr, mais le mécanisme compte davantage que le piquant. Zig traite la provenance comme une partie de la capacité à relire : si les mainteneurs ne font pas confiance à la manière dont un artefact a été produit, ils peuvent choisir de ne pas consacrer leur rare temps de revue à le démêler. Let’s Data Science ajoute que la règle couvre le code, les modifications, les traductions, le brainstorming, la recherche de bugs, et même le fait de mentionner l’utilisation de LLM dans les espaces du projet. AI Weekly indique de même que l’interdiction couvre les artefacts touchés par des LLM, y compris les issues, les commentaires et les pull requests. Autrement dit, Zig ne dit pas seulement : merci de ne pas coller du code de chatbot dans le compilateur. Le projet dit que le canal de communication lui-même a une exigence de qualité de source, ce qui est de la gouvernance portant un sweat à capuche de compilateur.

La bande passante des relecteurs est

la ressource rare, selon Loris Cro et Let’s Data Science

Loris Cro, écrivant à partir de son expérience avec la Zig Software Foundation, présente les contributions open source comme un échange plutôt qu’un panier-cadeau. Il soutient que les pull requests peuvent elles-mêmes devenir du travail supplémentaire et une source de friction, et qu’il est courant qu’un mainteneur dépense moins d’efforts à implémenter directement un changement qu’à relire un correctif soumis. C’est la partie que beaucoup de débats sur le codage par IA contournent poliment, comme un Roomba évitant une chaussette. Let’s Data Science rapporte que Zig comptait environ 200 pull requests ouvertes et un petit groupe de relecteurs principaux lorsque la politique a été formulée. Ce contexte fait que l’interdiction ressemble moins à une pureté esthétique qu’à de la gestion de file d’attente. Si un projet a déjà plus de demandes de revue que de relecteurs de confiance disponibles, les soumissions générées peuvent se comporter comme un test de charge synthétique pour humains, sauf que personne n’a déposé de plan de capacité. AI Weekly indique que Kelley a présenté la politique comme un triage des ressources, en citant la valeur de revue négative des soumissions par IA. Cette expression est la poutre porteuse ici. Un correctif généré peut être peu coûteux localement pour le contributeur et coûteux globalement pour les mainteneurs, ce qui est essentiellement la tragédie des biens communs, mais avec de l’autocomplétion et davantage de YAML.

Bun montre le risque côté amont, selon AI Weekly et Simon Willison

AI Weekly rapporte que Bun, propriété d’Anthropic et qui s’appuie sur des workflows assistés par IA, a forké Zig après avoir été incapable de faire intégrer ses changements en amont. Simon Willison note également que Bun exploite son propre fork de Zig et indique que Bun a été acquis par Anthropic en décembre 2025. Pour les équipes qui construisent des produits commerciaux sur des fondations open source, c’est la leçon de gouvernance qui a du mordant. Le fantasme habituel en entreprise est que l’amont est un tapis roulant amical : contribuer des améliorations, les faire fusionner, réduire la divergence, tout le monde se tape dans la main dans un couloir de conférence. La politique de Zig montre un autre mode d’échec. Si votre workflow d’ingénierie dépend de l’assistance par IA et qu’un projet amont rejette les contributions rédigées par LLM, vous devrez peut-être maintenir un fork, réécrire le travail manuellement, ou changer la manière dont les contributions sont préparées. Cela ne rend pas Zig anti-productivité dans un sens cosmique. Cela signifie que Zig optimise la confiance des mainteneurs plutôt que le débit des contributeurs. Ce sont deux valeurs réelles, et faire semblant qu’elles n’entrent jamais en conflit est la façon dont on se retrouve avec un backlog en forme de formation géologique.

Cela dépasse Zig, selon Research Information

Research Information rapporte qu’arXiv a averti les auteurs qu’ils pourraient faire face à une interdiction de soumission d’un an pour des travaux contenant des preuves claires de sortie de grand modèle de langage non vérifiée. Ce n’est pas le même domaine que les pull requests de compilateur, mais le schéma rime fort. Les institutions passent d’une étiquette de l’IA fondée sur l’ambiance à des règles explicites de responsabilité. Pour les créateurs d’IA, la leçon pratique n’est pas de paniquer ni d’organiser un bannissement rituel de chatbot sous la pleine lune. C’est de concevoir des workflows de contribution qui rendent la revue moins coûteuse : déclarer l’utilisation d’outils lorsque c’est autorisé, garder les correctifs petits, fournir des tests, expliquer l’intention, et être prêt à assumer chaque ligne comme si un perroquet stochastique ne l’avait pas chuchotée à l’existence. Si un projet interdit l’assistance par LLM, respectez cette limite ou contribuez ailleurs. La prochaine chose à surveiller est de voir si davantage de projets open source copient la ligne rouge nette de Zig ou choisissent des règles plus souples autour de la divulgation et de la vérification. Dans tous les cas, les outils de codage par IA quittent la scène de la démo et entrent dans la feuille de calcul de la gouvernance. Il s’avère que la partie la plus difficile du code généré reste les humains qui doivent y croire.