De três protótipos a seis jogos: o que a IA acelerou — e o que continuou sendo engenharia

O ganho mais evidente apareceu no começo. Em vez de montar toda a estrutura antes de testar a ideia, eu conseguia descrever uma interação, gerar uma versão executável e descobrir rapidamente se ela fazia sentido.

Isso foi especialmente útil porque cada jogo tinha uma mecânica pequena e observável. No caça-palavras, por exemplo, não bastava pedir uma grade com letras. Era preciso definir a matriz 10×10, a seleção letra a letra, a validação e o feedback visual. No Quebra-Cabeça Deslizante, o movimento permitido dependia da posição vazia, e a condição de vitória precisava reconhecer a sequência completa.

Linguagem natural ajudou a produzir a primeira implementação. Não virou código-fonte por decreto. O sistema continuou dependendo do código gerado, do comportamento no navegador e das decisões que sobreviveram às iterações.

Adicionar um jogo não significava apenas criar outra rota. O portal precisava continuar parecendo um produto único.

Caça-Palavras trabalha com categorias e dificuldade. Jogo da Velha e Mu Torere precisam lidar com adversário humano ou computador. O Quebra-Cabeça aceita uma foto enviada pela pessoa. O Quebra-Cabeça Deslizante combina peças, tempo e movimentos. A Forca depende de vocabulário, tentativas e feedback progressivo.

Cada experiência tem regras próprias, mas todas precisam responder às mesmas perguntas: como uma partida começa, como recomeçar, o que funciona por toque e como o estado aparece para quem está jogando.

Gerar uma tela de cada vez é relativamente simples. Impedir que seis telas resolvam o mesmo problema de seis maneiras diferentes dá mais trabalho.

Um dos problemas no Quebra-Cabeça Deslizante foi o erro Maximum update depth exceeded, do React. O componente entrava em um ciclo de atualização porque um efeito dependia de uma referência que mudava durante a renderização.

A IA ajudou a localizar o padrão. A correção envolveu estabilizar as dependências e usar atualização funcional de estado onde ela era apropriada.

Esse episódio não prova que IA faz debugging sozinha. Mostra algo mais útil: quando há um erro reproduzível e contexto suficiente, ela pode encurtar a investigação. Ainda cabe ao desenvolvedor verificar se a correção elimina a causa ou apenas silencia o sintoma. Compilar continua sendo um critério bastante generoso de qualidade.

Com o avanço do projeto, escrever a primeira versão deixou de ser o gargalo principal. Revisar passou a ocupar mais espaço.

Era preciso decidir se uma regra estava correta, se o jogo funcionava no celular, se um botão de reinício era claro e se uma nova melhoria justificava mais complexidade.

A IA oferecia implementações depressa. Nem sempre oferecia a melhor fronteira para o produto. Ela não sabia, por conta própria, quais seis jogos deveriam compartilhar comportamento nem quando uma solução local criaria inconsistência no restante do portal.

O papel humano não ficou restrito a curar sugestões. Houve especificação, decomposição, revisão, teste e escolha. Chamar tudo isso de curadoria deixa a engenharia educadamente fora da fotografia.

Foi possível testar mecânicas e interfaces cedo, descartar caminhos baratos e ampliar o escopo sem começar cada jogo do zero. Também ficou claro que a velocidade inicial cobra disciplina depois: revisar estados, regras e consistência de seis experiências é trabalho de produto e engenharia, independentemente de quem digitou a primeira função.

Este é um resultado menor e mais concreto do que uma tese universal sobre produtividade. Justamente por isso, é mais útil.

A parte mais interessante da IA neste projeto não foi transformar prompt em produto. Foi tornar algumas hipóteses baratas o bastante para serem testadas.

O produto começou quando essas hipóteses precisaram conviver.