Spawn: agentes de IA programan el juego con US$3M al mes

¿Qué es Spawn y quién está detrás?

Spawn es un entorno de juego multijugador masivo donde los jugadores no programan: piden. A través de prompts dirigidos a Savi —el agente de IA con el que se construye dentro del juego—, cualquiera puede modificar el mundo en tiempo real. Simon Willison lo probó unos minutos desde el teléfono: hizo aparecer un castillo, después un dragón, y terminó volando sobre el castillo montado en el dragón. Lo publicó en su blog el 29 de octubre de 2026.

El juego no es lo interesante del caso. Lo interesante es que, según el relato de Jacob Sansbury, Spawn se desarrolla de forma autónoma: un enjambre de agentes impulsados por modelos Fable escribe el código, lo lleva a producción cada hora y consume más de US$3M al mes en tokens.

Para un founder, ese número es la noticia. No por el monto en sí, sino por lo que implica: alguien está poniendo una factura de tokens de esa escala y obteniendo un ciclo de entrega que ningún equipo humano sostiene sin fricción.

¿Cómo funciona el bucle de agentes que despliega cada hora?

Según el relato de Sansbury, los agentes escriben y despliegan ellos mismos. El bucle arranca casi siempre en producción:

• Los agentes leen cada error, reporte de bug y métrica por su cuenta, y cambian el código en vivo.
• Cerca del 60% del trabajo nace de un error de producción, un reporte de bug de Savi, una rareza en los logs o un pedido de funcionalidad.
• Savi también reporta sus propios bugs: cuando un usuario choca con uno, o cuando ella misma lo encuentra dentro del producto, lo registra. Un agente decide si es un bug real que hay que arreglar, algo que no van a arreglar, o diseño intencional que necesita una decisión.
• En el caso típico, la corrección llega a ese usuario dentro de la misma hora, con un mensaje en el mismo chat.

El ritmo no es una preferencia: es una regla operativa. Una hora sin un despliegue se trata como un incidente SEV-0, la categoría más severa. El argumento que da Sansbury es de coherencia, no de velocidad: un agente solo puede sostener unas pocas horas de trabajo en la cabeza, así que desplegar más rápido de lo que puede recordar lo ayuda a no perder el hilo.

En paralelo, el sistema apuesta fuerte a poder deshacer. Según la misma fuente, un cambio roto se revierte en 30 segundos, exactamente donde se rompió y en ningún otro lugar. Cuando se dispara una alerta de monitor o de log, se despierta a un agente responsable del incidente. Y rompen cosas a propósito para probar que esos caminos de recuperación funcionan.

¿Por qué Fable 5 y no Opus 5.5 o GPT-6 Astra?

Sansbury sostiene que Fable 5 —y después Fable 5.1— fue el modelo que hizo posible este nivel de autonomía. Opus 5.5, dice, no le alcanza para su caso. Y su experiencia con GPT-6 Astra es la anécdota más útil del texto: al pedirle que aplicara las correcciones de una revisión de seguridad, el resultado fue que todo dejó de funcionar.

Su descripción del episodio: cada funcionalidad quedó deshabilitada y marcada para reactivarse cuando terminaran los arreglos de seguridad. El modelo había recorrido el producto entero y había vuelto seguro lo inseguro apagándolo.

La lección no es que un modelo sea mejor que otro, que sería una conclusión sacada de un solo caso. Es que la autonomía sin criterio de producto se resuelve apagando cosas. Un agente capaz de tocar cualquier parte del sistema va a elegir la salida más simple que cumpla la instrucción, y esa salida suele ser quitar la funcionalidad que causaba el problema.

¿Qué significa esto para tu startup?

Tres cosas, y ninguna requiere gastar US$3M al mes.

Primero, el cuello de botella dejó de ser escribir código. Si tus agentes pueden escribir, el límite pasa a ser cuánto tardas en saber que algo se rompió y cuánto tardas en deshacerlo. Ahí conviene invertir: observabilidad real, tests que corran solos y despliegues separados por componente en lugar de un monolito que se publica entero.

Segundo, el rollback es la condición previa, no el plan B. Autonomía sobre un sistema sin reversión en minutos es una apuesta, no un proceso. Antes de dejar que un agente despliegue, comprueba que puedes volver atrás rápido y de forma quirúrgica.

Tercero, dónde probarlo. Este experimento vive en un juego, donde un error cuesta una partida. Willison escribe que le cuesta imaginar este estilo de desarrollo en software con apuestas más altas. Traducido a tu caso: empieza por herramientas internas, un producto secundario o un entorno de staging con datos reales. No por el camino de pagos.

Acciones concretas para esta semana:

• Mide tu bucle. Cuenta cuánto tarda hoy un bug real desde que se reporta hasta que está en producción. Si la respuesta es en días, el problema no es el modelo: es el pipeline.
• Pon precio al bucle. Registra cuántos tokens consume cada tarea cerrada por un agente y compáralo con las horas de ingeniería que reemplaza. Sin ese número no puedes decidir si escalas.
• Automatiza el reporte antes que el arreglo. Ese es el orden que describe Sansbury: primero el sistema detecta y registra, después el agente decide y arregla. Un agente sin telemetría no tiene de dónde partir.

¿Dónde están los límites de este experimento?

El caso Spawn es un extremo, y los extremos sirven para ver el borde del terreno, no para copiarlo. Tres cautelas:

• Es un videojuego. Las consecuencias de un error son bajas y el usuario las tolera. En salud, finanzas o infraestructura crítica la ecuación cambia por completo.
• Depende de un modelo concreto. Si la autonomía se apoya en capacidades específicas de Fable 5 y 5.1, cambiar de proveedor no es una decisión de precio: puede ser rediseñar el sistema.
• El costo es de otra liga. Más de US$3M mensuales en tokens implica que el experimento se sostiene con capital. Para la mayoría de las startups hispanohablantes la pregunta no es si copiarlo, sino qué parte del bucle se puede automatizar con un presupuesto muchísimo menor.

Al cierre de esta nota no se encontraron coberturas adicionales verificables sobre Spawn más allá del texto de Sansbury y la lectura que hace Willison. Todo lo que este artículo atribuye a la operación viene de ahí.

Fuentes

• How I Built the Most AI-Pilled Company in the World (Simon Willison's Weblog) (fuente original)