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

• 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
• 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

À lire ensuite

• Principles : nos convictions sur le développement logiciel avec des agents
  • Le logiciel grandit selon une structure graine → harness de validation → boucle de feedback, dans laquelle les tokens servent de carburant
  • Tout logiciel a besoin d’une graine initiale : autrefois un PRD ou une spécification, aujourd’hui quelques phrases, une capture d’écran ou une codebase existante peuvent suffire
  • Le harness de validation doit être de bout en bout et se rapprocher autant que possible de l’environnement réel (clients, intégrations, économie)
  • Une boucle fermée qui réinjecte les échantillons de sortie en entrée comme feedback permet au système de s’auto-corriger et d’accumuler sa justesse de manière composée
  • La théorie de la validation et du feedback est facile à comprendre, mais la pratique exige une ingénierie créative et de pointe : trouver comment convertir chaque obstacle dans une représentation compréhensible par le modèle
• Techniques : des motifs récurrents pour appliquer ces principes
  • Digital Twin Universe (DTU)
    • Réplique les comportements observables de l’extérieur des dépendances tierces importantes
    • Valide à des volumes et à une vitesse bien supérieurs aux limites de la production
    • Fournit des conditions de test déterministes et reproductibles
  • Gene Transfusion
    • Ancre les agents dans des exemples concrets pour transférer des patterns de fonctionnement d’une codebase à l’autre
    • Une solution associée à une bonne référence peut être reproduite dans un nouveau contexte
  • Filesystem
    • Permet au modèle d’explorer rapidement le dépôt et d’ajuster son propre contexte en lisant et écrivant des fichiers
    • Les répertoires, index et états on-disk servent de base mémoire pratique
  • Shift Work
    • Sépare le travail conversationnel du travail entièrement spécifié
    • Quand l’intention est complète (spécification, tests, application existante), l’agent peut exécuter la tâche de bout en bout sans aller-retour
  • Semport
    • Portage automatisé avec compréhension sémantique, ponctuel ou continu
    • Déplace du code entre langages ou frameworks tout en préservant l’intention
  • Pyramid Summaries
    • Des résumés réversibles à plusieurs niveaux de zoom
    • Compression du contexte sans perdre la capacité de revenir à l’ensemble des détails
• Products : les outils que nous utilisons chaque jour et que nous pensons utiles à d’autres
  • CXDB est un magasin de contexte self-hosted pour agents IA, avec Turn DAG, déduplication de blobs, typage dynamique et débogage visuel
  • StrongDM ID est un système d’identité pour humains, workloads et agents IA, prenant en charge l’authentification fédérée et le partage à portée de chemin
  • Attractor est un agent de coding non conversationnel structuré en graphe de phases, pour une exécution de bout en bout lorsque la tâche est entièrement spécifiée