La génération de code par LLM peut entraîner un affaiblissement de la confiance

• La génération de code basée sur les LLM est récemment de plus en plus utilisée parmi les développeurs
• Le code généré automatiquement alimente des inquiétudes croissantes concernant la qualité du code et sa fiabilité
• Les développeurs constatent une hausse de la difficulté de maintenance des projets en raison d’une compréhension insuffisante du code et d’une validation incomplète
• La diffusion de l’usage de code non fiable a un impact sur l’ensemble de l’écosystème logiciel
• Avec les avancées technologiques, la nécessité de mettre en place des moyens de garantir la fiabilité est soulignée

---

Aperçu

Dans son blog, Jay aborde l’impact des récentes technologies de génération de code basées sur les LLM (grands modèles de langage) sur le développement logiciel. Si l’évolution de ces outils améliore l’efficacité du développement, elle fait aussi émerger des questions de fiabilité et de qualité du code.

L’essor des technologies de génération de code par LLM

• Dans le développement logiciel, les outils de génération automatique de code utilisant des LLM se diffusent rapidement
• Ils offrent une forte productivité pour l’implémentation de fonctionnalités complexes ou les tâches de codage répétitives
• Ils présentent l’avantage de permettre un prototypage rapide et d’alléger la charge liée à l’apprentissage de nouveaux langages

Les problèmes de fiabilité

• Le code généré par les LLM ne fonctionne pas toujours comme prévu
• L’intention et la logique de conception internes du code sont parfois floues, ce qui complique les processus de compréhension et de vérification
• Si les phases de revue et de test sont insuffisantes, des bugs ou vulnérabilités inattendus peuvent apparaître

Maintenance des projets et impact sur l’écosystème

• Le code généré automatiquement souffre souvent d’un manque de documentation et d’explications insuffisantes
• Les développeurs ont du mal à comprendre le principe de fonctionnement du code, ce qui accroît la complexité de maintenance
• Il existe un risque de dégradation de la culture de développement de logiciels fiables

Conclusion et recommandations

• Les technologies de génération de code basées sur les LLM sont innovantes, mais garantir leur fiabilité est un enjeu essentiel
• Lors de l’adoption de code généré automatiquement, la nécessité de renforcer la validation et de mener des revues de code systématiques est soulignée
• À long terme, il est important d’établir des standards pour préserver la confiance dans l’écosystème informatique

[GN⁺]

Avis sur Hacker News

• Partage d’un lien archive.is, qui fonctionne même sur de vieux navigateurs, et JavaScript n’est nécessaire que pour contourner CloudSnare

• Un ami me dit toujours que « l’innovation avance à la vitesse de la confiance ». Depuis l’arrivée de GPT3, cette phrase me trotte dans la tête. La vérification a un coût élevé, et la confiance est un moyen essentiel de réduire ce coût. Mais je ne sais pas comment construire cette confiance avec les LLM. Ils codent et manient le langage naturel avec une grande aisance, tout en s’égarant parfois dans des directions qu’on jugerait malveillantes chez un humain

  • Auteur ici : j’aime vraiment beaucoup cette citation. Elle résume de façon très concise ce que j’ai essayé d’expliquer en plusieurs paragraphes. Franchement, vivre dans un monde où il faut tout vérifier une par une est vraiment épuisant et lent
  • On ne peut pas avoir une confiance totale dans les résultats des LLM. Mais on peut les encadrer et limiter leur pouvoir de nuisance. En filtrant les entrées utilisateur, en faisant des tests d’intrusion, en cachant les secrets dans des fichiers dot, on va au final converger vers des standards du type « bonnes pratiques » et « conformité à la régulation SOC-AI ». Les LLM sont trop utiles pour être ignorés. La confiance aussi se construit étape par étape. Les humains sont de toute façon loin d’être fiables, et si on compare aux voitures autonomes, on finira probablement par produire dans des règles bien définies un code avec moins de bugs que celui des humains. Ensuite, on améliorera peu à peu la complexité gérée
  • « L’innovation avance à la vitesse de la confiance » : cette phrase mériterait d’être davantage expliquée. Est-ce qu’il y avait autant de confiance quand on a découvert l’électricité, l’aviation ou la radioactivité ? En science, la confiance se construit au fil de l’avancement

