Les raisons de la politique anti-IA du projet Zig
(simonwillison.net)- Zig applique une règle stricte interdisant l’usage des LLM dans les issues, les Pull Requests, les commentaires du bug tracker et les traductions
- L’usage de l’anglais n’est qu’une recommandation, pas une obligation ; les contributeurs peuvent écrire dans leur langue maternelle, et les autres peuvent interpréter le contenu avec l’outil de traduction de leur choix
- Bun a ajouté à son fork interne de Zig une analyse sémantique parallèle et plusieurs unités de génération de code dans le backend LLVM, obtenant ainsi des performances de compilation 4 fois supérieures pour Bun, mais il n’existe actuellement aucun plan d’upstream en raison de l’interdiction des contributions rédigées par LLM
- La manière dont Zig mène les reviews vise moins à rejeter des PR incomplètes qu’à aider les nouveaux contributeurs à parvenir à un travail fusionnable, en accordant plus d’importance à la progression des contributeurs qu’aux contributions individuelles
- Les PR majoritairement rédigées par un LLM font que le temps de review ne sert plus à augmenter le nombre de nouveaux contributeurs fiables, et ouvrent aussi la possibilité pour les mainteneurs d’exécuter eux-mêmes un LLM pour résoudre le même problème
Conflit entre la politique et le fork de Bun
- Zig indique explicitement dans son Code of Conduct l’interdiction d’utiliser des LLM dans les issues, les Pull Requests, les commentaires du bug tracker et les traductions
- L’usage de l’anglais est recommandé, mais les contributeurs peuvent écrire dans leur langue maternelle
- Les autres peuvent interpréter le contenu avec l’outil de traduction de leur choix
- Parmi les projets emblématiques écrits en Zig figure le runtime JavaScript Bun, acquis par Anthropic en décembre 2025
- Bun maintient son propre fork de Zig et a ajouté au backend LLVM « parallel semantic analysis and multiple codegen units », obtenant une amélioration des performances de compilation par 4 pour Bun
- Le code correspondant est publié dans le lien de comparaison oven-sh/zig
- Bun n’a actuellement aucun plan d’upstream, car Zig interdit strictement les contributions rédigées par LLM
- Selon un contributeur principal de Zig, ce patch serait difficile à accepter même indépendamment de la question des LLM
- L’analyse sémantique parallèle est une fonctionnalité prévue de longue date, mais elle affecte le langage Zig lui-même
Contributor Poker et review centrée sur les contributeurs
- Le contributor poker présenté dans Contributor Poker and Zig's AI Ban est une métaphore clé pour comprendre la politique d’interdiction stricte de Zig
- Les projets open source qui réussissent finissent par recevoir plus de PR qu’ils ne peuvent en traiter
- Pour maximiser le ROI, Zig choisit non pas de rejeter les PR incomplètes, mais d’aider les nouveaux contributeurs à rendre leur travail fusionnable
- Cette approche est considérée non seulement comme « la bonne chose à faire », mais aussi comme « la chose intelligente à faire »
- Zig accorde plus d’importance aux contributeurs qu’aux contributions individuelles
- L’objectif principal des reviews et de l’acceptation des PR n’est pas d’ajouter du nouveau code, mais d’aider des personnes à devenir, avec le temps, des contributeurs fiables et productifs
- Chaque contributeur devient un objet d’investissement pour la core team de Zig
- L’assistance par LLM casse cette structure
- Même si un LLM aide à rédiger une PR parfaite, le temps que l’équipe Zig consacre à la review ne contribue pas à augmenter le nombre de nouveaux contributeurs compétents, confiants et fiables
- « contributor poker » vient d’une métaphore où l’on joue en regardant les personnes, pas les cartes
- L’idée est plus proche du fait de parier sur le contributeur que sur le contenu de sa première PR
- Si une PR est majoritairement rédigée par un LLM, un mainteneur du projet peut choisir, au lieu de reviewer et discuter cette PR, d’exécuter directement un LLM pour résoudre le même problème
2 commentaires
C’est parce que les humains sont le goulot d’étranglement. Comme ils pourraient ne plus pouvoir développer Zig à force de passer leur temps à relire un flot de PR poubelles, ils mettent en place à l’avance une politique de premier filtrage.
Avis sur Hacker News
Selon https://kristoff.it/blog/contributor-poker-and-ai/, les contributions basées sur des LLM ont été globalement négatives
Des PR opportunistes sans valeur ont augmenté le bruit de fond avec du code halluciné, ne compilaient pas ou ne passaient pas la CI, et on a même vu des primo-contributeurs envoyer des PR de 10 000 lignes
Il y avait aussi des PR qui semblaient correctes à première vue et précisaient ne pas utiliser de LLM, mais les discussions suivantes ont rapidement révélé que l’auteur s’était en réalité appuyé en douce sur un LLM et répétait des réponses erronées
Les hooks n’offrent pas de moyen propre d’imposer leur installation au clone, mais il peut y avoir les workflows GHA ou des fonctions équivalentes sur d’autres forges
Pour un projet d’une certaine taille et popularité, ça me semble être une exigence de base
Une grande partie du problème « l’IA ne sait pas contribuer » semble pouvoir être atténuée avec de meilleurs contrôles automatiques et garde-fous
À part le fait que l’IA a rendu possible ce nouveau type de spam, le fond du problème n’est pas l’IA
Même sans IA, si des gens embauchaient à bas coût des armées de développeurs offshore pour produire en masse des PR opportunistes de qualité moyenne, l’effet serait le même
On peut produire du bon code avec l’IA, mais comme n’importe quel autre outil, elle doit être utilisée avec discernement
Ici, ce n’est pas une contribution construite avec soin par quelqu’un qui connaît le projet et ses objectifs en utilisant bien l’outil, c’est du spam
Le bruit autour de la politique IA semble venir du fait que des développeurs de Bun disent ne pas pouvoir proposer en amont leur PR de performance à cause de cette politique
Mais la vraie raison semble être que le code de cette PR est lui-même en mauvais état et introduit une complexité malsaine https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
D’après l’explication citée, l’analyse sémantique parallèle est un plan explicite du compilateur Zig depuis longtemps et a fortement influencé la conception du compilateur Zig self-hosted, mais l’implémenter correctement nécessiterait des changements non seulement dans le compilateur, mais aussi dans le langage Zig lui-même
Il entre en conflit avec la propre feuille de route de Zig pour obtenir de meilleurs résultats et gêne la direction visant à continuer d’améliorer l’ensemble du langage
La politique interdit explicitement tout code LLM, donc c’est évidemment la « vraie raison »
Côté Zig, on a l’impression qu’ils suivent la voie de ZeroMQ https://zguide.zeromq.org/docs/chapter6
L’idée est « d’imposer une propriété collective du projet afin d’augmenter les incitations économiques des contributeurs et de réduire le risque de détournement par des acteurs hostiles »
Une communauté de contributeurs saine est plus importante que la simple performance du code, le nombre de fonctionnalités ou le nombre de lignes
Aujourd’hui, la « communauté » zeromq est assez clairsemée ; il y a encore quelques personnes formidables actives, mais les processus et canaux de communication à l’échelle humaine ne sont ni bien définis ni suffisamment animés
Comme libzmq et la plupart des bindings sont stables, ce manque d’activité et d’interaction humaines peut être dans une certaine mesure acceptable ou justifiable, mais la vision remarquable de Hintjens a amené zeromq jusque-là, et depuis sa disparition le projet donne une impression de dérive
Ironiquement, pour une vision centrée sur la communauté, il semble qu’il faille un leader charismatique et actif pour obtenir et conserver une communauté, ce qui en dit peut-être plus sur la nature humaine que sur le développement logiciel
Pour revenir à Zig, l’hypothèse est qu’ils ne manquent pas de PR et peuvent donc filtrer en amont les contributions no-LLM
C’est un bon choix pour eux, et l’idée de « contributor poker » se comprend
Mais si les nouveaux arrivants se raréfient, la donne change, et à ce moment-là les gens de Zig pourraient devoir élargir le filet s’ils veulent encore de nouveaux contributeurs
Cela dit, si ce moment arrive, il sera peut-être déjà trop tard pour se relancer en ouvrant la porte aux contributions assistées par LLM
Ce qui m’intrigue dans les contributions OSS générées par l’IA, c’est ceci
Si l’IA augmente vraiment autant la productivité des développeurs, pourquoi un maintainer voudrait-il intercaler entre lui et un LLM un contributeur qu’il ne connaît pas ?
Le maintainer peut simplement interroger Claude Code lui-même
Pour reprendre les mots d’un collègue : « Nous n’avons pas besoin d’intermédiaires pour parler aux modèles d’IA, et le codage n’est pas le goulot d’étranglement »
Il produit avec l’IA une première mauvaise version, ajuste les prompts, corrige manuellement, lui fait corriger d’autres parties, découvre des fonctions connexes et lui fait les ajouter, puis lance des benchmarks pour retirer une petite fonctionnalité ou choisir entre deux implémentations proches
Il ajoute encore des corrections manuelles ici et là, exécute des tests automatiques étendus pour trouver des bugs bizarres dans des configurations atypiques, puis les corrige avec l’IA et à la main
Après ces 20 heures, la version finale ne fait que 50 lignes et chaque ligne a peut-être été réécrite 5 fois
Le maintainer n’a alors plus qu’à relire la version finale pendant environ 1 heure
C’est totalement différent de passer 5 minutes à faire écrire un patch par une IA et d’envoyer au maintainer 1000 lignes qui ne compilent même pas sans les avoir relues
« C’est tellement facile que j’aurais pu le faire moi-même »
Certes, mais tu ne l’as pas fait
Mais ce n’est pas le genre d’outil auquel on peut juste lancer des consignes de haut niveau comme à un humain
Les gens qui prétendent que l’IA fonctionne avec de simples instructions de haut niveau travaillent peut-être surtout sur des projets « sans réflexion », où le développeur n’a pas besoin de beaucoup penser aux détails
J’espère aussi que tu ne veux pas dire que le seul intérêt des LLM est de générer le code pénible à taper soi-même
L’explication selon laquelle « Zig accorde plus d’importance aux contributeurs qu’aux contributions. Le but principal de la revue et de l’acceptation des PR n’est pas d’ajouter du nouveau code, mais d’aider les gens à devenir avec le temps des contributeurs fiables et productifs. L’assistance par LLM casse complètement cela. Même si le LLM aidait à soumettre une PR parfaite, ce serait toujours le cas » est la meilleure justification que j’aie vue jusqu’ici
Je soutiens pleinement la décision de Zig et j’apprécie leur vision de long terme, pour la communauté comme pour le projet lui-même
Honnêtement, je ne pense pas que les LLM soient si bien adaptés au travail réellement collaboratif
On verra comment cela évolue, mais quand j’accepte des PR générées par IA, je finis souvent par devoir les refaire moi-même, et ironiquement avec un LLM, ce qui me rend de plus en plus ambivalent
Malgré tout, je pense qu’au moins pour les 5 prochaines années, la politique de Zig est une bonne idée
Je pense que c’est probablement la formulation la moins hostile qu’ils puissent employer, et je respecte cela comme une décision concernant leur projet
Mais j’ai quand même l’impression que cela bride inutilement le projet
Les LLM sont des outils, ils peuvent aider à réfléchir, faire des recherches et coder
On peut en abuser, mais il faut les accepter là où ils sont utiles
Refuser la PR de Bun pour d’autres raisons est parfaitement légitime, mais interdire simplement toutes les PR écrites avec un LLM est inutilement restrictif
Il suffit de se concentrer sur la qualité du travail
Si le maintainer utilise lui-même un LLM pour faire la même chose, il pourra probablement le faire avec une meilleure conception et une approche plus réfléchie
Un maintainer ne passe pas son temps à faire de la revue de PR à faible effort ; il doit aussi consacrer du temps au développement
Le flot de code LLM déplace l’équilibre au détriment des maintainers, et je comprends très bien pourquoi ils voudraient simplement l’interdire
Mon impression générale après avoir fait tourner des LLM et des coding agents pendant un moment, c’est que ce sont des outils électriques ou des grues, pas des outils de prise de décision
Dans une organisation, les personnes qui ont une excellente compréhension conceptuelle et une compréhension d’ingénierie en profondeur voient leur productivité exploser
À l’inverse, ceux qui comprennent mal, ou les débutants, ou les juniors, produisent un code infernal dès lors que « ça tourne »
Les LLM créent un écart intellectuel dans les organisations, et plus on les utilise, plus cet écart se creuse
On pourrait finir par ne plus faire confiance à la production interne de l’organisation à cause du code généré plus tard
L’IA amplifie généralement les compétences, dans le bon comme dans le mauvais sens
Un cas d’usage récent vraiment excellent a été la rédaction du concept d’un authentication daemon
J’ai discuté avec Codex, sélectionné ses propositions, recoupé avec une recherche web classique, arrêté une version finale, puis en ai discuté avec mes collègues
Ce planning conversationnel avec recherche web intégrée est extrêmement utile, et je vois aussi un bénéfice net à faire relire par l’IA du code déjà écrit
Mais la mise en garde fondamentale avec l’IA, c’est qu’au final il faut être plus intelligent que l’outil
Si Codex suggère d’utiliser la tech stack X, il faut enquêter sur les raisons pour lesquelles c’est réellement bon, les comprendre complètement, et comparer avec d’autres solutions
Beaucoup de gens sautent cette étape, ce qui crée énormément de problèmes, et c’est fatal
À la fin de la conversation, tu dois être devenu plus intelligent que l’IA, et capable de comprendre et critiquer entièrement ce qu’elle a dit
Une fois l’architecture fixée, les LLM se débrouillent plutôt bien pour l’implémentation
On peut généralement leur faire produire un excellent code, bien testé, parfois bien meilleur que ce qu’on aurait fait seul dans le même temps
Mais suivre en permanence tout ce que l’IA a produit reste un défi
La logique « si une PR est en grande partie écrite par un LLM, pourquoi le maintainer ne lancerait-il pas simplement son propre LLM pour résoudre le même problème au lieu de passer du temps à relire et discuter la PR ? » s’applique aussi à l’open source lui-même
Pourquoi utiliser le projet de quelqu’un d’autre si un robot peut l’écrire directement ?
Surtout si ce projet open source est vibe coded
L’IA et la tech en général rendent la personnalisation bon marché et facile
Autrefois, tout le monde devait utiliser des produits de masse à peu près satisfaisants pour tous, mais maintenant on peut espérer obtenir quelque chose d’excellent rien que pour soi
En outre, le fait que beaucoup de gens recréent des projets open source avec des LLM stimule aussi l’économie du travail à divers endroits
Les LLM peuvent produire ça en quelques minutes
Ce que je veux avant tout, c’est un historique d’usage
Je veux utiliser un logiciel que d’autres ont utilisé avant moi, en espérant qu’ils aient rencontré les bugs et les angles morts et les aient polis
Du style : qui achèterait encore des objets si on peut télécharger un modèle chez soi, l’imprimer et le personnaliser à l’infini ?
Si nous avons une civilisation, c’est pour pouvoir déléguer la plupart des problèmes de la vie à quelqu’un d’autre et se concentrer soi-même sur une seule chose qu’on fait bien
Si tu es dentiste ou que tu tiens un muffler shop, ton temps quotidien est limité et tu préfèreras probablement payer un fournisseur SaaS plutôt que d’apprendre le vibecoding et de superviser un subordonné étrange et très demandeur
Il existe des exceptions, mais ce ne sont que des exceptions
Si un vendor conçoit un produit raisonnable et compétent, je paierai volontiers
C’est pareil pour l’open source
Même si un LLM pouvait créer de façon fiable un nouveau système d’exploitation à partir de zéro, est-ce vraiment ce que je voudrais ?
Je n’ai pas envie de maintenir un OS, ni de gérer quelqu’un qui maintient un OS, et je ne crois même pas avoir dès le départ une vision cohérente de ce que devrait être cet OS
Au-delà d’un certain niveau de complexité, il est difficile d’espérer qu’un robot lise suffisamment dans mes pensées pour produire un résultat de haute qualité « excellent pour moi »
Le projet Zig est clairement bien au-delà de cette capacité
Certains ne peuvent pas se permettre le coût, et même quand on y a accès il y a parfois, voire durablement, des problèmes comme les pannes de Claude ou une dégradation générale des performances avec le temps
Il y a quelques mois, quand j’ai commencé à utiliser Claude, j’avançais facilement sur plusieurs projets en une semaine, mais aujourd’hui j’ai surtout l’impression de regarder un spinner et la qualité du code a chuté brutalement, au point que je n’arrive presque plus à rien faire
J’ai quelques dépôts à environ 100 étoiles, rien d’exceptionnel, mais jusqu’à l’an dernier je recevais occasionnellement des PR, alors que cette année jusqu’ici il n’y en a presque pas
Mon hypothèse est que les LLM préfèrent s’accrocher aux projets grand public
Comme beaucoup de développeurs dépendent maintenant fortement des LLM, il y a un biais croissant en faveur d’ignorer l’essentiel de ce que je propose
On voit aussi davantage de réinvention de roue avec les LLM, simplement parce que le coût de repartir de zéro a baissé
Il devient donc plus simple de juste générer ce dont on a besoin au lieu d’utiliser quelque chose d’obscur sur GitHub, par exemple quelque chose comme le mien
Je constate le même phénomène dans mes choix de dépendances
Sauf très bonne raison, j’ai tendance à prendre ce que le LLM me suggère
Je suis d’accord dans une certaine mesure, mais pas complètement
Faire grandir les contributeurs est bien la bonne priorité
Mais je vois l’IA comme une technologie d’assistance
Un peu comme un screen reader ou une magnifying glass, même si bien sûr il y a beaucoup de différences
On peut aussi la voir comme un exosquelette robotique
Elle servira à de mauvaises choses et à des choses stupides, mais elle servira aussi à permettre à des gens qui n’auraient pas pu auparavant de faire de bonnes choses ou de devenir plus compétents
Pour certaines personnes, l’IA rend possible un codage qu’elles ne pouvaient pas faire auparavant ; pour beaucoup, elle devient un moyen d’apprendre à coder en regardant ce qu’elle fait ; pour d’autres encore, elle leur permet de coder beaucoup plus vite ou mieux
Chez certains, certaines compétences pourraient régresser pendant que d’autres se développent
On aurait le même problème avec des exosquelettes si des produits corrects arrivaient sur le marché, mais globalement ce seraient des outils capacitants
Je ne vois pas pourquoi former des contributeurs qui utilisent des technologies d’assistance serait pire que former des contributeurs qui n’en utilisent pas
Bien sûr, cela peut être plus difficile
Les LLM ne sont pas aussi intelligents que ce qu’affirment les vendors de LLM
Si c’était vraiment le cas, ils seraient entièrement autonomes et nous n’aurions pas cette discussion
Les gens qui soumettent aveuglément du code généré par LLM ou qui n’indiquent pas qu’ils l’ont utilisé doivent vraiment arrêter
Le problème restant, c’est que cela reste un outil
Si on demande à un développeur pris au hasard de « rendre Zig plus rapide avec une PR one-shot », cela ne donnera pas un bon résultat
Par le passé, les projets OSS s’auto-filtraient parce qu’il fallait être capable de produire du code fonctionnel, et à ce stade on avait généralement appris pendant des années à faire à peu près ce qu’il faut, avec un certain raisonnement sur les fonctionnalités ou les besoins
Aujourd’hui, même si les LLM étaient parfaits et excellents en reasoning, ils exécuteraient quand même les instructions de la personne qui les utilise
Cette auto-sélection a disparu
Il sera de plus en plus difficile pour les développeurs de Zig de distinguer ce qui est du code produit par LLM de ce qui est du code écrit par un humain
Il y a peut-être déjà du code généré par LLM qui est entré, mais au moins ces soumissionnaires humains doivent encore assez bien maîtriser le code
Je me demande si au final on ira vers « seuls les humains avec un badge d’honneur de confiance peuvent commit », ou vers un niveau où « le LLM raisonne suffisamment pour dire : non, va-t’en. Cette fonctionnalité, ce plan, cette idée, c’est de la poubelle, je ne la construirai pas »
S’il n’existe aucun moyen de leur infliger une vraie conséquence quand ils le font, je ne vois pas ce qui les arrêterait