L’arrêt du classement IA de decomp.dev révèle un jeu de chiffres creux

decomp.dev a gelé son index public et son classement après deux ans, estimant que l’IA avait transformé des progrès mesurables en une compétition nuisible. L’arrêt du classement IA de decomp.dev n’efface ni le site ni ses archives historiques. Il retire le tableau de scores partagé qui aidait autrefois les spécialistes de la rétro-ingénierie à trouver des projets, suivre leur avancement et célébrer un travail difficile.

Son créateur, Luke « encounter » Street, affirme que l’IA n’est pas à elle seule le problème. Utilisée avec une supervision humaine et une revue du code, elle peut accélérer considérablement la décompilation de jeux. Le conflit commence lorsque cette vitesse récompense plus visiblement les forks hostiles, le code peu vérifié et les ports PC précipités que la recherche rigoureuse.

Cette distinction compte au-delà du retrogaming. Les projets ouverts utilisent souvent des métriques publiques pour motiver les contributeurs, mais ces métriques supposent que chaque unité de progrès représente un effort globalement comparable. L’IA brise cette hypothèse. Dès lors que les pourcentages d’achèvement peuvent augmenter par des méthodes très différentes, un classement cesse de mesurer une réussite collective et commence à orienter les comportements autour d’un chiffre peu fiable.

Ce que change réellement l’arrêt du classement IA de decomp.dev

decomp.dev abandonne ses fonctions publiques de découverte et de classement, sans supprimer tous les enregistrements de projets qu’il a collectés.

Street a lancé decomp.dev en 2024 afin de centraliser le suivi de la progression des décompilations correspondantes. La décompilation correspondante consiste à réécrire un programme de sorte que le nouveau code source produise un code machine identique au binaire original lorsqu’il est compilé dans les bonnes conditions.

Ce travail diffère d’une demande adressée à un décompilateur pour produire du code approximativement lisible. Les développeurs étudient l’assembleur, déduisent les structures de données, reconstituent le flux de contrôle, identifient le comportement du compilateur et ajustent sans cesse le code source. Un projet peut consacrer plusieurs jours à faire correspondre une seule fonction récalcitrante, car une petite différence au niveau du source modifie la sortie du compilateur.

Le site rendait ce processus lent lisible. Les visiteurs pouvaient voir les pourcentages d’achèvement, l’activité récente et les évolutions historiques de nombreux projets. Une fraction de point de pourcentage pouvait représenter une enquête approfondie ; voir ce chiffre progresser offrait donc aux contributeurs une forme utile de reconnaissance.

L’avis d’arrêt du 15 octobre de Street indique que l’index central et la prise en charge de l’ajout de projets sont désactivés. Les pages de projets existantes et les informations historiques resteront accessibles et continueront de suivre les projets connus. La décision suspend donc la compétition publique tout en préservant une grande partie des archives.

Cette nuance a parfois été perdue dans les premières couvertures. decomp.dev ne disparaît pas simplement du jour au lendemain. Son créateur retire les éléments qui transforment des projets indépendants en une seule course visible.

Selon l’avis, l’index a attiré des personnes qui voulaient réellement apprendre et contribuer. Il a également attiré des participants qui traitaient le pourcentage comme un objectif détaché de la recherche qui le sous-tend. Street a conclu que l’index public et le classement causaient plus de tort que de bien.

Cette décision fait suite à des plaintes concernant des personnes qui forkent des dépôts existants et utilisent l’IA pour « terminer » un travail commencé par une autre équipe. Les licences open source peuvent autoriser les forks, mais l’autorisation légale ne règle pas les questions d’attribution, de consentement de la communauté ou de gestion responsable.

Un fork peut aussi attirer l’attention avant que l’équipe d’origine ait eu le temps d’évaluer le code généré. Cela crée une incitation difficile. Les mainteneurs doivent soit accélérer leur propre travail, soit consacrer du temps à auditer la production d’autrui, soit regarder un projet dérivé approximatif s’emparer du récit public.

La couverture de l’arrêt décrit une autre source de tension : des opportunistes qui se précipitent pour publier des ports à peine fonctionnels fondés sur les recherches de la communauté. Un écran-titre jouable ou une bande-annonce soignée peut circuler bien plus vite qu’une explication rigoureuse des lacunes de précision.

Geler le classement retire un amplificateur à cette course. Cela n’empêche ni la décompilation assistée par IA, ni les forks de dépôts, ni les ports concurrents. Cela empêche simplement decomp.dev d’attribuer à ces efforts une position publique commune.

