Une usine logicielle utilise des boucles à grande échelle. Vous pouvez exécuter la boucle avec des humains dedans (usine claire) : échanger jugement et concentration contre vitesse et casse. Ou vous pouvez ignorer les humains (usine sombre) et laisser ces agents définir, construire et livrer du code, sans que personne ne lise vraiment les détails. Mais si les gens arrêtent de lire, ils cesseront de comprendre votre logiciel. Votre tâche la plus difficile est maintenant de savoir quels contrôles mettre en place et combien d'autonomie déléguer.
Cette idée d'usine logicielle est un terme qui remonte à l'article de Bob Bemer, "The economics of program production" présenté en 1968. Pendant un demi-siècle, beaucoup ont rêvé d'un monde où le logiciel serait un processus de production reproductible et instrumenté (analogue à l'emboutissage de pièces automobiles dans une usine) plutôt que l'artisanat isolé d'individus. Historiquement, ce rêve a généralement (mais pas universellement) échoué, en partie à cause de la difficulté d'emboutir des idées.
Mais au cours des deux dernières années, les choses ont suffisamment changé pour qu'il soit logique de jeter un nouveau regard sur ce vieux rêve. Et comme certaines subtilités peuvent facilement être négligées, il vaut la peine d'être un peu précis sur ce qui est vraiment nouveau et différent, et sur ce qui pourrait être des pièges récurrents, déguisés en nouvelles opportunités.
@dexhorthy, co-fondateur de HumanLayer, a récemment donné une excellente conférence à l'AI Engineer World's Fair intitulée "Harness Engineering is not Enough: Why Software Factories Fail." qui vaut le détour sur ce sujet.
La boucle est l'atome. L'usine est la boucle à grande échelle.
La structure est primordiale, et tout commence par de petites unités. L'ensemble de la pile repose vraiment sur trois concepts superposés : la boucle, le harnais et l'usine.
Une boucle est un agent effectuant une seule tâche en répétition : rassembler le contexte, agir, vérifier le résultat, et recommencer jusqu'à ce qu'une condition soit remplie. C'est la plus petite unité de travail agentique, et tout ce qui est au-dessus n'est que des boucles empilées sur des boucles.
L'intérêt de l'ingénierie des boucles est que vous arrêtez de guider l'agent tour par tour et concevez à la place le petit système qui le guide pour vous.
Un harnais est les murs autour d'une boucle : le bac à sable dans lequel elle s'exécute, les outils auxquels elle peut accéder, la mémoire qui persiste entre les exécutions, et les portes qui décident ce que "fini" signifie. La boucle est le comportement ; le harnais est l'environnement dans lequel ce comportement s'exécute.
Donnez un modèle brut sans harnais et il tournera joyeusement pour toujours. Le harnais est tout ce qui l'entoure et le rend utile et sûr à exécuter.
Une usine logicielle est composée de nombreuses boucles harnachées fonctionnant en même temps, alimentées par une file d'attente de travail et drainées via une porte de révision vers la production, avec des humains qui supervisent le tout. Ce n'est pas un plus gros agent ; c'est un organigramme fait de boucles.
Le changement de paradigme final consiste à passer de l'écriture de code à la construction et à l'exploitation de l'usine qui l'écrit. L'unité de travail monte d'un niveau, vers la boucle, le harnais et le flux entre eux, plutôt que vers la simple modification de code individuelle.
Boucle → harnais → usine. Une usine n'est pas un agent plus intelligent ; c'est plusieurs boucles harnachées alimentant une seule porte de révision, avec un humain supervisant la boucle externe. L'usine, dessinée
La diapositive centrale sur laquelle Dex a passé le plus de temps était brillante car c'est un schéma de câblage clarifiant qui visualise ce qui autrement est une boucle évidente. Voici mon interprétation :
L'usine est une boucle fermée : l'intention et les signaux de production alimentent une file d'attente, le harnais construit, les contrôles automatisés et la porte de révision la valident, le déploiement expédie, la surveillance transforme la production en signaux. L'intention provient de la vision de la direction technique, et directement des ingénieurs, dans une file d'attente de choses à faire. Les signaux générés par les incidents et les demandes des utilisateurs alimentent la même file d'attente.
Le harnais est simplement la chose qui sélectionne un élément de la file d'attente et construit une modification pour celui-ci. Au-delà du harnais, nous pouvons voir tous les contrôles automatisés nécessaires pour rendre les modifications suffisamment sûres pour être mises en production. Ces contrôles automatisés s'exécutent en même temps, sans effort, sans aucune implication consciente des ingénieurs, grâce à l'intégration continue, aux tests, à l'analyse statique et à l'analyse de toutes sortes. Le seul point de décision ici est la porte de révision. Après approbation, les modifications sont déployées et surveillées en production, les données de surveillance alimentant en retour les signaux qui ont déclenché la boucle au départ.
Dans l'ensemble, chaque boîte de ce diagramme est presque à coût nul : génération, tests, analyse. Ils fonctionnent tous à grande échelle pour un coût négligeable. Il n'y a qu'une seule boîte coûteuse qui se révèle obstinément résistante à la mise à l'échelle, et c'est la porte de révision. Cette boîte ambrée brillante est le "jugement", et c'est là que réside le cœur du débat sur la possibilité d'accélérer et de rendre plus fréquent le développement.
Pourquoi nous l'appelons "sombre"
Une usine sombre fonctionne avec les lumières physiquement éteintes, car les seules choses sur le sol sont des machines et les machines n'ont pas besoin de lumière pour voir. Une usine logicielle sombre fait la même chose : le code est livré sans qu'aucun humain ne l'ait lu, vérifié uniquement par d'autres machines.
L'image est empruntée à la fabrication. Ses origines sont physiques plutôt que numériques, ancrées dans des installations où les lumières sont éteintes et le travail effectué par des robots. FANUC au Japon fait fonctionner des usines sans personnel de ce type depuis 2001 ; Xiaomi, en 2024, a ouvert sa propre usine sombre fortement automatisée. Ce qu'elles ont en commun, c'est un produit assemblé et expédié sans qu'un seul humain n'en ait lu une partie. Le "sombre" apparaît lorsque cet acte de lecture est retiré du processus.
Je n'emprunte pas le concept pour son ambiance ou comme une insulte. Malgré tout son côté inquiétant, "sombre" est ici une simple affirmation physique : le sol d'usine d'origine, mais sans lumière. Dans le logiciel, le sol est la différence. Qui que soit celui qui a écrit la différence, qui l'a révisée, qui l'a livrée, ces humains ont disparu, et ce qui reste est une différence vérifiée uniquement par les machines qui l'ont construite.
C'est une chose étonnamment facile à faire, du moins au début. C'est facile parce que cette étape de révision manquante entrave tout. Son absence donne l'impression que le débit vertical de votre équipe est soudainement et radicalement plus élevé. On a l'impression d'avoir franchi le mur du son. Malgré toute sa facilité apparente, il est plus difficile qu'il n'y paraît de survivre à ces flux de travail sombres, avec tous leurs coûts cachés.
L'ingénierie du harnais ne suffit pas
Le harnais d'orchestration, de prototypage en bac à sable et d'appel d'outils, à mesure que les modèles interagissent avec le monde et entre eux, deviendra de plus en plus puissant et efficace. Cependant, il existe une défaillance inhérente au modèle lui-même lorsqu'il s'agit de maintenir la qualité de la base de code sur le long terme et à travers des changements additifs, et je pense qu'il y a de bonnes raisons de croire que les modèles seuls perdront finalement cette bataille contre la dette de compréhension.
La dette de compréhension est l'écart croissant entre la quantité de code qui existe et la quantité qu'un humain comprend encore. Une usine sombre ne la rembourse pas ; elle l'accumule aussi vite que possible, les tests restant verts tout du long.
C'est une distinction importante car les modèles réussissent bien certaines tâches. Mais pour tout ce qui n'est pas un changement immédiat dans une petite partie d'une base de code, en particulier dans un système brownfield complexe, le codage automatisé par modèle seul se heurte à un obstacle insurmontable. Les applications greenfield, les projets du week-end et les projets secondaires sont similaires en ce sens que quelques mois de cycles de développement suffisent généralement pour que les choses fonctionnent, ou du moins s'en approchent.
Mais un système d'entreprise qui est en développement depuis une décennie ou plus est un animal différent ; il doit être maintenu, dans un environnement professionnel et à un rythme professionnel. Trois à six mois après le début d'un projet, vous êtes déjà submergé par du code non lu. Ce type d'environnement, et surtout les contraintes imposées par le code de production, ferait même échouer un agent puissant, le tout contrastant avec le codage "vibe" dont jouissent les développeurs travaillant sur des projets du week-end.
Dex rapporte d'expérience que c'est un échec majeur, à tel point qu'il a nécessité un débogage manuel minutieux pour l'identifier. Cela provenait de l'exploitation d'une usine de code entièrement automatisée pendant environ quatre mois, pendant lesquels aucun humain n'a regardé le code qui était écrit. Sous-jacente à cette expérience se trouve un compromis entre deux métriques contradictoires. L'une est la maximisation de l'utilisation des tokens, le nombre que nous traitons actuellement comme un progrès. L'autre, qu'elle minimise silencieusement, est la quantité du système qu'un participant humain comprend encore à un moment donné.
Là où l'usine sombre brille vraiment, c'est dans sa capacité à brûler du code vierge pendant que les tests restent verts. Le règlement de comptes ultime, quand il arrivera, ne sera pas un moment dramatique de "tout va de travers". Ce sera silencieux et tardif.
Sombre et clair sont le même pipeline avec les lumières à différents endroits. La version claire ne se contente pas d'ajouter une révision à la fin - elle déplace également le jugement humain en amont, vers la conception et l'architecture. Le goulot d'étranglement n'a jamais été la génération
La contrainte fondamentale dans une usine logicielle n'est pas la quantité de code que nous pouvons produire : c'est la rapidité avec laquelle nous pouvons le vérifier.
La contre-pression est la règle selon laquelle vous ne pouvez accorder à une boucle qu'autant d'autonomie que vous pouvez vérifier à moindre coût et de manière fiable, et pas un pouce de plus. La vérification, et non la génération, est la véritable contrainte d'une usine.
Parce que la capacité de génération illimitée est en tension perpétuelle avec la ressource finie et non extensible de l'attention humaine, le problème central est l'écart entre la génération bon marché et la révision limitée. Regardez l'entonnoir : tant que le goulot d'étranglement représentant la vérification ne s'élargit pas, il va s'accumuler. Comme le souligne Dex, le volume seul n'est pas le problème : ce dont nous souffrons vraiment, c'est d'un surplus de mauvaises PR. Lorsque vous avez un volume élevé sans portes fiables, les défauts de fabrication sont inévitables. C'est encore une fois la contre-pression : l'autonomie ne peut pas s'étendre au-delà de ce qui peut être vérifié à moindre coût et de manière fiable.
Le problème de second ordre est de savoir pourquoi l'amélioration du modèle ne devrait pas automatiquement combler l'écart entre ce qu'il peut générer et ce qui peut être vérifié. L'entraînement sur des systèmes bien architecturés est une proposition sans doute plus difficile que de réussir des tests simples : rappelez-vous, les fonctions de coût mesurant l'excellence architecturale ne se mesurent pas en secondes ou même en minutes, mais en mois et en années. Des gradients clairs sont fonctionnellement impossibles à calculer, donc un système qui s'attend à une évaluation nette et instantanée de décisions de conception complexes ne sera pas entraîné sur de bons exemples.
La génération est une bouche large ; la vérification est le goulot d'étranglement étroit. Accélérer la bouche ne fait qu'approfondir la pile au goulot.
Rallumer les lumières
Une usine claire est le même pipeline avec les lumières allumées là où se trouve le jugement. Les agents font toujours la plupart du travail de construction, mais un humain lit ce qui sort avant qu'il ne soit livré, et les lumières restent allumées partout où une erreur coûte cher.
La version claire n'ajoute pas une révision à la fin, mais déplace le point de jugement humain en amont, vers le produit, la conception et l'architecture avant qu'un agent ne commence une boucle.
Un grand avantage de cette heure initiale est qu'elle conduit à moins d'heures de mise en œuvre. Elle transforme une longue et frustrante révision de code en une lecture rapide d'un plan de deux cents lignes. Vous révisez une décision avant qu'elle ne soit construite, donc plus tard vous ne passez pas votre temps à fouiller dans deux mille lignes de code généré pour découvrir quelle était même la décision. Certaines décisions sont suffisamment coûteuses et durables pour que vous souhaitiez qu'une personne soit impliquée tôt, avant que le coût ne se cumule. Bien sûr, il y a encore des moments où vous regardez les différences, même lorsque vous avez passé du temps au préalable.
Vous pourriez penser que tout cela semble peu glamour. Vous avez raison. Le filet de sécurité est composé de pratiques architecturales parfaitement ordinaires que nous avons toujours connues et que nous avons surtout ignorées : de bons types et signatures de méthodes pour que les erreurs soient attrapées par le compilateur plutôt qu'en production ; des points de test où nous pouvons fixer le comportement et rendre le changement observable ; organiser le code pour que le prochain lecteur, humain ou modèle, sache où trouver ce qui l'intéresse ; garder les piles d'appels courtes et lisibles ; garder les limites des composants bien définies pour qu'un changement n'ait pas un rayon d'explosion énorme ; et l'injection de dépendances pour que nous puissions remplacer une pièce par une autre. Rien de tout cela n'est nouveau. Nous avons toujours dit que nous nous soucions de la bonne architecture. Mais maintenant que nous utilisons des agents de codage automatisés, cette architecture fait enfin un deuxième travail en tant que filet de sécurité bon marché et difficile à truquer contre les erreurs que l'agent commettra.
Ce filet de sécurité doit vivre en dehors du modèle, car le modèle ne le fournira pas. Les agents de codage qui semblent les plus capables, Claude Code et Codex parmi eux, sont entraînés par renforcement contre leur propre harnais et outils : ils sont à l'aise avec tous les outils et idiomes du métier, mais pas avec des choses comme la maintenabilité à long terme. L'architecture délibérée dont nous avons toujours parlé est l'outil qui attrape cette dette, et l'investissement que nous y faisons est notre façon de racheter notre autonomie.
Combinez cela avec une infrastructure sûre, et vous avez des boucles serrées à faible risque que vous pouvez exécuter sans surveillance. Horthy en a décrit une dans un récent article : un cron GitHub Actions nocturne qui corrige exactement un anti-modèle, une violation de lint ou une propriété inutilement optionnelle, effectue un commit et ouvre une petite pull request, tout seul, afin que l'équipe se réveille avec une base de code légèrement meilleure et une différence suffisamment courte pour être lue. Mais pour les boucles avec des enjeux suffisamment élevés, vous ne voulez pas risquer de vous réveiller avec un système d'authentification cassé, un moteur de facturation ou un contrat d'API publique cassé. Gardez les lumières allumées là, et faites confiance à une personne ayant du jugement et une réelle connaissance pratique du système pour attraper l'erreur.
Ce qui permet à une boucle de devenir sombre
Cette règle s'applique que vous l'appeliez contre-pression, vérification ou interrupteur.
Une boucle ne peut obtenir le statut entièrement automatisé que si la vérification est bon marché, s'exécute à haute fréquence et repose sur quelque chose qui ne peut pas être facilement truqué. Les oracles vert-ou-rouge, les portes de type, les tests de propriété et un agent de révision couplé à une véritable grille d'évaluation entrent tous dans cette catégorie. Vous avez également besoin que l'oracle réponde immédiatement et ne dérive pas dans le temps. Lorsque "fini" peut être prouvé non seulement par vous mais aussi par une machine, vous avez atteint l'automatisation.
Les boucles courtes sont plus faciles à vérifier que les longues. La règle empirique de Dex : un agent tient bon pendant trois à dix étapes, puis commence à perdre le fil après vingt. La raison est l'accumulation de contexte : plus l'agent en traîne, plus il est susceptible de s'égarer. Lorsqu'une boucle est courte, la vérifier est bon marché. Les boucles tentaculaires cachent les erreurs dans les coins, ce qui est une autre façon de dire qu'elles n'ont jamais mérité le statut de fonctionnement sans surveillance.
Garder les lumières allumées est le cas inverse. Une boucle doit être révisée si une mauvaise réponse est coûteuse et que seule une personne peut l'attraper. Les bugs de production subtils qui ne peuvent pas être attrapés par les tests, les grands rayons d'explosion et une décision qui va façonner le travail d'un an ou plus entrent tous dans cette catégorie. Dans ces cas, votre attention est le véritable produit, le coûteux, l'essentiel.
Le danger est d'oublier de basculer chaque interrupteur et de simplement tous les mettre sur le même mode. Tout sombre, et vous êtes coincé à tout démonter quatre mois plus tard. Tout clair, et personne ne peut terminer les révisions à temps et vous êtes coincé dans un énorme goulot d'étranglement. Le travail difficile et qualifié est de décider où placer chaque interrupteur.
Boucles, graphes ou machines à états ?
Vous devriez lire "State machines in 2 minutes" par @DavidKPiano
Lorsque vous confiez une tâche à un agent, vous allez probablement construire un graphe autour d'elle, que vous appeliez ce graphe une machine à états finis ou un ensemble d'appels de service conditionnellement liés. C'est un cadre où le logiciel ne suit pas seulement des règles abstraites, mais un flux de travail structuré : chaque nœud est une étape explicite, et chaque arête entre les nœuds est une condition explicite.
Cela semble beaucoup de structure, mais la majeure partie est déjà présente dans tout logiciel, puisque tout code peut être exprimé sous forme de graphe de flot de contrôle. Donc la seule véritable nouveauté est qu'un agent insistant sur l'autonomie ne fait en réalité que se promener autour d'un graphe particulier, et sa liberté est contrainte à l'intérieur d'un nœud. Et voici la partie que les gens oublient, que Dex a écrite il y a un an : le logiciel a toujours eu cette structure. Il y a une raison pour laquelle nous avions l'habitude de dessiner les programmes sous forme d'organigrammes.
La véritable nouveauté a été d'essayer de jeter le diagramme, en s'appuyant sur une boucle où le modèle choisit le chemin, appel d'outil après appel d'outil, jusqu'à ce qu'il se déclare terminé. Cela ressemblait à une libération, jusqu'à ce que cela rencontre une base de code de dix ans, et la discipline que tout le monde redécouvre maintenant, posséder son propre flot de contrôle, revient en fait à ramener le graphe autour de la boucle. Donc, la question de savoir si nous devrions passer des boucles aux graphes est presque un aveu que nous avions besoin de l'organigramme depuis le début.
Voici à quoi cela ressemble en pratique. Prenons un bug à corriger. En tant que boucle pure, vous vous asseyez et pensez : comprendre ce qui ne va pas, modifier du code, exécuter les tests, voir ce qui se passe, et si ce tour ne tue pas l'exécution, revenir en arrière et recommencer. L'ensemble du voyage est décidé au fur et à mesure : quel problème vous poursuivez, le code exact que vous modifiez, les tests que vous exécutez et dans quel ordre, si vous exécutez même des tests, et si vous réessayez ou déclarez victoire.
En tant que graphe, la première chose que vous faites est de cartographier ce qui devrait se passer. Reproduire le bug ou aller demander plus d'informations, trouver la cause, essayer un correctif, exécuter les tests, et laisser une exécution échouée revenir au correctif tandis qu'une exécution réussie passe à la révision, où seule une approbation atteint l'état "fini". L'agent est toujours intelligent à l'intérieur de chaque boîte ; il ne peut tout simplement pas s'éloigner des chemins que vous avez autorisés. Santi a présenté cela avec un diagramme qui rend la différence évidente.
L'attrait réel de ce graphe, bien sûr, est qu'il s'agit d'une contre-pression dessinée sous forme de diagramme. Vous abandonnez une partie de la liberté de l'agent et obtenez en retour des vérifications obligatoires et des points de défaillance lisibles, de sorte que lorsqu'une exécution meurt, vous pouvez pointer le nœud qui l'a tuée. C'est le même instinct derrière la ligne directe de Dex selon laquelle la plupart des soi-disant agents ne sont pas du tout très agentiques, "un code pour la plupart déterministe, avec des étapes LLM saupoudrées aux bons endroits." Et ce n'est pas seulement un artefact de la façon dont les gens construisent actuellement les choses : vous pouvez voir le modèle dans LangGraph et LlamaIndex Workflows, dans le graphe de flux de travail hybride sur agent de Jerry Liu avec une boucle externe qui développe des parties du graphe au fur et à mesure de son exécution, et dans le rappel de David Khourshid qu'il s'agit en réalité de machines à états et du modèle d'acteur qui se présentent sous de nouveaux vêtements.
Une clarification, car le terme est terriblement surchargé : quand je continue d'appeler cela un graphe, je ne veux pas dire un graphe de connaissances. Je veux dire un graphe orienté prédéfini de la façon dont le travail devrait circuler, arêtes conditionnelles incluses, donnant à la boucle une forme à laquelle vous pouvez réellement faire confiance.
Où va réellement l'humain
Remarquez que la personne n'a jamais quitté l'usine. Elle a bougé.
Je pense que les ingénieurs doivent de plus en plus posséder la boucle externe. Les agents peuvent enquêter sur un bug, rédiger le diagnostic, implémenter un correctif, exécuter les tests et rédiger un rapport. C'est l'exécution de la boucle interne, et ils peuvent le faire aussi efficacement que n'importe qui. Mais ce n'était jamais le travail. Les parties que vous possédez sont ce que j'appellerais la boucle externe : décider si c'est la bonne façon d'aborder le problème, vérifier que le diagnostic et l'implémentation sont solides, approuver le changement, et porter les conséquences d'une erreur. La frontière entre les deux boucles est la preuve : les différences, les tests, les journaux et une brève explication qui les relie. Les types, les points de test et les grilles d'évaluation permettent de superviser tout cela sans faire beaucoup de travail pour chaque changement.
Il est utile de le formuler ainsi : vous n'êtes plus sur la ligne à écrire des changements ; vous êtes au bout de la ligne de production à la concevoir et à garder la porte. Il y a beaucoup de choses que vous pouvez faire pour améliorer le modèle et rendre le harnais plus capable, mais j'ai observé que l'identification des problèmes coûteux à long terme n'est généralement pas quelque chose que vous pouvez automatiser. La chose fondamentale qui reste le travail est d'exercer le jugement humain mieux que tout flux de papier et de puissance de calcul.
Les robots se débrouillent bien dans l'obscurité, mais les humains ont besoin de voir ce qu'ils font. Si tout sur le sol de l'usine est sombre, et que vous ne pouvez rien voir, et que vous ne pouvez même pas trouver l'interrupteur, c'est là que se trouve le danger.
Pangram a noté cet article comme étant écrit à 100 % par un humain.
