L’avènement de la Software Factory et de l’ère des agents

(factory.strongdm.ai)

13 points par GN⁺ 2026-02-08 | 3 commentaires | Partager sur WhatsApp

L’équipe IA de StrongDM défend le concept de Software Factory, qui permet de produire des logiciels de haute qualité sans même regarder le code
À partir de spécifications et de scénarios, des agents écrivent le code, exécutent le harness de test et convergent sans revue humaine, dans un mode de développement non conversationnel
Le code ne doit ni être écrit ni relu par des humains, et il faut dépenser au moins 1 000 dollars par jour et par ingénieur en tokens pour qu’une Software Factory fonctionne correctement
Depuis la seconde révision de Claude 3.5 (octobre 2024), les workflows de coding agentique de longue durée ont commencé à accumuler la justesse de manière composée, au lieu d’accumuler les erreurs, confirmant la possibilité d’un développement non conversationnel
En élargissant la notion classique de test, l’équipe introduit les concepts de scénario (scenario) et de satisfaction (satisfaction), afin de construire un système où le LLM évalue probabilistiquement la satisfaction utilisateur
Avec le Digital Twin Universe (DTU), l’équipe réplique les principaux SaaS comme Okta, Jira et Slack pour effectuer une validation à grande échelle, avec des volumes et une vitesse supérieurs aux limites de la production
L’ère des agents transforme en profondeur l’économie du logiciel, au point que la construction de clones SaaS haute fidélité, autrefois économiquement impossible, devient désormais une tâche courante

Concept de Software Factory

Un système de développement non conversationnel dans lequel des spécifications (specs) et des scénarios (scenarios) pilotent les agents pour écrire et valider le code
- L’écriture et la revue de code par des humains sont interdites, et l’ensemble du processus de développement est pris en charge par les agents
- L’efficacité est mesurée à l’aune d’une consommation de plus de 1 000 dollars de tokens par jour et par ingénieur
Cette approche vise à construire un environnement autonome de production logicielle où le code est généré, validé et amené à converger automatiquement, sans intervention humaine

Lancement de l’équipe IA de StrongDM

Le 14 juillet 2025, l’équipe IA de StrongDM a été constituée pour lancer des expérimentations en développement non conversationnel
- Participants : Jay Taylor, Navan Chauhan, Justin McCarthy (cofondateur et CTO)
Depuis fin 2024, après Claude 3.5 (révision d’octobre), la précision du code produit sur de longues durées s’est améliorée, rendant possible une accumulation de justesse (compounding correctness) au lieu d’une accumulation itérative d’erreurs
Le mode YOLO de Cursor a clairement mis en évidence les capacités du modèle pour l’écriture de code sur le long terme
Avec les modèles précédents, l’application répétée des LLM aux tâches de développement faisait s’accumuler toutes sortes d’erreurs — incompréhensions, hallucinations, erreurs de syntaxe, violations de DRY entre versions, incompatibilités de bibliothèques — jusqu’à ce que l’application « s’effondre »
La combinaison des modèles mis à jour d’Anthropic et du mode YOLO a révélé une première possibilité de développement non conversationnel ou de logiciel qui grandit

Principe fondamental : ne pas toucher

Dès la première heure du premier jour de l’équipe IA, une charte a été établie, avec comme principe le plus important : « le code ne doit pas être écrit directement par des humains »
Au départ, il s’agissait d’une intuition simple et d’une expérimentation : jusqu’où peut-on aller sans écrire la moindre ligne de code à la main ?
Des limites sont d’abord apparues, puis les progrès ont commencé après l’ajout de tests
Les agents se focalisent sur la tâche immédiate et choisissent des raccourcis : des tests trop étroits peuvent être validés avec un simple return true, sans que cela ne se généralise au logiciel réellement souhaité
De simples tests ne suffisent pas ; il faut étendre le dispositif à des tests d’intégration, de régression, de bout en bout et de comportement

Des tests aux scénarios et à la satisfaction

