La tour continue de s’élever

• Les logiciels produits en vibe coding, qui évoluent de façon aléatoire et inattendue, rappellent la tour de Babel, où la construction s’est arrêtée après la perte d’une langue commune ; à l’ère de l’IA, la différence est que la construction continue même après l’effondrement de la compréhension
• La limite des logiciels à grande échelle ne dépend pas seulement de la vitesse de production de code individuelle, mais aussi de la capacité à bien coordonner une compréhension partagée des concepts, des frontières, des invariants, de la propriété et des raisons de conception
• Les frictions liées à l’exploration du code, aux questions, aux revues et aux concertations entre équipes étaient du gaspillage, mais aussi un processus de synchronisation mutuelle de la compréhension et de vérification du consensus sur le système
• Les agents peuvent réaliser en parallèle, sans conversation, des tâches comme l’ajout d’OAuth, le caching ou la reconstruction d’une base de données ; même si chaque changement est rationnel et passe les tests, le modèle commun des humains peut s’affaiblir
• Dans l’ingénierie assistée par l’IA, les agents interprètent et modifient chaque domaine pour poursuivre immédiatement la construction sans échec visible, ce qui rend plus difficile de remarquer la perte du langage architectural qui permettait aux humains de raisonner ensemble sur le système

---

La force de la tour de Babel tenait plus à la coordination qu’à la technologie

• L’évolution parfois aléatoire et imprévisible de certains logiciels issus du vibe coding fait penser à The Tower of Babel de Bruegel
• L’histoire de la tour de Babel est souvent interprétée comme un récit sur l’orgueil, l’ambition et l’origine des langues différentes, mais elle montre aussi l’unité qui rend le progrès technique possible
• Dans Genèse 11:3-6 (KJV), les hommes améliorent leur technique en utilisant des briques cuites au lieu de pierres et du bitume au lieu de mortier, puis cherchent à construire une ville et une tour qui atteignent le ciel
• Ce que Dieu considère comme problématique, ce ne sont ni les briques ni le savoir-faire de fabrication, mais le fait que les hommes ne forment qu’un et partagent une seule langue, de sorte que rien ne les limite
• Quand un langage commun permet d’assembler le travail de chacun, on peut construire ce qu’aucune personne ne pourrait réaliser seule
• Ce n’est pas la disparition des briques ou des méthodes de fabrication, mais celle de la capacité à se comprendre mutuellement, qui a rendu la coordination impossible et interrompu la construction

La tour continue de monter même après que les agents IA ont supprimé les frictions

• La programmation assistée par l’IA fournit aux individus des outils plus puissants, et les développeurs qui utilisent des agents peuvent modifier une codebase à bien plus grande échelle
• Cependant, la limite des grands projets ne dépend pas seulement de la vitesse à laquelle un individu produit du code, mais aussi de la qualité de la coordination entre les personnes dans leur compréhension du système à modifier
• Le langage commun d’un projet logiciel n’est ni l’anglais ni Python en soi, mais une compréhension partagée des éléments suivants
  • ce que signifie chaque concept
  • où se situent les frontières du système
  • quels invariants sont importants
  • qui possède quoi
  • pourquoi le système a adopté sa structure actuelle
• Cette compréhension n’est jamais entièrement consignée en un seul endroit ; elle s’accumule non seulement dans la documentation et le code, mais aussi dans les code reviews, les conversations, les débats et l’expérience d’avoir expliqué ses changements à d’autres
• Avant les agents, modifier la couche de stockage d’une autre personne impliquait souvent de lire le code, de poser des questions et parfois de se coordonner avec une autre équipe qui exploitait des services dépendants
  • Ce processus comportait du gaspillage, mais il servait aussi à transmettre la compréhension d’une personne à une autre et à vérifier que les deux parties restaient d’accord sur le fonctionnement du système
  • Cette friction synchronisait la compréhension des personnes
