- Le développement assisté par l’IA fait progresser la vitesse de production du code plus vite que la vitesse de compréhension humaine, créant une « dette cognitive » (cognitive debt)
- Même si le code fonctionne correctement et passe les tests, l’accumulation d’un état où les développeurs eux-mêmes ne comprennent pas la structure du code ni les raisons qui la sous-tendent se poursuit
- Les limites de la revue, la perte de connaissances tacites dans l’organisation et le déficit d’apprentissage des développeurs juniors accélèrent cette dette
- Les organisations ne mesurent que des indicateurs centrés sur la vitesse (
DORA, story points, etc.) sans parvenir à détecter le déficit de compréhension
- Plus l’écart entre productivité et compréhension se creuse, plus le risque est grand, à long terme, de voir apparaître des échecs de maintenance, des ruptures de savoir et une stagnation de la progression des ingénieurs
Le décalage de compréhension (The Comprehension Lag)
- Le codage manuel réalise simultanément deux processus, production et assimilation, et la friction de la saisie stimule la réflexion
- En écrivant le code, on forme naturellement des modèles mentaux et de l’intuition
- Le développement assisté par l’IA dissocie ce processus : la vitesse de sortie explose, tandis que la vitesse de compréhension reste limitée par les capacités humaines
- Cet écart entre sortie et compréhension constitue précisément la dette cognitive et, contrairement à la dette technique, il n’apparaît pas dans les indicateurs de vitesse
- Le problème ne se révèle que plus tard, à travers des indicateurs de fiabilité comme une hausse du MTTR ou du taux d’échec des changements
Ce que les organisations mesurent réellement (What Organizations Actually Measure)
- Les organisations ne mesurent que des résultats visibles (nombre de fonctionnalités, commits, vitesse de revue, etc.)
- Par le passé, production et compréhension étaient liées, si bien que livrer une fonctionnalité impliquait qu’on la comprenait
- Mais à l’ère de l’IA, il devient possible de déployer des fonctionnalités avec une compréhension superficielle seulement, ce qui invalide cette hypothèse
- Comme les indicateurs organisationnels ne captent pas le manque de compréhension, les systèmes d’évaluation des performances et de récompense se trouvent biaisés
Le dilemme du reviewer (The Reviewer’s Dilemma)
- Avec l’IA, un junior peut générer du code plus vite qu’un senior
- Les reviewers seniors n’ont pas le temps d’examiner en profondeur de tels volumes de code et doivent sacrifier la profondeur de revue
- En conséquence, l’idée selon laquelle « code revu = code compris » s’effondre
- Comme la pression organisationnelle privilégie la vitesse, une culture centrée sur le débit plutôt que sur la qualité de revue se renforce
Le schéma du burn-out (The Burnout Pattern)
- Les ingénieurs qui utilisent des outils d’IA éprouvent une fatigue où coexistent une forte production et un faible niveau de confiance
- Le code fonctionne, mais l’angoisse de ne pas comprendre pleinement le système qu’on a produit persiste
- Un système d’évaluation centré sur la vitesse fait du temps investi dans une compréhension approfondie un désavantage, ce qui accélère la dette cognitive
L’effondrement de la mémoire organisationnelle (When Organizational Memory Fails)
- La connaissance d’une organisation se compose de connaissances explicites documentées et de connaissances tacites présentes dans la tête des développeurs
- Le développement avec l’IA raccourcit le processus de formation des connaissances tacites (l’expérience d’implémentation directe), empêchant l’accumulation de savoir
- Au final, le système fonctionne, mais les personnes capables de le comprendre disparaissent progressivement
- Lorsqu’un problème survient, on se retrouve dans un état où personne n’est capable d’expliquer le contexte du système
L’accumulation de la dette cognitive (How the Debt Compounds)
- Premièrement, plus le code est ancien, plus il devient risqué — un code déjà imparfaitement compris au moment de son écriture devient totalement opaque
- Deuxièmement, le temps de restauration explose lors de la réponse à incident — on se retrouve à déboguer « une boîte noire produite par une boîte noire »
- Troisièmement, l’absence de futurs ingénieurs seniors — la dépendance à l’IA efface la courbe d’apprentissage et crée, à long terme, un vide de leadership
Le point de vue du directeur (The Director’s View)
- La direction ne perçoit que des signaux positifs comme la hausse de productivité, la réduction des délais et l’optimisation des effectifs
- Comme il n’existe pas d’indicateur mesurant la « profondeur de compréhension » ou l’« explicabilité », la dette cognitive n’est pas remontée
- Ainsi, la prise de décision fondée sur les données est rationnelle mais incomplète, et les risques réels restent cachés
Les limites de ce modèle (Where This Model Breaks)
- Le concept de dette cognitive ne s’applique pas de manière identique à tous les types de travail
- Il peut convenir à des tâches répétitives simples ou à des expérimentations rapides
- Par le passé aussi, le niveau de compréhension variait selon les individus ; il se peut qu’il s’agisse moins d’un phénomène nouveau que d’un déplacement de distribution
- Des améliorations futures des outils et de la documentation pourraient aussi réduire cet écart de compréhension
Le problème de la mesure (The Measurement Problem)
- Les organisations n’optimisent que ce qui est mesurable
- La vitesse est mesurable, mais la compréhension ne l’est pas
- Tant que la compréhension n’est pas intégrée au système d’évaluation, des incitations centrées sur la vitesse continueront de dominer
- Ce n’est pas l’échec d’un individu ou d’un manager, mais le résultat d’un système de mesure hérité d’une époque passée et désormais en décalage avec la réalité actuelle
- Au final, cet écart pourrait se manifester par une hausse des coûts de maintenance, des retards dans la réponse aux incidents et une exposition accrue aux fragilités du système
- Le texte se conclut ainsi : « Un système s’optimise en fonction de ce qu’il mesure. Mais ce que nous mesurons aujourd’hui ne capture plus ce qui compte vraiment. »
3 commentaires
Je réfléchis à des choses similaires en ce moment, donc j’ai écrit hier un billet de blog sur la dette cognitive, et on dirait que beaucoup de gens se posent les mêmes questions.
Comment faut-il évaluer la compréhension du code ? Faut-il la mesurer en proposant, par exemple, des quiz basés sur la base de code interne ?
Réactions sur Hacker News
Mon expérience de ces derniers mois résonne énormément avec l’article
Le projet sur lequel je travaille a continué à grandir, mais le nombre d’ingénieurs a au contraire diminué
Nous avons accru notre dépendance aux tests et basculé vers un développement basé sur des simulateurs. Il est rare de valider sur le système réel, et quand cela arrive, c’est toujours sur les parties les plus complexes
Depuis environ l’an dernier, j’ai remarqué que même des fonctionnalités sur lesquelles j’avais travaillé pendant des mois, j’en oubliais vite les détails. Et c’était déjà le cas avant l’adoption massive des agents de code
Depuis l’arrivée des agents, les revues de PR sont devenues bien plus implicites, et comme le contexte ne reste pas en tête, il faut faire un effort conscient pour se concentrer. Mes collègues rapportent la même chose
En ce moment, nous essayons plusieurs approches, comme committer le plan de l’agent avec le code. Au final, cela rend le processus plus structuré et explicite
En revanche, les engineering managers semblent très peu conscients de cette hausse de la charge cognitive
L’hypothèse de départ de l’article, selon laquelle « les développeurs se souviennent du code qu’ils ont écrit il y a 6 mois », est fausse
Cela a toujours été plus facile de comprendre du code quand on l’écrit que quand on le lit. Joel Spolsky disait aussi que « lire du code est plus difficile que l’écrire »
Le problème du « code incompréhensible » existait déjà avant l’IA
Par exemple, dans le cas de suppression du code Pinball de Microsoft, un ancien code sous-traité était devenu si complexe que plus personne ne le comprenait, et la fonctionnalité a fini par être abandonnée
Le cas de la codebase Oracle RDBMS est similaire
La formule « un système qui fonctionne, mais qui reste étranger » m’a marqué
Cela ressemble au sentiment qu’on éprouve en passant de développeur à manager. Plus on s’éloigne du code, plus la compréhension devient abstraite et fragmentée
La phrase la plus douloureuse, c’est que « les ingénieurs qui cherchent à comprendre en profondeur sont pénalisés dans les métriques de vitesse »
Le marché valorise la vitesse plus que la qualité, ce qui crée au final un système où les ingénieurs consciencieux se font licencier
Nous allons peut-être entrer dans l’ère du « LGTM, LLM »
L’industrie pousse toujours trop loin avant de retrouver un équilibre. Le vrai problème, c’est l’attente impossible qui consiste à exiger 20 fois plus de productivité tout en demandant 100 % de responsabilité
Au final, soit on renonce à la compréhension, soit on accepte un gain de productivité limité à environ 20 %
Cela me fait penser à la philosophie Worse Is Better de Richard Gabriel
Le code généré par l’IA privilégie souvent la simplicité plutôt que la correction, mais cette approche réaliste du « tant que ça marche, ça gagne » pourrait l’emporter
Une fois qu’un système fonctionnel existe, on peut l’améliorer progressivement
Notre équipe a vécu exactement le même phénomène que celui décrit dans l’article au cours des 6 derniers mois
La phrase centrale, selon laquelle le développement assisté par l’IA interrompt l’accumulation de savoir implicite, est tout à fait juste
Cela dit, il est possible que ce soit une phase transitoire
À long terme, les LLM pourraient fournir une valeur au niveau méta, en structurant bien le code pour aider les humains à ne plonger en profondeur que lorsque c’est nécessaire
Quand la documentation manque, les équipes de support produit prennent aussi un gros coup
Quand un client demande pourquoi le produit se comporte d’une certaine façon, il devient difficile de répondre si même les ingénieurs connaissent mal le code qu’ils ont écrit
Si les mises à jour vont trop vite, les autres équipes ont du mal à suivre
On a déjà vécu quelque chose de similaire avec l’arrivée des langages de haut niveau, et au final tout s’est bien passé
Alors, est-ce qu’il serait acceptable que les LLM abstraient aussi la compréhension du code ?
La différence, c’est qu’un compilateur est déterministe alors qu’un LLM est probabiliste