Thème récurrent de l’ère des agents : il faut un nouveau langage ; le mot « test » est insuffisant et ambigu
Les tests stockés dans la codebase peuvent être réécrits de manière paresseuse pour correspondre au code, ou le code peut être réécrit pour les satisfaire de façon triviale
Le terme scénario est redéfini : il désigne une user story de bout en bout, stockée hors de la codebase (à la manière d’un ensemble de « holdout » pour l’entraînement d’un modèle), que le LLM peut comprendre intuitivement et valider avec souplesse
Comme le logiciel en croissance contient lui-même des composants agentiques, le critère de réussite passe d’une simple valeur booléenne à une satisfaction probabiliste et empirique
- Satisfaction : quantification de la proportion de trajectoires observées ayant passé tous les scénarios et susceptibles de satisfaire l’utilisateur

Validation de scénarios via le Digital Twin Universe

Dans le paradigme précédent, on déterminait si « ça fonctionne ? » à l’aide de tests d’intégration, de régression et d’automatisation UI
Deux limites des techniques auparavant jugées fiables ont été identifiées :
- Les tests sont trop rigides : comme le code est produit par des agents et que les boucles LLM/agent deviennent des primitives de conception, l’évaluation du succès nécessite souvent un LLM-as-judge
- Les tests sont vulnérables au reward hacking : il faut des mécanismes de validation moins exposés à la triche du modèle
Le Digital Twin Universe (DTU) constitue la réponse : des clones comportementaux des services tiers dont dépend le logiciel
- Des jumeaux d’Okta, Jira, Slack, Google Docs, Google Drive et Google Sheets sont construits pour répliquer les API, les edge cases et les comportements observables
- Le DTU permet une validation à des volumes et à une vitesse bien supérieurs aux limites de la production
- Il permet aussi de tester des modes de défaillance risqués ou impossibles à reproduire sur des services en ligne réels
- Des milliers de scénarios par heure peuvent être exécutés sans atteindre les rate limits, déclencher la détection d’abus ni accumuler des coûts d’API

Une économie non conventionnelle

Le succès du DTU montre l’une des multiples façons dont le moment agentique (Agentic Moment) transforme en profondeur l’économie du logiciel
- Créer des clones haute fidélité de grandes applications SaaS a toujours été possible, mais économiquement irréaliste
- Plusieurs générations d’ingénieurs ont rêvé d’une réplique complète en mémoire d’un CRM de test, sans jamais même l’évoquer à leur management, convaincus qu’on leur dirait non
Publicité
Les bâtisseurs de Software Factory doivent pratiquer une naïveté délibérée (deliberate naivete) : identifier puis éliminer les habitudes, conventions et contraintes héritées du Software 1.0
- Avec le DTU, ce qui était inimaginable il y a six mois est désormais routinisé comme un travail quotidien

3 commentaires

pencil6962 2026-02-08

J’ai essayé le développement piloté par les spécifications avec des agents multiples. Il est vrai que cela réduit fortement la charge de travail, mais à cause des limites de performance des LLM, on ne peut pas créer un produit qui satisfasse le client. Un remplacement à 100 % est impossible, et une certaine part de travail humain reste nécessaire.

xguru 2026-02-08

C’est un peu trop provocateur, mais je peux aussi le comprendre dans une certaine mesure… C’est un texte qui laisse une sensation assez étrange.

En lisant cet article puis celui ci-dessous, on se sent encore plus en phase avec ce point de vue.
Nous pleurons notre esprit d’artisanat

GN⁺ 2026-02-08

Avis Hacker News

