You Need AI That Reduces Maintenance Costs

Article original : jamesshore.com Lire en 🇫🇷 via Google Translate

Auteur: James Shore
Thème: IA
Mots-clés: maintenance costs, AI coding agents, productivity, technical debt, software engineering economics
Ton: opinion

Résumé

James Shore livre un avertissement sans détour : ton agent IA de codage doit réduire tes coûts de maintenance, pas seulement ta vitesse d'écriture. Si tu codes deux fois plus vite mais que la maintenance reste constante, tu accélères ton endettement technique au lieu de produire de la valeur. La productivité réelle est déterminée par les coûts de maintenance accumulés, pas par la vélocité instantanée. Sans réduction substantielle de cette maintenance, l'IA crée un piège : un boost temporaire suivi d'une servitude permanente.

💡 Pourquoi ça compte

C'est le contre-pied le plus rigoureux qu'on ait vu cette année au discours "10x developer with AI". Pour un Engineering Director ou un CTO, c'est la grille de lecture à appliquer à tout pilote d'agent de codage avant de signer un budget annuel.

Analyse approfondie

J'irai droit au but : ton agent IA de codage, celui que tu utilises pour écrire du code, doit réduire tes coûts de maintenance. Et pas juste un peu. Tu écris du code deux fois plus vite maintenant ? Tu as intérêt à avoir divisé tes coûts de maintenance par deux. Trois fois plus productif ? Un tiers des coûts de maintenance. Sinon, tu es fichu. Tu échanges un boost temporaire de vitesse contre une servitude permanente.

Tu veux savoir pourquoi ? D'accord. Embarquons pour un trip. Sur une autoroute désertique sombre…

La productivité est déterminée par les coûts de maintenance

Chaque ligne de code que tu écris doit être maintenue : corrections de bugs, nettoyages, mises à jour de dépendances, et ainsi de suite. Je ne parle pas des nouvelles features ou des évolutions. Juste de la maintenance. Pour chaque mois passé à écrire du code, tu vas passer un certain temps l'année suivante à maintenir ce code, et un certain temps chaque année après, indéfiniment, tant que ce code existe.

Disons que tu interroges une foule, disons 50 développeurs, sur ces coûts de maintenance. En utilisant la technique de la sagesse des foules (Wisdom of the Crowd), tu pourrais obtenir une réponse raisonnablement précise.

Cette foule pourrait te dire que, pour chaque mois passé à écrire du code, tu passeras :

10 jours de maintenance la première année ; et
5 jours de maintenance chaque année après.

Si tu étais un individu particulièrement obsessionnel, tu pourrais passer des heures à faire un tableur modélisant comment ces estimations affectent la productivité dans le temps. (L'auteur partage effectivement un tableur Google modélisant ce calcul.)

Le résultat est simple et brutal : à long terme, le temps total consacré à un mois de code écrit aujourd'hui dépasse rapidement le mois initial. Au bout de quelques années, la maintenance accumulée domine ta capacité totale. Tu n'as plus de bande passante pour de nouvelles features parce que tu maintiens du code écrit il y a deux, trois, cinq ans.

Ce que ça change avec l'IA

Si un agent te permet d'écrire deux fois plus de code dans le même temps, mais que la maintenance par ligne reste inchangée, tu doubles tes coûts de maintenance futurs. Tu paies un mois aujourd'hui pour avoir deux mois de capacité, mais tu paies deux fois la maintenance chaque année derrière.

À court terme, c'est invisible. Tu shippes plus vite, ton équipe a l'impression d'être plus productive, tout le monde est content. À moyen terme, tu commences à voir les coûts de maintenance manger ta capacité. À long terme, tu n'écris plus de nouvelles features : tu passes tes journées à maintenir le code que ton agent a généré.

C'est pour ça que la promesse "X fois plus rapide" est trompeuse si elle n'est pas accompagnée d'une réduction équivalente de la maintenance. La vraie métrique, ce n'est pas la vitesse d'écriture — c'est le ratio entre code produit et coût total de possession sur cinq ans.

Ce qu'il faut chercher dans un agent

L'auteur soutient qu'il faut évaluer ses outils IA non pas sur "à quelle vitesse je shippe", mais sur "comment évolue mon coût total de maintenance" :

Le code produit est-il plus testable que le code humain équivalent ?
Les dépendances introduites sont-elles plus stables ?
La structure est-elle plus refactorable ?
Les bugs détectés sont-ils corrigés avant le commit ?

Tant que ces questions ne sont pas mesurées, parler de productivité IA, c'est parler d'un proxy. Et un proxy n'est jamais la valeur réelle — c'est juste ce qu'on sait mesurer.