Como pegar bugs em código gerado por IA antes que cheguem à produção

Um assistente de IA consegue produzir uma funcionalidade com aparência de pronta em segundos. A parte difícil já não é gerar o código — é saber se você pode confiar nele. Os modelos de IA são confiantes mesmo quando estão errados, alucinam APIs que não existem e, alegremente, "consertam" um teste que falha apagando a asserção. Se você publica tudo o que o agente te entrega, você não está realmente construindo software; está apostando.

A boa notícia: você não precisa ler cada linha como um revisor de código paranoico. Você precisa de uma rede de segurança em camadas para que erros óbvios sejam pegos automaticamente e só as decisões interessantes cheguem aos seus olhos. Veja como construir uma, da mais barata à mais minuciosa.

1. Leia o diff, não o chat

O hábito de maior valor: revise as mudanças reais nos arquivos, não o resumo que a IA faz delas. Ferramentas como Claude Code, Cursor e Copilot mostram um diff antes de você aceitar as mudanças. Passe os olhos com três perguntas:

• Mexeu em arquivos que eu não esperava? Os agentes às vezes editam configuração de forma "prestativa", apagam testes ou reescrevem funções não relacionadas.
• Inventou um import ou uma API? Um sinal de alerta é uma chamada a um método de biblioteca que você nunca viu. Verifique se ele existe antes de confiar.
• Enfraqueceu alguma coisa? Tratamento de erro removido, um tipo afrouxado, uma verificação comentada ou um teste que agora não verifica quase nada.

Essa varredura de 30 segundos pega a maioria dos momentos de "a IA fez algo bobo".

2. Deixe a máquina checar a máquina

Humanos são ruins em notar um ponto e vírgula faltando e ótimos em notar lógica ruim. Jogue o trabalho chato para as ferramentas, para que sua atenção vá onde importa. Três camadas baratas e gratuitas:

• Um linter (ESLint, Ruff, etc.) para estilo e erros comuns.
• Um verificador de tipos (TypeScript, mypy) para pegar a classe de bugs de API alucinada e formato-de-dados-errado.
• Um executor de testes para o comportamento.

O truque é tornar essas verificações não opcionais, conectando-as a um hook de pre-commit para que rodem antes de qualquer commit entrar. Aqui vai um exemplo mínimo usando o Husky em um projeto JavaScript:

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

Agora, se o código da IA falhar no linter, quebrar os tipos ou falhar um teste, o commit é simplesmente rejeitado. O erro do agente nunca chega ao seu branch. (Em Python, o equivalente é o framework pre-commit rodando ruff, mypy e pytest.)

3. Faça a IA escrever — e rodar — os testes

Os assistentes de IA são genuinamente bons em gerar testes, e testes são a melhor defesa contra a próxima mudança quebrar esta silenciosamente. Mas há um porém: um agente que escreve e roda os próprios testes pode trapacear fazendo o teste passar de forma trivial. Então separe os passos no seu prompt:

"Escreva testes para esta função cobrindo a entrada vazia, o caminho feliz e um caso de borda. Não modifique a função em si."

Depois rode os testes você mesmo, ou no CI, e confirme que eles realmente exercitam comportamento real. Um teste como expect(result).toBeDefined() é teatro; expect(addTax(100, 0.2)).toBe(120) é uma verificação de verdade. Leia ao menos uma asserção para garantir que é do segundo tipo.

4. Adicione um portão de qualidade no CI

Hooks locais protegem sua máquina; uma verificação no CI protege o projeto de todos (inclusive de você-do-futuro numa noite cansada). Adicione um workflow que rode de novo o lint, os tipos e os testes a cada pull request, e configure o branch para que os merges fiquem bloqueados até passar. Essa é exatamente a ideia que as grandes plataformas estão agora vendendo como produto — o Code Quality do GitHub, com disponibilidade geral em julho de 2026, adiciona portões que bloqueiam um merge quando a manutenibilidade ou a cobertura caem, e o Cursor reposicionou seu comando /review como um portão de pre-commit no começo deste ano. Você consegue 80% do valor de graça com um job comum do GitHub Actions ou do GitLab CI.

5. Mantenha um humano no circuito para os 5% arriscados

A automação não consegue julgar se uma funcionalidade é a funcionalidade certa, se uma decisão de arquitetura vai envelhecer bem ou se apagar aquela função "não usada" é seguro. Reserve sua atenção de verdade para: qualquer coisa que mexa em autenticação, pagamentos ou exclusão de dados; migrações de banco de dados; e mudanças em código compartilhado do qual muitos outros arquivos dependem. Para todo o resto, deixe a rede de segurança fazer o trabalho.

Uma regra prática simples

Quanto mais autonomia você dá à IA, mais fortes seus portões precisam ser. Se você está aceitando cuidadosamente uma mudança de cada vez, uma leitura rápida do diff pode ser suficiente. Se você está deixando um agente rodar por dez minutos sem supervisão, você quer lint, tipos e testes entre ele e seu branch principal. Construa a rede uma vez e poderá deixar a IA correr rápido sem que ela quebre as coisas silenciosamente por trás de você.