Dette technique, dette cognitive, dette d’intention
(martinfowler.com)- Dans un environnement où les LLM produisent du code en masse, ce ne sont pas seulement les problèmes du code lui-même qui s’aggravent : la compréhension partagée de l’équipe et la mémoire des objectifs du système s’affaiblissent aussi, d’où l’importance croissante de traiter séparément la dette technique, la dette cognitive et la dette d’intention
- La technical debt limite la capacité à faire évoluer le système à l’avenir, la cognitive debt affaiblit la capacité de l’équipe à raisonner sur les changements du système, et la intent debt brouille la trace des objectifs et contraintes, ce qui freine l’évolution continue du système par les humains comme par les agents IA
- La théorie Tri-System, qui place l’IA en System 3, distingue la cognitive surrender, c’est-à-dire le fait de faire confiance sans esprit critique à un raisonnement artificiel externe et de court-circuiter la réflexion, du cognitive offloading, qui relève au contraire d’une délégation stratégique de la cognition
- À mesure que le coût du code baisse, ce qui devient coûteux, c’est la verification ; les critères d’exactitude et de succès varient selon le contexte, qu’il s’agisse d’ETA dans le trafic, de répartition de chauffeurs ou d’exploitation de centaines de microservices, ce qui rend encore plus crucial le jugement humain et la conception de systèmes de vérification
- Le centre de gravité de l’ingénierie se déplace de la quantité d’implémentation vers la vérification, et les humains continueront à jouer un rôle essentiel pour créer des abstractions utiles, nommer les choses et concevoir des acceptance criteria et des test harness qui préservent le sens du système
Trois dettes et la santé des systèmes
- Dans un environnement où les LLM génèrent de grandes quantités de code, les équipes perdent plus facilement la compréhension de ce que fait réellement le système, ce qui alimente une lecture croissante du problème en termes de Cognitive Debt
- Les trois couches de la santé d’un système divisent la dette selon trois dimensions : le code, les personnes et les artefacts
- La technical debt réside dans le code ; elle s’accumule lorsque des décisions d’implémentation nuisent à la capacité de faire évoluer le système et limitent la manière dont il peut changer à l’avenir
- La cognitive debt réside chez les personnes ; elle s’accumule lorsque la compréhension partagée du système se dégrade plus vite qu’elle n’est reconstituée, ce qui limite la capacité de l’équipe à raisonner sur les changements
- La intent debt réside dans les artefacts ; elle s’accumule lorsque les objectifs et contraintes censés guider le système ne sont pas correctement documentés ou maintenus, ce qui limite la capacité à continuer de refléter l’intention d’origine et à faire évoluer efficacement le système, tant pour les humains que pour les agents IA
- Cette approche inclut aussi des sections consacrées au diagnostic et à l’atténuation de chaque dette, tout en montrant leurs interactions mutuelles
- Les équipes doivent mener en parallèle des activités transverses pour garder ces trois dettes sous contrôle
Théorie Tri-System et reddition cognitive
- Un article qui ajoute les LLM au modèle de pensée à deux systèmes de Kahneman étend le cadre cognitif en plaçant l’IA en System 3
- Le System 1 prend des décisions rapides par intuition, tandis que le System 2 correspond à une pensée délibérée face aux problèmes
- Pour économiser de l’énergie, les humains ont naturellement tendance à s’appuyer sur l’intuition, au risque de manquer des éléments qu’une réflexion plus approfondie aurait permis de repérer
- Le résultat de l’apparition du System 3 est la cognitive surrender, définie comme un état dans lequel on fait confiance sans critique à un raisonnement artificiel généré à l’extérieur, en contournant le System 2
- L’article la distingue du cognitive offloading
- Le cognitive offloading est traité comme une délégation stratégique de la cognition au sein d’un processus de réflexion
- L’article développe en détail la Tri-System theory of cognition et la met à l’épreuve à travers plusieurs expériences pour évaluer sa capacité à prédire les comportements, au moins en environnement de laboratoire
Le symbole <> comme icône du code
- Certaines illustrations récentes utilisent le symbole « <> » comme icône du code, mais cette notation paraît peu familière comme manière d’entourer des éléments de langage de programmation
- Si l’on emploie « <> » plutôt que des symboles comme « { } », c’est vraisemblablement parce qu’il évoque HTML ou XML
- Lorsque l’on va jusqu’à utiliser la forme « </> », l’association avec HTML est encore plus directe, alors même que HTML n’est pas considéré comme un langage dans lequel les programmeurs écrivent des programmes
Quand coder devient bon marché, ce qui coûte cher devient la vérification
- if coding agents make coding free, what becomes the expensive thing estime que, plus les agents de codage font baisser le coût de l’écriture du code, plus la verification devient l’élément coûteux
- Les critères de correction varient en permanence selon le contexte
- Un algorithme d’ETA dans le trafic de Jakarta et un algorithme d’ETA dans le trafic de Ho Chi Minh City peuvent ne pas partager la même définition de ce qui est « correct »
- Dans la répartition des chauffeurs, il faut optimiser en même temps l’équité des revenus, le temps d’attente des clients et le taux d’utilisation des véhicules ; il n’existe donc pas une seule définition de ce qui est « successful », mais plusieurs
- Dans un environnement où des centaines d’ingénieurs déploient en continu sur environ 900 microservices, « correct » n’a pas une définition unique mais se fragmente en des milliers de définitions, toutes mouvantes et dépendantes du contexte
- Ce type de jugement reste un travail que les agents ne peuvent pas remplacer
- Les agents fonctionnent particulièrement bien dans des flux où le résultat du travail peut faire l’objet d’une vérification de qualité, idéalement automatisée
- Ce type de flux encourage le Test Driven Development
- Comme le volume de vérification à effectuer reste considérable, il faut investir davantage dans des moyens permettant aux humains de comprendre facilement une couverture de test plus large
- Sur le sujet de la modernisation des systèmes legacy, quelques désaccords sont également mentionnés
- L’idée selon laquelle l’agentic coding finira par résoudre définitivement la modernisation du legacy est surestimée
- En revanche, il existe de solides éléments montrant que les LLM aident beaucoup à comprendre ce que fait réellement le code legacy
Réorganiser l’organisation autour de la vérification
- Si les agents prennent en charge l’exécution, le travail humain se déplace vers la conception du verification system, la définition de la qualité et le traitement des cas ambigus que les agents ne savent pas résoudre
- La structure même des organisations doit évoluer en conséquence
- Lors du stand-up du lundi matin, la question centrale ne devient plus « qu’avons-nous déployé ? », mais « qu’avons-nous vérifié ? »
- Au lieu de suivre le volume produit, on suit si le résultat était correct
- Une équipe de 10 ingénieurs auparavant dédiée à la création de fonctionnalités pourrait être recomposée en 3 ingénieurs, plus 7 personnes chargées de la définition des acceptance criteria, de la conception des test harness et du monitoring des outcomes
- Cette réorganisation peut être inconfortable, car elle dévalorise symboliquement l’acte de produire au profit de l’acte de juger
- Une culture d’ingénierie qui ne rejette pas ce changement a davantage de chances de bien s’en sortir
L’avenir du code source et les langages favorables aux LLM
- À mesure que les LLM sont traités comme des programmeurs, l’avenir même du code source devient une question à part entière
- several views of the future of code rassemble plusieurs points de vue sur cette évolution
- Certains expérimentent des langages entièrement nouveaux conçus dès le départ avec les LLM en tête
- D’autres estiment que les langages existants, notamment des langages à typage strict comme TypeScript et Rust, pourraient être mieux adaptés aux LLM
- L’article est riche en citations et plus limité en analyse originale, mais il reste utile comme vue d’ensemble de la discussion
Les abstractions et le fait de nommer restent humains
- Même lorsqu’on construit des logiciels avec des LLM, les humains continueront à jouer le rôle consistant à créer des abstractions utiles permettant de parler de ce que fait le code
- Cela rejoint l’Ubiquitous Language de la DDD
- growing a language traite de la manière de faire évoluer un langage avec l’aide des LLM
- Programmer ne consiste pas seulement à saisir une syntaxe de codage que l’ordinateur peut comprendre et exécuter, mais aussi à donner une forme à la solution
- Cela implique de découper le problème en unités cohérentes, de regrouper ensemble les données et les comportements associés, et de choisir des noms qui révèlent l’intention
- De bons noms tranchent dans la complexité et transforment le code en une structure que tout le monde peut suivre, tout en reliant clairement la structure du problème à celle de la solution
3 commentaires
Le terme « dette d’intention » est un terme que j’avais défini à ma manière il y a quelque temps, donc ça fait plaisir de le revoir ainsi. J’imagine que les gens pensent tous plus ou moins de la même façon.
Article de blog : https://brunch.co.kr/@limjk/2
Le fait de réorganiser rapidement l’organisation pour s’adapter au changement me laisse aussi une légère impression de conservatisme, ce qui suscite une certaine réticence chez moi.
Avis sur Hacker News
Si vous êtes du genre à ne vous sentir rassuré que lorsque vous comprenez en profondeur tout ce que vous déployez, ce genre de changement peut sembler assez anxiogène
Aujourd’hui, même un projet de modernisation qui aurait pris 2 mois peut être bouclé en une semaine environ si l’on se concentre sur la bonne conception des frontières et des interfaces, au lieu d’essayer de disséquer toute la logique métier pour la reproduire à l’identique
Et comme le dit le billet, il suffit ensuite de construire un bon test harness pour vérifier au maximum l’équivalence
J’ai moi aussi beaucoup hésité au début, puis en y réfléchissant, je me suis rendu compte que je ne connaissais pas non plus si bien que ça l’implémentation interne ou la logique métier des autres systèmes que je maintiens au quotidien
C’était du code que j’avais écrit il y a des années et presque jamais retouché, donc quand il fallait modifier quelque chose, je finissais de toute façon par faire confiance à la suite de tests ou par remonter la structure du code pour comprendre un comportement précis
J’ai vu plusieurs fois que, lors de licenciements ou de phases de réduction des coûts, ceux qui possédaient beaucoup de ce savoir survivaient plus longtemps que les autres
Je me demande ce qui m’échappe
Les LLM ne sont pas totalement dépourvus de la vertu de la paresse
Avec un prompt de base adapté à l’intention, j’ai réussi à pousser un agent basé sur Claude à minimiser les modifications de code, à faire des passes de déduplication et à adopter des comportements qui ressemblent beaucoup aux instincts d’un développeur très senior
Je ne pense pas que le modèle soit incapable d’avoir appris cela, simplement que, dans sa configuration par défaut, ce n’est pas ce qui ressort en premier
Je pense que tout le monde a déjà vu des modèles au style sur-correctif, qui remanient tout le code sans retenue et ne se soucient absolument pas des changements des autres ni des risques de perte de connaissance
La question de la génération et de la validation de documentation ressemble au fond à un problème classique de verrouillage, avec des solutions classiques
Un agent peut tout à fait lire git et comprendre ce qui a été fait en premier, ou si, par convention, il faut attendre d’autres changements
Je suis moi-même assez senior, et j’ai même déjà travaillé dans la même équipe que certaines des personnes citées dans ce billet
Je ne pense pas qu’elles remettraient en cause mes standards d’ingénierie
Pourtant, dans mon workflow LLM, je vois très peu ce type de dette, et j’ai même l’impression que la qualité des projets est meilleure qu’il y a 5 ou 10 ans, même selon les critères d’autrefois
Ce n’est pas magique, il suffit de bien faire tourner des agents qui partagent ces priorités de qualité
Et au lieu de chercher à faire parler de moi dans les conférences, je produis davantage de travail concret
En revanche, dire que c’est mieux qu’il y a 5 ou 10 ans même selon les indicateurs traditionnels de qualité logicielle, cela me semble trop vague
J’aimerais savoir plus précisément quels indicateurs vous utilisez, et comment le code d’il y a 10 ans, d’il y a 5 ans et celui d’aujourd’hui se comparent respectivement
Sans ces précisions, j’ai l’impression que le message devient plus flou et s’éloigne du point central
S’il y a davantage à partager, cela m’intéresse beaucoup
Vous pourriez même écrire un livre intitulé Practical LLM Coding
Je pense que ce qui est le plus sous-estimé ici, c’est le cadrage en termes d’intent debt
La dette cognitive ou la dette technique laissent au moins des traces visibles dans le code, mais l’intent debt ne se voit pas
Elle n’apparaît vraiment que lorsqu’un changement semble plausible localement, mais est faux à l’échelle globale
Parce que les contraintes d’origine n’ont été conservées dans aucun artefact
Le cas le plus difficile, c’est quand, dans un système d’entreprise, cette contrainte venait d’une exigence réglementaire, qu’elle a discrètement changé il y a trois ans, et que personne n’a mis le code à jour
Les tests continuent de passer, donc c’est encore plus facile à rater
La suite de tests seule ne permet pas de reconstituer l’intention
Je ne pense pas que Martin ait complètement tort, mais cet argument me semble être le genre de chose qu’on peut dire à chaque montée en couche d’abstraction
D’après sa définition, passer de l’assembleur à Python créerait aussi énormément d’intent debt et de dette cognitive
Puisqu’on ne réfléchit plus directement à la manière de manipuler les bits, et qu’on laisse cela à l’interpréteur
Mon contre-argument, c’est que l’intention technique dont il parle existe surtout parce qu’il fallait traduire l’intention humaine en langage machine
Réfléchir profondément au problème n’exige pas nécessairement de construire dans le code des abstractions orientées domaine
On peut aussi réfléchir en profondeur avec une carte mentale, un journal ou des Post-it collés au mur
L’abstraction orientée objet n’a rien de magique
C’est souvent là que surgissent les ambiguïtés, les détails qu’on n’avait pas envisagés, voire le fait qu’il faut repenser toute l’approche
Écrire en langage naturel peut aussi servir à penser, mais il y a quelque chose de fondamentalement différent dans le fait d’ajuster sa pensée à un langage formel qui n’autorise pas l’ambiguïté
C’est un peu comme faire des mathématiques uniquement en langage naturel, sans notation mathématique : c’est plus lourd et plus sujet aux erreurs
On le fait simplement dans un langage plus facile à comprendre pour l’humain
Il existe une correspondance directe entre l’intention et l’implémentation
Parce que la correspondance est bien définie et déterministe
Le but de l’abstraction est de permettre de croire que ce qu’on vient de faire reste correct sans devoir replonger en dessous
C’est possible parce que moi, ou quelqu’un en qui j’ai confiance, avons payé ce coût une fois
Mais avec les LLM, il faut vérifier la sortie à chaque génération, et donc repayer cette dette à chaque fois
C’est pour cela qu’il est difficile de considérer cela comme une abstraction
Le billet est vraiment très bien écrit
J’ai moi-même noté hier dans mes notes personnelles que, si l’on ne fait pas évoluer le code de façon organique et continue, il devient difficile de dire qu’on le possède réellement
Avant, c’était comme une voiture autonome où l’on retenait au moins le paysage du trajet ; maintenant, on a l’impression d’être simplement téléporté ailleurs, puis de ne voir qu’un enregistrement
Ce type de revue perd en efficacité
Ce ghosted code peut aller pour de petits outils, mais dans des systèmes comme une base de données, cela m’inquiète vraiment
Du coup, je ne donne presque plus de droits d’écriture aux agents et je suis revenu à une approche surtout centrée sur la QA manuelle, comme il y a 2 ans
C’était même plus efficace, que ce soit en consommation de tokens ou en résultats
Bien sûr, cela reste uniquement mon expérience
Malheureusement, une grande partie du papier de Wharton qu’il a lié semble avoir été générée par IA, et il n’a toujours pas été évalué par les pairs
Je sais bien qu’aujourd’hui beaucoup de chercheurs utilisent l’IA pour aider à écrire, mais quand le sujet du papier est précisément la cognitive surrender, il devient difficile de prendre son contenu au sérieux
not merelypas moins de 7 foisJe me demande si un LLM irait vraiment jusqu’à répéter autant la même tournure, ou si l’auteur n’a pas plutôt pris l’habitude d’écrire comme un LLM
Martin n’a pas complètement tort, mais j’ai vu de mes propres yeux des cas où l’IA a produit du code paresseux, et où la bonne réponse était en réalité d’écrire davantage de code
Concrètement, il y avait des modèles Python définissant un schéma de base de données pour un certain ensemble de concepts logiques
On a ajouté un nouveau concept très proche des concepts existants, et Claude a jugé qu’il suffisait de réutiliser tel quel l’ensemble de modèles déjà en place
En théorie, cela fonctionnait, mais côté consommateurs réels, cela obligeait à toutes sortes de contournements à cause de l’inférence de type à l’exécution
Ça marchait, mais c’était un cas où la couche d’abstraction choisie était complètement mauvaise
Les humains aiment les abstractions, mais parfois la répétition est simplement plus adaptée
Si la machine écrit et maintient le code, les couches d’abstraction supplémentaires d’autrefois ne sont peut-être plus toujours nécessaires
Autrefois, on utilisait le Duff’s device et on déroulait les boucles à la main pour créer volontairement du code dupliqué
Aujourd’hui, le compilateur comprend l’intention, génère de l’assembleur redondant si nécessaire, et cette redondance ne nous préoccupe plus
Récemment, j’avais besoin de quelques morceaux de code de géométrie computationnelle assez peu triviaux ; autrefois, j’aurais dû chercher une bibliothèque, obtenir les validations de conformité, puis adapter mes structures de données métier au format de cette bibliothèque
C’était sans doute moins coûteux qu’une implémentation maison, mais certainement pas négligeable
Maintenant, un LLM peut m’écrire juste la partie dont j’ai besoin, en utilisant directement le format de données que j’ai déjà stocké
Pas besoin d’intégrer une grosse bibliothèque ni de transformer les structures de données
En théorie, il faudrait sans doute utiliser une geometry library pour éviter la duplication, mais ici une fonction autonome fait très bien l’affaire
C’était vraiment l’une des meilleures choses que j’aie lues sur Hacker News depuis longtemps
Je m’y retrouve énormément
Entre la cognitive debt de Simon Willison et cette idée que « ton travail consiste à ne déployer que du code dont tu as démontré qu’il fonctionne », cela m’a amené à travailler sur des projets autour de l’Intent-Driven Development
J’avais l’impression que l’intention initiale s’estompait toujours à mesure que les changements s’accumulaient
Je pourrais peut-être formaliser cela en véritable protocole et le publier plus tard sur Hacker News
Si vous n’avez pas encore vu mes billets, je vous recommande d’y jeter un œil
En résumé, c’est ceci
Pour l’instant, ma visualisation du problème ressemble davantage à ce schéma : https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU...
Je pense que le goulot d’étranglement cognitif de l’ingénierie logicielle se situe moins à l’intérieur du code qu’entre les artefacts
Le code n’est que l’un d’entre eux
outcome → requirements → spec → acceptance criteria → executable proof → review
Je construis un outillage expérimental pour automatiser les parties fastidieuses de ces transitions, et laisser les humains se concentrer sur la vérification que l’intention survit à chaque étape
J’aimerais y ajouter une couche supplémentaire : les proxies / métriques
Dans les systèmes très orientés analyse, la vraie perte ne se situe souvent pas entre la spec et le code, mais entre la question et le proxy
Une fois que le proxy est gravé dans les acceptance criteria, les dashboards ou les evals, les gens se mettent à l’optimiser, et oublient progressivement qu’il ne s’agissait que d’un indicateur de substitution
Sur téléphone, dès que j’essaie de faire un panoramique, de zoomer ou de scroller, je finis par déplacer des éléments du canvas