• J’ai vécu ce sujet en entreprise d’une manière inattendue. Sous la pression de livrer vite, un collègue et moi avons fusionné la grosse refactorisation sur laquelle je travaillais alors qu’elle n’était encore qu’en PR provisoire. Ensuite, des bugs sont apparus dans du code non testé. Pendant le débogage, mon collègue a fini par m’avouer qu’il pensait que j’avais codé avec l’IA, et que cela l’avait frustré d’essayer de comprendre après coup du code supposément généré par IA. Or ce code était entièrement écrit à la main, très soigneusement, et les bugs venaient simplement de petites erreurs lors d’un changement d’API. Cette expérience nous a plutôt permis de mettre au jour, de façon naturelle et constructive, une tension liée à la confiance entre nous. Avec le recul, cette expérience de construction de confiance a eu du sens, et dans un autre contexte cela aurait pu devenir bien plus compliqué. Cela m’a rappelé qu’il faut toujours rester prudent

• J’ai du mal à comprendre le postulat. La confiance dans le fait qu’une personne écrit du bon code vient de l’expérience réelle où cette personne a codé elle-même et produit de bons résultats. Si quelqu’un utilise un LLM et sort malgré tout du code sans bug, je lui fais confiance ; s’il utilise un LLM et produit du code buggué, je ne lui fais pas confiance. Je ne vois pas en quoi c’est différent d’un code écrit uniquement de tête

  • Auteur ici : mon point, c’est que dans les environnements à faible confiance — grandes équipes de confiance moyenne, open source, etc. — les LLM rendent de plus en plus difficile l’évaluation du niveau réel d’un développeur à partir du seul code soumis. Comme on ne peut plus cerner la personne en face, on finit par devoir adopter une posture de « confiance nulle » et relire tout le code en détail. Les raccourcis qu’on utilisait jusque-là pour faire des reviews rapides ne fonctionnent plus, et cela peut être assez douloureux pour des organisations habituées à cette culture. Si vous travaillez déjà dans une équipe où la confiance est très forte, ce problème peut sembler complètement abstrait
  • Avant, si A=B, alors une hausse de B signifiait aussi que A était bon. Maintenant, c’est devenu A+Ai=B, donc même si B est élevé, A ne l’est pas forcément. Et vu l’état actuel de l’IA, qui reste probabiliste, elle fait souvent pire que ne rien faire du tout
  • Tu dis « je ne fais confiance qu’au code qui fonctionne », mais la base de cette confiance, c’est que le développeur sait à l’avance que le code est réellement sans bug. Or, dans un système complexe, pour savoir comment le code va interagir avec le reste et quels cas limites peuvent apparaître, l’auteur du code doit comprendre le contexte global. Si un LLM a écrit le code à sa place et que le développeur ne comprend pas entièrement ce qu’il a soumis, alors la charge de vérification est transférée au reviewer, qui finit en surcharge. C’est ça l’argument
  • Quand on code avec un LLM, les premières réussites donnent vite trop confiance et on relâche les tests. En réalité, beaucoup de problèmes viennent d’erreurs de communication. La personne comprend clairement la tâche globale, mais le LLM a du mal à maintenir l’état et, si le contexte est ambigu, il fait des hypothèses absurdes. J’aimerais vraiment que l’approche de 4o — demander d’abord continuellement les informations complémentaires nécessaires — devienne un standard pour tous les modèles de génération de code, ça éviterait énormément de problèmes
  • La confiance ne se construit pas seulement sur le fait que ça marche ou non. On la construit aussi sur la capacité à expliquer clairement les changements, l’historique de bonnes contributions, une taille de changements appropriée (par exemple des commits de taille raisonnable), le bon ordre de priorité des problèmes (corriger les bugs avant d’ajouter des fonctionnalités), la capacité à maintenir le code existant, la régularité des contributions, etc.

