- 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
2 commentaires
> Le code généré automatiquement est non déterministe (non-deterministic)
> Opposé au branding « intelligence artificielle »
C’est vraiment le point le plus important...
Sur GeekNews aussi, certains font l’analogie avec une calculatrice ou un appareil photo, mais si même les développeurs ont cette perception, c’est inquiétant de voir ce qu’il en est pour le grand public.
Commentaires sur Hacker News
Tant que l’IA sera perçue non pas comme un « vélo pour l’esprit », mais seulement comme un produit destiné à maximiser les profits des grandes entreprises, il sera difficile de justifier son état actuel
Une structure qui aspire des données, les transforme puis les recrache sans véritable processus d’apprentissage nuit à la croissance intellectuelle humaine
Au final, l’essentiel est de construire un modèle de revenus, sinon il est impossible de maintenir des LLM de haute qualité
Je ne fais désormais presque plus aucune édition manuelle. Il suffit de donner l’URL du ticket à Claude Code et, dans la plupart des cas, c’est réglé du premier coup
Je suis convaincu que les équipes qui investissent dans cette manière de faire seront bien plus productives que celles qui ne le font pas
Les LLM sont une technologie qui offre une expérience totalement différente selon les personnes, avec une grande liberté dans les prompts
Pour implémenter un design précis, il est souvent plus rapide de l’écrire soi-même
Dire « je ne peux pas comprendre du code que je n’ai pas écrit » n’est pas réaliste
Le but d’une revue de code n’est pas l’identité de l’auteur, mais d’assurer la fiabilité du système
Que ce soit un humain, une IA, ou même un golden retriever qui l’ait tapé, peu importe
Mais plutôt que de perdre du temps à essayer de comprendre une PR produite par une IA, j’ai l’impression qu’il vaut mieux envoyer moi-même le prompt et obtenir le résultat
En s’appuyant sur les LLM, les développeurs perdent l’occasion d’apprendre la structure du projet, et finissent par traiter le système comme une boîte noire
Cette évolution transforme les développeurs en « prompt kiddies »
Je comprends l’idée de dire « plutôt que de perdre du temps à peaufiner des prompts, je préfère écrire le code moi-même »
Le problème, ce n’est pas la « génération », mais la génération non structurée
Au lieu de prompts improvisés, il faut une approche fondée sur une composition claire par unités de compétence
Dire à l’IA « tu es un expert des systèmes distribués », c’est une histoire de l’époque GPT-3
Aujourd’hui, grâce au fine-tuning et aux techniques de post-traitement, ce type de prompt basé sur les rôles n’est plus nécessaire
En voyant l’engouement autour de la génération de code par LLM, j’avais peur d’être en train de décrocher
J’utilisais Copilot et Claude uniquement comme assistants d’autocomplétion, et pour le code complexe c’était toujours médiocre
Mais aujourd’hui, les outils fondés sur des agents explorent la base de code, cherchent des ressources sur le web et ajustent eux-mêmes le contexte
Au final, le problème vient de « gens qui se plaignent sans vraiment comprendre la technologie »
En pratique, il est très probable qu’ils ne maîtrisent pas assez l’art du prompt
S’ils donnent l’impression de « penser », c’est seulement parce que les outils autour automatisent la recherche et l’exécution
Au final, c’est de l’automatisation, pas de l’intelligence
En ce moment, beaucoup de posts et de commentaires sur HN donnent l’impression d’avoir été écrits par un LLM
Il n’y a rien de nouveau, et la plupart ne font que répéter des généralisations superficielles
Quand on regarde les actualités récentes, on voit que l’IA n’est pas encore assez mature
Ex. : la baisse des objectifs de revenus de Copilot chez Microsoft et
les problèmes de sécurité de Moltbook
En fin de compte, la plupart des gens ne font pas confiance à l’IA
L’IA est utile pour explorer des idées ou écrire du boilerplate, mais la capacité de réflexion reste essentielle
L’IA est la meilleure tentation qui soit pour remplacer la pensée humaine, mais à long terme elle risque d’affaiblir notre muscle de la réflexion
Si, après une période d’usage, on essaie de recoder à la main, on sentira probablement une baisse de fluidité
Peut-être que Claude est simplement meilleur que Copilot, et que les problèmes de sécurité de Moltbook sont le destin habituel d’un service naissant
Au final, c’est le taux de survie des entreprises qui adoptent l’IA et de celles qui ne l’adoptent pas qui montrera le résultat
Moi aussi, avant, je pensais que « l’IA est une boîte noire stupide », mais ces six derniers mois, mon point de vue a complètement changé
Si on apprend à s’en servir correctement, elle peut produire des résultats surprenants
Aujourd’hui, je vois l’IA comme un amplificateur, un outil qui étend mes capacités