Les agents d’IA utilisés pour écrire du code doivent réduire les coûts de maintenance
(jamesshore.com)- À long terme, ce sont les coûts de maintenance qui déterminent la productivité bien plus que la vitesse d’écriture du nouveau code
- Dans le modèle d’exemple, au bout de deux ans et demi, la maintenance dépasse la moitié du temps total
- Si les agents d’IA augmentent à la fois la production et les coûts de maintenance, leur effet disparaît rapidement
- Même si l’on cesse d’utiliser l’agent, le surcoût de maintenance du code déjà produit reste présent
- Si la production double, le coût de maintenance par unité de code doit aussi être divisé par deux
Les coûts de maintenance déterminent la productivité
- Tout le temps consacré à écrire du code génère ensuite en continu du temps de maintenance, comme les corrections de bugs, le nettoyage du code ou les mises à niveau de dépendances
- L’analyse ne porte pas sur les nouvelles fonctionnalités ni sur les améliorations, mais uniquement sur la maintenance récurrente qui se répète chaque année tant que le code existe
- L’estimation d’exemple suppose qu’un mois d’écriture de code entraîne 10 jours de maintenance la première année, puis 5 jours chaque année suivante
- Selon l’auteur, en demandant à une cinquantaine de développeurs d’estimer les coûts de maintenance selon une approche de type Wisdom of the Crowd, on peut obtenir une réponse assez précise
- D’après ce modèle sur feuille de calcul, le début d’un nouveau projet consacre l’essentiel du temps au développement de fonctionnalités, mais avec le temps la part de maintenance du code passé grossit
- Dans cette estimation, au bout de deux ans et demi, le temps consacré à la maintenance dépasse la moitié du total, et après 10 ans, il devient presque impossible de faire autre chose
- Si l’on divise par deux l’estimation de maintenance, on gagne encore 3 ans avant d’atteindre le seuil des 50 % ; si on la double, la productivité tombe sous les 50 % en moins d’un an
- Si l’on veut une équipe productive, il faut se concentrer sur les coûts de maintenance plus que sur la vitesse d’écriture du nouveau code
Le modèle peut être faux, mais la direction est juste
- Dans des startups en phase plus avancée, après 5 à 9 ans, des équipes se retrouvaient à ne plus vraiment réussir à terminer leur travail, ce qui ressemblait au schéma montré par le graphique
- Si les équipes réelles n’ont pas l’air d’aller aussi mal que le graphique, c’est peut-être parce que leurs coûts de maintenance étaient plus faibles, ou parce qu’elles ont masqué le problème autrement
- Les réponses possibles consistent à ne pas corriger tous les bugs, à ne pas mettre à jour toutes les dépendances, à ajouter du personnel quand l’équipe ralentit puis à continuer d’en ajouter, ou à tout abandonner et réécrire
- Les chiffres exacts peuvent se discuter, mais la grande tendance d’une productivité qui diminue avec le temps semble empiriquement correcte
L’effet multiplicateur créé par les agents de code IA
- À titre d’exemple, l’auteur suppose que le framework récent d’agent de code Rock Lobster double la quantité de code produite
- Il suppose aussi que le code devient un peu plus difficile à comprendre, que l’équipe se retrouve noyée sous les pull requests et qu’elle ne lit plus vraiment le code avant validation
- Si l’on produit en un mois l’équivalent de deux mois de code, et que le coût de maintenance de ce résultat double aussi, alors le coût de maintenance du mois suivant est multiplié par 4
- Dans cet exemple extrême, environ 5 mois après l’adoption de Rock Lobster, la productivité revient à son niveau initial, puis quelques mois plus tard devient pire que sans l’outil
- Cela ne signifie pas que l’IA double réellement la productivité ou les coûts de maintenance, mais souligne que même si la maintenabilité reste équivalente à celle du code écrit par des humains, le gain de productivité ne dure pas longtemps
Même si l’on arrête l’agent, les coûts de maintenance restent
- Les agents de code ont un coût, et lorsque leur utilité devient inférieure à ce coût, on peut vouloir revenir à l’ancienne manière de travailler
- Si l’on arrête d’utiliser l’agent, le gain de productivité disparaît, mais le surcoût de maintenance du code produit avec l’agent persiste tant que ce code existe
- Dans ce cas, on peut se retrouver bloqué avec une productivité inférieure à celle que l’on aurait eue sans jamais utiliser l’agent
La seule mathématique qui tienne est la baisse des coûts de maintenance
- Pour que le calcul global de productivité tienne, les LLM doivent réduire les coûts de maintenance exactement dans la même proportion inverse que celle avec laquelle ils augmentent la production de code
- Si la production double et que le coût de maintenance du résultat double aussi, alors le coût total de maintenance est multiplié par 4
- Si la production double mais que le coût de maintenance par unité produite reste le même, le coût total de maintenance est quand même multiplié par 2
- Si la production double, le coût de maintenance doit être divisé par deux ; si elle triple, il doit être divisé par trois
- Il faut satisfaire cette condition pour obtenir un gain de vitesse sans créer une dépendance défavorable à long terme
Inquiétudes actuelles sur les agents de code et autres leviers possibles
- Sur des sources comme Hacker News, on voit beaucoup de signaux laissant penser que les agents de code augmentent les coûts de maintenance
- Certains disent qu’ils aident à comprendre les grands systèmes, mais l’auteur estime qu’on ne voit pas la forte baisse des coûts de maintenance nécessaire, et qu’on observe plutôt l’inverse
- Le modèle ne représente peut-être pas parfaitement la réalité, mais le message selon lequel l’IA doit réduire les coûts de maintenance à proportion de l’accélération de l’écriture de nouveau code reste valable
- Même si l’on cherche à améliorer la vitesse de codage, il faut consacrer autant d’efforts à améliorer les coûts de maintenance
- Il ne s’agit pas d’un argument anti-IA : il peut aussi exister d’autres leviers, comme une IA qui rend les tâches de maintenance elles-mêmes plus productives, même sans améliorer directement la maintenabilité du code
- Pour adapter les hypothèses à une situation réelle, on peut copier la feuille de calcul et ajuster les différentes variables du modèle
1 commentaires
Commentaires sur Hacker News
Lors de la présentation Dconf'24 Software as investment, il a été proposé un framework de base fondé sur des fonctions de valeur composables pour chaque morceau de logiciel
Ce framework lui-même n’a pas particulièrement besoin de changer à cause de l’IA, il suffit plutôt de mettre à jour le modèle de coût selon la qualité du travail de l’IA en maintenance
On dit que l’IA introduit 1,7 fois plus de bugs, mais elle les corrigera peut-être aussi plus vite, donc difficile à trancher
Si on considère le logiciel comme un investissement, on parle de « valeur » plutôt que de « dette technique », et la dette n’est qu’un actif dont la valeur est inférieure à 0
Si le logiciel sort du monde passé des fortes marges, il faut définir avec précision ce qu’est un logiciel qui mérite d’exister économiquement
Dans le logiciel, il y a toujours des parties qui auraient pu être mieux écrites, et c’est cela, la dette
C’est une perspective pertinente, et je suis d’accord
Malheureusement, la maintenabilité finit souvent dans la case des « exigences non fonctionnelles »
Pourtant, des exigences non fonctionnelles comme la maintenabilité devraient être vues comme ce qui préserve et rend possible la livraison des futures exigences fonctionnelles
Il ne faut pas simplement les présenter comme le « comment » par opposition au « quoi » du logiciel
Pour un projet où l’ajout continu de fonctionnalités et les améliorations comptent, sauf à très court terme, la maintenabilité est en pratique presque une exigence fonctionnelle
À partir du moment où on leur donne un nom séparé, on fournit à quelqu’un qui ne comprend pas bien le sujet un prétexte pour les isoler et les déprioriser
La qualité est importante, et si on ne l’entretient pas, l’impact sur le compte de résultat arrive très vite et très fort
Elle est donc aussi importante que n’importe quel autre facteur
On peut utiliser les termes de Kevlin Henney : caractéristiques opérationnelles et caractéristiques de développement
La maintenabilité est fondamentalement une caractéristique de développement
Elles ont peut-être une roadmap produit sur 1 à 2 ans, mais honnêtement, ces roadmaps servent souvent davantage au commercial qu’à la planification d’ingénierie
Quand le chiffre d’affaires fléchit, produit et ingénierie changent de cap, et cela arrive d’autant plus souvent que l’entreprise est jeune
Une fois sortie du mode startup, elle devrait se stabiliser, mais beaucoup ne le font pas et continuent à répéter ce schéma de planification à court terme
Résultat, la stabilité du produit reste une faible priorité
Au final, beaucoup d’entreprises semblent soit ne pas avoir les ressources pour produire du bon logiciel, soit ne pas vraiment s’en soucier
Dans notre projet, on a constaté que l’IA est rapide, mais que les bugs qu’elle introduit sont étrangement difficiles à repérer
Ce ne sont pas des bugs évidents : quelque chose casse en production trois semaines plus tard, et en retraçant, on découvre que l’IA avait mal compris une subtilité
Honnêtement, l’IA ne réduit pas tant le coût de maintenance qu’elle déplace le coût
Le temps d’écriture baisse, mais le temps de revue augmente
Le code IA, même quand il est faux, reste fluide et plein d’assurance, donc plus difficile à relire que du code humain
Le gain net dépend entièrement de la capacité de l’équipe à lire le code plus qu’à l’écrire
D’après mon expérience, l’IA réduit les coûts de maintenance
Cela dit, le contexte compte sans doute. Je travaille sur plusieurs projets vieux de plusieurs décennies, avec beaucoup de nouvelles fonctionnalités aussi, et le vieux code comme les vieux projets sont soudain devenus bien plus faciles à manipuler, à moderniser, et dans plusieurs cas à supprimer
Les dépendances vers d’anciennes bibliothèques et d’anciens outils de build ont parfois été mises à jour, parfois simplement retirées, et les builds sont plus rapides et plus simples pour les développeurs
La mise en place et l’automatisation des tests end-to-end sont aussi devenues beaucoup plus faciles, le DevOps s’est nettement amélioré, et le diagnostic des incidents en production aussi
Il y a énormément de logs et d’informations, avec des dashboards intégrés et du monitoring pour capter ce qui compte, mais désormais je peux faire bien plus d’analyses sur environ 50 projets déployés
Le point central du texte est de savoir combien d’heures de maintenance il faut pour une heure de développement de fonctionnalité « créatrice de valeur »
Donc, premièrement, il ne faut pas mesurer seulement le coût de maintenance mais le ratio, et deuxièmement, ce vieux code n’a de toute façon pas été écrit par l’IA
Mais le point de l’auteur semble être que si l’on perd l’accès aux outils IA, tout devient bien plus pénible
C’est comme déplacer une montagne confortablement avec des engins lourds puis revenir à des outils manuels
Le nombre d’incidents a augmenté avec le nombre de lignes déployées, et ces incidents deviennent aussi de plus en plus graves
Bien sûr, on a beaucoup amélioré du vieux code, on en a supprimé davantage, on peut automatiser la modernisation, mieux diagnostiquer les problèmes et on a plus d’options de mitigation
Mais tout cela n’a pas compensé l’ampleur écrasante du code déployé sans que personne ne le comprenne réellement
Notre équipe utilise aussi l’IA pour ajouter du code, mais également pour supprimer agressivement du code ancien et abandonné
Des questions comme « Quelqu’un utilise encore ça ? » ou « Comment ceci est-il appelé ? » deviennent faciles à traiter si l’on donne à l’agent le front-end, le back-end, voire toute la codebase, pour qu’il construise une cartographie du projet logiciel
Les IDE peuvent le faire dans une certaine mesure, mais souvent dans un seul langage et généralement dans un seul projet, tandis que des frontières comme RPC ou REST cassent beaucoup d’outils d’IDE
J’aime beaucoup cette question : si vous pouviez choisir, quelle codebase voudriez-vous ?
En y réfléchissant un instant, vous ne voudriez probablement pas une codebase bourrée de fonctionnalités
Vous voudriez une codebase assez proche de celle que vous avez aujourd’hui, mais facile à comprendre, à maintenir et à faire évoluer selon les enjeux métier à venir
Une codebase « active », c’est-à-dire une codebase qu’on maintient, résout des problèmes du monde réel, et résoudre ces problèmes doit toujours passer avant la propreté
Une codebase propre n’est souvent qu’un exemple de démonstration posé sur une étagère pour être admiré
J’aimerais ajouter deux choses
D’abord, dans le logiciel, il n’y a pas que la maintenance technique, il y a aussi le support utilisateur, et cela augmente à mesure que le logiciel grossit
Ensuite, je ne suis pas convaincu que les coûts de maintenance augmentent de façon linéaire
Même s’ils augmentaient linéairement, on finirait de toute façon par atteindre un point où tout le temps est absorbé par la maintenance
C’est possible s’il faut maintenir non seulement chaque partie, mais aussi la manière dont ces parties interagissent entre elles
Le signal le plus fort que j’aie vu pour savoir si l’IA réduit réellement les coûts de maintenance, c’est de voir si les développeurs traitent la sortie de l’IA comme un brouillon, ou comme un livrable final
Quand on utilise des outils IA sur une codebase existante, par exemple pour comprendre un module inconnu, générer un refactoring ciblé ou écrire des scripts de migration, la charge de maintenance diminue réellement
Parce que l’IA travaille sur du code dont je comprends déjà l’architecture, je peux donc évaluer rapidement sa sortie
Le problème apparaît quand l’IA génère du nouveau code que personne ne comprend en profondeur
Ce code doit ensuite être maintenu par quelqu’un qui ne l’a ni écrit ni conçu
Avec du code écrit par une autre personne, on peut au moins déduire l’intention à partir des noms, de la structure et de l’historique des commits
Le code généré par l’IA manque souvent de cette intention lisible, parce que son « auteur » n’a pas d’intention cohérente à l’échelle de l’ensemble du fichier
Là où l’article a raison, c’est qu’il faut mesurer non seulement la vitesse, mais aussi les coûts de maintenance
En pratique, il faut suivre sur plusieurs mois, et non quelques jours, le temps nécessaire pour comprendre du code assisté par l’IA versus du code écrit par des humains, ainsi que le taux d’échec des modifications
Il en va de même pour la revue de code
Je me demande si l’IA pourrait rendre les revues de code plus lisibles
Dans les revues de code humaines, les développeurs apprennent vite à éviter les changements visuels inutiles, comme reformater le code ou les commentaires, modifier l’indentation que l’outil ne peut pas masquer, déplacer des fonctions ou supprimer des lignes
Il faut aussi éviter les refactorings inutiles
On pourrait peut-être scinder les revues entre changements fonctionnels et changements de forme
Cela rend la revue beaucoup plus facile
La revue part du principe que « rien ne doit avoir changé », et le reviewer peut faire du pattern matching
Sinon, le reviewer doit réévaluer chaque ligne pour vérifier que rien n’a changé, ce qui est vraiment difficile à faire correctement
Les systèmes de gestion de versions que j’ai utilisés permettaient tous d’avoir une file de changements revue indépendamment
Si un refactoring est nécessaire en cours de développement, on pousse un commit, on refactore, on envoie la revue, puis on rebase le travail en cours et on continue
Si l’on envoie régulièrement des changements du type « CLEANUP: », « REFACTOR_ONLY: », le changement final sera bien plus petit qu’une énorme modification monstrueuse
Les reviewers vous seront reconnaissants pour cet effort
Dans une telle organisation, on peut même jouer avec les métriques sans que cela devienne malsain
L’auteur semble partir de l’hypothèse qu’un humain doit examiner en détail tout le code produit par l’IA, et être capable de le comprendre et de le maintenir sans aide de l’IA
D’après mon expérience, ce n’est pas ainsi que les gens utilisent l’IA
Au début, oui. Avant d’avoir confiance et avant d’apprendre à formuler des prompts donnant le résultat souhaité, on l’utilise pour automatiser les parties ennuyeuses, tandis que l’implémentation initiale ou les patterns sont fournis par les humains et l’IA complète les blancs
Cela ressemble moins à un grand bouleversement de la manière d’écrire du code qu’à une autocomplétion améliorée
Plus les gens travaillent avec l’IA, moins ils s’inquiètent réellement du code qu’elle génère
Cela ne veut pas dire que c’est une bonne chose. Cela peut produire des bugs, des problèmes de performance et des failles de sécurité
Mais c’est la réalité. Le code IA a créé un bug ? Il suffit de demander à l’IA de le corriger
Le code IA est verbeux et difficile à lire ? Si cela vous gêne, demandez à l’IA de le corriger. Beaucoup de gens ne s’en soucient pas
Si l’humain sort complètement de la maintenance du code, le besoin de code maintenable disparaît aussi
On n’en est pas encore à 100 %, mais on va dans cette direction
Dans beaucoup d’entreprises, c’est déjà suffisamment acceptable pour que prendre le risque et avancer en mode YOLO en vaille la peine
Personnellement, je n’ai pas assez confiance pour ne pas lire le code généré par l’IA, mais je ne lis pas non plus chaque ligne
Je regarde davantage les tests que le code testé, je prête plus d’attention aux parties sensibles en performance, et j’oriente la structure d’ensemble
Et si le résultat reste en dessous du niveau attendu, je ne le maintiens pas moi-même : je demande à l’IA de le corriger
Si la maintenance devient si peu coûteuse, alors le coût de maintenance ne remonte tout simplement pas dans mes priorités
Cet article met bien en lumière le fait que les agents IA ou outils d’assistance doivent aider non seulement sur la phase initiale du « crée-moi un nouveau widget », mais sur de nombreuses dimensions du développement logiciel
L’auteur estime que si quelqu’un utilise des agents IA ou des assistants uniquement au stade de la création de nouveaux widgets, alors le volume de code à maintenir augmentera fortement, puisque l’IA permet de produire beaucoup plus de code
Même avec une qualité de code élevée, des coûts de maintenance finissent par apparaître avec le temps
Cela dit, le problème que décrit l’auteur ne sera pas nécessairement celui de tout le monde ; dans une large mesure, c’est presque un problème qu’il se crée lui-même
La situation de startup qu’il décrit — « faisons en sorte que ça marche coûte que coûte pour valider le product-market fit et attirer des clients » — s’est toujours accompagnée plus tard de coûts de maintenance plus élevés
C’est dans une certaine mesure justifié, car si l’on veut vérifier qu’il existe bien un marché puis croître vite s’il existe, il peut être raisonnable de sacrifier de la qualité au nom de la vitesse
J’ai aussi eu l’impression que l’auteur évitait de parler de la manière dont l’IA peut concrètement aider sur la partie maintenance
L’IA peut être très utile, avec un guidage humain, pour corriger d’anciennes dépendances ou résoudre des bugs pénibles
Ce sont précisément le genre de tâches qui peuvent donner aux ingénieurs logiciel l’impression de faire du sale boulot, et pour lesquelles on a envie d’être aidé par l’IA