O Claude Code produz código que funciona mais rápido do que eu consigo ler. Lá pelo meu terceiro projeto de verdade com ele, percebi que o meu dia tinha se invertido: quase nada de tempo digitando código, e a maior parte do tempo conferindo se o que o agente construiu faz mesmo o que eu pedi.
A saída são testes automatizados com o Claude Code: dar ao agente permissão pra rodar testes, fazer ele escrever testes pra tudo o que constrói e ligar hooks pra que os testes disparem sem ninguém precisar lembrar. O agente pega os próprios erros antes de você ver qualquer coisa, e a pilha de revisão encolhe até sobrar só o que precisa mesmo de um humano.
Essa última parte é o objetivo inteiro.
Por que os testes viraram o gargalo
Hoje, verificar é a etapa mais lenta do desenvolvimento com agentes. Gerar código ficou barato; ter certeza de que o código está certo, não. Se você usa um agente de programação todo dia, o seu gargalo já saiu de "escrever a feature" e foi pra "provar que a feature funciona", tenha você dado esse nome ou não.
Já vi esse filme, em velocidade humana. Na Green Hat, antes de a gente ter um pipeline, os desenvolvedores subiam arquivo direto no servidor. Coisa era sobrescrita, ambientes se misturavam, e todo deploy era um pequeno ato de fé. Montamos um pipeline de produção, staging e desenvolvimento em que ir do staging pra produção exigia pull request e aprovação, e os erros de deploy caíram pela metade. Ninguém trabalhou mais. O caminho só deixou de depender da memória de alguém.
Agente de programação recria exatamente o mesmo problema, dez vezes mais rápido. Um agente que edita quinze arquivos em vinte minutos e nunca roda um teste é um dev júnior com acesso FTP à produção. A resposta é a mesma de antes: uma trava determinística que dispara toda vez, sem depender da disciplina de ninguém.
O que são testes automatizados com Claude Code, de fato
Tirando o barulho, testes automatizados com o Claude Code são duas peças mecânicas mais um hábito. As peças: o agente tem acesso suficiente pra rodar a sua suíte de testes de verdade, e hooks no .claude/settings.json rodam esses testes sozinhos em momentos definidos do ciclo, devolvendo as falhas pro contexto do agente pra que ele corrija na mesma sessão. O hábito: mandar o agente escrever e atualizar testes como parte de toda implementação, sempre.
Nada disso é exótico. É a mentalidade de sempre de CI/CD aplicada dentro do ciclo do agente, e não depois dele.
O acesso vem primeiro, e é onde a maioria das configurações falha em silêncio. Se os testes precisam de banco, o agente precisa de banco. Se precisam de uma instalação WordPress, suba um wp-env ou uma stack Docker que o agente possa jogar fora e reconstruir. Um agente que não consegue rodar o teste vai te dizer, todo contente, que ele "passaria", o que não serve pra muita coisa. Escrevi sobre as escolhas de permissão com mais calma em quando seu agente de IA tem as chaves de tudo, mas o resumo é: limite o acesso a um ambiente descartável e seja generoso lá dentro.
A parte do prompt é uma frase que você vai reutilizar pra sempre: "Escreva testes de integração para isso, rode-os e não pare até passarem." Agente é preguiçoso pra terminar. Sozinho, o Claude Code declara vitória em "o código parece correto". A instrução explícita de continuar até a suíte ficar verde muda a qualidade do resultado mais do que qualquer troca de modelo que eu já tentei.
Ligando hooks pra que os testes rodem sem ninguém pedir
Hooks são comandos de shell que o Claude Code roda em pontos fixos do ciclo dele, e são a diferença entre "o agente costuma testar" e "o agente sempre testa". A própria documentação da Anthropic descreve os hooks como controle determinístico, que é um jeito educado de dizer: instrução no CLAUDE.md às vezes é pulada; hook, nunca.
Dois eventos fazem quase todo o trabalho. O PostToolUse dispara depois de cada edição de arquivo; aponte pra uma checagem rápida e restrita, tipo npx jest --findRelatedTests ou phpcs no arquivo que mudou. O Stop dispara quando o agente termina de responder; é ali que vai a suíte completa, porque rodar tudo depois de cada edição trava a sessão.
Uma configuração mínima, com sabor de WordPress:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "phpcs --standard=WordPress \"$CLAUDE_FILE_PATH\" || true"
}
]
}
],
"Stop": [
{
"matcher": "",
"hooks": [
{ "type": "command", "command": "vendor/bin/phpunit --testdox 2>&1 | tail -10" }
]
}
]
}
}
O || true no hook rápido faz diferença: você quer que o agente veja a saída da falha, sem que um erro do formatador congele a sessão inteira. E o tail -10 deixa o resumo da suíte curto o bastante pra informar o agente em vez de inundar o contexto dele.
Mais um detalhe que merece o espaço: hooks PreToolUse que devolvem uma decisão deny bloqueiam a chamada de ferramenta mesmo quando você roda com --dangerously-skip-permissions. Então dá pra dar ao agente bastante autonomia, pela velocidade, e ainda travar de vez os comandos que arruinariam a sua semana. Essa combinação, caminho livre com paredes de concreto, é o que torna viável deixar sessões longas rodando sem supervisão. Ela casa bem com o jeito de trabalhar com skills do Claude Code, em que procedimentos repetidos saem dos prompts e vão morar em arquivos que o agente precisa seguir.
O que muda num projeto de verdade
O efeito prático aparece no trabalho de manutenção, que é a maior parte do trabalho. O WP-AutoInsight passou de 6.000 downloads, e o problema de um plugin nessa escala é que uma atualização descuidada gera ticket de suporte por dias. Quando o agente propõe uma mudança, os hooks rodam o PHPCS no arquivo mexido na hora, e a suíte de testes quando ele termina. Quando eu vou olhar, a falha óbvia já sumiu. A minha revisão vira o que uma revisão deveria ser: essa mudança faz sentido? Ela trata o caso extremo que os testes não previram?
Alguma verificação ainda precisa de um humano. Comportamento da interface em temas diferentes, qualquer coisa que toque em pagamento, e-mail transacional, ações de admin pras quais eu não vou dar credencial a um agente. Nesses casos, faço o agente preparar o trabalho em vez de fazer: montar um checklist do que mudou, onde clicar, como deveria ficar e o que conferir se não ficar, pra minha passada manual levar cinco minutos em vez de trinta. É o mesmo princípio da versão automatizada: diminuir o custo mental de verificar até isso deixar de ser o gargalo.
Essa também é, discretamente, a linha que separa as configurações de agente que aguentam produção das que ficam lindas na demo e morrem, e é por isso que arquitetura de IA em produção passa a maior parte do tempo cuidando da estrutura em volta do modelo. Já escrevi sobre por que demos de IA falham em produção, e o padrão se repete aqui: a demo não tem ciclo de retorno de falha, e a produção exige um. Um agente com estrutura de testes é um sistema. Um agente sem isso é um estagiário muito confiante.
Por onde começar
Não monte toda a aparelhagem no primeiro dia. Acrescente um único hook Stop que rode a suíte de testes que você já tem e conviva com ele por uma semana. Depois acrescente a checagem rápida por edição. Depois as proteções com PreToolUse. Cada camada se paga antes de você colocar a próxima, e se o seu projeto não tem teste nenhum, o primeiro prompt é óbvio: mande o Claude Code escrever. Ele é bom de verdade nisso, o que tem lá a sua poesia.
Os agentes vão continuar ficando mais rápidos. E a distância entre gerar e verificar vai continuar aumentando pra quem não fechar o ciclo.
Pra onde vai o seu tempo de verdade quando você trabalha com um agente?
Se o seu time adotou agentes de programação e a velocidade de entrega subiu enquanto a confiança caiu, essa diferença é problema de processo, e problema de processo tem conserto. Desenhar estrutura de testes e proteções faz parte da consultoria de arquitetura de IA que eu faço. Me conta onde a confiança caiu.