Les agents IA de coding utilisés pour écrire du code doivent impérativement réduire les coûts de maintenance
(jamesshore.com)- Même si les agents IA de coding accélèrent l’écriture du code, s’ils ne réduisent pas les coûts de maintenance dans la même proportion, le gain temporaire de productivité finit au contraire par se transformer en baisse permanente de productivité
- Tout code, une fois écrit, exige une maintenance continue — correction de bugs, nettoyage, mise à niveau des dépendances, etc. — et avec le temps, cette maintenance finit par occuper la majeure partie du temps de travail
- Si la quantité de code produite double et que les coûts de maintenance doublent aussi, le coût réel de maintenance augmente de 4x, ce qui efface l’avantage de productivité en quelques mois
- Même si l’on retire l’IA, la charge de maintenance du code déjà généré reste là, enfermant l’équipe dans une productivité plus faible que si elle n’avait jamais utilisé l’IA
- Pour doubler la productivité, il faut une IA capable de réduire exactement de moitié les coûts de maintenance, ce qui impose d’investir autant d’efforts dans la baisse de ces coûts que dans l’accélération du coding
Les coûts de maintenance déterminent la productivité
- Chaque minute passée à écrire du code génère ensuite en continu du temps de maintenance, comme les corrections de bugs, le nettoyage ou les mises à niveau de dépendances
- L’analyse porte uniquement sur la maintenance récurrente année après année tant que le code existe, et non sur les nouvelles fonctionnalités ou les travaux d’amélioration
- 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 par an ensuite
- Selon l’auteur, en demandant à une cinquantaine de développeurs d’estimer le coût de maintenance avec 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, au début d’un nouveau projet, l’essentiel du temps va au développement de fonctionnalités, mais la part de maintenance du code passé augmente progressivement avec le temps
- Dans cette estimation, au bout de deux ans et demi, le temps consacré à la maintenance dépasse la moitié du total, et au bout de 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 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 de production de nouveau code
Le modèle peut être faux, mais la direction est la bonne
- Dans des startups à un stade avancé, après 5 à 9 ans, des équipes ont effectivement rencontré des situations où elles n’arrivaient plus à terminer correctement leur travail, ce qui ressemble au schéma montré par le graphique
- Si les équipes réelles semblent moins dégradées que le graphique, c’est peut-être parce que leurs coûts de maintenance étaient plus faibles, ou parce qu’elles masquaient le problème d’une autre manière
- Parmi les réponses possibles : ne pas corriger tous les bugs, ne pas mettre à niveau toutes les dépendances, ajouter des personnes quand l’équipe ralentit puis continuer à en ajouter, ou tout abandonner pour réécrire
- Les chiffres exacts peuvent se discuter, mais la grande tendance d’une baisse de productivité avec le temps paraît empiriquement juste
L’effet multiplicateur créé par les agents IA de coding
- L’exemple suppose que le framework de coding agentique récent Rock Lobster double le volume de code produit
- Il suppose aussi que le code devient un peu plus difficile à comprendre, que l’équipe est submergée par les pull requests et qu’elle ne lit plus correctement 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 cette production double lui aussi, alors le coût de maintenance du mois suivant est multiplié par 4
- Dans cet exemple extrême, après avoir adopté Rock Lobster, la productivité revient à son niveau initial en environ 5 mois, puis quelques mois plus tard devient même inférieure à celle d’un scénario sans usage de l’outil
- Cela ne veut pas dire que l’IA double réellement la productivité ou les coûts de maintenance ; l’idée est de souligner que même si la maintenabilité est identique à celle du code écrit par des humains, le gain de productivité ne dure pas longtemps
Arrêter les agents ne supprime pas les coûts de maintenance
- Les agents de coding ont un coût, et si leur utilité devient inférieure à ce coût, on peut vouloir revenir à la méthode précédente
- En arrêtant leur usage, le gain de productivité disparaît, mais les coûts de maintenance supplémentaires du code produit par les agents restent tant que ce code existe
- Dans ce cas, l’équipe peut se retrouver enfermée dans une productivité inférieure à celle qu’elle aurait eue sans jamais utiliser ces agents
Les mathématiques ne tiennent que si les coûts de maintenance baissent
- Pour que le calcul global de productivité fonctionne, les LLM doivent réduire les coûts de maintenance selon l’inverse exact du taux auquel ils augmentent la production de code
- Si la production double et que le coût de maintenance du code produit double lui 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 identique, le coût total de maintenance est encore doublé
- Si la production double, les coûts de maintenance doivent être divisés par deux ; si la production triple, ils doivent être divisés par trois
- C’est à cette condition qu’on peut obtenir un gain de vitesse sans créer une dépendance défavorable à long terme
Inquiétudes sur les agents de coding actuels et autres leviers possibles
- Sur des sources comme Hacker News, on voit beaucoup de signaux laissant penser que les agents de coding augmentent les coûts de maintenance
- Certains disent qu’ils aident à comprendre les systèmes à grande échelle, mais l’auteur ne voit pas de baisse massive des coûts de maintenance au niveau nécessaire, et estime même que la tendance va plutôt dans l’autre sens
- Le modèle ne représente pas parfaitement la réalité, mais le message selon lequel l’IA doit réduire les coûts de maintenance proportionnellement à l’accélération de l’écriture de nouveau code reste valable
- Même si l’on cherche à améliorer la vitesse de coding, il faut consacrer autant de temps à améliorer les coûts de maintenance
- Ce n’est pas un argument anti-IA : il peut aussi exister d’autres leviers, comme une IA qui rendrait 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 à un contexte réel, on peut copier la feuille de calcul et ajuster les différentes variables du modèle
2 commentaires
La raison la plus fondamentale de la méfiance envers l’IA,
c’est qu’à l’heure actuelle, la plupart des experts (autoproclamés) clament qu’eux ne rencontrent pas les défauts de l’IA dont parlent les autres, et qu’il n’existe aucun compromis, tout en se comportant comme des rabatteurs.
Comme il y a déjà de plus en plus d’arnaqueurs, une méfiance généralisée s’est installée.
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