Mastra lance Factory en version bêta, un environnement open source qui inscrit les agents de développement dans une chaîne de livraison structurée plutôt que dans une simple session de terminal. Le produit relie l’arrivée des demandes, leur qualification, la planification, l’implémentation et la revue des modifications, avec un choix explicite entre automatisation et intervention humaine à chaque étape.
Le point le plus instructif vient du retour d’expérience de Mastra lui-même. L’équipe explique avoir commencé par un fonctionnement beaucoup plus automatique, puis avoir ajouté des points de contrôle après avoir constaté que les erreurs commises en amont et les arrivées massives de tâches produisaient du travail difficile à absorber en aval.
Une chaîne de développement découpée en décisions explicites
Factory organise le travail en étapes telles que Intake, Triage, Planning, Build, Review et Done. Chaque élément dispose de sa propre session d’agent, avec espace de travail, fichiers, activité des outils et conversation. Les demandes peuvent provenir de GitHub ou de Linear, puis avancer jusqu’à l’implémentation et à une demande de fusion à relire.
Chaque étape peut fonctionner en mode manuel ou automatique. Cette souplesse n’est pas seulement une option de configuration. Mastra indique avoir testé au départ un flux entièrement automatique. L’import de lots de demandes a alors créé des pointes de charge, des problèmes d’infrastructure et beaucoup de résultats difficiles à relire. L’entreprise cite aussi des cas où une alerte erronée ou une mauvaise conclusion lors de la qualification initiale a entraîné les agents suivants dans une mauvaise direction.
Les chiffres internes ne sont pas un benchmark indépendant
Mastra affirme que, depuis le déploiement interne de Factory en version alpha en juillet, le système automatise 25 à 35 % de ses demandes de fusion et ferme 50 à 60 % de ses tickets. Le même billet montre cependant des graphiques agrégés portant sur 1 627 demandes fusionnées, dont 277, soit 17 %, sont attribuées à Factory, et sur 778 tickets fermés, dont 222, soit 28,5 %, le sont par Factory.
Open source ne signifie pas fonctionnement autonome par défaut
Le modèle de projet Factory est publié sous licence Apache-2.0 et le serveur peut être exploité comme un service Node.js persistant, sur une machine virtuelle ou dans un conteneur. Le dépôt prévoit aussi une base PostgreSQL locale et l’exécution locale des commandes.
En revanche, une nouvelle installation utilise par défaut la plateforme Mastra pour l’authentification, le stockage et les environnements isolés d’exécution. Ces composants peuvent être configurés séparément, y compris avec une exécution locale et d’autres solutions de stockage ou d’authentification.
Le véritable goulot d’étranglement devient la maîtrise du passage d’une étape à l’autre
Le lancement de Factory apporte surtout un exemple concret de ce qui se produit lorsque la production de code cesse d’être la ressource rare. Si un agent peut analyser, planifier, modifier le dépôt et préparer des demandes de fusion en continu, la question devient celle de la confiance accordée à chaque transition.
Les points de contrôle configurables de Factory répondent directement à ce problème. Ils permettent de donner des degrés d’autonomie différents selon la nature du travail, au lieu de réduire l’usage d’un agent à un choix binaire entre manuel et automatique.
Pour un responsable d’ingénierie, le bon critère d’évaluation n’est donc pas seulement le nombre de tickets que le système sait fermer. Il faut surtout vérifier si une hypothèse erronée peut être arrêtée au plus près de son origine, avant qu’elle ne se transforme en plan, en code puis en charge de revue.
Factory reste une bêta et ses chiffres de productivité sont déclaratifs. Le retour d’expérience publié est néanmoins utile: lorsqu’on augmente le débit des agents, des limites d’autorité explicites, une exécution contenue et des passages de relais observables deviennent plus importants, pas moins.