- Une usine logicielle exploite à grande échelle, dans un harnais, des boucles qui répètent collecte de contexte, action et validation ; elle se divise entre usines lumineuses, où l’humain juge, et usines sombres, où même la revue de code est confiée aux machines
- La génération de code, les tests et les scans passent presque à l’échelle sans coût, mais la revue et le jugement humains sont difficiles à étendre : le goulot d’étranglement devient donc la vitesse à laquelle on peut valider les résultats de façon peu coûteuse et fiable, plutôt que le volume généré
- Si les humains ne lisent pas le code, une dette de compréhension (comprehension debt) s’accumule entre la taille du code et la compréhension humaine ; même si les tests continuent de passer, des problèmes de maintenance peuvent apparaître tardivement dans des systèmes complexes exploités sur le long terme
- L’automatisation complète ne devrait être autorisée que pour des boucles courtes, dotées de critères de décision immédiats, stables et difficiles à manipuler ; pour les tâches où une mauvaise décision coûte cher et a un fort impact, comme l’authentification, les paiements ou les API publiques, la revue humaine doit rester en place
- Le rôle de l’ingénieur passe de l’écriture directe de changements individuels à la conception et à la protection de la boucle externe ; il doit valider les preuves du diagnostic, de l’implémentation et des tests réalisés par l’agent, puis assumer la responsabilité de l’approbation et des résultats
Des boucles aux usines logicielles
- L’idée de transformer le logiciel en un processus de production répétable et mesurable remonte à « The economics of program production », publié par Bob Bemer en 1968
- Comme il était difficile de produire des idées en série comme des pièces automobiles, ces tentatives sont restées globalement en deçà des attentes au cours du dernier demi-siècle
- Les changements des deux dernières années ont été assez importants pour réexaminer l’ancienne idée d’usine logicielle, mais les pièges du passé peuvent être reconditionnés comme de nouvelles opportunités
- Le système complet se compose de trois couches : boucles, harnais et usines
- Une boucle est l’unité minimale de travail dans laquelle un agent rassemble du contexte, agit, puis vérifie le résultat, en répétant jusqu’à satisfaire une condition d’arrêt
- Le loop engineering consiste à concevoir de petits systèmes qui fournissent des prompts à un agent, plutôt que de demander à un humain de saisir un prompt à chaque fois
- Un harnais comprend la sandbox dans laquelle la boucle s’exécute, les outils utilisables, la mémoire conservée entre les exécutions et les gates qui déterminent si le travail est terminé
- Un modèle sans harnais peut tourner indéfiniment ; c’est donc le harnais qui rend la boucle utile et sûre
- Une usine logicielle est une structure qui prélève des éléments dans une file de travail, exécute simultanément plusieurs boucles fondées sur des harnais, puis les envoie en production après des gates de revue
- Elle ressemble moins à un grand agent unique qu’à un organigramme composé de boucles
- L’unité de travail de l’ingénieur se déplace elle aussi des changements de code individuels vers les boucles, les harnais et les flux entre boucles
Flux de travail et goulots d’étranglement de l’usine
- La vision du leadership engineering, l’intention des ingénieurs, ainsi que les signaux issus des incidents et des demandes utilisateurs entrent dans une même file de travail
- Un harnais choisit un élément et produit un changement, tandis que la CI, les tests, l’analyse statique et divers scans l’examinent en parallèle
- Si le gate de revue l’approuve, le changement est déployé, et les données de monitoring en production redeviennent des signaux déclenchant du travail
- La génération, les tests et les scans peuvent passer à l’échelle pour un coût négligeable, mais le jugement humain au gate de revue est difficile à étendre
- La capacité à augmenter la vitesse de développement et la fréquence de déploiement dépend de la manière dont on traite ce goulot d’étranglement du jugement
Usines sombres et dette de compréhension
- Dans l’industrie, une usine sombre est une installation exploitée lumières éteintes, car les machines n’ont pas besoin d’éclairage
- FANUC exploite ce type d’usine depuis 2001, et Xiaomi a également ouvert en 2024 une usine sombre fortement automatisée
- Dans une usine logicielle sombre, les humains ne lisent pas le code et déploient les changements uniquement sur la base de la validation effectuée par les machines qui ont produit ce code
- Ici, l’obscurité n’a pas une connotation négative : elle signifie que les humains ont disparu du processus consistant à écrire, relire et déployer les diffs
- Supprimer la revue humaine enlève une source de friction et peut donner l’impression que le débit vertical de l’équipe augmente fortement
- Mais des coûts cachés rendent ce flux de travail plus difficile à maintenir longtemps qu’il n’y paraît
- L’orchestration, le prototypage en sandbox et les appels d’outils continueront de gagner en puissance, mais les harnais seuls ne suffisent pas à préserver la qualité d’une base de code sur le long terme
- La dette de compréhension est l’écart entre la quantité de code existante et la quantité de code réellement comprise par les humains
- Les usines sombres accumulent rapidement de la dette de compréhension, même lorsque les tests passent
- Contrairement aux changements immédiats sur une petite zone de code ou aux projets de week-end, les systèmes existants complexes développés depuis plus de dix ans doivent continuer à être maintenus avec une rigueur professionnelle
- Après 3 à 6 mois d’exploitation d’un projet d’automatisation, on peut se retrouver submergé par du code non lu
- Lorsque Dex Horthy a exploité pendant environ quatre mois une usine entièrement automatisée où les humains ne regardaient pas le code généré, trouver la cause des problèmes nécessitait un débogage manuel pénible
- Plus on maximise l’usage de tokens, plus la compréhension humaine du système diminue silencieusement
- L’échec peut survenir tardivement et silencieusement, plutôt que par l’effondrement soudain d’un système dont les tests passaient jusque-là
Pourquoi la validation devient la contrainte, plus que la génération
- La back pressure est le principe qui consiste à n’accorder d’autonomie aux boucles que dans la mesure où l’on peut valider leur travail de manière fiable et peu coûteuse
- Le problème central est l’écart entre une capacité de génération presque illimitée et une attention humaine limitée
- Si la zone de validation ne s’élargit pas, les changements s’accumulent ; augmenter seulement le volume, sans gate fiable, produit des PR de mauvaise qualité et des défauts manufacturés
- L’amélioration des performances des modèles ne réduit pas automatiquement l’écart entre génération et validation
- La valeur d’une bonne architecture se révèle sur des mois et des années, pas en quelques secondes ou minutes
- Il est difficile de calculer une fonction de coût propre ou un signal d’évaluation immédiat pour l’excellence architecturale, et donc difficile d’entraîner de bonnes décisions de conception complexes à partir de bons exemples
Comment rallumer les lumières
- Même dans une usine lumineuse, les agents prennent en charge l’essentiel de l’implémentation, mais on rallume la lumière aux points où le coût d’un mauvais jugement est élevé, et des humains lisent les livrables avant le déploiement
- Le jugement humain ne doit pas seulement être accolé à la dernière revue de code : il doit être déplacé en amont, aux étapes produit, design et architecture, avant que l’agent ne démarre sa boucle
- Relire à l’avance pendant une heure un plan de 200 lignes peut éviter une longue revue consistant à fouiller 2 000 lignes de code généré après l’implémentation pour retrouver les décisions de conception
- Plus une décision est coûteuse et durable, plus l’humain doit intervenir avant l’implémentation ; et même après une revue en amont, il faut vérifier directement le diff si nécessaire
- Le filet de sécurité ne repose pas sur de nouvelles techniques, mais sur des pratiques d’architecture familières
- Utiliser de bons types et de bonnes signatures de méthodes pour attraper les erreurs dans le compilateur plutôt qu’en production
- Prévoir des points de test (seams) afin de figer le comportement et d’observer les changements
- Organiser le code pour que les humains comme les modèles puissent trouver facilement ce dont ils ont besoin
- Garder des piles d’appels courtes et lisibles
- Clarifier les frontières entre composants afin de limiter le périmètre d’impact des changements
- Rendre les composants remplaçables grâce à l’injection de dépendances
- Cette architecture joue un second rôle : empêcher les erreurs des agents de codage automatique de manière peu coûteuse et difficile à contourner
- Des agents comme Claude Code et Codex sont entraînés par renforcement sur leur propre harnais et l’usage d’outils, mais ils n’apportent pas à eux seuls la maintenabilité à long terme
- Le filet de sécurité doit exister en dehors du modèle, et l’investissement architectural devient un moyen d’obtenir davantage d’autonomie en toute sécurité
- Combinées à une infrastructure sûre, certaines boucles courtes et peu risquées peuvent s’exécuter sans supervision
- Par exemple, chaque nuit, un cron GitHub Actions peut corriger exactement un antipattern, une violation de lint ou une prop inutilement optionnelle, le committer et ouvrir une petite PR
- Les éléments à fort coût d’échec, comme les systèmes d’authentification, les moteurs de paiement ou les contrats d’API publiques, doivent être revus par des humains avec leur connaissance du système et leur jugement
Les boucles qui méritent l’automatisation
- Pour qu’une boucle soit entièrement automatisée, elle doit s’appuyer sur des contrôles peu coûteux, exécutés fréquemment et difficiles à tromper
- Cela inclut des arbitres renvoyant clairement vrai ou faux, des gates de typage, des tests par propriétés et des agents de revue combinés à de véritables grilles d’évaluation
- La décision doit être immédiate et ne pas dériver avec le temps
- On peut automatiser lorsque l’état terminé peut être prouvé par la machine, et pas seulement par un humain
- Les boucles courtes sont plus faciles à valider que les longues
- Selon la règle empirique de Dex, les agents fonctionnent bien sur 3 à 10 étapes, mais commencent à perdre le fil au-delà de 20 étapes
- Plus le contexte s’accumule, plus l’agent risque de sortir du chemin prévu, et les longues boucles cachent les erreurs dans les recoins
- Si le coût d’une mauvaise réponse est élevé et que seul un humain peut la détecter, il faut rallumer la lumière
- Cela concerne les bugs de production subtils que les tests ne détectent pas, les périmètres d’impact larges et les décisions qui influencent plus d’un an de travail
- Dans ces cas, l’attention humaine est le véritable produit et une ressource coûteuse mais indispensable
- Mettre toutes les boucles dans le même mode fait échouer les deux approches
- Tout exploiter dans l’obscurité peut obliger à démonter le système quelques mois plus tard
- Tout exploiter en pleine lumière transforme la revue en énorme goulot d’étranglement
- La compétence clé consiste à décider, pour chaque boucle, à quel endroit allumer la lumière
Graphes et machines à états autour des boucles
- Le travail des agents finira probablement par être structuré en graphe orienté, qu’on l’appelle machine à états finis ou appels de services conditionnels
- Chaque nœud est une étape explicite, et les arêtes entre nœuds sont des conditions explicites
- Tout code peut être représenté comme un graphe de flot de contrôle, donc la structure elle-même n’est pas nouvelle
- L’autonomie de l’agent est limitée à l’intérieur de chaque nœud, et non à l’ensemble du graphe
- La nouveauté a consisté à supprimer l’organigramme et à laisser le modèle choisir son chemin à chaque appel d’outil, puis déclarer lui-même qu’il a terminé
- Après le choc avec de vieilles bases de code, le mouvement visant à reprendre possession du flot de contrôle revient à restaurer des graphes classiques autour des boucles
- Une correction de bug se déroule différemment dans une boucle pure et dans un graphe
- Dans une boucle pure, l’investigation du problème, le changement de code, le choix et l’ordre d’exécution des tests, les nouvelles tentatives et le jugement de complétion sont tous décidés en cours de route
- Dans un graphe, la reproduction du bug ou la demande d’informations supplémentaires, l’identification de la cause, la correction, les tests et la revue sont définis à l’avance comme un parcours
- Un échec de test ramène à l’étape de correction ; un succès mène à la revue, et le travail n’est terminé que s’il est approuvé
- L’agent agit intelligemment dans chaque nœud, mais ne peut pas s’écarter vers des chemins non autorisés
- Le graphe est une forme de visualisation de la back pressure
- En renonçant à une partie de la liberté de l’agent, on obtient des contrôles indispensables et des points d’échec lisibles
- En cas d’échec d’une exécution, on peut identifier le nœud qui l’a arrêtée
- Comme dans l’approche des 12-factor agents, beaucoup de systèmes d’agents ressemblent à « du code majoritairement déterministe dans lequel on mélange des étapes LLM aux bons endroits »
- Le même schéma apparaît aussi dans LangGraph et LlamaIndex Workflows, dans les graphes de workflows hybrides au-dessus des agents de Jerry Liu, ainsi que dans les machines à états et le modèle d’acteurs reliés par David Khourshid
- Ici, le graphe ne désigne pas un graphe de connaissances, mais un graphe orienté qui définit à l’avance le flux de travail et les arêtes conditionnelles
Les humains possèdent la boucle externe
- Les humains ne disparaissent pas de l’usine : ils quittent la ligne d’exécution pour passer dans la boucle externe
- L’agent exécute la boucle interne : enquêter sur le bug, rédiger le diagnostic, implémenter le correctif, lancer les tests et rapporter les résultats
- L’ingénieur juge si le problème est résolu de la bonne manière, valide le diagnostic et l’implémentation, approuve le changement et assume la responsabilité des mauvais résultats
- À la frontière entre boucle interne et boucle externe se trouvent des preuves : diff, tests, logs, et un bref commentaire qui les relie
- Avec des types, des points de test et des grilles d’évaluation, on peut superviser l’exécution des agents sans beaucoup de travail manuel à chaque changement
- La place de l’ingénieur se déplace de l’écriture directe de changements sur la ligne de production vers la conception de cette ligne et la surveillance des gates
- Les modèles et les harnais peuvent s’améliorer, mais il restera difficile d’automatiser le jugement humain qui identifie les problèmes coûteux à long terme
- Le plus dangereux est de rendre tout l’espace de travail sombre au point que les humains ne puissent plus voir ce qui se passe, ni même trouver l’interrupteur
Aucun commentaire pour le moment.