• Les agents réduisent fortement cette friction et permettent à plusieurs personnes de demander des changements différents sans même se parler
  • L’une peut ajouter OAuth, une autre mettre en place du caching, une troisième reconstruire la base de données depuis zéro et rendre l’interface rose
  • Chaque changement peut être rationnel pris isolément, le code peut compiler, passer les tests et même générer des explications si nécessaire
  • Personne n’a besoin de parler aux autres, ni d’acquérir une partie du modèle partagé qu’autrefois on apprenait au cours du changement
• Les agents ne ressentent pas la douleur, seuls les humains la ressentent, et ils permettent désormais de modifier des zones du système et de la codebase qui exigeaient auparavant l’aide d’autres personnes
• Les projets de vibe coding qui changent d’échelle deviennent des codebases de type tour de Babel non pas parce qu’il est impossible de communiquer, mais parce qu’il n’est plus nécessaire de communiquer
  • Chaque développeur dispose d’un traducteur infatigable capable d’expliquer une zone précise de la tour et d’effectuer le changement local souhaité
  • Les changements continuent d’être intégrés, mais le langage architectural qui permettait aux humains de raisonner ensemble sur le système peut disparaître
• Dans le récit biblique de la tour de Babel, la perte d’une langue commune a interrompu la construction ; dans l’ingénierie assistée par l’IA, la construction peut continuer même après l’effondrement de la compréhension partagée
• Comme la tour ne s’effondre pas et qu’aucun échec immédiat ne survient, il est difficile de remarquer ce qui a été perdu, et la tour continue de s’élever

[GN⁺]

Avis sur Hacker News

• Je pense depuis longtemps que la composabilité du logiciel devrait fonctionner comme dans Tetris, où les lignes doivent disparaître. Les ingénieurs peu expérimentés ou ceux qui utilisent maladroitement des agents ont tendance à manquer ce travail de rangement et à ne faire qu’empiler la tour
  On peut amener un agent à intégrer de façon répétée les éléments existants dans de meilleures abstractions, mais même Fable ou Sol 5.6 restent très en retrait par rapport aux humains pour ce sens architectural de haut niveau qui permet d’anticiper l’évolution subtile du logiciel. Les systèmes actuels semblent encore incapables de maintenir correctement les modèles du monde, rares, de haute qualité et capables de zoom avant/arrière, que les humains manipulent ; mais le simple fait que l’écart se soit resserré jusqu’à ce niveau de subtilité est en soi encourageant

  • Je ne peux pas le prouver, mais je crois fermement que la logique et l’intuition nécessaires aux abstractions conçues en vue de changements futurs ne peuvent pas être réalisées uniquement par une suite de tokens prédits. Il manque quelque chose d’immesurable
  • Autrefois, la capacité de l’esprit humain constituait la limite supérieure de la complexité des programmes, mais le vibe coding peut franchir cette barrière. Non pas parce que le problème est réellement si complexe, mais parce que le processus de développement ne converge pas vers des abstractions concises
    C’est une version IA du problème de passage à l’échelle traité par Brooks dans The Mythical Man-Month : plus l’échelle augmente, plus l’explosion combinatoire s’aggrave, et du code implémentant de fait la même fonctionnalité se duplique partout dans le projet. Il faut trouver un moyen de faire en sorte que le développement assisté par IA recherche la concision
  • La fenêtre de contexte humaine est peut-être bien plus petite que celle des LLM actuels. Cette contrainte a l’avantage de nous pousser à modulariser et à abstraire pour pouvoir garder le travail en tête ; les LLM, qui peuvent absorber bien plus d’un coup, n’ont pas la même incitation, ce qui conduit les agents à produire du code spaghetti mal organisé
  • Au final, ce n’est qu’une question de temps. gpt2 ou llama2 sont aujourd’hui d’une médiocrité choquante comparés aux modèles actuels, et ils étaient déjà pratiquement inutiles à l’époque, mais nous étions impressionnés
    Même GPT3.5 et gpt4, qui suscitaient l’enthousiasme, sont désormais largement dépassés par qwen27b ou gemma31b. Avec assez de temps et le bon reinforcement learning (RL), les modèles finiront eux aussi par construire dans leur esprit d’excellents modèles de systèmes logiciels
  • Et si c’était simplement le résultat d’un renforcement des LLM pour résoudre des tâches à horizon court ? Contrairement aux tâches de réussite aux tests, des efforts étalés sur des années, une architecture propre et un bon jugement sont difficiles à maximiser via des benchmarks

