- Le moteur de jeu open source Godot a décidé d’interdire dans sa politique de contribution le code écrit par l’IA et les soumissions par agents IA, après que les Pull Requests générées par l’IA ont accru la charge de revue
- Les mainteneurs estiment que l’examen des PR générées par l’IA rend un travail de revue déjà fastidieux encore plus épuisant, et réduit aussi l’effet qui consiste à former de nouveaux contributeurs pour en faire de futurs mainteneurs
- La nouvelle politique prévoit de refuser explicitement le code écrit par l’IA, les Pull Requests soumises par des agents IA, ainsi que le texte généré par l’IA dans les communications entre personnes
- Les contributeurs ne pourront utiliser l’IA qu’en appoint pour des « menial things » et devront en déclarer l’usage ; la traduction automatique basée sur un texte original écrit par une personne restera autorisée
- La Godot Foundation indique qu’elle adoptera d’abord une approche prudente, les outils d’IA évoluant rapidement, et qu’elle réévaluera sa politique en fonction de l’évolution de la situation
Changement de la politique de contribution de Godot
- Après plusieurs mois de discussions, la Godot Foundation et les mainteneurs ont décidé de modifier les directives de contribution afin de limiter les soumissions liées à l’IA
- Sont visés le code écrit par l’IA, les Pull Requests soumises par des agents IA et le texte généré par l’IA dans les communications entre personnes
- Godot est un moteur de jeu open source utilisé par des jeux comme Slay the Spire 2 et The Case of the Golden Idol
La charge de maintenance créée par les Pull Requests IA
- Depuis février, les mainteneurs discutent de la façon de répondre à l’augmentation des Pull Requests d’AI slop
- Ce flux de PR est devenu « increasingly draining and demoralizing » pour les relecteurs de code du projet
- La Godot Foundation estime que le problème n’est pas temporaire et cherche à réduire la charge des mainteneurs tout en préservant le parcours permettant de faire de nouveaux contributeurs de futurs mainteneurs
Le problème d’une revue qui ne débouche pas sur du mentorat
- Le nombre élevé de PR en attente de revue peut en soi être vu comme le signe d’un intérêt croissant pour l’utilisation de Godot et la contribution au projet
- Mais avec l’augmentation des contributions écrites ou soumises par l’IA, les mainteneurs sont moins enclins à consacrer du temps à la revue de PR
- Si les retours sur les PR ne servent pas à mentorer de potentiels futurs mainteneurs et sont plutôt « absorbés par une machine », il devient difficile de justifier le fait de consacrer son temps libre aux revues
Les restrictions concrètes de la nouvelle politique
- La politique de contribution de Godot inclura bientôt un refus explicite du AI-authored code
- Les contributeurs devront limiter l’assistance de l’IA aux « menial things » et déclarer son usage
- La Foundation déclare que « l’IA ne peut pas assumer de responsabilité, et nous ne pouvons pas faire confiance aux grands utilisateurs de l’IA pour comprendre suffisamment leur code afin de le corriger »
- Le texte généré par l’IA sera également refusé dans les communications entre personnes
- La Foundation décrit cela comme « a basic principle of respect »
- La traduction automatique fondée sur un texte original écrit par une personne restera autorisée
Orientation de la politique
- La Godot Foundation se concentre sur l’ajout de barrières aux contributions « slop » demandant peu d’effort
- Permettre aux mainteneurs de continuer les revues de code et faire grandir de nouveaux contributeurs pour en faire de futurs mainteneurs font aussi partie des objectifs de la politique
- Toute contribution doit venir d’une personne qui assume la responsabilité de son code et peut le corriger elle-même en cas d’échec
- La Foundation indique que les outils d’IA évoluent aujourd’hui quotidiennement ; elle maintiendra donc une politique prudente, tout en la réévaluant au fil des changements
1 commentaires
Réactions sur Hacker News
Cette politique est équitable. Se faire demander d’examiner à fond un mur de texte rédigé par IA interminable, c’est vraiment pénible, et ça ressemble à une attaque par déni de service contre l’esprit humain
Cela dit, ça ne bloquera sans doute pas le coding assisté par IA en lui-même. Dans le pire des cas, les auteurs pourraient simplement ajouter des marqueurs de style pour avoir l’air humains, en gardant le fond et l’ampleur de la contribution inchangés, avec juste un style plus étrange
Dans le meilleur des cas, cela pourrait produire des commits et des commentaires sans fioritures du type « voici le code, voici pourquoi je l’ai modifié, et voici l’impact ». Même si c’est généré par IA, ce genre de petite contribution devient bien plus facile à valider, et cela pourrait aussi créer une norme sur la bonne taille d’une contribution ou sur les changements qui exigent une revue plus stricte
Personnellement, tant que le contenu correspond au second cas, le fait qu’il soit généré par IA m’importe peu
Voir arriver de vrais « commits et commentaires sans fioritures », ce serait le rêve
Dans ce contexte, repousser les contributions IA est justifié, et encore plus pour un logiciel comme Godot, qui a déjà largement démontré sa valeur
Si un commit écrit par IA n’est pas fondamentalement différent, il n’y a pas non plus de raison de le refuser, donc je ne pense pas que l’objectif soit d’empêcher le coding assisté par IA
Il est intéressant de voir que, d’un côté, la valorisation des entreprises d’IA repose sur l’hypothèse que, dans un futur proche, tout le code et tous les contenus numériques seront écrits par l’IA, tandis que, de l’autre, presque tous les projets open source populaires essaient de bloquer les contributions IA. Les deux sont difficiles à concilier
Personnellement, après en avoir beaucoup utilisé dans mes propres projets open source, je ressens aussi une sorte de gueule de bois de l’IA. Sur le moment, on a l’impression d’avoir acquis une puissance extraordinaire, de construire en quelques heures une fonctionnalité qui aurait pris des semaines, puis, avec le recul, on regarde le code et on voit les fissures subtiles et les incohérences laissées par l’outil, ce qui devient embarrassant
Désormais, j’essaie de moins l’utiliser pour développer de grosses fonctionnalités, et davantage dans des domaines où l’on peut mettre en place des garde-fous stricts, comme la planification, le débogage ou le refactoring à périmètre réduit. Ça accélère quand même le travail, mais on est plus près de 1,5 à 3 fois plus vite que de 10 fois
La concentration mentale nécessaire au codage diminue, mais cela crée une nouvelle forme de fatigue liée au fait de discuter sans cesse avec la machine, sans savoir comment elle va interpréter les instructions en langage naturel. Cela donne l’impression d’essayer de piloter, avec des combinaisons de boutons, une machine dont le câblage interne change en permanence, et ce n’est pas satisfaisant
Ce que l’IA a rendu possible, ce sont les contributions de personnes qui n’ont absolument aucun lien avec le projet. Le simple fait d’avoir ouvert une PR ne suffit donc plus à considérer que « cette personne se soucie au moins un peu de la réussite du projet »
Bien utilisée, l’IA est un amplificateur, mais du point de vue des mainteneurs open source, elle permet surtout d’être facilement submergés par une masse de « contributions » de faible valeur produites par des gens qui ne se soucient pas du projet
En particulier à cause de la tendance à la flatterie de l’IA, qui répond sans cesse « bonne idée ! », alors que je sais très bien que la plupart de mes idées ne sont pas extraordinaires
Quand je vois des gens raconter qu’ils font du vibe coding sur leur téléphone tout en s’occupant de leurs enfants, ça me paraît presque relever de la compulsion
Et de toute façon, dans l’open source, la vitesse n’a jamais eu tant d’importance que ça, et il y avait de bonnes raisons à cela
Il y a aussi un problème de structure dopaminergique : dès qu’on travaille ou qu’on démarre un nouveau projet, on est trop facilement tenté de se tourner vers l’IA
En ce moment, j’essaie de réentraîner mon cerveau à préférer écrire la majeure partie du code à la main plutôt que d’ouvrir Claude en premier. Le temps dira si ce n’est qu’une phase passagère, ou s’il faudra finir par créer une sorte de groupe de parole anonyme pour utilisateurs de LLM
Il existe des listes qui recensent les logiciels sans IA. Ce serait intéressant de les indexer ou d’en faire des graphiques pour voir comment cela évolue avec le temps
https://codeberg.org/brib/slopfree-software-index
https://noai.starlightnet.work/list.html
https://hcker.news/?ai=exclude&include_domains=github.com
Pour des raisons fonctionnelles, une politique no-AI ne me vient pas naturellement à l’esprit. Peu importe qui l’a fait ou quoi l’a fait : si ça tourne, ça tourne
Même si l’on évite les déchets générés par IA, cela n’empêche pas de laisser passer des déchets produits par des humains ou par des humains + IA qui franchissent quand même le filtre
En revanche, on peut tout à fait imaginer des raisons non fonctionnelles : la provenance, la responsabilité, la preuve de travail, l’encouragement à ce que les gens écrivent eux-mêmes le code, ou encore le suivi empirique de la manière dont les humains font évoluer une base de code
L’essentiel est dans cette remarque de la Foundation : « Si les retours sur les PR ne servent plus à accompagner quelqu’un qui pourrait devenir un futur mainteneur, mais sont simplement absorbés par une machine, il devient bien plus difficile de justifier de consacrer son temps libre aux revues de PR »
Si vous ne comprenez pas, regardez simplement ceux-ci
https://github.com/godotengine/godot/pull/115280
https://github.com/godotengine/godot/pull/116410
Ce n’est pas juste envers les mainteneurs de leur demander de continuer à gérer ce genre de choses dans des projets déjà submergés par trop de PR à relire avant même l’ère de l’IA
Donc, le vrai grand changement de la politique, c’est la partie qui empêche les nouveaux contributeurs de prendre en charge de grosses fonctionnalités ou des refactorings
Avec les informations restées dans le dépôt, on pouvait retrouver son pseudonyme et ses comptes sociaux, et c’était un enfant qui n’avait même pas encore le début de l’adolescence. Il semble ne pas encore avoir les bases nécessaires pour comprendre le problème ou les structures sociales en jeu
C’est un cas où la loi de Brandolini s’applique parfaitement
Réfuter des absurdités demande dix fois plus d’efforts que les produire. La revue de code est une réfutation, et vérifier l’exactitude d’une proposition revient au même
Produire une proposition est facile, mais la réfuter impose de prouver qu’elle est vraie ou fausse, ou d’y trouver une contradiction. Cela gaspille inutilement l’énergie de mainteneurs open source qui manquent déjà de temps, donc je suis entièrement d’accord avec l’idée d’économiser cette énergie pour l’utiliser de manière productive
L’IA a découvert par hasard l’une des ressources les plus chères du secteur : le temps libre des gens qui maintiennent de l’open source le soir après leur vrai travail
La Foundation a pointé quelque chose qui a toujours été vrai, mais que l’IA a mis en pleine lumière. N’importe quel contributeur, IA comprise, peut très bien ne pas être capable de maintenir ensuite le patch qu’il soumet
Le cœur du problème n’est pas l’usage de l’IA en soi, mais le fait que c’est l’un des signes que l’auteur ne comprend pas vraiment ce qu’il soumet. Briser les conventions de nommage des variables, modifier des API qu’il ne faut pas toucher, ou faire des erreurs de langage de débutant peuvent tous justifier un refus, même si le patch fonctionne
Comme parade, on peut marquer qu’une PR est refusée à cause de l’IA, puis demander à l’auteur de citer un point dont il est particulièrement fier et d’expliquer avec ses propres mots — et non avec un mur de texte généré par IA — ce qu’il fait et pourquoi c’est bien. L’auteur doit montrer des goûts et des opinions que l’IA n’a pas
J’ai l’impression qu’ici beaucoup de gens réagissent au titre au lieu de lire la politique elle-même. La politique dit que l’une des raisons importantes est que les revues de PR servent à la formation des nouveaux contributeurs et à repérer de potentiels futurs mainteneurs
Indépendamment de la qualité des contributions générées par IA, ce point semble difficile à contester
Sauf si l’on croit que l’IA va rendre inutile toute l’idée même de contribution ou de maintenance open source ; mais dans ce cas, il serait sans doute plus logique de forker le moteur et de laisser des agents travailler dessus plutôt que d’envoyer des PR à Godot
Les contributeurs IA pensent-ils vraiment aider ? Ne voient-ils pas qu’ils abîment le projet avec ce genre de « travail » ?
Je ne comprends pas pourquoi ils dépensent de l’argent pour quelque chose que personne ne veut et qui sera refusé. Ils n’ont pas de hobby ? Ou bien ce sont des instances OpenClaw laissées en liberté parce que leur créateur les a oubliées ?
Ces gens récoltent des contributions à de grands projets FOSS pour gonfler leur CV. On voit la même chose dans les signalements de vulnérabilités
Les producteurs de masse pensent peut-être sincèrement aider, ou savent peut-être que leur « contribution » est une perte nette pour le projet. Mais quand l’incitation économique directe existe et que leur situation est précaire, les externalités passent au second plan
Claude l’a fait en une heure, et j’ai ensuite retouché 3 ou 4 fois pour réduire le mur de texte et coller au style du projet d’origine. L’alternative aurait été de simplement l’ignorer ou d’ouvrir une issue en laissant la charge au mainteneur
Donc oui, j’estime avoir aidé. J’ai d’ailleurs découvert ce cas limite en bricolant mon homelab, qui est mon hobby
Les deux PR étaient petites et ne différaient pas de PR humaines. Je continue à penser que c’étaient des ajouts utiles, et certains mainteneurs ont manifestement pensé la même chose
Ils ne veulent pas coder ni améliorer un produit, ils veulent un « nombre de lignes de code », des « commits » et un joli profil GitHub tout vert, même sans comprendre les détails