Pourquoi decomp.dev a supprimé le tableau de scores plutôt que d’interdire l’IA

Une interdiction générale de l’IA traiterait l’assistance responsable et la génération non vérifiée comme une seule et même pratique, tout en obligeant un seul amateur à surveiller une frontière instable.

Street reconnaît explicitement que l’IA peut aider à la décompilation lorsque des personnes compétentes la guident et examinent les résultats. Un modèle peut suggérer des noms, rédiger des traductions, expliquer des instructions peu familières ou générer du code candidat qu’un humain peut tester. Ces usages peuvent réduire le travail répétitif sans remplacer le jugement technique.

Le problème est que « assisté par IA » couvre un spectre très large. Un projet peut utiliser un modèle pour expliquer une optimisation du compilateur après des heures d’analyse manuelle. Un autre peut accepter de gros correctifs générés sans en comprendre le comportement. Les deux peuvent porter la même étiquette.

Les preuves présentes dans les dépôts sont aussi incomplètes. Un projet peut divulguer l’usage de modèles dans sa documentation, les métadonnées de ses commits ou les notes de ses contributeurs. Un autre peut l’omettre entièrement. Du code écrit par des humains peut être médiocre, tandis que du code généré peut faire l’objet d’une revue attentive. Un simple badge oui-ou-non ne peut pas établir la qualité.

La modération dépend alors de jugements subjectifs sur l’intention, la compétence et le niveau d’assistance acceptable. Street estime que décider quels projets méritent de la visibilité ne devrait pas devenir la responsabilité d’un seul amateur. Toute politique d’exclusion susciterait des litiges de la part des partisans comme des critiques de l’IA.

Une interdiction passerait également à côté de la faiblesse plus profonde du système. Le classement mesurait les progrès de correspondance, et non la maintenabilité, l’attribution, la documentation, les tests ou le support à long terme. Même une détection parfaite du code généré par IA ne permettrait pas à un pourcentage unique de représenter toutes ces qualités.

Street a plutôt retiré la surface compétitive. C’est une intervention plus limitée que de surveiller chaque dépôt, mais elle vise l’incitation créée par decomp.dev lui-même. Sans classement public, les participants reçoivent moins de récompense à l’échelle de la plateforme lorsqu’ils font grimper un chiffre avant que leur travail ne soit prêt.

Ce choix rappelle un schéma de modération bien connu. Lorsqu’une plateforme ne peut pas classer de façon fiable chaque soumission douteuse, elle peut réduire la visibilité de la métrique qui encourage ces soumissions. Cette approche sacrifie les avantages de découverte afin de protéger les normes de la communauté.

Elle reconnaît également une vérité difficile sur la collaboration ouverte. L’ouverture fournit la matière qui permet aux nouveaux venus d’apprendre, de vérifier les résultats et de s’appuyer sur les travaux antérieurs. Cette même ouverture permet à un fork opportuniste d’absorber des années de connaissances accumulées et de pousser ses mainteneurs vers une finalité plus commercialisable.

L’IA raccourcit cette seconde voie. Elle peut transformer l’historique d’un dépôt, des fonctions partiellement mises en correspondance, de la documentation et des discussions d’issues en contexte pour une génération rapide. Le code produit exige toujours une validation, mais il devient plus facile de produire quelque chose qui semble terminé.

Cela ne fait pas de chaque fork un acte hostile. Le fork demeure une protection importante lorsque les mainteneurs disparaissent ou que les projets refusent des changements utiles. Des implémentations indépendantes peuvent aussi tester différentes approches techniques.

Le comportement contesté est plus précis. Il consiste à utiliser le travail inachevé d’une autre équipe pour revendiquer l’achèvement, attirer l’attention ou publier un port tout en contribuant peu en retour à l’effort initial. L’IA réduit le temps et l’expertise nécessaires pour tenter cette manœuvre.

La décision de decomp.dev évite donc de présenter le différend comme une opposition entre humains et machines. Son conflit principal oppose la recherche rigoureuse à la mise en scène de l’achèvement. L’IA compte parce qu’elle rend cette mise en scène plus rapide, moins coûteuse et plus facile à industrialiser.

L’impact de l’IA sur la décompilation de jeux dépasse le simple code plus rapide

L’IA modifie le sens du progrès lorsqu’un pourcentage d’achèvement ne reflète plus un processus de recherche commun.

