- Face à l’adoption enthousiaste par l’industrie des outils de génération de code par LLM, l’article souligne l’importance de la réflexion dans le développement logiciel
- Le code généré automatiquement est non déterministe (non-deterministic) et son fonctionnement interne est opaque, ce qui le distingue fondamentalement de la mécanisation qui garantit le même résultat à chaque fois
- Les LLM apprennent à partir de code existant de mauvaise qualité, répètent les mêmes erreurs, puis réapprennent ces erreurs dans un cycle de « human centipede epistemology »
- Confier la génération de code à des agents affaiblit le contexte partagé et la responsabilité lors des revues de PR, ce qui nuit à la qualité logicielle
- Les LLM peuvent être utiles pour des usages limités comme le prototypage, mais il est dangereux pour les développeurs d’externaliser l’acte même de réfléchir, et la maintenance devient impossible sans compréhension
Malaise face à la génération de code par LLM
- Malgré une longue habitude de suivre les évolutions du secteur et de partager avec ses collègues les nouveautés CSS et JS, l’auteur a ressenti l’angoisse d’être laissé derrière à mesure que la génération de code fondée sur les LLM se diffusait rapidement
- Il utilisait Copilot et Claude comme « spicy autocomplete » et comme outils d’aide au débogage, mais dès qu’on leur demande une tâche un peu complexe, le résultat devient catastrophique
- Il faut fournir suffisamment de contexte, mais trop de contexte les surcharge, et l’on se retrouve à écrire de longs prompts pour ménager l’ego du LLM, du style « vous êtes un expert des systèmes distribués »
- Dans bien des cas, écrire directement le code va plus vite que passer du temps à peaufiner les prompts
- L’auteur s’interroge sur cette tendance des ingénieurs à abandonner le travail plaisant qu’est le développement pour ne garder que le travail ennuyeux qu’est la revue
Réponse à l’idée d’une « reconstitution de la révolution industrielle »
- De la même manière que la révolution industrielle a contribué au changement climatique, on retrouve un schéma similaire dans l’énorme consommation d’énergie des data centers de l’IA
- Toute cette électricité ne vient pas forcément des énergies fossiles, mais générer des images de « Jésus-crevette » reste un immense gaspillage de ressources
- La mécanisation a rendu les biens moins chers et plus largement disponibles, mais elle a aussi entraîné une baisse de qualité, menant à un monde où l’on peut acheter chez SHEIN un pantalon pour moins cher qu’un café
- Cela s’est aggravé avec le déclin du travail qualifié, la délocalisation des usines vers des pays à bas salaires et l’exploitation des travailleurs
- Le code généré ressemble à de la fast fashion : en apparence tout va bien, mais avec le temps il se couvre de trous, reprend souvent le code d’autrui sans autorisation et nuit lui aussi à l’environnement
- Différence essentielle : la mécanisation produit le même résultat à chaque fois et permettait d’inspecter l’intérieur en cas de problème, alors que la sortie d’un LLM est non déterministe et son fonctionnement interne opaque
- Un processus mécanisé qui donne un résultat différent à chaque exécution, avec des hallucinations, n’a rien d’utile
Réponse à l’idée d’une « nouvelle couche d’abstraction »
- Il est vrai qu’en utilisant Java ou Go, on n’a plus besoin d’apprendre l’assembleur, et que le runtime prend en charge le garbage collection ou l’allocation mémoire
- Mais l’architecture système, l’impact sur le chemin critique, les arbitrages entre maintenabilité et vitesse de livraison, la compatibilité navigateur, l’accessibilité, la sécurité et les performances restent des domaines où le développeur doit réfléchir par lui-même
- Le point où les LLM font le plus de dégâts, c’est quand les ingénieurs leur sous-traitent l’acte même de penser nécessaire au développement logiciel
- Comme les LLM ne raisonnent pas, si le développeur ne réfléchit pas et que le LLM ne réfléchit pas non plus, plus personne ne réfléchit
- Le cas du scandale Horizon : des bugs du logiciel de la Post Office ont conduit à l’emprisonnement d’employés innocents, et 13 personnes se sont suicidées
- La responsabilité (accountability) dans le logiciel n’a jamais été aussi importante
Le vrai problème : le code de mauvaise qualité
- Les développeurs humains écrivent eux aussi du code peu accessible, peu performant et trop dépendant de JavaScript
- Les LLM sont entraînés sur ce code de mauvaise qualité comme données d’apprentissage (sans consentement explicite) et reproduisent les mêmes erreurs
- Puis ce code médiocre généré par LLM est à son tour réappris par d’autres LLM, dans une boucle que l’auteur appelle « human centipede epistemology »
- Quand on pense aux utilisateurs de technologies d’assistance, aux personnes avec une mauvaise connexion internet ou aux victimes du racisme des logiciels de reconnaissance faciale, la qualité actuelle du logiciel est loin d’être suffisante
- Au lieu d’apprendre et de s’améliorer en tant qu’humains, nous avons sous-traité nos erreurs à des algorithmes dépourvus de pensée
Revue de PR et affaiblissement du contexte partagé
- Message central de la présentation de Jessica Rose et Eda Eren à la FFConf : « un code qu’on n’a pas écrit soi-même est un code qu’on ne comprend pas, et un code qu’on ne comprend pas est un code qu’on ne peut pas maintenir »
- Une PR rédigée par un collègue contient un certain niveau de confiance et de raisonnement, mais une PR générée par LLM n’offre aucune telle garantie
- Les mainteneurs open source font déjà l’expérience d’une explosion de PR de mauvaise qualité générées par LLM
- Certaines entreprises demandent à Claude dans Slack d’effectuer des modifications de code par chat, puis la même personne approuve la PR générée automatiquement
- Dans ce cas, toute la responsabilité se concentre sur un seul reviewer, et l’on perd une des deux paires d’yeux
- Le contexte partagé (shared context) dans l’équipe diminue lui aussi
- La revue de PR ne sert pas seulement à repérer des bugs, mais aussi à partager la compréhension du code et des changements
Pas contre le progrès, contre le battage médiatique
- L’auteur n’est pas opposé aux LLM eux-mêmes, mais à leur branding en tant qu’« intelligence artificielle »
- Les LLM ne sont pas intelligents ; c’est une forme de machine learning
- L’« IA générative » est une chaîne de Markov très bien conçue sur laquelle les gens projettent des attentes excessives
- Pour fabriquer rapidement des prototypes, des wireframes ou des démos interactives, l’outil peut être pertinent
- Le problème, c’est de croire qu’on peut produire un logiciel de niveau production avec du « vibe coding », ou de déléguer le processus de réflexion inhérent au développement
- Point de vue de Mikayla Maki sur le blog de Zed : il faut traiter les agents comme des contributeurs externes non dignes de confiance, ne les utiliser que pour des tâches qu’on sait déjà accomplir, et comprendre le code reste indispensable
- L’auteur continuera d’utiliser le « spicy autocomplete », mais n’externalisera pas sa réflexion, et rappelle qu’il faut se souvenir de ce qui nous a fait aimer ce métier au départ
Aucun commentaire pour le moment.