Análise, plano, código, verificações: o nosso ritmo para desenvolver com IA 🤖

Nunca escondemos que usamos muita IA no Blocks Beyond The Stars — sem ela, um jogo deste tamanho simplesmente não seria viável como projeto de depois do expediente. Mas, para nós, “desenvolver com IA” não significa: digitar um desejo, pegar o resultado e torcer. Ao longo dos meses surgiu um padrão fixo que soa surpreendentemente antiquado — e funciona justamente por isso. Hoje a gente conta tudo.

Tudo sempre começa com uma pessoa e uma ideia. Antes de qualquer IA fazer qualquer coisa, alguém quis ou percebeu algo: um jogador usando a tecla de feedback para relatar que animais aparecem dentro das paredes dele — ou nós mesmos, quando o Justus diz no meio do jogo o que sente falta. A IA não inventa tarefas por aqui. Ela as recebe.

Depois a IA trabalha em fases. Quatro delas, sempre na mesma ordem: análise, planejamento, implementação, verificação. (O quinto passo, o teste manual, vem depois — mas é de novo trabalho de gente, mais sobre isso daqui a pouco.) O truque mais importante é o que a IA não pode fazer: escrever código de cara. Uma IA que começa a digitar imediatamente resolve o problema errado com uma velocidade impressionante. Por isso toda tarefa maior começa com uma análise — o que já existe, onde está de fato a causa, o que mais está ligado a isso? O resultado é texto, não código.

Depois vem o plano — e ele é lido. A análise é seguida pelo planejamento: quais arquivos serão tocados, em que ordem, quais armadilhas já são conhecidas, quais decisões ainda estão em aberto? É exatamente aqui que surgem as perguntas que é melhor responder antes de programar (“Isso também deve funcionar no navegador?”, “O que acontece com os saves antigos?”). Só quando o plano está de pé vem a implementação — e ela costuma ser a parte mais chata de tudo. Que é exatamente como deve ser.

Coisas parecidas vão num lote só. Uma segunda regra que nos poupa muito tempo: quando vários problemas são parecidos ou ligados entre si — cinco menus de controle que compartilham o mesmo problema de foco, ou quinze achados da mesma rodada de testes — a IA os recebe agrupados como uma tarefa só, e não como quinze separadas. Assim ela só precisa percorrer o código afetado uma vez, as soluções combinam entre si em vez de se contradizerem e nada cai no chão entre duas tarefas.

Antes de cada lançamento: duas rodadas de inspeção separadas. Depois de cada etapa de trabalho maior — e sempre antes de uma nova versão chegar até vocês — soltamos a IA sobre o resultado mais uma vez. Mas com duas investigações deliberadamente separadas. Primeira: os recursos e as correções de bugs visados estão mesmo completamente prontos — ou ainda sobrou algum resto pela metade em algum lugar, um caso de borda esquecido, uma tradução faltando? Segunda, numa passada própria: as mudanças causaram problemas novos em outro lugar? Misturar as duas numa pergunta só não funciona — quem caça lacunas e danos colaterais ao mesmo tempo encontra metade de cada. Perguntadas separadamente, essas duas questões nos poupam um monte de retrabalho; uma boa parte do que aparece nas notas de lançamento como “corrigido no caminho” vem exatamente dessas rodadas de inspeção.

E bem no final, uma pessoa testa de novo. O quinto passo não é uma fase da IA, é nosso: teste manual significa jogar de verdade. Versão recém-compilada, um controle de verdade, uma criança de verdade jogando. Muita coisa que sobrevive a qualquer análise morre nos primeiros cinco minutos no sofá. Porque se algo parece certo é uma pergunta que nenhuma análise do mundo consegue responder.

Olhando de perto, você não vai achar mágica de IA nesse padrão, só o velho ofício da engenharia: primeiro entender, depois planejar, depois construir, depois conferir. E para nós a moldura em volta é sempre a mesma: uma pessoa tem a ideia, uma pessoa faz o teste final — a IA trabalha no meio. A única novidade é a rapidez que esse ciclo ganhou. 🔍