• L’argument central de ce texte fait penser à la Lisp Curse et au Bipolar Lisp Programmer. L’idée était que Lisp permet aux individus de construire trop facilement ce qu’ils veulent, ce qui réduit la motivation des programmeurs à coopérer pour bâtir des résultats génériques et complexes, et appauvrit l’écosystème du logiciel public par rapport à des langages exigeant des efforts plus importants
  Armin semble développer un argument très proche au sujet du codage avec l’IA : Lisp Curse, Bipolar Lisp Programmer

  • Les programmeurs assembleur tenaient le même raisonnement. C’est une idée reçue qui réapparaît à chaque changement de paradigme en ingénierie logicielle, et certains vivent plus difficilement la transition que d’autres
  • Je ne suis pas certain que ce soit vraiment le même raisonnement. Beaucoup pensent désormais qu’il n’est plus nécessaire de se rassembler pour collaborer : il suffit de mobiliser un essaim d’agents pour créer n’importe quel logiciel complexe que l’on peut imaginer
  • Au contraire, si TypeScript et Rust n’avaient pas à ce point dominé le marché, ce serait aujourd’hui un excellent moment pour devenir un pilote de LLM pour Lisp. Les agents actuels peuvent expliquer l’essentiel avec presque aucune hallucination ; pour peu qu’on ait la volonté de comprendre, la barrière de compréhension a pratiquement disparu, et c’est d’ailleurs le cœur du texte
  • Il n’est pas évident que d’autres langages exigent « beaucoup plus d’efforts » pour aboutir au même résultat. Beaucoup de développeurs non Lisp accordent de l’importance à la syntaxe, tandis que les développeurs Lisp n’y attachent pas la même importance, et même après avoir expérimenté l’élargissement de la pensée que procure Lisp, nombreux sont ceux qui ne le préfèrent pas
    Il existe peut-être entre ces deux groupes des modes de traitement cognitif différents. Pour que Lisp soit aussi productif que d’autres langages, il faut exploiter activement l’homoiconicité, ce qui fait que les programmes Lisp sérieux tendent facilement à devenir un ensemble de langages spécifiques au domaine (DSL) que seules une ou deux personnes comprennent

• La limite des grands projets logiciels ne tient pas à la vitesse à laquelle un individu peut produire du code, mais à la qualité de l’alignement de la compréhension commune qu’ont du système les personnes qui le modifient. Dire que tout est devenu plus complexe depuis le 30 novembre 2022 est exact.

  • Le logiciel est devenu excessivement complexe, couche empilée sur couche, et nous utilisons pour le gérer des outils qui créent encore bien plus de complexité. Dans les années 1990 et au début des années 2000, on pouvait créer des applications puissantes en Visual Basic ou en PHP sans formation formelle, mais aujourd’hui le développement web ou desktop est d’une complexité écrasante, et même pour bien utiliser React, il faut connaître énormément de choses.
    Introduire l’IA là-dedans revient presque à ajouter une nouvelle couche de complexité sur une complexité déjà existante. Au mieux, c’est un gaspillage matériel colossal ; au pire, les agents créent autant de nouveaux bugs qu’ils en corrigent, les logiciels fragiles et médiocres se multiplient, et comme les gens n’apprennent plus les compétences techniques, les capacités globales de l’humanité pourraient s’affaiblir. Le logiciel n’a pas intrinsèquement besoin d’être à ce point complexe, et pour y remédier, il faut valoriser l’artisanat.
  • Le fait qu’il faille comprendre un système avant de le modifier n’a rien de nouveau. Programming as Theory Building de Peter Naur existait déjà dans les années 1980, et même sans l’avoir lu, parmi les développeurs expérimentés il allait de soi que la compréhension du système était indispensable.
  • Tout n’est pas devenu plus complexe. Les principales bases de données intègrent désormais des outils de haute disponibilité pratiques, les microservices sont en recul, et les bases de données structurées reviennent à la place du NoSQL.
    HTML et le pré-rendu sont aussi de retour avec HTMx et LiveView, et le CSS s’est débarrassé des contournements grotesques du passé. Quand on explique à un jeune collègue comment on déboguait une page web sous IE6, on mesure le chemin parcouru. Certaines choses se sont complexifiées, mais d’autres ont suffisamment mûri pour devenir plus simples.
  • Il ne faudrait pas dire « depuis le 30 novembre 2022 », mais depuis 2022 avant notre ère. L’augmentation de la complexité, c’est pratiquement toute l’histoire de la civilisation humaine.
    Une personne de 20 000 avant notre ère cherchait de quoi manger et évitait le froid comme les prédateurs, mais une personne de 5 000 avant notre ère cultivait la terre, s’inquiétait de la pluie et des maladies, et créait des systèmes pour gérer la communauté et les terres. Aujourd’hui, la plupart des gens ne cultivent pas directement leur nourriture et gèrent à la place la complexité d’une société immense. Pour un développeur des années 1970-80, même le logiciel d’avant les LLM paraît extraordinairement complexe, et désormais presque plus personne ne code directement sur le matériel sans couches d’abstraction. En cryptographie aussi, les bibliothèques cachent la complexité et on enseigne de « ne pas l’implémenter soi-même ». La vraie question est maintenant : à quelle vitesse les LLM peuvent-ils aligner la compréhension d’un système à modifier ?

