- L’idée selon laquelle il suffirait qu’un humain vérifie toutes les erreurs fréquentes des outils de codage à base de LLM ne permet pas de garantir à la fois qualité et productivité, en raison des limites de capacité de traitement de la revue de code
- Selon des études empiriques, une revue efficace atteint un plafond d’environ 1 heure et 400 LOC par session ; au-delà, la fatigue et la baisse de concentration font rapidement chuter l’efficacité de détection des défauts
- En appliquant ce critère, chaque tranche de 400 LOC écrites par un LLM exige 1 heure de revue concentrée par un développeur expérimenté, ce qui ramène le débit quotidien réaliste à moins de 1 000 LOC
- Il existe des premiers indices montrant que les humains détectent moins de défauts dans le code généré par LLM tout en affichant une confiance plus forte, ce qui rend difficile l’idée qu’une simple revue suffise à filtrer correctement les erreurs
- Il faut des études empiriques mesurant et reproduisant directement le taux de détection des défauts, la vitesse de revue et la capacité soutenable par jour sur du code LLM, afin d’évaluer l’efficacité réelle de ces outils sur la base de preuves plutôt que d’anecdotes
Pourquoi je reste sceptique envers les outils de codage LLM
- Le cœur du problème ne porte ni sur la propriété intellectuelle, ni sur le coût écologique, ni sur la consommation de ressources, ni sur l’idée que tous les résultats des LLM seraient mauvais
- Avec les seules preuves scientifiques actuelles, il est difficile d’établir de quelle manière les outils de codage LLM aident les développeurs à écrire du code meilleur ou plus vite
- Les arguments en leur faveur ne traitent pas directement les problèmes ni les preuves disponibles, et les réponses au scepticisme tendent parfois à renforcer le problème
- Le texte ayant été écrit il y a environ un an, il emploie l’expression Coding Assistants, aujourd’hui presque remplacée, faute d’avoir trouvé un autre terme couvrant tous les usages de codage de l’IA générative
La métaphore du « stagiaire » et la solution de la revue intégrale
- Les outils de codage LLM présentent un risque d’erreur relativement élevé en raison de leur mode de fonctionnement et de leur interface d’interaction
- Ils peuvent produire des hallucinations ou des fautes de frappe
- Ils peuvent fournir un résultat sans rapport avec la demande ou accomplir la tâche par une autre voie
- Les utilisateurs comparent souvent ces outils à un stagiaire
- Il faut s’attendre à ce qu’une partie du résultat soit erronée
- Il faut supposer qu’ils travaillent sans bien comprendre ce qu’ils font
- La réponse la plus répandue consiste à faire relire l’intégralité du résultat par une personne expérimentée, comme pour le code d’un stagiaire ou d’un développeur junior
- Cela repose sur l’idée que l’humain comprend mieux la situation et porte la responsabilité finale
- S’y ajoute l’argument selon lequel tout code entrant dans une base de code devrait de toute façon être relu
Le niveau de revue nécessaire pour superviser les LLM
- Dans l’industrie comme dans la littérature de recherche, le terme revue recouvre plusieurs pratiques différentes
- Une revue légère, répartie entre plusieurs personnes, est utile pour partager la connaissance des changements et appliquer des règles de surface, mais elle ne suffit pas comme critère de supervision du code LLM
- Sans aller jusqu’aux inspections de comité du passé, où chaque ligne était examinée péniblement pendant des heures, il faut tout de même une revue de code assez profonde et complète
- Comme les LLM peuvent écrire du code complexe et que les défauts peuvent se cacher dans les détails du logiciel, une simple vérification superficielle ne suffit pas
Les limites empiriques auxquelles se heurte la revue de code
- Les principales limites d’une revue efficace mises en évidence par les études empiriques sont les suivantes
- Une session de revue dépassant 1 heure devient trop longue
- La quantité pouvant être revue efficacement dans ce temps est d’environ 400 LOC au maximum
- Une revue de plus d’une heure voit son efficacité diminuer rapidement, quelle que soit la taille du code
- Pas seulement parce que l’essentiel aurait déjà été vu
- Mais parce qu’une heure de forte concentration entraîne fatigue et ennui, et impose une pause
- Je n’ai pas trouvé d’étude portant sur le temps de récupération nécessaire entre deux sessions d’une heure
- En plafond extrême, on peut en imaginer plusieurs par jour
- Deux sessions quotidiennes sont parfois proposées comme ordre de grandeur moyen, sans que ce soit un chiffre établi
- Le nombre de lignes relues par heure varie fortement selon le contexte et la nature du code, ainsi que selon l’expérience et la connaissance du relecteur
- Ce n’est pas une règle absolue, mais les données empiriques montrent très peu de cas où des revues au-delà de 400 LOC/H trouvent et signalent efficacement les défauts ; on peut donc considérer ce rythme comme un maximum praticable
Calcul du débit appliqué au code LLM
- Si l’on veut résoudre les problèmes du code LLM par la revue, il faut au mieux 1 heure d’un développeur expérimenté pour chaque tranche de 400 LOC produites
- Un développeur ne peut consacrer qu’environ 10 à 40 sessions de revue par semaine, avec un temps de récupération inconnu entre chacune
- Ce temps de récupération pourrait être d’au moins 1 à 2 heures, mais aucune étude directe ne l’établit
- Ce temps de concentration doit aussi servir aux réunions, à la conception, à la réponse aux incidents et à la réflexion sur le code à écrire soi-même
- Dans le meilleur des cas, un développeur utilisant un LLM peut écrire, relire et valider quelques milliers de LOC par jour
- Dans un scénario réaliste, le débit quotidien peut tomber à moins de 1 000 LOC
- En incluant boilerplate, tests, migrations et fichiers de configuration
- Un seul fichier de test peut déjà dépasser 400 LOC
- Même dans les conditions les plus favorables, où l’essentiel du code est simple et facile à relire, la revue agit comme plafond du gain de productivité
Différences entre la revue de code humain et celle du code LLM
- Les preuves existantes viennent de situations où des relecteurs humains détectent des défauts dans du code écrit par des humains ; rien ne prouve que la même efficacité s’applique au code LLM
- Les premiers indices suggèrent que les personnes relisant du code généré par LLM repèrent moins de défauts tout en étant plus convaincues d’avoir tout trouvé
- Par rapport à un duo auteur humain / relecteur humain, un duo outil de codage LLM / relecteur humain peut produire un résultat de moindre qualité, tandis que ce dernier évalue pourtant sa propre performance plus favorablement
- La revue intégrale ne limite donc pas seulement l’avantage de productivité des LLM ; elle manque aussi de preuves solides montrant qu’elle résout réellement leurs erreurs fréquentes
Des coûts présents avant même la correction des défauts
- Ce calcul n’inclut pas le coût de correction des défauts détectés
- Il ne traite que de la capacité et du coût pour un développeur professionnel de relire du code et de signaler les problèmes dans un environnement de travail
- Quel que soit le nombre ou la gravité des défauts introduits par le LLM, le coût de relecture du code généré existe
- Même si les outils de codage LLM produisaient un code de très haute qualité, le même coût et les mêmes limites de productivité subsisteraient dès lors que tout résultat doit être relu
Le paradoxe de confier aux LLM le code le plus difficile à relire
- Les défenseurs des LLM présentent comme avantage le fait que l’outil puisse produire à la place des humains du code pénible à écrire
- Un exemple propose de faire écrire à un LLM 100 % du code Bash nécessaire à l’avenir
- Les scripts shell ont une syntaxe souple et des significations excessivement imbriquées : une simple erreur de ponctuation peut être sans effet… ou supprimer tout un ordinateur
- Ce type de code est facile à rendre erroné, difficile à comprendre et à relire, et il est aussi difficile d’y repérer les erreurs graves
- Confier le code le plus difficile à relire à un outil qui produit des erreurs aléatoires, puis dire qu’un humain n’a qu’à vérifier, ne démontre pas d’abord que la sortie du LLM constitue réellement un objet de revue efficace
- Le problème est de prendre le code le plus difficile à relire comme cas d’usage emblématique sans répondre à la question de savoir si la revue corrige bien les erreurs et s’il reste malgré tout un gain de productivité suffisant
Les tâches empiriques à valider
- La première tâche consiste à mesurer dans quelle mesure les relecteurs humains trouvent réellement les défauts du code généré par LLM
- Capacité de détection des défauts
- Vitesse de revue
- Volume de revue soutenable sur une journée
- Comme pour les recherches sur le code écrit par des humains, il faut des données sur des humains relisant du code LLM
- Les expériences existantes et les données empiriques restent limitées en taille et en contexte, d’où la nécessité d’études de réplication plus nombreuses
- Les données scientifiques actuelles pointent plutôt vers l’idée que les humains relisent mal les résultats des LLM ou détectent difficilement leurs problèmes
- Cela peut correspondre au fait que les LLM sont entraînés à éviter la détection
- Il faut aussi vérifier si les résultats obtenus jusqu’ici étaient accidentels
- La deuxième tâche consiste à vérifier si la revue des productions LLM pose un problème qualitativement différent de la revue des productions humaines
- Si l’écart est assez grand pour que les recherches actuelles sur la revue de code ne s’appliquent plus, alors la critique actuelle pourrait s’effondrer
- Mais les premiers indices suggèrent au contraire que la revue du code généré par LLM pourrait être plus difficile, et non plus facile, ce qui renforcerait la critique
Une évaluation empirique d’outils professionnels, pas des anecdotes
- Compte tenu de ce que l’on sait sur la revue de code, il est difficile de voir quel bénéfice les outils LLM, dans leurs interfaces et procédures actuelles, apportent à des développeurs professionnels
- Plus que le fait que les fournisseurs continuent de proposer des outils et procédures en contradiction avec les preuves, ce qui suscite le plus de frustration est leur tendance à traiter les sceptiques comme des cas anormaux sans répondre au problème
- Avec le TDD, les systèmes de types, la séparation test/développement, le CI/CD ou le DevOps, on a déjà vu se répéter ce schéma où l’anecdote l’emporte sur la preuve empirique
- Au lieu de s’appuyer sur des récits du type « cette fois-ci, ça a marché pour moi », il faut mener de vraies études en suivant la manière dont les bases empiriques de la revue de code ont été construites
- Si l’on veut traiter les outils de codage LLM comme des outils de développement professionnels, il faut évaluer leurs effets et leurs limites à partir de l’ergonomie et de preuves empiriques
1 commentaires
Commentaires sur Lobste.rs
La vitesse n’a pas besoin d’être le seul objectif. Les corrections de bugs peuvent être séparées dans des commits préparatoires distincts et relues indépendamment ; on peut corriger les structures de types capables de représenter des états invalides ; et, si la fiabilité des tests est insuffisante, expérimenter avec les tests basés sur les propriétés, le fuzzing et les méthodes formelles.
Autrefois, on regroupait ce genre de travail dans un seul commit ou on le laissait sous forme de TODO de dette technique, mais aujourd’hui le coût marginal pour le faire correctement est étonnamment bas. Un LLM est un outil ouvert : il rend de la valeur à hauteur de ce que l’utilisateur juge important.
Il y a certes aussi le risque de voir proliférer des prototypes qui n’aboutissent jamais et n’atteignent pas la production, mais, dans l’ensemble, c’est d’une grande aide pour une ingénierie qui valorise la rigueur.
C’est peut-être un problème de culture d’entreprise, mais c’est décevant, et j’espère que le secteur se ressaisira pour produire des logiciels de meilleure qualité.
Si l’on lance un agent sur d’anciens projets avec un seul prompt, il continue de trouver de vrais bugs sans grand effort. Les humains sont faillibles, et moi aussi je fais des erreurs, mais les LLM sont rapides tout en étant plus stupides à bien des égards, ce qui fait simplement apparaître le problème plus tôt.
Les erreurs s’accumulent, donc si l’on laisse un agent modifier le code sans discernement, les choses se dégradent vite ; mais conclure que l’outil lui-même est inutile parce qu’un usage naïf est instable est aussi un jugement paresseux.
Aujourd’hui, à chaque changement, j’exécute automatiquement cinq revues spécialisées portant notamment sur l’architecture, la maintenabilité, la fiabilité et la sécurité, et je les organise dans un système de documents de conception, ce qui améliore fortement la prise de décision de l’agent. Ce n’est pas parfait, mais c’est mieux qu’une approche naïve, et le fait qu’il reste de la marge d’amélioration fait aussi partie du plaisir de travailler avec un nouvel outil.
Même si un prompt permet de générer plus vite, il faut ensuite davantage de temps pour vérifier et comprendre, au point de se demander s’il n’aurait pas été plus rapide d’écrire le code soi-même dès le départ. Décider quelle option est la meilleure prend déjà du temps et de l’énergie, et j’aimerais utiliser ces ressources ailleurs.
Cela dit, si l’auteur de la PR assume la propriété et la responsabilité du changement, le fait qu’il ait utilisé ou non un LLM n’a pas d’importance. Si les critères de qualité, d’exactitude et de cohérence sont respectés, il peut choisir la méthode la plus rapide, et la responsabilité reste celle de l’auteur humain.
Personnellement, je trouve l’IA utile pour apprendre et approfondir sa compréhension, mais si l’on considère tout le processus, et pas seulement le temps de saisie, écrire le code directement reste pour l’instant plus productif.
Le premier problème est que l’article a été écrit il y a près d’un an. Au cours des six derniers mois, et surtout des trois derniers, l’utilité des modèles cloud payants les plus récents a beaucoup augmenté.
Comme dans les principes MFIC développés dans le travail d’audit, il faut vérifier s’il existe des contrôles qui empêchent des catégories entières d’échecs : https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
Il faut aussi des outils comme https://github.com/pmarreck/dirtree et https://github.com/pmarreck/codescan, qui gardent en contexte le code existant et la structure du projet ; ils sont également utiles aux développeurs humains qui ont oublié la base de code ou ne la connaissent pas bien.
Au final, on peut soit exploiter correctement ces outils et en tirer avantage, soit écrire soi-même du code sur mesure tout en introduisant des bugs et des failles de sécurité, puis se faire dépasser par des concurrents plus rapides. Pour avoir passé deux années-personnes sur la base de code Ruby on Rails abandonnée d’un million de lignes de Desk.com, je dirais que le code d’entreprise est éphémère, ce qui le rend bien adapté au code généré par LLM.
Je n’aurais pas confiance pour des internes d’Erlang, mais on peut demander à l’outil d’écrire des fonctions une par une puis les relire, et parfois le résultat sera meilleur que prévu. Plutôt que de choisir uniquement entre les aiguilles à tricoter et le métier à tisser, l’idéal est d’utiliser les deux selon le contexte.
D’après mon expérience personnelle et celle de développeurs expérimentés et fiables autour de moi, les LLM ont permis à plusieurs reprises de coder mieux et plus vite ; j’ai donc du mal à prendre au sérieux un article qui affirme que les preuves scientifiques montrent qu’ils ne peuvent pas aider.
Même sans article évalué par les pairs, j’en ai déjà suffisamment vu, et le fait qu’une seule étude de METR contredise les estimations de gains de productivité des développeurs ne me fera pas changer d’avis.
Je suis prêt à changer d’avis si l’on me montre, de manière rigoureuse et méthodologiquement valide, en quoi cela diffère des travaux empiriques solides existants. Mais l’expérience personnelle ou une douzaine d’anecdotes sans explication ne suffisent pas.
La science et l’ingénierie ont amélioré la vie de milliards de personnes, et on ne peut pas les abandonner simplement parce que quelqu’un croit être meilleur.
Je ne cherche pas à traiter qui que ce soit de membre d’une secte, mais prendre personnellement les remises en cause de ses croyances tout en ne sachant pas comment convaincre autrui ressemble aux modes de communication des groupes sectaires.
Même pour une PR majoritairement produite par un LLM, la personne qui la soumet doit en assumer la responsabilité et la découper en éléments de taille et de contexte compréhensibles par les autres. Le code reste la spécification finale du logiciel, et le fait que les développeurs doivent en être propriétaires et le comprendre n’a pas changé.
Il est vrai qu’il y a un an les agents IA faisaient beaucoup d’erreurs, mais il n’est pas évident que ce soit encore le cas aujourd’hui ; vers novembre dernier, j’ai ressenti un point d’inflexion des modèles de pointe.
Il est vrai que les LLM augmentent la quantité de code et exercent une nouvelle pression sur la capacité de revue, mais les ingénieurs doivent y mettre un frein et s’assurer que le volume de revue corresponde à la capacité réelle de traitement.
Le pire, c’est que ce nouveau code fonctionne généralement, ce qui augmente les chances qu’il soit fusionné sans nettoyage.
Je trouve curieux que, alors que les modèles de pointe écrivent d’énormes quantités de code, on n’explore pas sérieusement la contribution négative consistant à proposer de supprimer du code. Comme dans « The Best Code is No Code At All » - Jeff Atwood, il serait intéressant de voir un modèle démêler la complexité de bases de code gonflées par les couches d’abstraction et proposer de supprimer des lignes.
C’est peut-être déjà possible, mais je ne l’ai pas encore vu moi-même.
Pour corriger : la section « The Limits Of Reviews » présente la vitesse maximale efficace comme étant de 400 lignes par heure, et non 400 lignes par revue comme je l’avais d’abord pensé.
Je reste toutefois curieux de savoir de quel article sur la revue de code proviennent précisément les chiffres d’une heure et de 400 lignes. Si vous n’avez pas noté le titre de l’article, inutile de passer beaucoup de temps à le rechercher.
Je suis actuellement en déplacement, donc rappelez-le-moi dans quelques jours.
Si la revue représente 25 % d’une semaine de 40 heures, cela fait environ 540 lignes par heure ; à 15 %, 900 lignes ; à 5 %, 2 700 lignes. J’estime que mon débit réel est d’environ 500 à 1 000 lignes par heure, ce qui est assez proche du chiffre non sourcé.
J’ai du mal à comprendre l’idée selon laquelle du code généré par IA devrait être relu davantage, ou moins, que du code écrit par un humain. Les critères d’approbation étant les mêmes, je le relis au même niveau.