Como dar autonomia ao Claude Fable para decidir quando testar (e parar de microgerenciar prompts)

Se você usa Claude Code ou Claude Fable 5 no dia a dia, provavelmente já caiu na armadilha de escrever instruções microscópicas: “rode os testes agora”, “atualize esse teste específico”, “não esqueça de rodar o linter”. Funciona, mas cria dois problemas: você gasta tempo ditando passos óbvios e o agente perde a chance de aplicar bom senso em situações que você não previu. Neste tutorial vamos configurar prompts que dão ao Fable liberdade para decidir quando testar, baseado no tamanho e no risco da mudança, e não numa lista fixa de regras.

Por que isso importa

A dica veio direto do time do Claude Code em um fireside chat recente: em vez de dizer exatamente como o agente deve trabalhar, você pode confiar no julgamento dele para decisões operacionais como testes. O ganho prático é duplo. Primeiro, você escreve prompts mais curtos e reutilizáveis, porque não precisa prever cada cenário. Segundo, o agente para de rodar suítes de teste completas para mudanças triviais, o que economiza tempo de execução e ruído no terminal.

Passo 1: identifique onde você está microgerenciando

Antes de mudar o prompt, olhe seu histórico de instruções para o Fable. Se você costuma escrever coisas como as abaixo, é sinal de microgerenciamento:

Rode `pytest tests/` depois de qualquer alteração
Atualize o teste unitário toda vez que mudar uma função
Sempre rode o linter antes de commitar

Essas instruções tratam testes pequenos e grandes da mesma forma. Um ajuste de string em um comentário não precisa do mesmo tratamento que uma nova função de autenticação.

Passo 2: escreva a instrução em termos de critério, não de comando

Em vez de dizer “rode isso agora”, diga qual é o critério para decidir. O Fable consegue interpretar critérios de tamanho e impacto razoavelmente bem. Um exemplo direto de prompt de sistema ou instrução de projeto:

Use testes automatizados apenas para features maiores.
Não atualize nem rode testes para mudanças pequenas,
como ajustes de texto, refactors triviais ou correções
de digitação. Para features novas ou mudanças que alterem
comportamento de lógica de negócio, escreva e rode os
testes relevantes antes de considerar a tarefa concluída.

Repare que a instrução não lista comandos específicos. Ela delega ao agente a avaliação de “isso é grande o suficiente para justificar teste?”.

Passo 3: coloque isso no CLAUDE.md do projeto

Se você usa Claude Code, o arquivo CLAUDE.md na raiz do repositório é o lugar certo para esse tipo de diretriz, porque ele é carregado automaticamente em cada sessão. Um bloco simples:

# CLAUDE.md

## Testes
Use seu julgamento para decidir quando rodar testes automatizados.
Mudanças pequenas (typos, ajustes de copy, refactors sem
alteração de comportamento) não precisam de testes novos.
Features novas, mudanças de API pública ou lógica de negócio
sensível devem vir acompanhadas de testes automatizados
relevantes, rodados antes de finalizar a tarefa.

Se tiver dúvida sobre o tamanho do impacto, prefira rodar
o teste. É melhor gastar alguns segundos a mais do que
deixar passar uma regressão.

Essa última frase é importante: ela dá uma regra de desempate para quando o agente não tiver certeza, evitando que ele simplesmente pule testes por preguiça de avaliar.

Passo 4: aplique o mesmo princípio a outras decisões operacionais

Testes foram o exemplo dado, mas a mesma lógica vale para outras decisões que você costuma ditar manualmente. Alguns candidatos comuns:

• Quando rodar o linter ou formatter automaticamente versus deixar para o commit
• Quando criar branches novas versus trabalhar direto na atual
• Quando pedir confirmação antes de uma mudança versus seguir direto
• Quando gerar documentação para uma função nova

Para cada um, troque a instrução de comando fixo por um critério de julgamento. Exemplo para linter:

Rode o linter automaticamente após qualquer mudança em
arquivos .py ou .ts. Para mudanças em arquivos de
configuração ou documentação, não é necessário.

Passo 5: teste a autonomia com uma tarefa real

Depois de ajustar o CLAUDE.md, valide com uma tarefa mista, que misture uma mudança trivial e uma mudança de lógica, para ver se o Fable diferencia os dois casos. Um prompt de teste:

Corrija o typo no comentário da função `parse_config` em
config.py e depois adicione suporte para carregar variáveis
de ambiente com prefixo APP_ na mesma função.

O comportamento esperado é o agente ignorar testes para a correção do typo e escrever/rodar testes para a parte de variáveis de ambiente, já que essa é uma mudança de comportamento real. Se ele rodar testes para as duas coisas ou para nenhuma, revise a redação do critério no CLAUDE.md, provavelmente falta clareza sobre o que conta como “mudança de comportamento”.

Passo 6: monitore e ajuste ao longo do tempo

Julgamento de agente não é estático. Se você perceber que o Fable está sendo conservador demais (testando tudo) ou relaxado demais (pulando testes que deveriam rodar), ajuste a redação do critério, não adicione uma lista de exceções. Listas de exceção reintroduzem o microgerenciamento que você está tentando evitar. Prefira reforçar o princípio geral:

Ao decidir se uma mudança precisa de testes, pergunte-se:
"isso pode quebrar algo que um usuário real depende?"
Se a resposta for sim ou incerta, escreva e rode o teste.

Dicas finais

Dar autonomia para decisões operacionais não significa abrir mão de controle sobre o resultado final. Você ainda revisa o diff, ainda pode rejeitar uma mudança. A diferença é que o agente para de perguntar ou de executar passos redundantes para cada tarefa pequena, e você escreve prompts mais curtos porque não precisa prever cada cenário possível. Comece aplicando esse padrão só para testes, valide por uma semana de uso real, e depois expanda para linter, branches e documentação conforme o Fable mostrar que interpreta bem os critérios.