- On pense souvent que la dette technique (tech debt) deviendra moins importante parce que l’IA aide à écrire et à nettoyer le code
- Mais en réalité, l’IA augmente encore le coût de la dette technique
- Le gain de vitesse des outils d’IA est maximal dans des codebases à faible dette, mais leur efficacité chute fortement dans des codebases legacy à forte dette
- En conséquence, les codebases très endettées rencontrent davantage de difficultés à tirer parti des outils d’IA
L’IA générative est fragile face au code complexe
- Les outils de code assisté par IA comme Cursor ou Aider sont très sensibles à la complexité du code
- Les gains de vitesse sont importants lorsque les patterns existants ou les interfaces sont bien définis, mais ils ont du mal à produire des réponses valides face à des flux de contrôle complexes et à du code fortement dépendant
- Les codebases complexes rendent également plus difficile, non seulement pour les modèles d’IA mais aussi pour les développeurs, la formulation claire des demandes
- Pour cette raison, beaucoup de développeurs ont tendance à attendre que les outils d’IA puissent gérer une complexité de niveau « production »
Bien exploiter les outils d’IA
- Plutôt que de forcer l’usage des outils d’IA sur une codebase legacy, il est important que des experts humains la refactorisent afin que l’IA puisse fonctionner correctement
- Si un refactoring direct est risqué, on peut utiliser des approches comme le pattern Strangler Fig pour développer de nouveaux modules et bénéficier immédiatement des avantages des outils d’IA
- Cela permet aux équipes de développement de se concentrer sur un niveau d’abstraction plus élevé, et de mettre l’accent sur la conception de l’architecture plutôt que sur les détails d’implémentation du code
Une approche compatible avec l’IA
- Il est important de modulariser le système afin que les outils d’IA puissent fonctionner correctement, et de définir les interactions entre modules via des interfaces claires
- Conserver une structure modulaire permettant de décrire les fonctions clés et les flux de données en langage naturel constitue un bon critère pratique
- En utilisant des outils comme Gauge Tach pour mettre en place de la visibilité et des règles d’architecture, il devient possible d’évoluer vers un système modulaire
La qualité détermine la vitesse
- Maintenir une codebase de haute qualité est plus important que jamais
- En investissant dans une architecture modulaire, les équipes peuvent tirer le meilleur parti des outils d’IA, tout en développant rapidement des fonctionnalités et en construisant un logiciel de haute qualité
4 commentaires
L'obésité logicielle semble être un destin inévitable.
J’ai l’impression que certains managers ou ce genre de personnes, après avoir vu des trucs ici ou là, ont en tête que l’IA va tout résoudre. ChatGPT a vraiment nourri beaucoup de fantasmes. Il faudrait sans doute insister sur le fait que c’est encore au niveau d’un élève de primaire. Il faudrait expliquer que ça ne fait qu’aider un tout petit peu, comme outil d’assistance… Et je comprends aussi bien la situation décrite plus haut : quand c’est complexe, il se trompe dans sa compréhension. On dirait qu’il n’arrive pas à saisir le flux global du projet.
On n’échappe décidément pas au principe du garbage in, garbage out.
Avis Hacker News
Les entreprises disposant d’une base de code récente et de haute qualité tirent le plus grand bénéfice des outils d’IA générative. À l’inverse, celles qui ont des bases de code legacy complexes ont du mal à les adopter. J’ai constaté quelque chose de similaire en utilisant des LLM sur des projets personnels : dès qu’une base de code devient un tant soit peu atypique, le modèle commet des erreurs et le travail devient plus difficile
Les LLM rendent les tâches faciles encore plus faciles, mais font des erreurs sur les tâches difficiles. Cet écart ne se réduit pas, il s’agrandit au contraire
Dans des environnements à « forte dette », les subtilités du flux de contrôle, les dépendances à long terme et les schémas inattendus compliquent la génération de réponses utiles. Dans bien des cas, cela ne relève pas de la « dette technique », mais de la maturité de la base de code
Plutôt que de forcer les outils d’IA générative à résoudre des problèmes complexes dans des bases de code legacy, il faudrait que des experts humains refactorisent le code existant afin que l’IA générative puisse fonctionner correctement
On voit émerger l’idée que l’IA rendra la dette technique moins importante. Pourtant, le code généré par l’IA est irrégulier, incohérent et très sensible aux prompts spécifiques ainsi qu’au contexte fourni
Le code généré par l’IA peut réellement avoir de la valeur, mais le cadrage de cet article est irréaliste
Le machine learning ressemble à une carte de crédit à taux exorbitant pour la dette technique. Plus la génération de code devient facile, plus on produit de code, et plus le coût de maintenance augmente
J’admire les capacités des LLM à générer du code, mais l’objectif devrait être de réduire la quantité de code
L’IA prend en charge les tâches simples et génère davantage de code, mais produit aussi des bugs difficiles à détecter. Ces outils permettent d’aller plus vite, mais exigent aussi une autre manière de travailler
L’IA peut aider à comprendre et modifier le code, mais le copier-coller aveugle est une mauvaise idée. La revue de code, les demandes d’explication et les itérations restent nécessaires