Construindo um mundo de jogo multijogador com modelos autônomos da classe Fable

Como construí a empresa com mais recursos de IA do mundo. Não se deixe intimidar pela manchete clickbait, este artigo de Jacob Sansbury descrevendo como eles estão construindo Spawn é uma exploração fascinante do que há de mais moderno no que é possível com a engenharia de agentes contra modelos de fronteira.

Spawn é um ambiente de jogo multijogador massivo onde os jogadores podem usar instruções (para o agente do jogo, Savi) para modificar o mundo do jogo.

Liguei no meu telefone por alguns minutos e fui capaz de criar um castelo, depois um dragão, e depois montar o dragão para voar ao redor daquele castelo.

Segundo Jacob, Spawn agora está sendo desenvolvido de forma autônoma por um enxame de agentes movidos por Fable, custando mais de US$ 3 milhões em tokens. por mês:

Nossos agentes alteram o código ativo diretamente e enviam para produção de hora em hora, para que eles próprios leiam todos os erros, relatórios de bugs e métricas. Cerca de 60% do nosso trabalho começa com um erro de produção, um relatório de bug do Savi (Savi é a IA com a qual você constrói jogos no Spawn), algo estranho em nossos logs ou uma solicitação de recurso.

Savi arquiva bugs sozinha. Quando um usuário acerta um, ou Savi acerta um no produto, ela o arquiva. Vai direto para um agente que decide se é um bug real a ser corrigido, algo que não iremos consertar ou um design intencional que precisa de uma decisão. Geralmente vira uma mudança, entregue a esse usuário em até uma hora, com uma mensagem no mesmo chat.

Esta é uma implantação contínua aumentada para 11:

Um circuito tão apertado só funciona se nunca parar, por isso tratamos uma hora sem nave como um SEV-0, o nosso tipo de incidente mais grave. As alterações não enviadas se acumulam e todos os problemas já em produção duram mais. O feedback também fica mais lento. Um agente só consegue manter algumas horas de trabalho em mente, portanto, enviar mais rápido do que isso realmente o ajuda a permanecer coerente. (…)

Podemos reverter uma alteração quebrada em 30 segundos, exatamente onde ela está quebrada e em nenhum outro lugar. Quando um monitor ou alerta de log é acionado, ele inicia ou desperta um agente proprietário do incidente, e quebramos as coisas propositalmente para testar se esses caminhos de recuperação funcionam.

Minhas sobrancelhas se ergueram pelo menos uma dúzia de vezes lendo alguma coisa. Tenho dificuldade em imaginar esse estilo de desenvolvimento funcionando em software com riscos mais altos para quando algo dá errado, mas para um jogo isso parece estar funcionando surpreendentemente bem.

Jacob diz que Fable 5 (e depois 5.1) foi o modelo que tornou possível esse nível de autonomia. O Opus 5.5 não consegue hackear para eles, e quando eles tentaram o GPT-6 Astra para aplicar correções de uma revisão de segurança, tudo parou de funcionar:

Todos os recursos foram desativados e marcados para serem ativados novamente assim que as correções de segurança forem concluídas. A Astra examinou todo o nosso produto e tornou seguras as coisas inseguras, desativando-as.

Esses tipos de experimentos extremos são o motivo pelo qual estou entusiasmado com o desenvolvimento de jogos como substrato para explorar os limites do que os agentes de codificação de hoje podem fazer.