Le modèle initial de decomp.dev transformait la patience en jeu. Les contributeurs pouvaient voir un projet difficile avancer par petites étapes, sachant que chaque amélioration avait passé les vérifications de compilation et de correspondance. Le tableau de scores transformait un travail technique invisible en signal partagé.

Ce mécanisme fonctionnait tant que les progrès restaient rares. Cette rareté donnait du sens à chaque incrément. Les contributeurs devaient comprendre suffisamment le programme ciblé, le compilateur, l’architecture et le projet environnant pour produire du code répondant à des exigences strictes de correspondance.

L’IA ne supprime pas nécessairement ces exigences. Le code machine correspond à la cible ou n’y correspond pas. Toutefois, un modèle peut générer et réviser rapidement de nombreux candidats, surtout lorsqu’un humain fournit les sorties d’outils et délimite la tâche.

Street affirme que cette approche guidée peut accélérer la décompilation « de manière significative ». Le changement important n’est pas que la justesse devienne soudain facultative. C’est que le chemin vers un résultat correct peut impliquer beaucoup moins de reconstruction humaine directe.

Cela rend le pourcentage ambigu. Il peut toujours décrire la part de code qui correspond, mais il en dit moins sur la manière dont les contributeurs sont parvenus à ce stade. Les lecteurs peuvent en déduire une profondeur de compréhension, de documentation ou de revue que le chiffre n’a jamais garantie.

L’ambiguïté grandit lorsque « décompilation » devient un raccourci pour « port PC ». Un projet de décompilation reconstitue et étudie avant tout le code d’un jeu. Un port source adapte du code reconstitué pour l’exécuter sur une autre plateforme. La recompilation statique traduit le code machine à l’avance, produisant souvent un résultat jouable sans générer le même type de code source lisible.

Ces voies peuvent se chevaucher, mais elles ne sont pas interchangeables. Une décompilation correspondante terminée peut exister sans port convivial. Une recompilation statique peut produire une version jouable sans recréer un code source lisible fonction par fonction.

Street affirme que les communautés de décompilation ont historiquement mis l’accent sur la recherche. Les développeurs veulent comprendre le fonctionnement des jeux, retrouver les choix de conception, documenter les anciens systèmes et révéler des détails techniques que les studios d’origine n’ont jamais publiés.

Les ports restent un résultat précieux. Ils peuvent améliorer la compatibilité, prendre en charge les écrans modernes, permettre les modifications et maintenir l’utilité des anciens jeux sur le matériel actuel. Le conflit apparaît lorsque le port visible devient le seul résultat valorisé par le public.

Les projets fondés sur la recompilation statique proposent désormais un modèle différent. Le répertoire recomps.wtf distingue la décompilation de la recompilation statique et demande aux projets de divulguer l’implication de l’IA. Ses pages indiquent si l’IA a aidé à nommer des fonctions, à rédiger des outils de traduction ou à vérifier le travail.

Ce modèle fondé sur la divulgation ne résout pas le contrôle de la qualité, mais il préserve des informations qu’un classement unique masque. Les lecteurs peuvent juger un projet selon sa méthode, son état, les plateformes prises en charge, ses versions et sa documentation plutôt qu’à partir d’un pourcentage universel.

L’impact plus large de l’IA sur la décompilation de jeux est donc institutionnel. Les communautés ont besoin de nouvelles façons de représenter le travail après que l’automatisation en a modifié le coût. Une métrique conçue pour l’effort manuel peut rester techniquement exacte tout en devenant socialement trompeuse.

Les équipes logicielles hors du retrogaming font face au même problème. Les lignes modifiées, les issues fermées, les tests générés et les tickets terminés sont faciles à compter. L’IA peut gonfler chacun de ces chiffres sans apporter une compréhension ou une fiabilité proportionnelle.

La réponse n’est pas de masquer toutes les données de productivité. Il faut associer les métriques de production à des éléments attestant des revues, de la profondeur des tests, de la provenance, de la maintenance et du comportement en conditions réelles. Les équipes qui conservent ces éléments peuvent créer une archive d’ingénierie consultable plutôt que de s’appuyer sur de simples comptages d’activité.

L’expérience de decomp.dev montre ce qui se produit lorsque la signification sociale d’une métrique évolue plus vite que l’interface qui l’affiche. Le chiffre continue de bouger, mais la communauté ne s’accorde plus sur ce que cette évolution est censée signifier.

