Dette technique, dette cognitive, dette d’intention

• 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