Claude Opus 5.5 cruza o ponto de inflexão do vibe coding para jogos

De "parece jogo" a "é divertido"

Simon Willison, criador do Datasette e um dos cronistas mais lidos da cena de agentes de código, publicou em 28 de outubro de 2026 um relato que ele próprio chama de ponto de inflexão: pela primeira vez, segundo ele, modelos de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → passaram a produzir jogos genuinamente divertidos de jogar, não apenas visualmente convincentes.

Willison já tinha usado esse rótulo antes, em novembro de 2025, quando Opus 4.5 e GPT-5.1 tornaram os agentes de código confiáveis o bastante para virar ferramenta diária de quem programa. Desta vez ele aplica o mesmo termo a uma área bem mais difícil de automatizar: o design de jogos, a arte de montar um loop de jogabilidade que desafia o jogador no ritmo certo.

Acho que chegamos a um novo ponto de inflexão em outubro de 2026, e desta vez é para o vibe coding de jogos de computador.

Simon Willison, desenvolvedor e autor do blog pessoal simonwillison.netI think we've reached a new inflection point in October 2026, and this time it's for vibe coding computer games.

Ele é claro sobre o que mudou: criar algo com cara de jogo (gráficos, menu, uma mecânica básica) já era possível havia tempo, em experimentos anteriores do próprio autor. O problema era chegar a um jogo que desse vontade de continuar jogando. Willison conta que não esperava que o Claude Opus 5.5 resolvesse isso, até pedir "torne isso muito mais divertido" e o resultado realmente melhorar.

Quatro jogos, quatro níveis de esforço

Willison lista quatro projetos construídos nas últimas semanas, todos em HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → e JavaScript rodando direto no navegador, sem instalar nada. Ele os ordena pelo esforço investido, que nunca passou de quatro horas de trabalho dele mesmo (fora o tempo que o modelo gastou sozinho processando):

• Tree Appreciator: um jogo de "ache as diferenças" entre duas árvores geradas proceduralmente, feito em uma única resposta do chat comum do Claude (sem precisar do Claude Code), usando three.js;
• Emberwick: um RPG top-down com vila medieval, NPCs, masmorras e um troll adormecido numa caverna, que cresceu prompt a prompt até virar uma campanha de 15 minutos com sistema de magia e reviravoltas na trama;
• Battle Drones: um RTS multiplayer ao estilo Command & Conquer, com exércitos de robôs disputando território;
• Quarter Sun Cove (também chamado de Pumpkin Farmer): um simulador de fazenda sobre cultivar abóboras gigantes, inspirado no festival anual da própria cidade de Willison, Half Moon Bay.

O ponto comum entre eles é o tipo de prompt usado. Para o Tree Appreciator, Willison só escreveu Build a three js game called "Tree appreciator" - it shows you two algorithmically generated trees and the game mechanics is about appreciating the differences between them. Think hard about how to make sure it is both fun and beautiful e recebeu o jogo pronto, incluindo um "herbário" de árvores colecionadas, na primeira tentativa.

Battle Drones: do protótipo capenga ao RTS open source

O projeto mais desenvolvido é o Battle Drones, sobre o qual Willison já havia escrito em outro post. As primeiras versões foram feitas em julho de 2026 com Claude Fable 5 e resultaram num Command & Conquer 2D jogável, mas sem graça. A virada veio quando ele passou a usar o Opus 5.5 e deu a mesma instrução curta: Make it a LOT more fun, seguida de Port this game to three.js para migrar o jogo para 3D.

Hoje o Battle Drones tem multiplayer para 2 a 4 jogadores via um relay de WebSockets também vibe coded, medalhas, replays, sete mapas, um gerador aleatório de mapas e variantes de regras chamadas de "mutators". Há até um modo em que diferentes modelos jogam uns contra os outros: o jogo avança cinco segundos, pausa, e cada modelo interpreta o novo estado antes de definir o próximo comando.

Willison liberou o código do Battle Drones sob licença Apache 2.0 na semana anterior ao post. Dias depois, o desenvolvedor Gabriel Turpin lançou um fork chamado Panache, reimaginando o mesmo jogo num cenário steampunk da Belle Époque francesa, com modelos 3D, música e intro animada próprios. É o tipo de reaproveitamento que só faz sentido quando o custo de gerar arte, música e código cai para quase zero.

Opus 5.5 entende diversão, GPT-6 Astra ainda não