J’adhère au concept de Digital Twin Universe
Mon codebase intègre aussi beaucoup de services externes, donc quand on bloquait les appels externes pendant les tests, on ne pouvait presque plus rien valider
Du coup, on a créé de fausses implémentations de chaque API, comme pour Okta, Jira, Slack, Google Docs, etc., afin de les tester
En revanche, on n’a pas répliqué l’UI, seulement imité le comportement des API
Dire que « s’il n’y a pas 1 000 $ de tokens dépensés par ingénieur et par jour, il y a une marge d’amélioration » paraît beaucoup trop irréaliste
J’ai du mal à croire que ce soit une affirmation sérieuse
- En faisant le calcul, on arrive à environ 250 k$ par an
  Si l’IA apportait vraiment autant de productivité, cela pourrait être rationnel
  En pratique, on serait plutôt sur l’efficacité de deux ingénieurs juniors
  Au final, les humains finiront sans doute par n’assurer qu’un rôle de lead pour la planification et la validation
  C’est un optimisme exagéré, mais pas complètement délirant
- Moi, je n’utilise que des abonnements Claude et OpenAI à 20 $ par mois
  Quand j’ai épuisé mes tokens, je vais me promener ou je lis un livre
  Je ne suis pas accélérationniste, mais je travaille quand même très bien
- Je fais partie de l’équipe StrongDM
  Dépenser 1 000 $ de tokens par jour est facile, mais le point essentiel, c’est que les dépenser de façon productive est difficile
- Ça ressemble simplement à de la frime
  On dirait une manière de signaler « nous sommes plus avancés que vous en IA »
- En lisant l’article, j’ai ressenti un certain malaise
  On a l’impression qu’ils emballent des mocks et des tests de simulation classiques comme une « innovation »
  Cela dit, je leur reconnais le mérite d’avoir exposé honnêtement leur structure de coûts
Sur leur site, je cherchais du vrai code ou produit
La seule chose que j’ai trouvée, c’est strongdm/attractor
Le « coding avec une petite amie canadienne » est donc devenu un modèle économique
J’ai aussi trouvé strongdm/cxdb, mais son historique de commits avait été nettoyé
- Il y a du vrai code dans le dépôt cxdb
- Je ne sais pas si c’est de la folie ou un aperçu du futur
- La page Products contient aussi une base de données et un système d’identité
  Pour que plusieurs agents collaborent, un contexte partagé et un système de permissions sont indispensables
- J’ai suivi un webinaire sur le BAML de BoundaryML
  Le spec-driven development est une approche qui crée des workflows structurés avec l’humain dans la boucle
  Elle définit clairement une boucle /research → /plan → /implement, avec une validation humaine à chaque étape
  C’est une philosophie à l’opposé de l’affirmation de StrongDM selon laquelle « les humains n’écrivent ni ne lisent le code »
- Cela ressemble encore à un article de blog creux
  Il n’y a aucun livrable concret, et cette histoire de 1 000 $/jour de tokens semble surtout destinée à impressionner les investisseurs
Tant qu’on ne résout pas le problème de validation, tout cela ne sera que de la frime
Même avec des revues automatiques ou des garde-fous, il faut au final un humain pour vérifier la concordance entre la spécification et le résultat
- Chez Speedscale, nous automatisons la validation par capture et rejeu du trafic
- En réalité, les développeurs humains ne sont pas parfaits non plus
  Il existe déjà de nombreuses procédures de validation systématiques : code review, tests, QA, etc.
  La vraie question n’est pas de savoir si l’IA est parfaite, mais si la qualité du système dans son ensemble converge
  D’après mon expérience, avec Opus 4.5, il y a un léger effet net positif
- Je suis presque entièrement d’accord
  Le cœur du sujet, c’est la validation plutôt que la génération
  Je construis une structure où plusieurs agents indépendants font émerger leurs désaccords puis convergent vers un consensus
- En clair, cela revient à faire porter aux utilisateurs finaux la validation et les tests de sécurité
- Il faut utiliser davantage les langages basés sur des spécifications et la vérification formelle
  Au bout du compte, la programmation sera redéfinie comme « l’acte de concrétiser une spécification »
