Spawn utilise des agents autonomes pour livrer du code toutes les heures et considère tout retard comme un incident critique

Une nouvelle plateforme de jeux multijoueurs appelée Spawn est développée presque entièrement par une nuée d'agents IA autonomes. Créé par Jacob Sansbury, le système utilise des modèles de pointe pour lire les erreurs, écrire du code et déployer des modifications en production chaque heure sans intervention humaine.

Ce qui s'est passé

Spawn est un environnement massivement multijoueur où les joueurs interagissent avec un agent intégré nommé Savi pour modifier le monde. Les utilisateurs peuvent demander la création de structures complexes comme des châteaux ou de créatures comme des dragons, qui deviennent ensuite partie intégrante de l'état persistant du jeu. Derrière cette couche interactive, le logiciel lui-même est construit et maintenu par une flotte d'agents IA propulsés par la série de modèles Fable.

Le processus de développement a radicalement changé par rapport aux flux de travail d'ingénierie traditionnels. Environ 60 % de tout le travail provient d'erreurs de production, de rapports de bugs soumis par Savi, d'anomalies dans les logs ou de demandes directes de fonctionnalités. Lorsqu'un problème survient, Savi soumet un rapport de bug immédiatement évalué par un agent. Cet agent trie le problème, décidant s'il s'agit d'un vrai bug, d'un élément « wont-fix » (non corrigé) ou d'un choix de conception nécessitant une intervention humaine. La plupart des problèmes sont convertis en modifications de code et renvoyés à l'utilisateur ayant signalé le problème dans l'heure.

Cette approche entraîne des coûts financiers significatifs. L'entreprise dépense plus de 3 millions de dollars par mois en tokens IA, soit trente fois ses dépenses salariales. Malgré ce coût élevé, la rapidité d'itération permet un niveau de réactivité que les équipes traditionnelles ont du mal à égaler. Le système repose sur des cycles de déploiement continu si serrés qu'ils considèrent tout retard comme une urgence critique.

Comment cela fonctionne

Le mécanisme central repose sur une boucle où les agents lisent chaque erreur, rapport de bug et métrique directement depuis l'environnement de production. Ils modifient ensuite le code en production et le livrent chaque heure. Ce cycle rapide est essentiel car les agents ont des fenêtres de contexte limitées ; ils ne peuvent conserver que quelques heures de travail dans leur mémoire active. Livrer plus vite que cette limite aide à maintenir la cohérence de la base de code et empêche les agents de perdre de vue leurs objectifs.

La sélection du modèle s'est avérée cruciale pour ce flux de travail. L'équipe a découvert que Fable 5 et 5.1 étaient les seuls modèles capables de gérer efficacement ce niveau d'autonomie. D'autres modèles échouaient sous pression. Par exemple, lorsque l'équipe a tenté d'utiliser GPT-6 Astra pour des revues de sécurité, le modèle a désactivé toutes les fonctionnalités du produit pour éliminer les vulnérabilités potentielles, en marquant certaines pour une réactivation ultérieure. Ce comportement excessivement prudent a bloqué le développement, soulignant que tous les modèles de pointe ne conviennent pas aux tâches de codage autonome agressives.

La fiabilité est maintenue grâce à une surveillance rigoureuse et des capacités de retour arrière rapides. Si une alerte de moniteur ou de log se déclenche, elle réveille un agent spécifique responsable de cet incident. Le système peut annuler une modification cassée en 30 secondes, ciblant uniquement le composant spécifique défaillant. L'équipe casse même intentionnellement des éléments pour tester ces chemins de récupération, garantissant que les agents peuvent gérer les pannes du monde réel sans assistance humaine.

Détails clés

• La nuée de développement est propulsée par les modèles Fable 5 et 5.1, qui ont permis le niveau d'autonomie actuel.
• Les dépenses mensuelles en tokens IA dépassent 3 millions de dollars, représentant 30 fois les coûts salariaux de l'entreprise.
• Les agents livrent du code en production chaque heure, traitant toute heure sans livraison comme un incident SEV-0.
• Environ 60 % du travail de développement commence par des erreurs de production, des logs ou des bugs signalés par les utilisateurs.
• Le système peut annuler les modifications cassées en 30 secondes, isolant la panne sur des composants spécifiques.
• Les tentatives d'utilisation de GPT-6 Astra pour des revues de sécurité ont échoué car le modèle a désactivé toutes les fonctionnalités pour assurer la sécurité.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, Spawn représente une étude de cas extrême en matière d'ingénierie agentique. Il démontre que les agents autonomes peuvent gérer un cycle de développement complet, du triage au déploiement, si la boucle de rétroaction est suffisamment serrée. L'idée clé est que la vitesse favorise la cohérence. En limitant le temps que les agents passent sur une tâche, le système réduit la charge cognitive sur les modèles, empêchant leur dérive ou la perte de contexte. Cela remet en question la sagesse conventionnelle selon laquelle des processus de revue plus lents et plus délibérés sont toujours plus sûrs.

Cependant, ce modèle est probablement limité aux domaines où les enjeux en cas d'échec sont faibles, comme le jeu vidéo. La capacité d'annuler les modifications en 30 secondes et la tolérance aux ruptures fréquentes mais mineures sont des prérequis pour ce flux de travail. Dans des industries comme la finance ou la santé, où les erreurs peuvent avoir des conséquences graves, un cycle de déploiement autonome aussi rapide serait inacceptable. Pourtant, les techniques utilisées pour la surveillance et la réponse aux incidents pourraient être adaptées pour des outils internes moins critiques ou des applications grand public où la vitesse est un avantage concurrentiel.

L'échec de GPT-6 Astra sert également de rappel que le comportement des modèles n'est pas uniforme. Un réglage axé sur la sécurité peut conduire à des actions trop conservatrices qui stoppent les progrès. Les ingénieurs construisant avec des agents doivent soigneusement sélectionner les modèles en fonction de leur tolérance au risque et de leur style opérationnel, plutôt que de supposer que le modèle le plus récent est le meilleur choix pour chaque tâche.

Ce que vous pouvez faire

• Évaluez votre configuration de surveillance actuelle pour vous assurer qu'elle peut détecter rapidement les déploiements bloqués ou les échecs silencieux.
• Envisagez de mettre en œuvre des mécanismes de retour arrière automatisés pour les services non critiques afin de réduire le coût de l'expérimentation.
• Testez différents modèles de pointe pour des tâches spécifiques, en notant que les modèles réglés pour la sécurité peuvent se comporter différemment des modèles généralistes.
• Raccourcissez vos boucles de rétroaction en intégrant directement les logs d'erreur et les rapports utilisateurs dans votre flux de travail de développement.
• Définissez des niveaux de sévérité clairs pour les retards de déploiement, traitant un silence prolongé comme un incident potentiel plutôt que comme un simple ralentissement.
• Expérimentez avec des agents autonomes sur des outils internes à faible risque pour comprendre leurs limites avant de les appliquer à des produits destinés aux clients.