Willison não fez um estudo controlado, mas registra uma diferença perceptível entre modelos. Ele rodou a mesma sequência de prompts do Emberwick no GPT-6 Pro e descreve o resultado como visualmente bonito, mas bem menos divertido de jogar do que a versão feita com Opus 5.5. Sua avaliação é que o GPT-6 Astra da OpenAI "consegue construir um jogo", mas ainda não tem o mesmo senso do que faz um jogo funcionar, algo que ele espera que mude até o fim de 2026.

Isso importa porque é um tipo de gap diferente do que se mede em benchmarks de código tradicionais. Não é sobre gerar três.js sintaticamente correto: os dois modelos conseguem isso. É sobre julgamento de design, uma camada que até agora parecia exigir intuição humana e que, segundo o relato, só um dos modelos testados demonstra ter.

O que muda pra quem prototipa: stack e fluxo de trabalho

Para quem quer reproduzir o experimento, a receita que Willison descreve é direta e vale registrar como roteiro, não como garantia:

1. Comece pelo chat comum (ChatGPT ou Claude.ai), sem abrir um agente de código completo, com um prompt do tipo Build a mobile-friendly three.js game where...;
2. Use bibliotecas que os modelos já conhecem bem, como three.js para 3D e Phaser para 2D;
3. Hospede o resultado como site estático, em GitHub Pages ou Cloudflare Pages, já que é HTML e JavaScript puros;
4. Quando o protótipo passar do estágio de prova de conceito, migre para um agente completo como Codex ou Claude Code para iterar com mais profundidade;
5. Se o jogo ainda estiver sem graça, peça literalmente Make it a LOT more fun.

Nenhum dos quatro jogos foi feito em uma tacada só, exceto o Tree Appreciator. O Emberwick, em particular, exigiu bastante playtesting e correção de bugs de jogabilidade, como um personagem não estar no lugar certo para completar uma missão porque outro evento da história já o tinha movido dali. Isso é o oposto de "vibe coding sem olhar o código": é iteração guiada por jogar o próprio jogo repetidas vezes.

Os limites: assets de IA e a reação da comunidade de jogos

Willison reconhece de forma direta que esses jogos reúnem tudo que parte da comunidade de games já rejeita: arte gerada por IA, música gerada por IA, texto gerado por IA e código gerado por IA, tudo ao mesmo tempo. Ele cita como exemplo uma reportagem da IGN sobre reclamações de "slop" (lixo gerado por IA) em jogos do Steam Next Fest, da Valve, como sinal de que essa reação já é real e crescente antes mesmo da onda de vibe coding de jogos completos.

A posição dele é pragmática: diz respeitar quem rejeita esse tipo de conteúdo, mas não compartilha a rejeição. Também é honesto sobre os limites morais que ele próprio impõe ao hobby: não pretende inscrever nenhum desses jogos em game jams ou competições tradicionais, por sentir que não teria "ganhado o direito" de competir ali. Ele espera que surjam categorias novas, específicas para jogos construídos dessa forma.

Agora imagine o que poderia ser alcançado por alguém que levasse isso a sério, investisse tempo criativo de verdade, aplicasse bom gosto em design de jogos e então testasse e iterasse o resultado até ficar o melhor possível.

Simon Willison, desenvolvedor e autor do blog pessoal simonwillison.netNow imagine what could be achieved by anyone who takes this seriously, invests significant creative time, applies better taste in game design, and then playtests and iterates on the result until it's as good as they can make it.

Em que caso não vale a pena

O próprio relato dá pistas de onde o método tropeça. Projetos mais ambiciosos, como o Emberwick, não saem prontos de primeira: exigem ciclos reais de playtesting, não só prompts mágicos. A entrada criativa de Willison em cada jogo foi mínima, quase sempre uma frase, o que é ótimo para prototipagem rápida, mas é exatamente o oposto do que se espera de um projeto com identidade autoral forte.

Há também um risco técnico concreto: Willison relata que uma tentativa de multiplayer baseado em áudio deu dor de cabeça de verdade na esposa dele, Natalie, um lembrete de que "baixo risco" não é sinônimo de "sem risco nenhum" quando o resultado roda no navegador de alguém. Para quem no Brasil quer testar o mesmo caminho, a vantagem é clara: custo de entrada baixo, stack conhecida (three.js, Phaser, hospedagem estática) e nenhuma dependência de engine pesada. A desvantagem é que, como em todo vibe coding, a responsabilidade por testar antes de publicar continua sendo humana.

Fonte: Simon Willison