À 1 000 $ de tokens par jour, on dépense plus pour l’IA que pour les humains
On dirait un point de rupture de la vision IA
- Simon Willison aurait mis à jour son article
- 240 k$ par an, c’est le niveau d’un ingénieur débutant chez un FANG
  Honnêtement, il y a aussi beaucoup de juniors moins bons que Claude
  On finira probablement par se réorganiser en structure pyramidale avec un petit nombre d’humains au sommet
- Si on peut terminer le même travail en 5 jours, alors le coût rapporté à la vitesse peut être raisonnable
- Si la production augmente de manière proportionnelle, l’efficacité coût/rendement peut tenir la route
  Et le prix des tokens pourrait aussi baisser
Les secteurs du droit et de l’assurance vont être ceux qui souffriront le plus de ce changement
Les erreurs humaines peuvent être modélisées, mais les erreurs en cascade dans des boucles autonomes posent un problème totalement différent
- Dans l’assurance, cela se réglera sans doute assez simplement
  Les décisions de l’IA finiront par relever de la responsabilité humaine
  Ce sera probablement le frein principal de tout le virage agentique
1 000 $ de tokens par jour, c’est un indicateur absurde
Si la qualité du code est mauvaise, la consommation de tokens explose
En fin de compte, c’est un codebase mal entretenu qui fait grimper la facture
Une équipe qui brûle mille dollars par jour n’aura quasiment aucune efficacité
(Voir aussi : ce mème)
- C’est un problème d’optimisation court terme vs long terme
  Il faut choisir entre améliorer l’efficacité immédiate ou améliorer le système dans son ensemble
- Peut-être que, pour une fois, la direction va enfin comprendre l’importance du refactoring
L’équipe dont je parlais autrefois à propos du pattern Dark Factory, c’était justement eux
J’ai écrit un article à ce sujet, et cette équipe est celle des expérimentateurs les plus ambitieux
- Mais en pratique, il n’y a presque aucun résultat concret
  Avec 10 k$ donnés à quelques étudiants, on obtiendrait sans doute quelque chose de meilleur
- 1 000 $ de tokens par jour, ce serait impensable avec le budget de mon équipe
  Même à titre personnel, c’est impossible à cause du coût de la vie
  Au final, on a l’impression d’être dans une situation où « si on le fait, on échoue ; si on ne le fait pas, on échoue aussi »
- Sans résultats vérifiables, ce ne sont que des paroles
  Et maintenant, même les paroles coûtent bien moins cher grâce aux LLM
- Il faudrait une communication éthique
  Le vocabulaire du site se contente de reconditionner des concepts existants
  « Digital Twin Universe », ce sont des mocks ; « Gene Transfusion », c’est lire du code de référence ; « Semport », c’est du transpiling
  Il n’y a absolument aucune donnée ni benchmark réels
  C’est du marketing IA déguisé en insight d’ingénierie
- En réalité, la plupart des morceaux de code essentiels sont déjà sur GitHub
  La vraie différence se joue dans la conception des mécanismes et les valeurs
  L’avenir ira vers une combinaison de méthodes formelles (formal methods) et d’IA
La méthode qui consiste à « garder des scénarios comme holdout set pour les tester » est intéressante
C’est une manière d’imiter les tests offensifs d’une équipe QA
Il est frappant de séparer l’équipe de build et l’équipe de détection de bugs pour créer une structure de concurrence mutuelle
En revanche, 1 000 $ de tokens par jour, pour les développeurs open source, c’est désespérant
- Avec des modèles locaux, on peut réduire les coûts
  Comme dans ce thread, l’automatisation d’agents en local est tout à fait possible
- Un jour, les agents finiront peut-être par se soudoyer entre eux
- Je continue de préférer une approche avec l’humain dans la boucle
  Brûler des tokens sans discernement, c’est du gaspillage
Dans mon article « LLMs aren’t tools », j’explorais le cadre mental d’utilisation des LLM
La « software factory » est le point d’aboutissement actuel, mais l’étape suivante consiste à voir le LLM comme une application
Autrement dit, on passe de la simple automatisation de workflows à la création d’un harnais sur mesure