Avec le codage par IA, vous pouvez désormais choisir le nombre de bugs que vous souhaitez

Par Nolan Lawson

Il y a un aspect étrange dans la programmation avec l'IA que j’essaie de cerner, et je pense que c’est celui-ci : vous pouvez en gros décider dès maintenant du nombre de bogues que vous voulez que votre logiciel contienne.

Nous l’avons d’abord découvert dans le domaine de la sécurité, car bien sûr, les bogues de sécurité sont ceux sur lesquels on ne peut absolument pas transiger. Mais je pense qu’une fois la « vulnpocalypse » (apocalypse de vulnérabilité) terminée, nous commencerons à nous intéresser à d’autres types de bogues : la justesse, les performances, l’accessibilité, la fiabilité, etc.

Certains d’entre nous le font déjà. Par exemple, je passe beaucoup de temps ces derniers temps à réviser du code, en utilisant des outils tels que ma compétence « triple-agent » de révision de code ainsi que la compétence « explain-diff » de Geoffrey Litt.

D’après mon expérience, dans un système complexe, on peut en gros trouver autant de bogues qu’on en demande aux agents. Si vous en avez assez de corriger les bogues directement dans la pull request, pas de panique : l’agent trouvera également de nombreux bogues préexistants sur lesquels vous pourrez vous pencher. La question est simplement de savoir quand vous souhaitez vous arrêter et considérer que le travail est « terminé ».

Bien sûr, la correction des bogues a un coût. Il reste encore de nombreux compromis à prendre en compte : le nombre de lignes de code par rapport à la probabilité que le bug se produise réellement, le risque d’introduire de nouveaux bugs dans une solution complexe, le coût lié au fait de rendre le code plus difficile à comprendre pour les futurs relecteurs ou agents, etc. Mais la détection des bugs est devenue pratiquement gratuite, et les agents IA sont également capables de trouver des bugs très subtils et complexes qui, sans cela, auraient pu passer inaperçus pendant des années. Ce que nous faisons de cette situation est la question intéressante.

Comme beaucoup l’ont fait remarquer, il ne semble pas que la qualité globale des logiciels se soit améliorée depuis l’avènement du codage par IA. Au contraire, on trouve simplement davantage de logiciels de mauvaise qualité et de produits de mauvaise qualité, dont la qualité est douteuse. Je pense que cela démontre que, bien que notre capacité à détecter de nouveaux bogues ait explosé, notre tolérance globale vis-à-vis des bogues n’a pas changé. De nombreux facteurs continuent de souffler dans la direction opposée :

- Le paradoxe du problème évitable : si un incident se produit et que vous intervenez pour le résoudre, vous passez pour un héros. Si vous empêchez le problème de se produire dès le départ, personne ne sait que vous avez agi.

- Dans le même ordre d’idées : au sein de nombreuses entreprises de logiciels, la pression consiste à continuer de livrer des résultats visibles, et non à peaufiner quelque chose qui « fonctionne » déjà. Avec le codage par IA, ce phénomène est amplifié : la direction part souvent du principe qu’une productivité multipliée par 10 signifie 10 fois plus de fonctionnalités et d’applications visibles.

- La paresse : l’une des vertus classiques du programmeur, qui, cette fois-ci, joue en notre défaveur. Je me retrouve mentalement épuisé après avoir parcouru péniblement le énième rapport de bug généré par l’IA, ce qui m’oblige à réfléchir minutieusement aux aspects complexes du système et à peser le pour et le contre d’une correction. J’imagine que bon nombre de mes confrères du secteur ont tout simplement cessé de prêter attention aux revues de code générées par l’IA ou ne se concentrent que sur les résultats les plus critiques.

Éviter les épicycles

Il existe toutefois plusieurs façons d’aborder ce problème qui ne nécessitent pas un labeur sans fin. L’une d’elles consiste à configurer l’agent en boucle, par exemple : « effectuer une revue de code, corriger tous les problèmes critiques/élevés/moyens, puis répéter ». Je trouve que cela peut fonctionner, mais cela a tendance à créer de nombreux épicycles.

Si vous n’êtes pas familier avec ce concept : dans le modèle pré-copernicien du système solaire, les astronomes de l’Antiquité « corrigeaient » les erreurs de calcul dans les orbites des planètes en ajoutant simplement davantage de cercles à leur mouvement. Cela améliorait la précision des prédictions, mais au prix d’une complication du modèle global. Évidemment, le simple fait de dire « la Terre tourne autour du Soleil » simplifie considérablement le tout, mais il faut d’abord avoir l’intuition nécessaire pour rendre cette simplification possible.

