La compréhension est le nouveau goulot d’étranglement
(geoffreylitt.com)- Alors que le code écrit par des agents continue de s’accumuler autour des humains, le facteur qui limite la vitesse de développement n’est plus la capacité à générer du code, mais la vitesse de compréhension humaine, c’est-à-dire la capacité à suivre le système et à imaginer le changement suivant
- L’objectif de comprendre le code ne se limite pas à la validation, qui consiste à approuver ou rejeter un résultat ; il s’agit aussi de proposer les idées suivantes et de participer au processus créatif au fil des multiples boucles de travail des agents
- Lire d’abord un document d’explication du code combinant contexte, objectifs de changement, schémas interactifs et diff narratif permet de saisir plus rapidement la structure et l’intention d’une modification qu’en examinant directement un diff brut
- Les quiz des documents explicatifs et les micromondes, qui permettent de manipuler directement le processus d’exécution, ne délèguent pas le jugement à l’agent : ils amènent l’humain à faire l’expérience des changements d’état du système et de son fonctionnement interne
- Si l’on n’utilise pas l’IA seulement comme un moyen d’automatiser pour retirer l’humain de la boucle, mais aussi pour créer des outils et des simulations au service de la compréhension, les personnes et les équipes peuvent au contraire participer plus profondément à la boucle
Des humains incapables de suivre la vitesse de génération du code
- Comme une pile de code écrite par des agents qui ne cesse de grandir autour d’une personne, la quantité de code généré augmente, mais la vitesse à laquelle les humains le comprennent n’augmente pas au même rythme
- Lire chaque ligne de chaque diff de code ne suffit plus à suivre la cadence de travail des agents
- Comprendre le code peut passer par bien d’autres moyens que les diffs bruts
- Des documents d’explication du code qui enseignent le système et les changements
- Des quiz qui vérifient la compréhension réelle
- Des micromondes où l’on apprend en manipulant directement le fonctionnement interne
- Des espaces partagés où toute l’équipe construit le même modèle mental
Comprendre ne sert pas à valider, mais à participer
- À la question de savoir pourquoi les humains doivent comprendre le code, la réponse la plus fréquente est : pour valider le travail de l’agent
- Vérifier qu’il correspond à la spécification
- Juger si la structure est appropriée
- Décider au final de l’approuver ou de le rejeter
- La présentation illustre cela comme un jugement binaire, pouce levé ou pouce baissé
- Si l’on réduit le rôle humain à la validation, la compréhension devient un simple processus de décision sur la réussite ou l’échec d’un résultat
- Mais les agents améliorent aussi en permanence leur capacité d’auto-validation, en exécutant et en inspectant eux-mêmes ce qu’ils produisent pour trouver des erreurs
- À mesure que les agents deviennent meilleurs pour valider, la question se pose : où reste la place de l’humain ?
- L’alternative consiste à participer par la compréhension
- Il faut savoir ce que fait l’agent pour que l’humain reste un membre actif du processus créatif
- Comprendre le système ne sert pas seulement à évaluer le résultat actuel, mais aussi à réfléchir à ce qu’il faut changer ensuite
Un projet n’est pas une boucle unique, mais une multitude de boucles
- Un vrai projet ne consiste pas à donner une instruction unique à un agent puis à recevoir un résultat : ce n’est pas une boucle unique
- Il s’agit d’une multitude de boucles itératives reliées entre elles : définir l’objectif, implémenter, vérifier, corriger, étendre
- À chaque itération, le niveau de compréhension du système par l’humain détermine la qualité et la portée de l’idée suivante
- Il faut avoir assez de concepts et de structures en tête pour traiter avec aisance des questions comme :
- Que faut-il ajouter ou retirer ?
- Quelle structure faut-il modifier ?
- Quelles nouvelles possibilités l’implémentation actuelle ouvre-t-elle ?
- Sans compréhension suffisante, on peut réagir au résultat produit par l’agent par un « ça a l’air à peu près bon », mais il devient difficile de piloter la direction du projet
La dette cognitive qui s’accumule quand on reporte la compréhension
- Accepter continuellement les résultats d’un agent sans comprendre le système permet d’avancer vite à court terme
- Mais, de même que la dette technique augmente le coût des changements futurs, travailler en faisant l’impasse sur la compréhension laisse une dette cognitive
- Quand la dette cognitive s’accumule, les personnes impliquées dans le projet perdent le fil d’ensemble
- Il devient difficile de comprendre pourquoi le code a adopté sa structure actuelle
- Il devient difficile de décider où raccorder de nouvelles exigences
- Il devient difficile de discuter de la pertinence du prochain changement proposé par l’agent
- Le problème de l’ère de l’IA n’est pas que le code ne soit pas généré, mais que les humains ne disposent pas de concepts suffisants sur les systèmes générés
Appliquer les méthodes pédagogiques à la compréhension du code
- Dans un environnement de travail IA qui évolue vite, construire la compréhension humaine ressemble à un problème que l’éducation traite depuis longtemps
- Pour former une véritable compréhension, il ne suffit pas de transmettre de nouveaux faits : il faut aussi fournir contexte, intuition, pratique et feedback
- On peut appliquer à la compréhension du code des méthodes développées en pédagogie
- Fournir contexte et intuition avant les détails d’implémentation
- Faire se remémorer le contenu et répondre après l’avoir lu
- Offrir un environnement permettant de manipuler directement des règles abstraites
- Amener les personnes à partager les mêmes concepts et le même vocabulaire
/explain-diff, pour enseigner les changements
- /explain-diff est une compétence qui transforme les changements effectués par un agent en document explicatif structuré
- La sortie peut prendre la forme d’une page HTML, Markdown ou Notion ; le document Notion peut servir de livrable collaboratif où les membres de l’équipe commentent et discutent ensemble
- Il ne s’agit pas d’une simple liste de changements de code, mais de matériel explicatif conçu pour aider les humains à apprendre les changements
- Dans un exemple où l’on change la perspective de l’écran d’un jeu, l’approche ne montre pas le code d’emblée, mais procède dans cet ordre
- Expliquer d’abord le mode de rendu du moteur de jeu existant
- Présenter l’objectif du changement : « donner un aspect tridimensionnel au jardin avec une technique de dessin 2D »
- Expliquer ce qu’est la projection isométrique afin de comprendre le principe visuel du changement
- Passer ensuite au code d’implémentation réel
Commencer par enseigner le contexte
- Une bonne explication commence moins par « qu’est-ce qui a changé ? » que par « qu’est-ce qui existait avant le changement ? »
- Sans connaître le système de coordonnées et la structure de rendu du moteur de jeu existant, lire uniquement le nouveau code de perspective rend la raison du changement difficile à comprendre
- Le document explicatif complète d’abord la structure du système existant pour permettre à une personne qui ne partage pas le même contexte que l’agent de participer à la discussion
- Ce n’est pas un simple résumé, mais un processus qui ramène la personne dans le contexte actuel du projet
Construire l’intuition avant les détails d’implémentation
- Expliquer en une phrase l’essence du changement avant le code permet de comprendre vers quel objectif pointent les détails d’implémentation
- Dans l’exemple du jardin rendu plus tridimensionnel, l’explication ne commence pas par les formules de la projection isométrique, mais par l’objectif visuel : faire paraître un dessin plat comme s’il était en 3D
- Une fois le contexte et l’objectif compris, il devient plus facile, en lisant les fragments de code, de relier chaque calcul et transformation au rôle qu’ils jouent dans le résultat global
- L’objectif est de faire de l’humain non pas un lecteur passif de détails de code, mais un participant à égalité qui comprend l’intention du changement
Faire l’expérience des transformations de coordonnées avec des schémas interactifs
- Au lieu de montrer uniquement une image statique, on utilise un schéma interactif où l’on peut faire glisser directement un rocher dans le jardin
- Quand le rocher se déplace, sa position à l’écran et ses coordonnées internes changent ensemble, ce qui permet d’observer la transformation de coordonnées de la projection isométrique
- En manipulant directement la relation entre entrée et sortie, il est possible de former une intuition plus facilement qu’en lisant seulement des formules ou du code
- En intégrant du HTML interactif dans une page Notion, le document d’explication du code lui-même peut devenir un petit environnement d’exécution
- L’IA peut non seulement rédiger des explications, mais aussi générer les outils de visualisation et de manipulation nécessaires à la compréhension
Transformer les diffs bruts en diffs narratifs
- Un diff de code classique énumère les fichiers modifiés par ordre de nom de fichier
- Il n’explique pas les relations entre fichiers
- Il n’indique pas l’objectif du changement
- Il ne guide pas sur l’ordre de lecture
- Un diff narratif (literate diff) réorganise les changements comme le fil d’un texte
- Il présente d’abord l’objectif du changement
- Il explique les fichiers et fonctions dans un ordre adapté à la compréhension
- Il n’insère que les fragments de code nécessaires entre les explications
- Il montre aussi les relations entre le contexte environnant et les choix d’implémentation
- Si le diff brut ressemble à des matériaux empilés tels quels, le diff narratif revient plutôt à monter le processus de changement en une histoire
- Lire d’abord l’explication puis examiner le diff brut permet de lire chaque fragment de code en sachant pourquoi il existe, ce qui accélère la revue
Lire sur papier une documentation générée par l’IA
- Le document explicatif final peut servir de paquet d’explication du code
- On continue à lire le diff brut, mais on lit toujours le document explicatif en premier
- Quand il faut se concentrer, il arrive d’imprimer le document et de le lire sur papier dans un café
- Il en résulte ce paradoxe : une activité interactive comme programmer avec l’IA se transforme en rapport papier statique propice à une concentration profonde
- L’essentiel n’est pas d’utiliser l’interface la plus récente, mais de transformer l’information sous une forme réellement favorable à la compréhension humaine
La différence entre avoir l’impression d’avoir lu et comprendre réellement
- Même bien structuré, un document explicatif ne garantit pas que le simple fait de lire produise de la compréhension
- Les humains peuvent facilement se croire capables de retenir ou de comprendre un contenu simplement parce que leurs yeux ont suivi les phrases
- L’idée s’inspire de “books don't work” d’Andy Matuschak et de Quantum Country d’Andy Matuschak et Michael Nielsen
- Quantum Country intègre des quiz à répétition espacée dans le texte pour obliger le lecteur à se remémorer activement le contenu
- La même méthode est appliquée aux documents d’explication du code, avec cinq questions interactives sur les changements placées à la fin
Les quiz sont le régulateur de vitesse de la boucle IA
- Une règle est utilisée : avant d’envoyer du code à quelqu’un d’autre, il faut réussir le quiz du document explicatif
- Le même critère s’applique aussi lors de la revue du code écrit par quelqu’un d’autre
- Le quiz n’est pas une fonction annexe destinée à évaluer des connaissances, mais un régulateur de vitesse
- Quand on travaille avec l’IA, les boucles d’implémentation, correction et régénération peuvent facilement avancer plus vite que la compréhension humaine
- Le quiz force à poser mécaniquement les questions suivantes à chaque boucle
- Peut-on expliquer ce qui a réellement changé ?
- Comprend-on pourquoi cette structure a été utilisée ?
- Connaît-on les contraintes qui influenceront le prochain changement ?
- Si l’on ne réussit pas, il faut ralentir le travail et compléter sa compréhension, ce qui permet à l’humain de rester un participant créatif
Les micromondes inspirés du Mathland de Seymour Papert
- La deuxième méthode, les micromondes, part d’une idée du pédagogue Seymour Papert
- Papert considérait que, de même qu’on vit en France pour apprendre le français, il faudrait vivre dans un Mathland où les mathématiques fonctionnent naturellement pour apprendre les mathématiques
- L’enfant n’écoute pas passivement une explication ; il explore l’environnement selon sa curiosité et assimile naturellement les concepts mathématiques
- Appliqué au code, cela ne consiste pas seulement à fournir un document qui explique le système, mais aussi à créer un environnement où l’humain peut entrer et faire directement l’expérience de son fonctionnement
- Un micromonde est un petit monde conçu pour faciliter l’observation de certains principes et changements d’état, plutôt que d’exposer tel quel tout le système de production
Explorer un interpréteur Prolog sur l’axe du temps
- Lors du développement d’un interpréteur Prolog, il était difficile de saisir intuitivement ce qui se passait à l’intérieur
- Avec un agent, un débogueur dédié a été créé pour explorer pas à pas le processus d’exécution
- Ce débogueur permet d’observer directement les éléments suivants
- Se déplacer en avant et en arrière dans le temps d’exécution
- Examiner les valeurs présentes sur la pile courante
- Vérifier quelles règles sont évaluées à chaque étape
- Laisser une note au moment où une règle donnée est correctement appliquée
- Au lieu de voir uniquement le résultat final, on peut suivre directement la manière dont l’exécution d’un langage logique se déploie dans le temps
- Confier le débogage à l’agent peut résoudre le problème, mais c’est en manipulant soi-même le débogueur que l’humain acquiert une compréhension de la structure d’exécution
La différence entre laisser l’agent déboguer et créer des outils de compréhension
- « L’agent trouve et corrige le problème » et « l’agent crée un outil qui permet à l’humain d’explorer le problème » produisent des résultats différents
- Le premier cas fournit vite un résultat de travail, mais la compréhension humaine du processus interne peut très peu progresser
- Le second offre un processus d’exploration où l’humain examine l’état d’exécution, formule des hypothèses et vérifie les résultats
- Même si une partie de l’écriture du code est confiée à l’agent, les étapes essentielles de réflexion et d’exploration peuvent rester humaines
- C’est une approche qui étend le rôle de l’agent, de fournisseur de réponses à créateur d’environnements de compréhension
Migrer un site web comme dans un jeu vidéo
- Lors de la migration d’un site web personnel d’un framework vers un autre, Claude a écrit un script d’automatisation
- N’étant pas familier du nouveau framework, il était difficile d’évaluer le script au-delà de « ça a l’air à peu près bon »
- Pour résoudre ce problème, il a été demandé à Claude de créer un centre de commande sous forme de jeu vidéo permettant d’effectuer directement la migration
- Dans ce centre de commande, on peut visualiser les étapes suivantes
- Appuyer sur un bouton pour exécuter les étapes de migration une par une
- Afficher l’ancien site et le nouveau site côte à côte
- Observer comment l’apparence du nouveau site change à chaque étape
- Voir dans quel ordre l’arborescence de fichiers évolue
- Au lieu d’exécuter toute la transformation d’un coup, on fait directement l’expérience du nouveau site qui prend vie étape par étape
- On obtient une compréhension proche de celle que l’on aurait eue en déplaçant tous les fichiers à la main, tout en avançant beaucoup plus vite parce que le travail nécessaire et l’environnement d’observation sont déjà préparés
Générer du code pour comprendre le code
- Le code qu’un agent peut écrire ne se limite pas aux fonctionnalités produit ni aux scripts d’automatisation
- Il peut aussi créer des outils temporaires destinés à aider les humains à comprendre d’autres codes, par exemple
- Des outils de visualisation de l’exécution
- Des débogueurs pas à pas
- Des écrans de comparaison côte à côte
- Des visualiseurs d’évolution de l’arborescence de fichiers
- Des explications conceptuelles interactives
- Des centres de commande qui découpent une tâche en petites étapes
- Ces outils peuvent avoir une réelle valeur même s’ils ne sont pas du code produit maintenu sur le long terme
- À mesure que le coût de création de code par IA diminue, il devient réaliste de créer des environnements d’apprentissage jetables pour une personne et une tâche spécifiques
En équipe, il faut comprendre ensemble
- La compréhension individuelle du système ne suffit pas pour le travail d’équipe
- Les membres de l’équipe doivent partager le même modèle mental pour évoquer les mêmes structures et comportements avec des expressions courtes
- Lorsque vocabulaire et images sont partagés, il devient plus facile d’échanger des idées à la volée et de faire émerger ensemble de nouvelles directions
- À l’inverse, si chacun travaille isolément avec son propre agent, plusieurs problèmes apparaissent
- Les mêmes termes sont utilisés avec des sens différents
- Les prémisses des plans techniques ne sont pas partagées
- Même si les livrables sont assemblés, la compréhension ne l’est pas
- L’usage de l’IA en équipe ne consiste pas seulement à augmenter la productivité individuelle, mais aussi à construire une compréhension partagée à l’échelle de l’équipe
Garder le travail des agents et des humains dans un même espace partagé
- Dans Notion, il est possible d’exécuter des agents Claude et Cursor à l’intérieur des pages
- Les plans techniques écrits par les agents sont par défaut créés dans des pages collaboratives
- Les membres de l’équipe peuvent examiner directement au même endroit les plans produits par l’agent, sans les copier dans un canal séparé
- Commenter une phrase précise
- Questionner un choix d’implémentation
- Modifier le plan ensemble
- Garder la discussion de l’équipe et le résultat de l’agent dans un même contexte
- Plutôt que de travailler dans des silos personnels, agents et humains réfléchissent autour d’un document commun
- L’espace partagé n’est pas une archive où stocker des résultats, mais un lieu où l’équipe fabrique ensemble son modèle mental
Le but de l’ordinateur a toujours été l’augmentation
- Les explications, quiz et micromondes pour comprendre le code ne sont pas propres à la programmation
- Les humains ont besoin de connaissances non seulement pour valider des résultats, mais aussi pour comprendre le fonctionnement du monde et participer à son évolution
- Il y a environ 50 ans, Alan Kay concevait l’ordinateur comme un nouveau média éducatif, meilleur que le livre
- Dans les dessins de l’époque, des enfants regardent un dispositif de type tablette, mais ils ne regardent pas passivement des vidéos
- Ils manipulent des simulations physiques interactives
- Ils jouent à des jeux tout en modifiant directement le code
- Ils observent comment le code modifié change les mouvements physiques
- L’ordinateur peut devenir non pas une machine de transmission d’informations statiques, mais un média dynamique qui permet de comprendre des concepts complexes en les animant et en les modifiant
Pas seulement automatiser, mais participer plus profondément
- L’idée centrale est exprimée par un mème où un astronaute regarde la Terre et demande : « Le but de l’ordinateur était-il de créer des simulations dynamiques pour comprendre des concepts complexes ? », tandis que l’astronaute derrière lui répond : « Ça l’a toujours été »
- Si l’on réduit l’objectif de l’ordinateur et de l’IA à supprimer le travail humain, l’humain risque d’être repoussé à l’extérieur du système
- À l’inverse, si l’on utilise l’IA pour créer des explications, des simulations, des micromondes et des espaces partagés, les humains peuvent comprendre davantage de concepts, plus en profondeur
- En abaissant le coût de création de simulations, l’IA permet de générer à la demande des environnements sur mesure pour apprendre un concept précis
- L’objectif n’est pas seulement de retirer l’humain de la boucle, mais de lui permettre d’entrer plus profondément dans la boucle qu’auparavant
Articles liés
- Enough AI copilots! We need AI HUDs - Des interfaces IA qui vont au-delà des copilotes pour étendre plus directement l’esprit humain
- AI-generated tools can make programming more fun - Un exemple où une UI de débogueur personnalisée générée par IA améliore le processus de programmation directe par l’humain
- Code like a surgeon - Une manière de déléguer les tâches répétitives annexes pour permettre à l’humain de se concentrer sur le travail essentiel
2 commentaires
Pour éliminer complètement les goulots d’étranglement,
Comme la structure de la cognition et de la mémoire humaines se divise en mémoire à court terme et mémoire à long terme, j’ai envie de dire que, même si l’on essaie ainsi d’accélérer le codage par l’IA, le fait qu’un humain vérifie régulièrement en cours de route et accumule de la mémoire à court terme est ce qu’il y a de plus efficace face à la dette cognitive.