• On est déjà dans cette époque-là. Je vois trop souvent des « désolé, j’ai raté ce point, vous avez raison ». Au moins 8 ou 9 fois sur 10. À l’inverse, je vois aussi souvent des gens faire du copier-coller vide de sens de code généré par LLM, puis se mettre en colère quand le résultat n’est pas à la hauteur. En fait, je préfère presque ça. Je préfère quelque chose de manifestement cassé à quelque chose qui a l’air correct en surface

  • D’après mon expérience, les LLM ont souvent tendance à modifier le code pour faire passer les tests plutôt que pour réellement satisfaire les exigences
  • Vous utilisez les LLM via un chatbot dans le navigateur ? Nous, on utilise des agents IA avec accès direct au code, et ils parlent beaucoup moins tout en faisant souvent un meilleur travail que les juniors autour de nous. Ils exécutent bien des tâches courtes et précises, si bien qu’un simple code review suffit souvent et qu’on est presque prêts à les utiliser tels quels. Bien sûr, un moteur de prédiction ne sait pas faire de la vraie ingénierie. Par exemple, si on ne demande pas explicitement un generator Python, il produit souvent du code qui explose la mémoire. Mais beaucoup de développeurs Python autour de moi font les mêmes erreurs. D’une certaine façon, cela pousse à écrire une spécification claire au lieu de juste demander « ajoute une feature », et c’est utile. Les agents IA sont particulièrement utiles sur le code legacy dont personne ne veut s’occuper. On a par exemple un système d’extraction de données basé sur 200 coordonnées issues d’un document reçu par fax, utilisé tel quel depuis plus de 30 ans, et le document a récemment changé. copilot a modifié les coordonnées en 30 secondes. Un humain aurait facilement passé la journée dessus. En revanche, je ne sais pas comment on devient expert dans une époque de développement façonnée par ce genre d’outils
  • 8 ou 9 fois sur 10, c’est vraiment énorme. C’est une statistique complètement inventée

• Les anciens outils d’abstraction réduisaient la complexité tout en prenant pour acquis la « justesse » de l’abstraction. Bien sûr, ce n’était pas parfait et il y avait des bugs, mais ils relevaient de l’implémentation, pas d’une erreur intrinsèque. Une fois corrigés, ces outils devenaient plus robustes. Les LLM, eux, sont des moteurs de prédiction probabilistes qui n’offrent qu’une exactitude approximative sur une période donnée. Cela dit, l’auteur passe à côté d’un point : on peut construire des systèmes déterministes dignes de confiance à partir d’agents probabilistes imparfaits. Par exemple, on ne fait pas confiance à un outil de garbage collection parce qu’on croit en son auteur, mais parce que l’outil lui-même a été suffisamment testé et qu’on a montré qu’il se comporte comme attendu. À l’avenir, j’ai l’impression que le développement piloté par les tests va se renforcer. Ce ne sera plus de la confiance, mais de la vérification

  • Penser que les tests automatisés peuvent tout attraper est naïf. Il y a trop de choses difficiles à automatiser : concurrence, gestion des ressources, failles de sécurité, etc. Et qui va vérifier les tests eux-mêmes ? Le code et les tests implémentent chacun une logique, et il arrive que la cause du bug apparaisse du côté des tests plutôt que du code. Il ne faut pas non plus faire une confiance aveugle aux tests
  • Auteur ici : je parle ici davantage de la nature de l’outil lui-même que de ses effets. Par exemple, si le modèle jouait directement le rôle d’un garbage collector, en recevant le dump mémoire d’un programme puis en décidant quels blocs inutiles libérer, je ne pourrais jamais faire confiance à ce jugement pour toujours. Même avec des « patchs » ou du fine-tuning, il y aurait une limite. Avec la JVM, si une erreur survient dans une sortie déterministe, un correctif élimine cette erreur une fois pour toutes. Ce n’est pas le cas avec un LLM. Je pense que cette différence constitue la bifurcation fondamentale entre les abstractions classiques et le monde des LLM. Je crois que les LLM auront un grand impact sur l’industrie, mais comme les précédents historiques sont limités, on est vraiment en territoire inconnu
  • Le passage sur le fait qu’« un système déterministe fiable peut émerger d’un facteur probabiliste, une machine à entropie », me paraît assez radical. Et j’ai l’impression qu’on présente toujours le TDD comme un outil miracle qui résoudrait tout. Pourtant, j’ai vu un nombre honteusement élevé de cas où de mauvais tests ont conduit à construire le mauvais logiciel

