Estava escutando um corte da última visita do Fabio Akita ao Flow Podcast e minha cabeça explodiu.

Não porque o Akita tenha apresentado alguma novidade bombástica. O que achei sensacional foi o papo. O Igor 3K estava contando como tem sido a experiência de criar um jogo usando inteligência artificial, e a conversa acabou passando por uma questão que parece simples, mas é muito importante: usar uma ferramenta não é a mesma coisa que entender o trabalho que precisa ser feito.

Ao longo do episódio, Akita fala sobre programação, criação de jogos, modelos de IA e sobre o que acontece quando alguém usa uma ferramenta poderosa sem saber avaliar o resultado. Ele também apresenta uma ideia que resume bem o assunto: a IA pode acelerar bastante uma pessoa que já sabe o que está fazendo — mas também pode produzir problemas muito mais rápido quando falta conhecimento e revisão.

O episódio completo, FABIO AKITA - Flow #663, tem mais de quatro horas e está disponível no YouTube. Vale ouvir a conversa inteira, especialmente se você tem curiosidade sobre programação, jogos ou sobre o uso de IA para criar coisas.

O que é um estado?

Imagine um jogo de futebol. Antes do apito inicial, o jogo está em um estado: placar zerado, jogadores em suas posições e bola parada. Depois do primeiro passe, o estado mudou. Se sai um gol, mudam o placar, a posição dos jogadores e talvez até a estratégia de cada time.

Um programa também está sempre em algum estado. Um botão pode estar disponível ou desabilitado. Uma compra pode estar aguardando pagamento, aprovada ou cancelada. Um personagem pode estar parado, correndo, pulando ou tomando dano.

Programar, em boa parte, é definir:

• quais estados existem;
• o que pode fazer o programa mudar de um estado para outro;
• o que deve acontecer em cada mudança.

Parece simples porque é um jeito bastante natural de pensar. A dificuldade aparece quando existem muitas regras ao mesmo tempo. Por exemplo: o que acontece se o jogador tentar pular enquanto está caindo? E se ele ficar sem energia durante o pulo? E se apertar dois botões ao mesmo tempo?

Quando essas situações não são previstas, aparecem aqueles comportamentos estranhos que todo mundo já encontrou em algum aplicativo ou jogo.

O que é um teste de regressão?

Agora imagine que você consertou um problema: o personagem não conseguia atravessar uma porta. Depois da correção, ele atravessa a porta, mas passa a atravessar também as paredes. Ou o botão de salvar começa a apagar o progresso em vez de guardá-lo.

Esse tipo de problema é uma regressão: algo que funcionava deixou de funcionar depois de uma mudança.

Um teste de regressão é uma verificação repetida para garantir que uma melhoria nova não estragou uma parte antiga do programa. Ele pode ser manual — alguém abre o jogo e refaz os passos — ou automatizado, quando outro programa executa as verificações sozinho.

A ideia não é testar absolutamente tudo a cada segundo. É criar uma rede de segurança para as partes importantes. Assim, o desenvolvedor pode experimentar, corrigir e melhorar o software com um pouco mais de confiança.

Repetir também é aprender

Outro ponto que apareceu na conversa foi a importância de repetir e refazer. À primeira vista, pode parecer que um bom desenvolvedor deveria acertar tudo de primeira. Na prática, quase nunca é assim.

A gente aprende quando tenta uma solução, observa o resultado, descobre o que não funcionou e tenta novamente. Isso vale para escrever uma função, montar uma fase de jogo, desenhar uma interface ou conversar com uma inteligência artificial para chegar ao resultado desejado.

Cada repetição ajuda a formar um modelo mental melhor. Aos poucos, a pessoa começa a perceber:

• quais problemas costumam aparecer;
• quais perguntas ajudam a encontrar a causa de um erro;
• quais mudanças são pequenas e seguras;
• quando é melhor voltar atrás e tentar outro caminho.

Isso não é uma característica exclusiva de quem programa. É o mesmo processo de aprender a tocar uma música, cozinhar uma receita ou escrever um texto: praticar, observar, ajustar e tentar de novo.

A IA muda o trabalho, não elimina o processo