• Le langage partagé d’un projet logiciel, ce n’est ni l’anglais ni Python, mais une compréhension commune du sens des concepts, de leurs frontières, des invariants, de la propriété, et des raisons pour lesquelles le système a pris sa forme actuelle. Le Pattern Language de Christopher Alexander traite précisément de ce problème, et sa recommandation de créer un langage de patterns adapté à chaque domaine a conduit aux célèbres GoF Design Patterns.
  J’expérimente actuellement une fonctionnalité où l’IA maintient, pour chaque projet, trois langages de patterns distincts — pour les domaines métier, produit et technique — et cela fonctionne très bien. On s’y réfère pendant la planification et on les fait évoluer pendant l’implémentation et la revue, ce qui rend même des projets codés à 100 % par IA plus structurés, mieux alignés entre domaines et plus faciles à gérer.

  • J’aimerais voir un exemple concret. J’ai souvent entendu dire que la maturation du code ressemblait à la croissance organique d’une ville, mais je n’ai jamais vu de résultat précis.
  • Je me demande s’il existe un exemple GitHub public.

• Dans la tour de Babel, la construction s’arrête quand on perd la langue commune ; avec le développement assisté par IA, la construction continue même après l’effondrement de la compréhension partagée. L’auteur ne dit pas explicitement si c’est bien ou mal, mais il est clair qu’il y voit quelque chose de négatif.
  Si savoir qu’une tomate est un fruit relève de l’intelligence et savoir ne pas la mettre dans une salade de fruits relève de la sagesse, alors l’IA est la forme ultime d’une intelligence totalement dépourvue de sagesse, presque une illusion d’intelligence. S’il n’y a plus personne pour comprendre ce que fait l’IA, il faut s’arrêter et reconnaître que nous manquons de la sagesse nécessaire pour contrôler ce que nous construisons.

  • J’aime le fait que l’auteur, au lieu de faire la leçon, laisse l’image elle-même porter le sens. L’histoire ne se répète jamais à l’identique, mais elle garde toujours une certaine rime.
  • Il vaudrait mieux éviter les clichés puérils du genre « savoir qu’une tomate est un fruit, c’est de l’intelligence », sauf si le but est d’induire en erreur. Rien que comprendre les classifications et les relations de dépendance est déjà un problème suffisamment difficile, et au supermarché comme dans Nix v. Hedden, la tomate est un légume au regard du critère fiscal.

