Non, ce n'est pas une usine logicielle — Ryan Cooke, WorkOS
Original · No, That's Not a Software Factory — Ryan Cooke, WorkOS
Key Takeaway
L'automatisation du développement logiciel par l'IA doit mesurer l'accélération de la livraison de valeur produit plutôt que la simple quantité de code généré, en intégrant les processus d'ingénierie et un contexte permanent via une passerelle MCP.
Highlights
Les métriques axées uniquement sur le volume ou le pourcentage de pull requests générées par IA risquent de masquer l'efficacité réelle des équipes d'ingénierie.
L'architecture d'usine logicielle de WorkOS s'appuie sur deux piliers : TARS pour l'intégration des flux de travail (Slack, Linear, GitHub) et Horizon pour l'orchestration de l'infrastructure.
L'utilisation d'un serveur et passerelle MCP interne connecte les agents IA aux bases de données comme Snowflake et uniformise la gestion du contexte applicatif.
L'automatisation complète de la création de documents de spécification (Hilltops) et de tickets Linear élimine le problème de la page blanche pour les développeurs.
La création d'une infrastructure propre de bac à sable en nuage permet de conserver un historique permanent des sessions pour améliorer continuellement les agents IA.
Timeline
Limites des métriques de production de code
L'engouement autour des usines logicielles pousse de nombreuses entreprises à publier des indicateurs basés uniquement sur la quantité de code poussée en production. Ces chiffres ne garantissent pas un gain d'efficacité ou une création de valeur concrète. L'attention doit se porter sur la vitesse d'expédition des fonctionnalités et la résolution de problèmes complexes.
- Mesurer la réussite d'une usine logicielle au volume de pull requests générées masque l'impact réel sur la livraison.
- L'objectif principal d'une usine logicielle consiste à doter chaque ingénieur des capacités d'une équipe complète.
Architecture de l'usine logicielle chez WorkOS
L'exécution d'un simple agent de codage dans un bac à sable Cloudflare n'apporte aucun gain mesurable par rapport à des assistants de code locaux. Pour dépasser ce stade, WorkOS sépare son architecture en deux composants principaux. TARS écoute les événements de plateformes comme GitHub ou Linear, pendant qu'Horizon gère l'infrastructure en amont d'un serveur MCP.
- Un bac à sable de code isolé ne produit pas de résultats supérieurs à l'utilisation d'outils IA locaux.
- Le système TARS gère l'interaction et les webhooks, tandis qu'Horizon orchestre l'infrastructure via MCP.
Autonomie et gestion du cycle de vie produit
En intégrant les webhooks des outils de gestion de projet, l'agent prend en charge le travail produit au-delà de l'écriture de code. Il évalue continuellement les dépendances entre tickets pour repérer les éléments manquants au cours du développement. L'agent PM génère un document de cadrage incluant analyses concurrentielles et maquettes, permettant aux ingénieurs d'intervenir directement sur une base existante.
- TARS enchaîne l'exécution des tickets dépendants dans Linear dès la réception d'un webhook de validation.
- Un agent dédié nommé PM rédige les premiers brouillons de spécifications produit (documents Hilltop).
Application pratique et intégration des outils
Le lancement d'un projet via Slack entraîne la création automatique de journaux de décision, de projets Linear et de brouillons de documentation dans Notion. L'ingénieur affine ensuite les détails imprécis avant de relancer l'exécution. Les informations structurées restent accessibles aux agents tiers ou aux modèles exécutés localement grâce aux protocoles standardisés.
- Une simple commande Slack suffit pour amorcer l'ensemble des ressources d'un nouveau projet.
- La documentation générée alimente aussi bien des agents externes comme Devin que des environnements locaux.
Rôle central du moteur de contexte MCP
Le moteur de contexte interne fournit aux agents les consignes de navigation et la structure des données de l'entreprise. En exposant les tables Snowflake relatives à l'utilisation des produits ou au support client, l'agent sait quelles requêtes exécuter pour répondre aux besoins. Cet outil initialement conçu pour le code est désormais utilisé par les équipes internes pour l'analyse de données.
- La passerelle MCP relie les agents IA aux tables sémantiques stockées dans Snowflake.
- Ce serveur de contexte s'est étendu à des requêtes d'analyse de données effectuées directement depuis Slack.
Auto-amélioration et souveraineté de l'infrastructure
L'automatisation s'étend au traitement des tickets de support client et à la résolution initiale des anomalies. Le développement d'une infrastructure propre de bac à sable garantit un contrôle complet sur la mémoire des sessions et la répartition des charges. Ces données d'utilisation permettent de détecter les lacunes des agents, de mettre à jour leurs compétences obsolètes et d'optimiser l'usine logicielle en continu.
- TARS effectue le premier tri des bugs et des demandes de support directement dans les canaux Slack.
- Posséder l'infrastructure de bac à sable permet de conserver la mémoire des sessions et d'affiner les compétences des agents.
Description
The standard software factory puts an agent in a sandbox, prompts it and merges the PR. When WorkOS built one, the results were hard to tell apart from engineers running Claude Code on their laptops. Ryan Cooke, an engineer at WorkOS, argues that counting PRs or lines of AI code is the wrong measure. What matters is outcomes: are you actually shipping more to customers? WorkOS's answer is to build its engineering process into the factory itself. TARS, its agent, lives in Slack, Linear and GitHub and uses webhooks to track projects and pick up the next ticket on its own. A PM agent drafts the "Hilltop" product doc and breaks approved work into tickets, which solves the blank-page problem. Horizon, the orchestration layer, sits in front of an internal MCP gateway that connects every tool, including Snowflake. Cooke calls that gateway the single best investment for any team starting a factory. He also covers bug and support triage, why WorkOS is building its own sandboxes and a company-wide memory layer, and how it measures success with defect rates, recovery time and adoption. Related links: WorkOS: https://workos.com Timestamps: 0:00 Intro: the standard software factory 1:17 Output metrics hide what's working 2:37 Measuring outcomes instead 3:12 Why a basic sandbox wasn't enough 4:07 TARS and Horizon 5:22 Webhooks: from code work to product work 6:32 Building the Hilltop doc into the factory 8:07 The PM agent 8:52 Demo: kicking off a project from Slack 10:17 Solving the blank-page problem 11:02 Works with Devin and Claude Code too 11:57 The MCP gateway: a context engine 13:37 Why every factory needs an MCP gateway 14:07 Bugs, support triage and our own sandboxes 15:27 Next: a company-wide memory layer 15:57 How we measure success 17:02 Owning the infrastructure to self-improve 18:02 Wrap-up