Jogo Spawn é desenvolvido por um enxame de agentes de IA: tokens custam $3 milhões por mês

Spawn é um jogo multiplayer com gráficos 3D de voxels em que o mundo é alterado por pedidos em texto. O jogador escreve para a assistente de IA integrada, chamada Savvy, o que quer adicionar, e ela completa o mundo. O desenvolvedor Simon Willison testou o jogo pelo celular e, em poucos minutos, conseguiu um castelo, depois um dragão e, em seguida, sobrevoou o castelo montado nele.

O mais interessante está em outro ponto: segundo o fundador, Jacob Sansbury, o próprio jogo é desenvolvido por um enxame de agentes com o modelo Fable. Pessoas quase não participam do processo, e os tokens custam mais de $3 milhões por mês. Aqui, tokens são a unidade de cobrança pelo trabalho de um modelo de linguagem.

Sansbury afirma que gasta 30 vezes mais com eles do que com salários. Em uma conta aproximada, a folha de pagamento da equipe fica na casa de $100 mil por mês.

Deploy a cada hora e bugs abertos pelo próprio jogo

Os agentes alteram o código em produção diretamente e enviam as correções para o ambiente de produção (ou seja, para os jogadores) uma vez por hora. Eles mesmos leem erros, relatórios de bugs e métricas. Cerca de 60% das tarefas começam em uma de quatro fontes:

• erro em produção; • bug report da Savvy; • registro estranho nos logs; • pedido de nova funcionalidade.

A Savvy abre bugs sozinha, tanto quando um jogador esbarra em um problema quanto quando ela percebe uma falha por dentro do jogo. O relatório vai para um agente, que escolhe uma entre três opções: é um erro real e precisa ser corrigido; não será corrigido; ou é um comportamento intencional, que exige decisão humana. Na maioria das vezes, o resultado é uma correção, e o jogador a vê em até uma hora, junto com uma mensagem no mesmo chat.

Esse ritmo só se sustenta enquanto o ciclo não para. Na Spawn, uma hora sem deploy é tratada como incidente SEV-0, ou seja, de gravidade máxima. Correções acumuladas prolongam a vida de problemas já existentes e atrasam o feedback. Há ainda um argumento ligado ao funcionamento dos próprios modelos: o agente mantém em mente apenas algumas horas de trabalho, então deploys pequenos e frequentes ajudam a não perder a coerência.

Rollback em 30 segundos e falhas planejadas

Para que essa velocidade não vire caos, a equipe criou um rollback rápido. Uma mudança com defeito é revertida em 30 segundos, exatamente no ponto em que quebrou, sem mexer no resto. Quando um monitor ou um alerta de logs dispara, o sistema aciona ou acorda o agente responsável por aquele incidente. Os caminhos de recuperação são testados na prática: a equipe quebra o produto de propósito e observa se os agentes dão conta.

Qual modelo aguentou e qual não

Segundo Sansbury, essa autonomia só se tornou possível com o Fable 5 e, depois, com o 5.1. O Opus 5.5 não atende às tarefas deles. Uma história à parte é contada sobre o GPT-6 Astra. Pediram que ele aplicasse as correções resultantes de uma auditoria de segurança. O resultado foi que todas as funções ficaram desativadas e marcadas para serem reativadas após o fim das correções: o modelo, como escreve Sansbury, «tornou o inseguro seguro simplesmente desligando-o». Formalmente, não há vulnerabilidades, mas também não há produto.

Simon Willison observa que levantou as sobrancelhas várias vezes durante a leitura. Ele duvida que essa abordagem sirva para software em que um erro custa caro. Para um jogo, na avaliação dele, o esquema funciona surpreendentemente bem. O jogo é um bom campo de testes: uma falha não ameaça nem dinheiro nem saúde, e os limites dos agentes de programação são testados rapidamente.

O que os engenheiros podem aproveitar

Os números de $3 milhões e a proporção de 30 vezes sobre os salários são, por ora, apenas o relato do próprio fundador, sem confirmação independente. Mas o conjunto de práticas é concreto e transferível:

• Deploys curtos como forma de manter o agente no contexto. Mudanças pequenas cabem nas poucas horas que o agente consegue manter em mente. • Rollback rápido e pontual. Reverter em 30 segundos torna aceitável o deploy a cada hora. • Simulações de recuperação. Quebras intencionais verificam se os agentes responsáveis pelos incidentes realmente colocam o serviço de volta no ar. • Triagem de bugs feita pelo agente. Os três desfechos (corrigir, não corrigir, precisa de decisão humana) deixam para as pessoas apenas as questões de intenção do produto. • Teste do modelo nas suas próprias tarefas. A mesma tarefa de segurança levou o Fable a um produto funcional e o Astra a um produto desligado.

Para o negócio, a conclusão é direta: com essa abordagem, o principal item de custo passa do pagamento de pessoas para o pagamento de computação. O esquema funciona onde o custo do erro é baixo e o rollback é barato. Para bancos e medicina, como observa com razão Willison, dificilmente será possível transferi-lo dessa forma.