Criei um jogo em 5 dias com IA: o que 'assistido' significa na prática
O que é o ECHO-7
É um jogo de exploração sci-fi pro navegador — sem combate, sem diálogo. Você controla um robô explorador enviado sozinho a um planeta que se acreditava abandonado, pra investigar uma transmissão que não deveria existir. A história não é contada, é reconstruída: escaneando estruturas, recuperando fragmentos de memória, resolvendo puzzles. Dá pra jogar direto no navegador, sem instalar nada, e o código está público no GitHub.
O MVP saiu em 5 dias, com ajuda de IA no processo. É sobre esse processo que quero falar aqui — não sobre "a IA fez um jogo", porque não foi bem assim.
Por que não foi "vibe coding"
Nenhuma linha de código de jogo foi escrita antes de terminar uma Fase 0: documento de design, arquitetura técnica, estrutura de pastas, modelo de dados, roadmap, riscos técnicos e o escopo exato do MVP — tudo isso definido e aprovado por mim antes da IA implementar qualquer coisa. Sem isso, 5 dias vira código gerado rápido que não vai a lugar nenhum depois do terceiro dia.
O roadmap inteiro foi quebrado em fases pequenas o bastante pra serem implementadas e testadas isoladamente — nunca mais de uma fase de cada vez. E dentro de cada fase, o ciclo era sempre o mesmo: a IA explica o objetivo da tarefa, explica a decisão técnica, lista os arquivos que vai mexer, implementa, mostra o código, explica como testar, aponta possíveis problemas — só então a próxima tarefa começa. Repetido em cada uma das dez fases do MVP.
A IA discordando de mim (de propósito)
Uma regra que dei desde o início: a IA age como Tech Lead, não como quem concorda com tudo. Se uma decisão minha tinha um problema técnico identificável, isso precisava ser dito, com uma alternativa — não implementado do jeito que eu pedi só porque eu pedi.
Aconteceu duas vezes logo na Fase 0: eu estava inclinado a uma câmera isométrica, e a IA recomendou 2D top-down, explicando o porquê antes de eu decidir por isométrica de qualquer jeito. E recomendou manter a posição do jogador (dado de alta frequência) fora do estado gerenciado pelo Zustand, pra não re-renderizar o React a cada frame durante o gameplay. As duas ficaram, e as duas evitaram problema que só apareceria depois, com o jogo já rodando.
Dois bugs reais, pegos antes de abrir o navegador
Isso é o que mais gosto de contar sobre o processo, porque não é teoria: na Fase 6, a primeira versão da instalação automática de upgrades usava um único snapshot do inventário — o que deixaria um mesmo componente "pagar" por dois upgrades diferentes que exigem 1 unidade cada. Pego em revisão, antes de testar, reavaliando o estado a cada instalação em vez de usar o snapshot inicial.
Na Fase 7, um ponto de retorno entre regiões tinha sido posicionado, sem querer, dentro de uma área só acessível com um upgrade específico — um softlock em potencial (o jogador ficaria preso, sem como voltar). Também pego relendo a posição contra a geometria da região antes de rodar o jogo pela primeira vez.
newsletter
Gostou do post? Quando eu publicar o próximo sobre Delphi, React ou IA aplicada ao desenvolvimento, você recebe um aviso por e-mail.