Le véritable affrontement oppose une recherche rigoureuse à la visibilité des ports en priorité

Un port approximatif peut capter l’attention en quelques heures, tandis que la recherche qui rend possibles des ports durables peut prendre des années et rester largement invisible.

La décompilation de jeux suivait autrefois une séquence relativement claire. Les chercheurs reconstruisaient le code, documentaient le comportement et produisaient progressivement une base source correspondante. Les développeurs de ports pouvaient ensuite adapter cette fondation aux systèmes modernes.

La recompilation statique a affaibli cette séquence en rendant possible plus tôt un résultat jouable. L’IA l’affaiblit davantage en aidant des développeurs moins expérimentés à générer rapidement du code de liaison, des couches de plateforme, des scripts de compilation et des correctifs.

Cette vitesse crée une véritable valeur. Davantage de joueurs peuvent redécouvrir des jeux que les éditeurs ne prennent plus en charge. Les développeurs peuvent tester des idées plus tôt, et les nouveaux venus curieux peuvent participer sans maîtriser chaque détail avant de commencer.

Cependant, une première build jouable n’est pas la même chose qu’une version fiable. Un port doit gérer les entrées, l’audio, le timing, le rendu, les sauvegardes, les différences entre plateformes et les états inhabituels du jeu. Des problèmes peuvent rester cachés lorsque les tests se concentrent sur l’accès au gameplay ou l’enregistrement d’une bande-annonce.

Un rapport de juillet sur le terrain d’affrontement des ports a documenté cette tension autour de Donkey Kong 64. Des développeurs expérimentés de la communauté ont critiqué un projet concurrent fortement axé sur l’IA et lancé une autre recompilation soutenue par une connaissance de longue date du jeu.

Le désaccord ne portait pas simplement sur le fait qu’un modèle ait touché au code. Les critiques soutenaient que des modifications mal comprises deviendraient plus difficiles à maintenir et pourraient provoquer de graves bugs. Leur inquiétude concernait la responsabilité du projet après sa sortie initiale.

Le code généré peut être testé, revu et maintenu comme toute autre contribution. Le risque augmente lorsque la personne qui l’accepte ne peut pas expliquer son comportement. Les corrections futures exigent alors de comprendre à la fois le jeu original et une implémentation générée dont les hypothèses n’ont jamais été consignées.

La visibilité récompense un autre ensemble de compétences. Un projet avec des annonces fréquentes, des gains de pourcentage rapides et des vidéos convaincantes peut dominer les discussions avant que les spécialistes n’achèvent un audit. Lorsque les défaillances apparaissent, le public peut déjà associer ce projet à l’achèvement du jeu.

C’est pourquoi un classement n’est pas neutre. Il oriente l’attention vers ce qu’il mesure. Lorsqu’il classe l’avancement, les contributeurs ressentent une pression à achever. Lorsque le public assimile l’achèvement à un port PC imminent, les mainteneurs subissent une pression pour produire un gameplay visible.

Street décrit cette progression comme un jeu de chiffres creux. L’expression désigne une défaillance des incitations, et pas seulement une aversion esthétique pour le code généré par l’IA. Les participants optimisent le score parce que le score contrôle l’attention.

Ce schéma complique aussi l’attribution. Un nouveau fork peut afficher des gains rapides uniquement parce qu’une équipe antérieure a cartographié les formats de fichiers, nommé les fonctions, documenté les outils de compilation et résolu des problèmes de compilateur. L’accélération visible du fork peut masquer le travail hérité qui la sous-tend.

Les licences open source établissent des autorisations légales, mais des communautés saines dépendent de normes que les licences n’encodent pas pleinement. Ces normes incluent l’attribution, la communication, le respect des mainteneurs et la volonté de reverser les améliorations en amont.

Un fork techniquement autorisé peut tout de même nuire à la coopération s’il présente un travail partagé comme une course individuelle. À l’inverse, un fork bien géré peut préserver des recherches abandonnées ou explorer une direction que les mainteneurs d’origine ne souhaitent pas suivre.

La distinction exige du contexte. C’est précisément ce que le classement ne pouvait pas exprimer. Il plaçait les projets dans un cadre comparatif sans montrer suffisamment leur origine, leurs normes de revue, leurs relations avec d’autres projets ou leurs résultats attendus.