• Être hostile aux LLM ne sert à rien. Aujourd’hui, les LLM améliorent la productivité des développeurs. C’est encore plus vrai, au moins, pour les développeurs moins expérimentés. Un outil qui augmente fortement la productivité ne sera abandonné quoi qu’on en dise. Même si des incidents apparaissent — gros bugs, interruption prolongée de grands services — la technologie ne s’arrêtera pas si le gain de productivité reste jugé important. La seule voie réaliste est d’avancer avec cette technologie tout en corrigeant ou atténuant ses faiblesses. Et si les mesures d’atténuation nuisent au gain de productivité, elles seront contournées ; ce sont donc les compléments compatibles avec la technologie qui finiront par s’imposer

  • Dire que « les LLM augmentent la productivité des développeurs » dépend énormément des personnes et du contexte. D’après mon expérience, ceux qui parlent de « productivité x10 » sont souvent soit des développeurs front-end juniors, soit des développeurs de startup qui créent souvent des apps au stade initial. Ce sont certes de bons cas d’usage, mais un profil comme ça et un senior en C embarqué ne parlent littéralement pas de la même chose. Le débat sur la productivité de l’IA est donc souvent une conversation entre contextes différents. Et même sur le plan de « l’usage raisonnable », je me demande si la notion même d’agent IA est une bonne idée. Quand on voit l’affaire Copilot, Microsoft comme l’IA ont été tournés en ridicule. Confier un travail de manière autonome à une IA n’est pas forcément une approche si intelligente. De la même manière, la blockchain a connu toutes sortes d’exagérations à l’époque de l’euphorie crypto, mais certains cas comme Coinbase ont trouvé une niche réellement utile. En 2020, IBM affirmait gérer la chaîne d’approvisionnement du café avec de la blockchain — vu depuis 2025, ça ressemble à une blague Twitter, mais à l’époque c’était présenté très sérieusement. Au final, les agents IA actuels, comme d’autres usages de l’IA générative, pourraient plus tard être vus comme des exemples d’hype excessive incident Copilot article Forbes
  • L’expression « plus productif » revient sans cesse, mais cela ne dit pas si l’association humain/IA répond mieux, au final, aux besoins des utilisateurs ; cela veut seulement dire qu’on produit « plus de code ». Je n’ai jamais entendu parler d’un LLM qui aurait créé une PR supprimant 2 000 lignes de code. En pratique, « améliorer la productivité des ingénieurs » signifie surtout écrire davantage de code
  • C’est une erreur de croire que l’intention de l’auteur est réellement hostile. La question n’est pas de choisir pour ou contre les LLM, mais de se concentrer sur la gestion et l’atténuation des risques. Pour prendre une analogie, ce n’est pas être contre l’invention de la voiture ; c’est dire que comme les voitures peuvent exploser, il faut davantage se concentrer sur la réduction de ce risque
  • Je ne vois pas le billet original comme une « plainte stérile », mais plutôt comme une réflexion réaliste sur les pièges dans lesquels on tombe facilement quand on collabore avec des LLM, et sur les garde-fous à mettre en place dans les équipes
  • Quand React est sorti, je regrette de ne pas l’avoir appris plus tôt. J’ai encore une forme de rejet vis-à-vis de GPT, et autour de moi j’entends souvent « c’est chatGPT qui l’a dit » ou « ça, c’est du code chatGPT », alors que moi j’ai une certaine fierté à coder en me débrouillant par moi-même. Je n’utilise pas GPT, mais au fond on pourrait aussi considérer Google ou stackoverflow comme une version lente de GPT

• Plutôt que des politiques du style « je promets que le code contribué n’est pas un produit de LLM, qu’il est original et que je le comprends entièrement » ou « la plupart des contributions doivent être faites à la main », il faut se concentrer sur le résultat. Exiger d’un contributeur qu’il comprenne bien ses changements, c’est très bien. En revanche, des règles comme « les juniors doivent limiter ou éviter les outils LLM pendant une certaine période » me semblent médiocres. Les LLM sont très utiles pour les problèmes pénibles de configuration d’environnement à l’onboarding. Ils aident aussi à comprendre le code et la documentation, et ce sont de bons outils de recherche textuelle et de synthèse

  • L’onboarding consiste en pratique à apprendre à résoudre des problèmes d’environnement aléatoires. Si on élimine toutes ces difficultés et cette complexité par l’automatisation, j’ai l’impression qu’un jour plus personne ne saura quoi faire dans ce genre de situation. Je me demande si je suis le seul à le penser