• Moi aussi, Babel et le tableau de Bruegel me viennent à l’esprit, mais de façon bien moins optimiste. J’y vois de petits agents myopes développer chacun leur zone d’un ensemble si vaste qu’il leur est impossible de le connaître : d’un côté cinquante courtines, de l’autre une étrange tour en saillie ; au-dessus d’une cour intérieure, un toit en adobe dont personne ne sait la raison, et sur le palier voisin, une tour coiffée d’un toit de chaume.
  Chaque décision est défendable à l’échelle locale, mais faute de politiques et de jugements à plusieurs niveaux pour intégrer l’entreprise dans son ensemble, on obtient un monstre architectural gigantesque. Le fait qu’il faille de la discipline pour créer et maintenir un langage commun dans une organisation assez grande se voit aussi dans le vocabulaire propre aux entreprises prospères comme aux armées. Les « Gastown Mayors », les « polecats » en dessous, puis les golems encore plus bas, croient parler la même langue ; mais une fois tout achevé, on découvrira que la compréhension que l’on croyait avoir parfaitement transmise depuis le trône n’était en réalité pas partagée.

• Anakin : « Les développeurs qui utilisent des agents vont voir leur capacité à modifier une codebase augmenter de façon spectaculaire. »
  Padmé : « Dans le bon sens, n’est-ce pas ? »
  Anakin : silence
  Padmé : « Dans le bon sens, n’est-ce pas ? »

• On dirait que si le vibe coding recommande de ne pas lire le code généré, c’est parce qu’une fois qu’on a vu l’horreur tapie dans un fichier Python, on ne peut plus l’oublier. Au sens large, le code fait ce qu’on lui a demandé, mais chaque fois qu’il choisit une manière d’atteindre l’objectif, il prend des décisions incohérentes.
  Il applique des validations étranges seulement à certaines entrées utilisateur, trie ou met en minuscules les données à trois étapes différentes sans raison, et va jusqu’à coder en dur sous forme de chaînes les noms de colonnes de la première ligne du CSV d’entrée. La moitié consiste en fonctions globales recevant des data classes, l’autre moitié est implémentée sous forme de classes. Dès qu’on pense au fait qu’il faudra un jour le mettre à jour et le maintenir soi-même, il devient difficile de ne pas le corriger ; mais à mesure qu’on le retouche, une bonne partie du temps gagné disparaît.

• La programmation basée sur des agents est bien plus proche d’un travail de gestion que de la programmation proprement dite. Un manager ne suit le travail des contributeurs individuels qu’à un haut niveau, et il lui manque souvent le temps, la bande passante cognitive ou même les compétences pour comprendre tous les détails
  Plus il y aura de logiciels écrits par des agents, plus le rôle de l’ingénieur logiciel se rapprochera d’un poste de management plutôt que d’un poste technique

  • C’est aussi vrai pour les programmeurs. La plupart des contributeurs individuels ne savent pas ce qui se passe sous la couche sur laquelle ils travaillent et ne maîtrisent pas l’implémentation interne des bibliothèques, frameworks, API distantes ou appels système
    Ils n’ont ni le temps ni la marge mentale pour tout comprendre, donc ils se contentent d’effectuer le travail nécessaire dans leur couche d’abstraction
  • Je l’utilise très peu, parce que cela donne l’impression de passer la journée à relire le code d’un développeur junior, et je m’en sers surtout pour repérer ce que j’ai pu manquer

• Autrefois, un refactoring de grande ampleur demandait tellement d’efforts qu’il fallait une très bonne raison pour le lancer. Aujourd’hui, si le prompt est un peu ambigu et que le résultat n’est pas correctement relu, un agent peut réécrire la moitié du code, si bien que l’âme du programme peut changer profondément chaque jour. C’est à la fois formidable et pas du tout

  • Le principal obstacle aux refactorings massifs n’a jamais vraiment été la charge de travail initiale, mais plutôt la réduction du risque de bugs, la préservation des fonctionnalités et la garantie de compatibilité avec l’écosystème existant. Si cela est devenu plus facile à l’ère de l’IA, c’est parce que nous avons cessé de nous en soucier autant