Reduzindo o desperdício de tokens e falhas dos agentes Claude com a configuração do Fallow
makedream1 de maio de 2026
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Quem já usou agentes de IA em monorepos de larga escala percebe rapidamente: eles leem milhares de arquivos indiscriminadamente, esvaziando sua carteira, enquanto entregam códigos que, muitas vezes, são lixo sem contexto. Antes de culpar a inteligência do agente, precisamos olhar para o que o estamos alimentando. Aqui está uma maneira específica de usar o Fallow, uma ferramenta de análise de código baseada em Rust, para fazer com que o agente leia apenas o "código realmente crítico".
É irresponsável entregar todo o codebase para o agente. Com excesso de informação, o modelo sofre do fenômeno "Lost in the Middle" (perdido no meio), esquecendo o conteúdo central. Você deve limitar fisicamente o escopo de exploração do agente usando os recursos de indexação do Fallow.
.fallow.json na raiz do projeto. Adicione **/dist/**, **/tests/** e pacotes legados ao array exclude. Reduzir o ruído é a prioridade.rules, defina o limite de high-complexity em torno de 15. Esse mecanismo força o agente a priorizar módulos com alta complexidade cognitiva.strictBoundaries. Isso evita o desastre de o agente ignorar as fronteiras dos pacotes e emaranhar as dependências.Apenas com essa configuração, o número de arquivos lidos pelo agente cai drasticamente. Na prática, bloquear a leitura de arquivos desnecessários pode economizar mais de 40% nos custos de API.
Não deixe o agente encontrar problemas lendo o código linha por linha. Isso é desperdício de dinheiro. É muito mais rápido e preciso fornecer dados estruturais pré-calculados pelo Fallow.
Execute fallow audit --format json > audit_report.json no terminal para extrair violações de arquitetura e relatórios de complexidade. Insira esses dados JSON diretamente na janela de contexto do Claude ou referencie-os no arquivo CLAUDE.md. No prompt do sistema, basta escrever: "Antes de qualquer modificação, verifique obrigatoriamente o verdict e o score de complexity no relatório, e comece o trabalho pelos módulos com menor pontuação".
O desenvolvedor não precisa dar explicações detalhadas. O agente iniciará a "cirurgia" pelo código mais deteriorado, seguindo as prioridades já organizadas pelos dados.
A análise estática sozinha não revela se o código está realmente rodando. O grande vilão dos monorepos é o "código zumbi" — onde a referência existe, mas ninguém o chama na prática. Como provado pelo framework SCARF da Meta, a exclusão segura só é possível unindo análise estática e cobertura dinâmica.
Após coletar os dados de cobertura do V8 (NODE_V8_COVERAGE), execute a função runtime-sync do Fallow. Você obterá uma lista de "funções que possuem referência estática, mas não foram executadas nenhuma vez no último mês". Dê essa lista ao agente e peça que ele solicite aprovação para exclusão. Você ouvirá do próprio agente argumentos como: "Esta função não tem registros de chamada há 6 meses, portanto é seguro removê-la".
Não se deve fazer o merge do código gerado pelo agente só porque ele funciona no momento. É preciso verificar se ele prejudica a legibilidade a longo prazo. O Fallow calcula o Índice de Manutenibilidade (MI) combinando a complexidade de Halstead e o número de caminhos lógicos.
Adicione uma etapa fallow audit --base main --format json ao seu GitHub Actions. Basta configurar para que o build falhe se o health_score cair abaixo de 70.
Este único gate economiza mais de 2 horas semanais do tempo de revisão de um desenvolvedor sênior. Em vez de limpar a sujeira deixada pelo agente, você revisa apenas o design de um código de alta qualidade já validado pela máquina. A diferença de produtividade na colaboração com agentes depende de quão friamente você utiliza essas ferramentas determinísticas.