L'IA est capable d'écrire pratiquement la totalité de notre code, mais elle peut aussi nous laisser avec une compréhension de plus en plus superficielle de ce que nous construisons.
Je n’écris quasiment plus de code moi-même.
Les LLM et les harnais qui les entourent ont progressé au point que mon workflow agentique génère aujourd’hui environ 98 % de mon code. Je décris ce que je veux, les agents explorent la codebase, proposent une implémentation et l’exécutent. Pendant un moment, j’ai vu cela uniquement comme un gain de productivité.
L’échelle à laquelle on délègue la création de code a augmenté de façon significative. Avant, j’avais une conversation avec un seul agent que je pouvais suivre. Maintenant, un agent peut lancer plusieurs sous-agents et travailler sur différents sujets en parallèle avec des worktrees Git. Lire chaque échange et chaque ligne générée n’est plus vraiment réaliste.
Puis j’ai réalisé que j’avais arrêté d’apprendre. Je produisais plus de code, mais je n’avais plus l’impression de progresser au quotidien.
Le signe le plus évident était ma façon de gérer les erreurs. Je copiais toute la stack trace dans une nouvelle session Claude, je le laissais mener l’enquête et appliquer les corrections, puis je vérifiais si l’erreur avait bien disparu. Si tout fonctionnait à nouveau comme il fallait, je passais à la suite sans vraiment comprendre ce qui s’était passé.
Avant d’avoir des agents aussi autonomes, une erreur me forçait généralement à chercher la cause racine. Je devais formuler une hypothèse, suivre le chemin d’exécution, lire de la documentation et comprendre suffisamment le problème pour choisir le correctif le plus approprié. Le processus était plus lent, mais il mettait à jour mon modèle mental du système.
Avec les agents, je continuais à faire avancer mes projets, mais avec une compréhension de plus en plus superficielle de ce que je construisais. J’en savais assez pour écrire le prochain prompt et orienter l’agent, mais pas toujours pour expliquer les choix d’implémentation qu’il avait faits.
C’est ce qui m’a amené à réfléchir au concept de dette cognitive. Cet article n’est pas un plaidoyer pour revenir à l’écriture manuelle de chaque ligne de code. Il s’agit de comprendre comment profiter des agents sans leur abandonner progressivement notre capacité à raisonner.
Utiliser du code que vous ne comprenez pas entièrement n’est pas un problème en soi. On dépend déjà de frameworks, de librairies externes et de systèmes d’exploitation sans connaître chaque détail de leur fonctionnement.
La dette cognitive est un déficit mental invisible qui s’accumule lorsque vous laissez l’IA prendre des décisions que vous ne comprenez pas, puis continuez à construire par-dessus. Comme la dette technique, elle échange de la vitesse à court terme contre un coût futur : vous devenez moins capable d’expliquer, de déboguer ou de faire évoluer votre propre système sans revenir vers l’outil.
Contracter cette dette n’est pas toujours une mauvaise décision. Un raccourci peut être raisonnable si vous savez qu’il existe et si vous pouvez y revenir plus tard. Le danger commence lorsque ces raccourcis s’accumulent sans rester visibles.
Personne ne décide volontairement d’arrêter de comprendre son travail. Cela arrive parce qu’accepter un résultat qui fonctionne est l’étape suivante la plus simple. Éviter la dette cognitive demande donc de choisir consciemment les parties du processus dont vous voulez rester responsable.
Avec les agents de code, cela peut arriver assez vite. Ils choisissent une architecture, ajoutent une abstraction ou utilisent une API que vous connaissez peu ou pas du tout. Le résultat fonctionne, donc vous continuez. Lors du changement suivant, votre modèle mental du projet est déjà moins précis, ce qui vous rend encore plus dépendant de l’agent.
Le problème ne vient pas d’une fonction générée ou d’un bug corrigé sans explication. Il vient de la boucle que ces deux formes de délégation peuvent créer.
Lorsque vous débuguez quelque chose vous-même, vous devez normalement rendre votre compréhension actuelle explicite. Vous prédisez où le problème pourrait se trouver, vous testez cette hypothèse, puis vous corrigez votre modèle mental s’il s’avère faux.
Un agent peut fermer cette boucle avant que l’une de ces étapes ait lieu. L’erreur disparaît, mais l’incompréhension qui l’a permis de vous surprendre reste présente.
Cela ne signifie pas que chaque erreur mérite une heure d’investigation. Comprendre pourquoi le nom d’une variable était mal orthographié n’est probablement pas une bonne utilisation de votre temps. La dette compte lorsque l’agent corrige le comportement d’une partie du système que vous devrez de nouveau modifier, débugguer ou prendre en compte dans vos décisions.
La prochaine fois que quelque chose casse à cet endroit, vous repartez avec la même compréhension superficielle. Vous envoyez la nouvelle erreur à l’agent, vous recevez une autre correction et vous ajoutez une décision que vous n’avez pas prise et que vous ne pouvez pas complètement expliquer.
À ce stade, l’IA ne vous fait plus seulement gagner du temps. Elle dépense aussi une compréhension dont vous pourriez avoir besoin plus tard.
On pourrait répondre que les développeurs ont toujours délégué une partie de leur compréhension. On utilise des frameworks sans lire leur code source et on copie des solutions depuis la documentation ou Stack Overflow sans toujours comprendre ce qu’on fait.
C’est vrai. Une compréhension complète n’est ni possible ni souhaitable.
La différence dépend de la partie du système modifiée par le travail délégué. Je n’ai pas besoin d’étudier chaque définition de type ou fichier de configuration généré. Je dois en revanche comprendre les décisions qui structurent le système et les idées fausses à l’origine de ses défauts.
| Situation | Ce que je dois comprendre |
|---|---|
| Travail répétitif suivant un pattern connu | Assez pour confirmer que le pattern s’applique toujours |
| Une nouvelle décision d’architecture | Les alternatives et la raison du choix |
| Un défaut dans un comportement métier | L’hypothèse incorrecte sur le modèle métier |
| Une défaillance technique inattendue | La chaîne causale et l’idée fausse précise à son origine |
Le but n’est pas de ralentir l’agent jusqu’à ce qu’il travaille à mon rythme, mais de décider où la compréhension a de la valeur et de refuser de la déléguer à ces endroits.
Avant de demander à un agent d’implémenter une fonctionnalité, je construis mon propre plan d’implémentation.
Il n’a pas besoin d’être écrit ni de contenir chaque fichier ou fonction. Je veux décider où le comportement doit se trouver, comment les données doivent circuler et quels compromis sont importants. Je compare ensuite ce plan avec celui produit ou proposé par l’agent.
C’est en comparant les deux que l’on peut continuer à apprendre. L’agent a peut-être trouvé une contrainte que je n’avais pas vue. Il a peut-être introduit une abstraction qui ne me paraît pas justifiée. Dans les deux cas, j’ai maintenant une décision concrète à examiner au lieu d’accepter passivement la première implémentation qui m’a été proposée.
Cette méthode préserve la majeure partie de l’efficacité de l’agent. Je ne réécris pas sa solution et je ne relis pas chaque ligne générée. Je m’assure que la direction de l’implémentation reste le résultat d’un raisonnement auquel j’ai participé.
Lorsque plusieurs sous-agents travaillent en parallèle, lire tout ce qu’ils produisent enlève une grande partie de l’intérêt de cette approche. À la place, je lis le résumé final en entier, en particulier les décisions prises pendant le travail.
Si le résumé ne les contient pas, je demande un journal de décisions :
Liste les décisions prises, les difficultés rencontrées et les particularités de ton approche que je devrais garder en tête.
Cela me donne une carte des endroits où l’implémentation s’est éloignée de mon plan initial. J’obtiens également une courte liste d’hypothèses et de compromis qui méritent d’être examinés.
Il ne faut cependant pas faire aveuglément confiance à ce résumé. Lorsqu’une longue exécution atteint les limites de contexte de l’agent et provoque une compression automatique, le modèle peut halluciner une explication crédible au lieu de rapporter le raisonnement qui a réellement eu lieu. Je considère le journal comme une liste d’affirmations à vérifier dans l’implémentation, pas comme une preuve.
Le but est de préserver la vitesse de l’agent tout en gardant les décisions visibles.
Lorsqu’une erreur apparaît, je continue de donner la stack trace à l’agent et je le laisse enquêter. C’est l’un des endroits où un agent peut me faire gagner beaucoup de temps.
Ce que je ne veux plus faire, c’est m’arrêter dès que l’erreur a disparu. Une correction rétablit le comportement attendu, mais elle n’améliore pas forcément ma compréhension et n’empêche pas le même type de défaut de se reproduire.
Pour cela, j’utilise un exercice inspiré du livre The Toyota Way of Dantotsu Radical Quality Improvement de Sadao Nomura. Je l’ai adapté au développement logiciel pour partir d’un défaut visible et aller plus loin que la recherche de la ligne de code fautive.
| Étape | Question |
|---|---|
| Chaîne causale | Comment le système est-il passé du défaut visible au comportement fautif dans le code ? |
| Hypothèse du code | Qu’est-ce que le code suppose vrai, et qu’est-ce que le système exige réellement ? |
| Ma compréhension | Aurais-je pu détecter et expliquer cet écart avant que l’agent le corrige ? |
| Échec de détection | Pourquoi le typage, les tests, la validation, la revue ou le monitoring ne l’ont-ils pas exposé plus tôt ? |
| Éradication | Où la même hypothèse pourrait-elle exister, et comment l’empêcher ou la détecter à ces endroits ? |
Pour formuler l’apprentissage, un développeur peut compléter :
Je pensais que ___, mais en réalité ___.
Cela suppose que le développeur a écrit le code fautif. Avec les agents de code, l’auteur est moins évident. Si Claude a généré l’implémentation, compléter cette phrase peut m’attribuer l’idée fausse de l’agent.
Je commence donc par une version neutre :
Le code généré suppose que ___, alors que le système exige ___.
Cette formulation identifie le modèle fautif inscrit dans l’implémentation sans prétendre que l’agent ou moi y avons consciemment cru. Je me pose ensuite une question séparée : Aurais-je pu détecter et expliquer cet écart avant que l’agent le corrige ?
Si la réponse est non, il y a quelque chose à apprendre. J’identifie la partie manquante dans mon propre modèle et je la reformule avec mes mots. Si la réponse est oui, le défaut ne révèle pas forcément une dette cognitive. L’agent manquait peut-être de contexte, mes instructions étaient peut-être ambiguës ou le système n’a pas détecté une erreur que je savais déjà expliquer.
L’agent peut m’aider à reconstruire la chaîne causale, mais je vérifie tout de même son explication dans le code et la documentation. Une explication crédible générée après la correction ne suffit pas.
Enfin, l’éradication transforme le constat en une amélioration du système. Cela peut mener à un pattern de code plus simple, une contrainte de typage, un test, une règle de lint ou une documentation plus claire. L’apprentissage n’existe alors plus uniquement dans ma tête.
Je ne déroule pas cet exercice complet pour chaque typo ou erreur familière. Je l’utilise lorsqu’une erreur me surprend, révèle une incompréhension du métier ou touche une partie du système sur laquelle je devrai de nouveau raisonner.
L’IA ne m’a pas fait arrêter d’apprendre en me donnant de mauvaises réponses. Elle a supprimé beaucoup de situations qui m’obligeaient auparavant à me poser des questions et me stimulaient intellectuellement.
Imaginer le plan d’implémentation avant de lui demander de le générer me permet de rester impliqué dans les décisions. Le comparer au plan de l’agent me montre où ma compréhension diffère de sa solution et m’oblige à exercer mon esprit critique.
Lorsqu’un défaut inattendu apparaît, le corriger n’est pas la seule contre-mesure. Retracer sa chaîne causale et trouver l’idée fausse qui en est à l’origine transforme ce défaut en une mise à jour concrète de mon modèle mental.
Ces pratiques sont volontairement sélectives. Comprendre chaque ligne générée supprimerait une grande partie de l’intérêt d’utiliser un agent. Les éléments qui méritent d’être protégés sont les décisions qui structurent le système et les idées fausses qui me suivraient sinon dans la prochaine fonctionnalité.
J’aime voir cela comme une amplification mutuelle. Mon workflow agentique s’améliore lorsque je documente les difficultés, clarifie mes instructions et rends les décisions utiles accessibles aux prochaines exécutions. Je progresse lorsque je compare les plans, questionne ces décisions et recherche les idées fausses derrière les défauts.
Je n’ai aucun problème à laisser l’IA écrire 98 % de mon code. Je ne veux pas que cette facilité me laisse seulement une compréhension superficielle de ce que je construis.
Le but n’est pas de résister à la délégation. Il est de travailler avec des agents d’une façon qui améliore à la fois le système que j’utilise et ma compréhension du système que je construis.