Usar IA para escrever código pode dar a impressão de que basta descrever uma ideia e esperar. Às vezes, ela realmente produz algo útil em poucos segundos. Mas o programa continua tendo estados, regras e possíveis regressões.

A IA pode sugerir uma solução, mas alguém ainda precisa verificar se ela faz sentido, testar os casos importantes e entender o suficiente para corrigir o que der errado. Se o código gerado funcionar apenas no exemplo mais simples, ainda não temos um produto pronto — temos um ponto de partida.

No episódio, aparece uma comparação boa: uma máquina de escrever deixa uma pessoa escrever mais rápido, mas não transforma alguém que não sabe escrever em um bom escritor. A ferramenta aumenta a velocidade; ela não substitui o conhecimento.

Com programação acontece algo parecido. Uma pessoa que entende o problema pode usar a IA para explorar alternativas, criar um primeiro rascunho, automatizar tarefas repetitivas e corrigir pequenos detalhes. Porém, ainda precisa decidir o que construir, conferir se a solução está correta e perceber quando o resultado está frágil.

É por isso que a IA também pode acelerar a chamada dívida técnica. Esse nome descreve problemas que ficam escondidos no software: código difícil de entender, regras duplicadas, testes ausentes e soluções improvisadas. Se ninguém revisar o que foi produzido, esses problemas se acumulam — só que agora em uma velocidade maior.

Primeiro faça funcionar; depois melhore

Outro ponto interessante da conversa é que não precisamos tentar produzir a versão perfeita logo na primeira tentativa. Quando criar e descartar uma tentativa ficou mais barato, faz sentido experimentar mais.

Isso não significa aceitar qualquer resultado. Significa separar as etapas:

1. construir uma primeira versão que permita verificar a ideia;
2. testar se ela funciona nos casos importantes;
3. jogar fora o que não serve, sem apego;
4. refazer com mais informação;
5. organizar e melhorar o código depois que o caminho estiver claro.

A IA é especialmente útil nesse ciclo porque consegue gerar alternativas rapidamente. Mas a decisão de qual alternativa vale a pena testar continua sendo humana. E, principalmente, alguém precisa reconhecer quando uma solução apenas parece funcionar.

Experiência é saber onde procurar

A conversa também ajuda a explicar por que experiência continua valiosa, mesmo com ferramentas capazes de escrever código.

Uma pessoa iniciante pode imaginar vinte maneiras de resolver um problema e precisar testar todas. Quem já enfrentou problemas parecidos reconhece mais cedo quais caminhos provavelmente darão errado. Não existe mágica nisso: é um repertório construído depois de muitas tentativas, erros e correções.

A inteligência artificial pode ajudar a explorar essas possibilidades, mas não cria automaticamente o repertório necessário para julgar cada resposta. Por isso, aprender os fundamentos continua sendo importante. Quanto mais a pessoa entende, melhores são as perguntas que consegue fazer e mais rapidamente identifica uma resposta ruim.

Isso também muda o papel de quem tem mais experiência. Um bom profissional não serve apenas para escrever código: ele ajuda outras pessoas a entender o sistema, explica onde as coisas podem dar errado e compartilha critérios para tomar decisões. Ferramentas novas podem acelerar esse trabalho, mas não tornam o aprendizado desnecessário.

Engenharia de software está em mais lugares do que parece

Depois de tantos anos nessa indústria vital, a gente acaba perdendo a percepção de como esses conceitos elementares — e, de certa forma, intuitivos — fazem parte da nossa rotina.

Quando alguém organiza uma lista de tarefas por etapas, está pensando em estados. Quando confere se uma alteração não quebrou outra coisa, está fazendo um teste de regressão. Quando repete uma atividade para melhorar o resultado, está usando um processo muito parecido com o de desenvolver software.

Talvez seja isso que eu tenha achado tão legal no episódio: a conversa não ficou restrita a termos técnicos. Ela mostrou que engenharia de software é, no fundo, uma maneira organizada de lidar com problemas: dividir uma situação em partes, experimentar, observar o resultado e melhorar aos poucos.

Muito massa o papo — e uma boa lembrança de que não precisamos conhecer todo o vocabulário para começar a entender como as coisas funcionam.