Um agente de código é uma ferramenta de IA que trabalha dentro do seu projeto: lê arquivos, edita, executa comandos como os testes e confere o que aconteceu. Um chat comum diz o que mudar; o agente muda. Exemplos conhecidos são Claude Code, Codex e Cursor. Revisar o que ele fez continua sendo seu trabalho.
✅ Testes passando
Uma pergunta do app. Escolha uma resposta.
Você pediu para corrigir uma errata. O diff também muda o cálculo dos preços. E agora?
Talvez, mas ninguém pediu nem revisou. Uma mudança nos preços merece sua própria revisão.
Não fazia parte do pedido. Se acha que há um erro nos preços, que conte à parte e você decide.
Testes testam o que testam. O problema é outro: é uma mudança que você não pediu, em algo delicado.
Você pede para corrigir um erro no formulário de cadastro. Um chat devolve um bloco de código para você colar. Um agente procura o arquivo, edita, roda os testes e conta o resultado. Por dentro costuma haver um modelo de linguagem com ferramentas: decide qual usar, olha o que aconteceu e segue. Por isso é um tipo de agente de IA. Para uma busca longa ele pode lançar um subagente, com contexto próprio.
"Pronto, já funciona" é uma afirmação, não uma prova. O que sustenta isso é um resultado: testes rodados e lidos, com as falhas à vista. E mesmo assim, testes que passam provam o que testam, não o app inteiro.
Muitas ferramentas leem um arquivo de instruções no repo, como CLAUDE.md ou AGENTS.md; qual cada uma lê depende da ferramenta e da configuração. Ali vai o que não dá para deduzir do código: "os textos saem em português, espanhol e inglês", "rode os testes antes de terminar". Esse arquivo costuma ser carregado em cada sessão e ocupa espaço na janela de contexto, então vale deixá-lo curto.
As instruções orientam, não garantem: o agente pode esquecê-las. O que de fato o limita são as permissões, que ações pode fazer e quais pedem sua aprovação. Para mudar um texto do app, ele não precisa de acesso ao banco de dados de produção.
Para uma mudança grande ou arriscada, peça um plano e revise antes que ele mexa em algo. Se o plano inteiro diz "conserto o necessário", peça detalhes. Se propõe criar uma coluna e sua equipe não mexe no banco, corrija ali. Para uma errata, o plano sobra.
Depois, o diff mostra o que mudou de verdade, pedido ou não. Exemplo: você pediu para mudar a cor de um botão e o diff também mexe na validação do login. Isso não fazia parte do pedido: sai e, se precisar, se discute à parte. Cuidado com arquivos novos, que às vezes não aparecem no diff.
Muita gente chama de "vibe coding" programar pedindo tudo ao agente e aceitando o que sai sem ler. Para um protótipo de uma tarde que você vai jogar fora, pode servir. Num projeto com usuários, pagamentos ou dados pessoais, uma mudança que ninguém leu é um risco: o modelo pode inventar uma função que não existe ou "consertar" algo que você não pediu.
Se você está aprendendo a programar, tem mais um motivo: ler o diff é o jeito mais rápido de entender o que o agente fez e por quê. Se aceita sem olhar, o código avança e você não.