Supprimer l’index ne rétablit pas l’ancienne séquence. Les projets assistés par l’IA et les ports rapides continueront d’apparaître. Des annuaires alternatifs chercheront aussi à devenir l’endroit où les joueurs les trouvent.

La fermeture du classement IA de decomp.dev accomplit quelque chose de plus modeste. Elle refuse de laisser un service communautaire respecté transformer des formes de travail incompatibles en une seule course.

Ce que la fermeture ne prouve pas au sujet du « AI slop »

La fermeture étaye une critique des incitations, mais elle ne prouve pas que toute décompilation assistée par l’IA est inexacte ou indésirable.

« AI slop » est une étiquette émotionnellement forte, sans définition technique stable. Elle peut désigner du code généré non revu, une présentation peu soignée, des affirmations trompeuses, un volume de sorties excessif ou simplement un travail qu’un critique n’apprécie pas.

Street reconnaît ce problème de modération. Le slop apparaît sous différentes formes et est difficile à définir de façon cohérente. Le choix des outils d’un projet ne peut pas remplacer l’examen de son code, de ses tests, de sa documentation et de ses pratiques de maintenance.

Les éléments disponibles sont également en grande partie qualitatifs. Les plaintes publiques signalent des forks hostiles, des ports approximatifs et des comportements visant à capter l’attention. Elles ne fournissent pas de taux d’échec exhaustif comparant les projets écrits par des humains et ceux assistés par l’IA.

Cette lacune est importante. Une analyse rigoureuse ne devrait pas transformer la décision d’un dirigeant communautaire en preuve que l’IA ne peut pas contribuer à l’ingénierie inverse. La propre déclaration de Street rejette cette conclusion en reconnaissant une accélération significative sous la direction d’experts.

Des progrès plus rapides ne rendent pas non plus automatiquement une réalisation vide de sens. Un développeur qui utilise l’automatisation pour éliminer le travail répétitif de correspondance peut consacrer davantage de temps à l’étude de l’architecture, à la validation des comportements et à la documentation des découvertes.

L’automatisation a toujours fait partie de la décompilation. Les outils de diff, les désassembleurs, les décompilateurs, les explorateurs de compilateurs et les scripts réduisent déjà l’effort manuel. La nouvelle préoccupation porte sur la façon dont les systèmes génératifs modifient l’échelle, l’accessibilité et la relation entre la production et la compréhension.

Il existe aussi un point de vue opposé légitime. Les joueurs se soucient souvent davantage du bon fonctionnement d’un port que de la manière dont ses développeurs l’ont produit. Si une build assistée par l’IA s’exécute fidèlement, respecte les licences du projet, crédite les travaux antérieurs et bénéficie d’un soutien continu, de nombreux utilisateurs verront peu de raisons de la rejeter.

Certains développeurs soutiennent également que des réviseurs expérimentés peuvent utiliser l’IA sans abandonner le contrôle. Un modèle peut proposer du code, tandis que les tests et le jugement humain déterminent s’il entre dans le projet. Dans ce flux de travail, l’IA devient un outil faillible parmi d’autres.

L’argument le plus solide contre les projets fortement axés sur l’IA ne peut donc pas reposer sur la pureté. Il doit souligner des défaillances observables, telles que des crashs, des comportements inexacts, des problèmes de sécurité, des attributions manquantes, du code impossible à maintenir ou de fausses affirmations sur l’achèvement.

Les discussions communautaires après l’annonce révèlent aussi un désaccord sur le but de la décompilation. Certains participants valorisent la recherche et la préservation. D’autres utilisent ouvertement les suivis de projet pour estimer quand un port PC jouable pourrait arriver.

Aucun de ces publics ne disparaît parce que decomp.dev retire son index. La fermeture met plutôt en lumière un problème de communication entre eux. La même barre de progression nourrissait deux attentes différentes.

Pour les chercheurs, elle représentait des connaissances récupérées et du code correspondant. Pour les spectateurs centrés sur les ports, elle ressemblait à un compte à rebours avant de pouvoir jouer au jeu sur du nouveau matériel. L’IA a élargi cet écart en faisant apparaître plus tôt et plus fréquemment des résultats jouables.

Les questions juridiques restent distinctes et propres à chaque cas. Les projets d’ingénierie inverse évitent couramment de distribuer des ressources de jeu protégées par le droit d’auteur et exigent que les utilisateurs fournissent leur propre copie. Cette conception n’accorde pas de protection automatique à chaque projet ou implémentation.

