Addy Osmani définit la dette de compréhension comme le coût caché pour l’intelligence humaine et la mémoire résultant d’une dépendance excessive à l’IA pour générer du code. C’est l’écart grandissant entre la quantité de code présente dans un système et la part de ce code qu’un être humain comprend réellement.
Les points clés de l’article :
1. Une menace invisible Contrairement à la « dette technique » classique qui se manifeste par des ralentissements visibles (bugs, lenteurs), la dette de compréhension crée une fausse confiance. Le code semble propre et les tests sont au vert, mais personne ne peut expliquer les décisions de conception sous-jacentes. Le problème surgit brutalement lorsqu’il devient impossible de modifier le système sans tout casser.
2. L’asymétrie de vitesse L’IA génère du code beaucoup plus rapidement que les humains ne peuvent l’évaluer. Auparavant, les ingénieurs seniors pouvaient réviser le code plus vite que les juniors ne l’écrivaient. Aujourd’hui, l’IA inverse ce rapport : un junior peut générer une telle masse de code qu’un senior ne peut plus l’auditer de manière critique. La revue de code, autrefois un gage de qualité, devient un simple problème de flux de données.
3. Les limites des tests et des spécifications
- Les tests : Bien qu’indispensables, ils ne suffisent pas. On ne peut pas tester ce qu’on n’a pas imaginé (les cas limites imprévus). De plus, si l’IA modifie l’implémentation et met à jour automatiquement les tests pour qu’ils correspondent, on perd toute capacité de contrôle.
- Les spécifications : Écrire des spécifications détaillées ne garantit pas une bonne traduction par l’IA. Une spécification trop précise devient aussi complexe que le code lui-même, annulant les gains de productivité.
4. L’humain devient plus précieux Ironiquement, plus le code est généré par l’IA, plus l’ingénieur qui comprend le système en profondeur devient indispensable. La compétence rare devient la capacité à voir si un changement est architecturalement sûr, au-delà de la simple syntaxe.
5. L’échec des mesures actuelles Les outils de mesure actuels (vélocité, nombre de PR, couverture de tests) ne détectent pas cette dette. Une équipe peut paraître extrêmement productive sur le papier tout en étant en train de perdre totalement le contrôle intellectuel de son projet.
Conclusion
Générer du code n’est plus ce qui coûte cher ; c’est comprendre le code qui devient le travail principal. Addy Osmani avertit que si les équipes privilégient la vitesse de fusion (merge velocity) au détriment de la compréhension réelle, elles s’exposent à un retour de bâton violent, particulièrement dans les secteurs régulés (santé, finance) où « l’IA l’a écrit et on n’a pas tout vérifié » ne sera pas une défense acceptable en cas d’incident.