Un enjambre de agentes de IA desarrolla el juego Spawn: los tokens cuestan $3 millones al mes

Spawn es un juego multijugador con gráficos 3D de vóxeles en el que el mundo se modifica con peticiones de texto. El jugador escribe a la asistente de IA integrada, llamada Savvy, lo que quiere añadir, y ella completa el mundo. El desarrollador Simon Willison probó el juego desde el móvil: en pocos minutos obtuvo un castillo, después un dragón y luego sobrevoló el castillo a lomos de la criatura.

Lo más interesante es otra cosa: según el fundador, Jacob Sansbury, el juego lo desarrolla un enjambre de agentes basado en el modelo Fable. Los humanos casi no participan en el proceso, y los tokens cuestan más de $3 millones al mes. Aquí, los tokens son la unidad de pago por el trabajo de un modelo de lenguaje.

Sansbury dice que se gasta en ellos 30 veces más que en salarios. Haciendo una cuenta aproximada, la masa salarial del equipo ronda los $100 mil al mes.

Despliegue cada hora y bugs que registra el propio juego

Los agentes modifican directamente el código en vivo y envían los cambios a producción (es decir, a los jugadores) una vez por hora. Ellos mismos leen los errores, los informes de bugs y las métricas. Alrededor del 60% de las tareas arranca en una de estas cuatro fuentes:

• un error en producción; • un informe de bug de Savvy; • una entrada extraña en los logs; • la petición de una función nueva.

Savvy registra bugs por sí misma, tanto cuando un jugador se ha topado con el problema como cuando ella detecta un fallo desde dentro del juego. El informe llega a un agente, que elige entre tres opciones: es un error real y hay que corregirlo; no se va a corregir; o es un comportamiento intencionado sobre el que deben decidir las personas. Lo más habitual es que el resultado sea una corrección, y el jugador la ve en menos de una hora, junto con un mensaje en el mismo chat.

Este ritmo solo se sostiene mientras el ciclo no se detiene. En Spawn, una hora sin despliegue se considera una caída SEV-0, es decir, un incidente del máximo nivel de gravedad. Las correcciones acumuladas alargan la vida de los problemas existentes y retrasan el feedback. Hay además un argumento que tiene que ver con cómo funcionan los modelos: un agente solo puede mantener en la cabeza unas pocas horas de trabajo, de modo que los despliegues pequeños y frecuentes le ayudan a no perder coherencia.

Rollback en 30 segundos y fallos provocados a propósito

Para que esa velocidad no degenere en caos, el equipo montó un sistema de rollback rápido. Un cambio que falla se revierte en 30 segundos, justo en el punto donde se ha roto, sin tocar el resto. Si salta un monitor o una alerta de logs, el sistema lanza o despierta al agente responsable de ese incidente. Las rutas de recuperación se prueban en la práctica: el equipo rompe el producto a propósito y comprueba si los agentes lo resuelven.

Qué modelo dio la talla y cuál no

Según Sansbury, esta autonomía la hicieron posible Fable 5 y, después, Fable 5.1. Opus 5.5 se queda corto para sus tareas. Sobre GPT-6 Astra cuentan una historia aparte. Le pidieron aplicar las correcciones derivadas de una revisión de seguridad. El resultado fue que todas las funciones quedaron desactivadas y marcadas para volver a activarse cuando terminaran las correcciones: el modelo, como escribe Sansbury, «hizo seguro lo inseguro simplemente apagándolo». Formalmente ya no hay vulnerabilidades, pero tampoco hay producto.

Simon Willison señala que al leerlo levantó las cejas más de una vez. Duda de que este enfoque sirva para software en el que un error sale caro. Para un juego, en su opinión, el esquema funciona sorprendentemente bien. Un juego es un buen campo de pruebas: un fallo no pone en riesgo ni el dinero ni la salud, y los límites de los agentes de programación se comprueban rápido.

Qué pueden aprovechar los ingenieros

La cifra de $3 millones y la proporción de 30 a 1 frente a los salarios son, por ahora, solo el relato del propio fundador, sin confirmación independiente. Pero el conjunto de prácticas es concreto y trasladable:

• Despliegues cortos para mantener al agente en contexto. Los cambios pequeños caben en las pocas horas que el agente es capaz de retener. • Rollback rápido y puntual. Un rollback en 30 segundos hace admisible el despliegue cada hora. • Simulacros de recuperación. Los fallos provocados a propósito comprueban que los agentes responsables de cada incidente realmente reponen el servicio. • Triaje de bugs por un agente. Tres desenlaces (corregir, no corregir, requiere decisión humana) dejan a las personas solo las cuestiones de diseño e intención. • Evaluar el modelo con tus propias tareas. La misma tarea de seguridad llevó a Fable a un producto que funcionaba y a Astra a uno apagado.

Para el negocio, la conclusión es directa: con este enfoque, la principal partida de gasto pasa de pagar a personas a pagar cómputo. El esquema funciona donde el coste del error es bajo y el rollback es barato. En banca y medicina, como señala con acierto Willison, es poco probable que se pueda trasladar tal cual.