Como revisar uma mudança que um assistente de IA fez no seu jogo antes de ficar com ela?

Compare os arquivos alterados com a sua tarefa, leia o diff a partir das remoções, rode as verificações você mesmo, jogue a mudança e só então faça o commit.

Olhe quatro coisas, nesta ordem: quais arquivos mudaram, o que o diff removeu e adicionou, o que as verificações dizem quando você mesmo as roda e como o jogo se comporta onde a mudança caiu. Fique com a mudança só quando as quatro baterem com o que você pediu, e guarde-a como commit. Se alguma não bater, desfaça e peça de novo com uma tarefa melhor. O relatório do assistente diz onde olhar; ele não é a revisão.

Por que «pronto» não basta?

Porque é uma afirmação, e a prova é a própria mudança. Um assistente pode dizer que um recurso funciona quando só verificou que o código compila, ou que mexeu em um arquivo quando um comando que ele rodou reescreveu três.

Parte disso nem aparece no editor. A página do Visual Studio Code sobre revisar edições feitas por IA diz que as edições pendentes já estão salvas em disco, que mudanças feitas por comandos de terminal ou scripts não aparecem na sua lista de edições e que os seus pontos de verificação não desfazem comandos de terminal nem implantações. Era o que a página dizia em 29 de outubro de 2026, com última atualização em 21 de outubro. Seja qual for a ferramenta, a visão confiável é a do controle de versão: todo arquivo que difere do seu último commit.

Por isso o primeiro passo acontece antes de o assistente começar: salve uma versão que funciona como commit. Sem ele, não há com o que comparar a mudança nem para onde voltar.

O que olhar primeiro?

A lista de arquivos alterados. Dois comandos a mostram:

git status
git diff --stat

git status nomeia cada arquivo alterado e cada arquivo novo. git diff --stat acrescenta quantas linhas cada arquivo ganhou e perdeu. Note que git diff sozinho não mostra arquivos novos que ainda não foram adicionados ao Git; git status mostra, então leia os dois.

Agora compare a lista com a sua tarefa. Se você escreveu uma tarefa que diz onde a mudança entra e o que não pode mudar, isso leva segundos.

Nada disso é errado por si só. Mas cada item é algo que você não planejava revisar, então ele vem primeiro.

Como ler o diff se você não é programador?

Leia como uma lista de linhas removidas (em vermelho, marcadas com -) e linhas adicionadas (em verde, marcadas com +), e comece pelas removidas. Uma linha que some é a mudança mais fácil de deixar passar e a mais difícil de perceber jogando: uma verificação que impedia o jogador de atravessar paredes, o zerar da pontuação, uma proteção contra um jogo salvo vazio.

Depois procure alguns padrões fáceis de ver sem conhecer a linguagem:

• Números que mudaram: velocidades, vidas, cronômetros, preços. Cada um deveria estar na sua tarefa.
• Código transformado em comentário, ou um bloco inteiro apagado e escrito de novo em outro lugar.
• Uma função nova parecida com uma antiga: o mesmo trabalho feito duas vezes, e com o tempo as duas cópias se afastam.
• Texto que o jogador vê: menus, dicas, mensagens de erro. Ainda está correto e no lugar certo?

Para qualquer linha que você não consiga ler, pergunte ao assistente o que ela faz e o que a chama. A pergunta não custa nada, e uma resposta que não bate com o código já é uma descoberta.

Quais verificações rodar você mesmo?

As que a sua tarefa citou, rodadas por você em vez de relatadas. Se a tarefa pedia um teste, rode os testes e leia o resultado. Se pedia que a página carregasse sem erros, abra o jogo com o console do navegador aberto. Uma verificação que você viu passar vale mais que uma frase dizendo que ela passou.

Um teste verde só prova o que ele testa. Se um arquivo de testes mudou no mesmo diff, leia essa parte: um teste que antes esperava pontuação 0 depois de reiniciar e agora espera o que o código devolver não verifica mais nada.

O que jogar antes de ficar com a mudança?

Primeiro a própria mudança, do jeito que a tarefa descreveu. Depois um percurso curto pelo resto do jogo, sempre o mesmo, porque uma mudança num lugar muitas vezes quebra outro:

1. comece o jogo a partir de uma página nova;
2. use cada controle uma vez, no teclado e no celular se o jogo tiver controles de toque;
3. pause, perca, reinicie;
4. salve, recarregue a página, carregue.

O percurso leva alguns minutos e pega o que os testes raramente cobrem: um botão que não responde mais, uma tela da qual não dá para sair, um jogo salvo que não volta. Se a mudança adicionou uma tecla ou uma tela, confira que elas também funcionam pelo toque; é a regra que seguimos no KittenGalaxy desde que adicionamos os controles de toque.

Como ficar com a mudança, ou jogá-la fora?

Para ficar com ela, faça um commit com uma mensagem que diga o que mudou nas palavras do jogador: «cada onda 10% mais rápida, até o dobro da velocidade inicial». Uma tarefa, um commit. Depois, quando algo quebrar, você descobre qual mudança causou e desfaz exatamente aquela.

Para jogá-la fora, volte ao último commit. No Git, git restore . devolve os arquivos que o Git já acompanha ao estado do seu último commit, a menos que as mudanças tenham sido preparadas com git add; arquivos criados pelo assistente não são removidos por ele, então confira git status de novo e apague-os à mão. Editores com desfazer próprio ou pontos de verificação fazem o mesmo, dentro dos limites que descrevem. Então escreva uma tarefa melhor: diga o que deu errado e acrescente uma verificação que teria pegado o problema.

É tentador ficar com uma mudança quase certa e consertar o resto na próxima tarefa. Faça isso só quando você souber dizer o que está errado e for pouco. Uma mudança que você não entende não fica mais fácil de entender depois que a próxima é construída em cima dela. É assim que jogos feitos com assistentes saem do controle, e é por isso que um primeiro jogo pequeno é mais fácil de manter funcionando.

Outra IA pode fazer a revisão?

Ela pode ler o diff com você: explicar linhas, apontar verificações removidas, perguntar para que serve uma função nova. Isso ajuda, principalmente se você não lê código. Mas ela não pode decidir se o jogo ainda faz o que você queria, porque só você sabe isso, e não pode jogar por você. Use-a como segunda leitora, nunca como aprovação.

Perguntas frequentes

Quanto tempo uma revisão deve levar? Mais ou menos tão pouco quanto a mudança é pequena. Se ler o diff demora mais do que escrever a tarefa, a tarefa provavelmente era grande demais; divida a próxima.

Preciso de Git para isso? Você precisa de algum jeito de ver o que mudou e de voltar atrás. O Git é o jeito comum e é gratuito; a maioria dos editores e assistentes trabalha com ele.

E se a mudança está certa, mas o código parece bagunçado? Fique com ela se funciona e você a entende, e escreva uma tarefa separada para arrumar, com as mesmas verificações. Não misture arrumação com um recurso novo.

Devo revisar mudanças em arte, som e arquivos de fase? Sim, olhando e jogando em vez de ler o diff. A lista de arquivos alterados ainda diz quais olhar.

Quando outras pessoas podem jogar? Quando o percurso acima passa numa página nova e um desconhecido consegue terminar o jogo sem a sua ajuda. Aí você pode enviá-lo ao HeapPlay.