Checagem: não acredite de cara
Aula 22 de 26 do curso “Vibe coding”. Grátis, com animações e teste.
“Pronto” não quer dizer “funciona”
Você pediu ao agente estatísticas do mês no seu app de treinos. Dois minutos depois: “Pronto, tudo funcionando!”. Parece confiante, mas o agente pode não ter rodado o código, ter testado um caso entre muitos ou não ter notado que quebrou a página vizinha. Lembra do ciclo do esquema: você descreve, a IA escreve, você confere? O último passo é seu, e não dá para pular.
Clique pela prévia
O agente trabalhou numa branch e abriu um PR, então existe um link de prévia: uma cópia do site com a função nova, sem mexer no site no ar. Abra no celular e no computador. Primeiro o caminho normal: registrar um treino, abrir as estatísticas. Depois o estranho: um mês sem treinos, um nome enorme, dois toques no botão. O que quebra costuma quebrar no estranho.
Testes automáticos: checadores robôs
Teste automático é um programinha que confere o seu código. Exemplo: “se há três treinos seguidos, a sequência mostra 3”. Peça ao agente para escrever testes para a função nova e rodá-los, muitas vezes com o comando npm test. A vantagem: na próxima vez que a IA mudar algo, os testes mostram na hora o que quebrou. A pegadinha: um teste que sempre passa. Leia os nomes dos testes: eles devem descrever o comportamento real.
CI: checagem em todo PR
CI (continuous integration, integração contínua): o GitHub roda sozinho os testes e o build em todo PR, por exemplo com GitHub Actions. Build é o passo que transforma o projeto nos arquivos prontos do site. O resultado aparece no próprio PR: um check verde ou um X vermelho, como no cartão do esquema. Vermelho? Não faça merge: abra o log e passe o erro ao agente. Dá para pedir ao próprio agente que configure o CI.
Leia o diff antes do merge
Os checks estão verdes, mas olhe o diff mesmo assim. O que procurar: código apagado que você não pediu, como a linha vermelha “checagem removida?” no esquema. Chaves e senhas no código. Pacotes novos com nomes estranhos: fique com os conhecidos, porque golpistas publicam cópias com nomes parecidos. Mudanças em arquivos que não têm nada a ver com a tarefa. Achou algo? Pergunte ao agente “por quê?” antes do merge.
Checklist antes do merge
Resumindo, cinco itens antes do merge. Prévia conferida no celular e no computador. Testes verdes. CI verde. Diff lido: sem chaves, sem checagens apagadas, sem pacotes estranhos. Commits com mensagens claras. Tudo certo? Merge, e a hospedagem atualiza o site no ar. Algo errado? Corrija na mesma branch. A regra do cartão do esquema: primeiro confira, depois merge. Pratique no simulador do GitHub.
Teste-se
- O agente escreveu “Pronto, tudo funcionando”. E agora?
Resposta certa: Conferir você mesmo a prévia e os testes. O “pronto” do agente não é prova. Ele pode não ter rodado o código ou testado só um caso. A prévia e os testes mostram a verdade. - O que é CI?
Resposta certa: O GitHub roda sozinho os testes em todo PR. CI (integração contínua) roda automaticamente testes e build em todo PR e mostra um check verde ou um X vermelho. - No diff sumiu uma checagem que você não pediu. O que fazer?
Resposta certa: Pergunto ao agente “por quê?” antes do merge. Testes verdes não pegam tudo: podem não notar uma checagem apagada. Resolva antes do merge, antes que a mudança chegue ao site no ar.
← Bugs: lendo o erro Ajudantes do agente: skills e revisão por IA →