Des annuaires alternatifs expérimentent déjà des règles plus explicites. Le modèle de divulgation des projets étiquette les travaux assistés par l’IA et explique les méthodes techniques. De tels systèmes donnent davantage de contexte aux lecteurs, mais leur efficacité dépend de déclarations exactes et d’une modération active.

La conclusion sceptique est simple. decomp.dev a documenté un échec de gouvernance communautaire, et non une étude contrôlée de la qualité logicielle. Sa réponse mérite l’attention parce que le site occupait une position centrale, et non parce qu’elle règle chaque débat sur le code généré par l’IA.

Trois signaux montreront si la communauté peut rétablir la confiance

La prochaine phase dépendra de la capacité des projets à remplacer le prestige fondé sur la vitesse par des preuves transparentes de qualité, d’origine et de maintenance continue.

Le premier signal sera de voir si les index alternatifs adoptent des divulgations significatives sur les projets. Une liste utile devrait distinguer la décompilation par correspondance, les ports de code source et la recompilation statique. Elle devrait également décrire l’utilisation de l’IA, les relations avec l’amont, l’état des tests et la maturité des versions.

Les étiquettes seules ne suffiront pas. « Assisté par l’IA » peut couvrir un commentaire généré ou la majeure partie d’une base de code. De meilleures divulgations expliqueront ce que le modèle a produit, qui l’a revu et comment les mainteneurs ont vérifié le résultat.

Si les annuaires convergent vers des divulgations détaillées, la décision de Street apparaîtra comme une remise à zéro ayant encouragé de meilleures mesures. S’ils recréent une course à l’achèvement classée avec quelques badges ajoutés, les mêmes incitations reviendront sous un nouveau domaine.

Le deuxième signal concerne la manière dont les forks les plus visibles interagissent avec les projets dont ils ont hérité. Il faudra observer des attributions claires, des pull requests vers l’amont, un suivi partagé des problèmes et une communication avec les mainteneurs d’origine.

Un fork qui restitue des correctifs et documente ses différences peut renforcer un projet ouvert. Un fork qui semble exister uniquement pour revendiquer l’achèvement, capter l’attention et abandonner la maintenance renforcera les inquiétudes autour des courses aux ports assistés par l’IA.

L’historique du dépôt fournit des preuves plus utiles que les vidéos promotionnelles. Des correctifs réguliers, des builds reproductibles, des réponses détaillées aux problèmes et des contributions revues montrent si une équipe comprend ce qu’elle a publié.

Le troisième signal est la qualité après la sortie. Les ports fortement axés sur l’IA feront face à leur test le plus exigeant une fois que les utilisateurs auront dépassé la séquence d’ouverture. La fidélité des sauvegardes, des mécaniques sensibles au timing, des scènes rares, des contrôleurs, du matériel graphique et des systèmes d’exploitation importera davantage que la vitesse de lancement.

Les distinctions techniques entre décompilation, recompilation et ports deviendront également importantes à mesure que les utilisateurs signaleront des problèmes. Un bug peut provenir du code de jeu traduit, d’une couche de plateforme, d’un composant dérivé d’un émulateur ou d’une amélioration ajoutée par le port.

Les projets capables de diagnostiquer ces couches gagneront la confiance. Les projets dont les mainteneurs ne peuvent pas expliquer leur propre implémentation auront des difficultés lorsque le code généré rencontrera des cas limites inconnus.

Ces signaux peuvent renforcer ou affaiblir l’argument à l’origine de la fermeture. De meilleures divulgations, des forks constructifs et des versions durables montreraient que les communautés peuvent intégrer l’IA sans abandonner la qualité. Des conflits répétés sur l’attribution et des ports défaillants confirmeraient l’avertissement de Street selon lequel les incitations actuelles récompensent les mauvais résultats.

La fermeture du classement IA de decomp.dev est, en définitive, une décision de gouvernance. Street n’a pas désactivé l’IA, fermé tous les dépôts ni déclaré que l’assistance automatisée n’a aucun rôle légitime. Il a retiré un tableau de scores après que ses chiffres ont cessé de représenter les valeurs qu’il avait été conçu pour célébrer.

Les développeurs et les utilisateurs ont désormais un choix concret. Ils peuvent juger les projets selon qui a terminé en premier, ou examiner la manière dont le travail a été produit, testé, attribué et maintenu. Au cours des prochains mois, quels éléments de preuve compteront davantage que la prochaine affirmation d’un achèvement à 100 % ?