• Je découvre pour la première fois le concept d’« AI Cliff » (le moment où la précision d’un LLM chute brutalement). Je suis curieux de savoir si d’autres l’ont vécu

  • Oui, souvent. Quand la complexité du code dépasse un certain seuil critique, le LLM n’arrive plus à garder tout le contexte en tête et se met à dérailler. Mon rôle consiste à gérer la complexité à laquelle le LLM est exposé. Les LLM actuels ont tendance à complexifier davantage la structure au fil du temps. En général, je leur demande de refactoriser pour simplifier ou, si ça devient vraiment trop complexe, je reprends moi-même le ménage. Si on les laisse faire trop longtemps, les LLM finissent par produire une énorme machine de Rube Goldberg, et c’est ensuite à l’humain de nettoyer. Un développeur expérimenté repère vite jusqu’où le LLM l’emmène au large et peut revenir tôt ; un débutant, lui, risque d’être complètement perdu avant même d’avoir compris qu’il y avait un problème
  • J’appelle ça être ivre de contexte. Si l’entrée contient 10 000 tokens et qu’elle est correcte à 99 %, puis que le LLM produit une réponse de 1 000 tokens correcte à 90 %, à force d’échanges une grande partie de la fenêtre de contexte finit remplie de sorties du LLM moins exactes que l’original. Les erreurs s’accumulent et, comme les informations récentes pèsent davantage, cela devient de plus en plus bancal. Ce problème n’apparaît pas seulement dans le code, mais aussi dans la prose
  • Moi, j’appelle ça la pourriture du contexte. À mesure que le contexte s’accumule, la qualité de sortie baisse. Plus il y a de bavardage ou de contenu hors sujet, plus la dégradation s’accélère. C’est particulièrement vrai quand du chain of thought (COT) reste dans le contexte : si le raisonnement déraille, la trace empire la situation. Personnellement, j’aimerais qu’il existe une fonction de pruning pour couper une partie du contexte. En attendant, je résume moi-même puis je repars dans une nouvelle session pour contrer cette pourriture du contexte
  • Je n’ai connu ça que dans des interfaces de chat type vibe coding ; avec les outils orientés agents, qui gèrent eux-mêmes la fenêtre de contexte du code et exécutent directement les outils de développement pour faire des sanity checks, cela arrive bien moins souvent
  • Je réinitialise souvent mes sessions IA pour le travail, donc je ressens peu cet « AI cliff ». En revanche, en écriture de fiction, où la longueur et la cohérence du contexte comptent beaucoup, j’ai déjà vu une IA ne plus réussir à maintenir correctement la personnalité d’un personnage et se mettre à réagir bizarrement. C’était une expérience très étrange, d’autant qu’on ne pouvait pas revenir en arrière

• L’auteur du billet dit qu’il ne va pas résumer les messages de tout le monde, mais en pratique c’est un peu ce qu’il fait. Cela dit, j’aimerais bien qu’il existe dans les PR un indicateur sur les fichiers contenant du code généré par IA. Les erreurs du code LLM et celles du code humain ne sont pas du même type, donc pouvoir les distinguer ferait gagner du temps en review. Je suis curieux de savoir si quelqu’un a déjà vu ce genre de politique dans une grande organisation, ou s’il existe déjà des outils d’automatisation pour cela. Si des entreprises mesurent la part de code générée par LLM, il existe peut-être déjà des outils capables d’aller jusqu’à ce niveau de métriques

  • Auteur ici : en pratique, il n’y a pas beaucoup de discussions explicites autour de la confiance dans l’équipe et des LLM, donc je n’ai pas vu d’exemples formalisés. Je ne sais pas si c’est parce que je travaille dans le mauvais environnement pour ce sujet, ou simplement parce qu’il est difficile à repérer dans le courant dominant