- git-annex a consacré environ 100 heures au cours du dernier mois à vérifier qu’il puisse être compilé sans dépendances contenant du code généré par LLM
- Ce travail met en évidence la réalité consistant à devoir suivre en continu l’ensemble de l’arbre des dépendances, plutôt que seulement du code individuel, ce qui alourdit fortement la charge de maintenance
- Lors de la vérification, plusieurs cas ont été observés : l’annulation sans explication de changements massifs générés par LLM, une modification de 10 000 lignes dans une base de code de 26 000 LOC, ou encore un message de commit incohérent de 1 489 lignes
- Le fait d’avoir obtenu des informations supplémentaires sur la qualité des dépendances est positif, mais un certain scepticisme demeure quant à une réponse au niveau d’organisations comme la Software Freedom Conservancy ou la FSF
- Même si les LLM peuvent faciliter l’ajout de configuration ou des changements de formatage, ce type de commit peut avoir un coût direct sur la confiance dans la collaboration et la participation aux projets
Vérification des dépendances de git-annex
- git-annex a consacré environ 100 heures sur près d’un mois à vérifier qu’il puisse être compilé sans dépendances contenant du code généré par LLM
- À ce jour, l’objectif semble avoir été atteint
- La page associée est git-annex no LLM code
- Le cœur du problème réside dans la charge liée à l’examen continu de l’ensemble de l’arbre des dépendances d’un programme
Cas révélés lors de la vérification et impacts
- Les cas constatés ne relèvent pas d’une simple préférence, mais touchent à la maintenance et à la confiance
- De grands changements générés par LLM ont été annulés sans aucune explication dans la version suivante
- Une modification de 10 000 lignes a été introduite dans une base de code de 26 000 LOC, avec un message de commit incohérent de 1 489 lignes
- Un prompt LLM demandait de copier du code depuis un autre projet, et il semble que la violation de droits d’auteur ait été évitée par chance
- Ce travail a permis d’obtenir des informations supplémentaires sur la qualité des dépendances, et ces informations pourront influencer les choix à venir
- La Software Freedom Conservancy semble avoir éludé ce problème dans ses recommandations sur l’IA générative fondée sur les LLM, et il n’est pas certain que la FSF fasse mieux
- Dans ce contexte de changements, la participation aux communautés concernées est réévaluée, mais le travail et l’assistance aux utilisateurs se poursuivent
- Donner à un LLM des prompts comme
Add fourmolu config and restyled,neat,format a module, puis committer le résultat, peut sembler facile, mais il faut tenir compte de la portée étendue de cet acte
1 commentaires
Avis sur Lobste.rs
J’ai appris aujourd’hui que git-annex est écrit en Haskell, et c’est classe
Aujourd’hui, dans le métro en rentrant chez moi, la personne à côté de moi regardait des YouTube Shorts au volume maximal, et dans une rame silencieuse et bondée, c’était une pollution sonore agaçante
Ce qui m’a encore plus agacé, c’est que la vidéo qu’il regardait était une vidéo de mauvaise qualité entièrement générée par IA
L’anecdote de cet article, où les auteurs de dépendances produisent avec des LLM des changements difficiles à comprendre, m’a parlé
Ce qu’il y a de plus frustrant dans le mauvais usage des LLM, c’est que cela dégrade nos interactions les uns avec les autres
Avant, même quand j’examinais une proposition mal ficelée au travail, l’idée centrale apparaissait telle quelle et il était facile de la repérer et de la commenter ; maintenant, n’importe qui peut mettre un changement mal ficelé dans un LLM et en tirer quelque chose qui a l’air bien structuré, mais qui se révèle plein de trous à la relecture
De la même manière, on peut produire du mauvais code qui a l’air bon
Ce n’est pas une plainte nouvelle, mais cela commence à me taper de plus en plus sur les nerfs
J’ai l’impression que nous sommes en train de perdre une partie essentielle du lien humain qui rendait le travail et la vie agréables et riches
J’apprécie qu’un collègue me dise honnêtement « ça, c’est 🤖 qui l’a fait », parce que je sais à l’avance quel niveau de revue attendre
En général, il s’agit d’une trace du processus qu’il a utilisé pour mieux apprendre la base de code, donc je peux croire qu’il a lu la sortie du LLM et qu’il veut vérifier qu’il a bien compris
Je pense que ce que les LLM ont changé, c’est le prix relatif de la qualité
Pour prendre l’analogie d’une maison : avant, une McMansion médiocre, avec un toit qui fuit et de mauvaises fondations, coûtait 1000X, tandis qu’une bonne maison sans problèmes cachés coûtait 2000X
Désormais, avec la technologie des LLM, une personne compétente peut théoriquement déléguer une partie du travail mécanique et facile à vérifier, et faire descendre le prix d’une bonne maison à 1500X
Mais la McMansion médiocre, elle, est tombée à 100X
Il est donc très probable que des McMansions de mauvaise qualité évincent de façon laide le travail de qualité
Je n’ai pas l’intention de m’en prendre aux artisans qui font passer une bonne maison de 2000X à 1500X, mais si des maisons bâclées à 100X chassent du marché ce qui est meilleur et créent un marché des lemons, les clients risquent de devenir beaucoup plus méfiants envers le logiciel dans son ensemble
Un marché des lemons est horrible parce que l’acheteur n’a aucun moyen de distinguer la qualité des déchets
L’exemple le plus célèbre dans le logiciel est le krach du jeu vidéo de 1983, où une énorme vague de jeux poubelles a échaudé beaucoup de clients, qui ont cessé d’acheter
Cette position me semble tout à fait raisonnable
Personnellement, je pense qu’avec le temps la plupart de ces efforts finiront par être vains, et cela ne m’inquiète pas beaucoup dans mon usage des logiciels, mais d’un point de vue subjectif c’est tout à fait défendable et intéressant, et je trouve bien que cette personne procède ainsi
Tout comme les optimistes de l’IA exagèrent, le camp anti-IA a aussi tendance à dramatiser à l’excès les aspects négatifs
Cet article lui-même est plutôt une exception, mais je pense que son intention et son message auraient été beaucoup plus forts sans la généralisation hâtive du dernier paragraphe
Cela dit, j’aime lire ce genre de texte et chercher les éléments intéressants derrière l’émotion
Une base de données du dernier code connu 100 % non LLM par projet serait intéressante
Une base de données du slop ayant eu un impact serait aussi amusante, sachant qu’ici « ayant eu un impact » doit couvrir à la fois le positif et le négatif, et que « slop » signifie une sortie non relue
On pourrait tricher en récupérant grosso modo les archives GitHub du début 2023, mais ce serait plus intéressant s’il s’agissait du dernier snapshot de commit par projet, et pas d’un simple instantané à une date donnée
Il me semble que ce jeu de données pourrait produire beaucoup de résultats intéressants, et il aiderait aussi les personnes qui, comme dans cet article, veulent construire un écosystème composé uniquement de logiciels non LLM
Comme vous vous en doutez sans doute déjà, j’utilise les LLM
Je pense tout de même être du côté raisonnable
Si cela vous intéresse, vous pouvez lire les articles de mon site web, mais je promets que le corps de mes billets de blog est écrit à 100 % par un humain
Je pense que lire des avis opposés est l’une des meilleures façons d’apprendre et de progresser, donc j’aime participer à ce genre d’initiative
Il est géré par des personnes farouchement anti-IA : https://codeberg.org/ethical-foss/open-slopware
Pour certains projets, il indique la « dernière version ou ID de commit non contaminé », mais il ne couvre pas tous les projets
J’ai soumis cet article parce que j’ai apprécié le fait que l’auteur ait recherché directement des commits précis suggérant l’usage de LLM dans ses dépendances, puis ait créé une page résumant ses découvertes
Personnellement, je n’étais pas sûr qu’il faille ajouter le tag
vibecoding, car cet article me semble porter davantage sur la communauté et les pratiques que sur le vibe codingIl y a ce passage : « Je sais qu’à ce stade, j’essaie peut-être de retenir la marée montante »
Si le compilateur dont dépend le projet est touché, on ne peut pas gagner
Moi aussi, je fais de la limitation des dégâts, mais au bout du compte il arrive un moment où s’obstiner sur l’alternative devient pire, et où l’on est forcé de céder
C’est un problème délicat
Même avec une analyse poussée, il sera probablement difficile d’éviter le code LLM
Par exemple, le code introduit via l’autocomplétion ne sera pas détecté
À mon avis, la confiance n’a pas été rompue au moment où ces bibliothèques ont commencé à utiliser des LLM, mais au moment où elles ont accepté et intégré des changements énormes accompagnés de messages de commit difficiles à lire et inutiles
C’est un échec de génie logiciel, indépendamment de l’usage ou non de LLM
Pour mémoire, j’aime Joey Hess et ses logiciels, et je suis plutôt d’avis que les contributions de code doivent être évaluées sur les mérites du résultat, quel que soit l’outil qui les a produites
La manière de présenter les choses est un peu décevante
Le commit
persistentne semble pas avoir été écrit par un LLMJ’aimerais que les gens arrêtent de dire que tous les commits contenant « Co-authored-by » sont générés par LLM
Le premier lien
yesodconcerne un changement de CI, donc j’ai du mal à considérer cela comme du code dont on dépendQuand j’ai lu « commit généré par LLM avec un message de commit de 1489 lignes », je m’attendais à un commit complètement délirant, mais en réalité c’est un squash merge raisonnable, même si le diff est énorme
Le commit
cabalindique que le LLM n’a généré que des tests, et je ne suis pas sûr qu’il faille considérer cela comme du code dont je dépendsLe commit
gitaussi, c’est juste de la CIJe ne doute pas que certaines de ces dépendances utilisent des LLM, mais il est difficile de dire que les éléments présentés tiennent vraiment la route
En revanche, c’est un travail qui a demandé beaucoup plus d’efforts que je ne l’aurais attendu, et j’apprécie qu’il y ait quelque chose de concret vers lequel pointer comme raison de ne pas utiliser certaines dépendances