J’ai constaté que les agents d’IA sont plutôt nuls pour ce genre de simplifications radicales (en d’autres termes, « les LLM ne savent pas sauter »). Ils se feront un plaisir de créer un épicycle par bug jusqu’à ce que le code devienne un véritable fouillis. Ainsi, une partie importante de la revue de code en IA consiste toujours à poser des questions telles que « Comment pouvons-nous simplifier cela ? » et « Y a-t-il une faille fondamentale dans la base de code que nous devrions corriger avant de nous attaquer à cette catégorie de bugs ? »

Une autre technique qui fonctionne bien consiste à disposer de bons tests. (Plus facile à dire qu’à faire !) Par exemple, lorsque je m’amusais à coder en vibe l’API IndexedDB du W3C, il m’est apparu assez clairement qu’un agent pouvait simplement passer au crible la suite de tests, et s’il atteignait près de 100 %, je pouvais alors être raisonnablement certain d’avoir une implémentation exempte de bogues. Mais si cela fonctionne, c’est uniquement parce que les Web Platform Tests constituent une suite de tests exceptionnellement performante, affinée au fil des années par des développeurs de navigateurs indépendants qui ont découvert des bugs insolites et ajouté des cas de test pour tous les scénarios improbables imaginables. La plupart des entreprises, pour leurs bases de code propriétaires, ne peuvent que rêver d’une telle suite de tests.

J’imagine toutefois que si vous développez un système à partir de zéro, et surtout si votre objectif est de reproduire le comportement d’un système existant, vous pouvez aller très loin en concentrant tous vos efforts sur la suite de tests, puis en laissant l’agent se débrouiller tout seul pour le reste. PGRust semble obtenir de bons résultats avec cette approche.

Une troisième technique consiste simplement à simplifier la conception de votre système afin que des catégories entières de bogues deviennent impossibles. Par exemple, je prône depuis longtemps les applications multipages (MPA) plutôt que les applications monopages (SPA), simplement parce qu’avec les MPA, des catégories entières de bogues n’existent tout simplement pas : dysfonctionnement du bouton « Retour », perte de l’état de défilement, fuites de mémoire côté client, accessibilité inadéquate lors des navigations entre les pages, etc.

Bien sûr, un système plus simple offre moins de puissance qu’un système complexe, et une réponse raisonnable pourrait être de choisir délibérément un système plus complexe tout en corrigeant simplement tous les bogues. J’ai toutefois le sentiment que cela conduirait encore à une sorte d’épicycles, et je préfère de loin lire (ou déboguer !) une base de code reposant sur des principes plus simples plutôt qu’une autre fondée sur des principes complexes, même si les deux présentent globalement le même niveau de bogues.

Conclusion

C’est devenu un cliché de dire que nous vivons une époque sans précédent, et que tout le monde cherche à définir à quoi doit ressembler exactement le génie logiciel à l’heure où les robots peuvent accomplir une bonne partie de ce qui constituait autrefois « le travail ». Et pourtant, cela vaut toujours la peine d’être dit. Tout ce que j’ai écrit dans cet article de blog risque de devenir obsolète en l’espace de quelques mois, et les cinq prochains articles sur l’IA que vous lirez sur Hacker News défendront probablement cinq opinions différentes. C’est un véritable chaos, et je ne suis pas convaincu d’avoir trouvé toutes les réponses.

J’ai donc choisi de me concentrer sur le court terme : c’est-à-dire ce pour quoi les agents sont doués aujourd’hui, et dans quels domaines les humains peuvent encore apporter une certaine valeur ajoutée. Certaines personnes partent du principe que toutes les préoccupations liées à la qualité du code, à sa complexité et à sa maintenabilité seront un jour balayées par des agents capables de gérer sans peine n’importe quel système hérité, aussi baroque soit-il. Cela finira peut-être par se vérifier, mais je ne vais pas parier là-dessus, car je ne l’ai pas encore constaté. Pour l’instant, je reste attentif à des principes tels que DRY et KISS, je garde à l’esprit une théorie opérationnelle du code (à la manière de Peter Naur) et j’essaie d’orienter l’agent vers une meilleure qualité de code.

Je trouve toutefois intéressant que nous disposions d’une capacité bien plus grande qu’auparavant à résoudre des bogues de plus en plus subtils. Peut-être cela mènera-t-il à une renaissance de la fiabilité, ou peut-être aboutira-t-il au même niveau global de bogues, mais avec davantage d’applications et davantage de fonctionnalités dans chacune d’elles. Je sais que ma préférence personnelle va vers un plus grand savoir-faire logiciel, mais il reste à voir comment l’industrie du logiciel dans son ensemble relèvera ce défi.

Source : "You can just choose how many bugs you want now"

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Comment j'utilise les grands modèles de langage (LLM) en tant qu'ingénieur logiciel en 2026, par Sean Goedecke

Une analyse honnête de la programmation avec l'IA, par Mathieu Ropert

Utiliser l'IA pour écrire un meilleur code, mais plus lentement, par Nolan Lawson