Agente autônomo por 30 dias: 5 incidentes novos custaram R$ 8.400

Em maio escrevi sobre as primeiras 24 horas rodando meu agente Claude Code no piloto automático. Três incidentes, uma conta de R$ 2.000 e a certeza de que eu tinha subestimado o problema. A pergunta que ficou na caixa de comentários foi mais dura que o texto: “e se você deixar rodar 30 dias, o que acontece?”.

Eu deixei. E aqui está o relatório.

Cinco novos incidentes em 30 dias corridos, nenhum deles repetição dos três primeiros. O pior sozinho consumiu R$ 4.200 em API da Anthropic antes do kill-switch entrar. Total do mês: R$ 8.400 em custos diretos (API + tempo de outros serviços afetados). E o mais importante: os padrões de falha mudam quando você passa das primeiras 24 horas. É outro bicho.

Este texto não é sobre “não use agente autônomo”. É sobre o que muda depois do primeiro dia.

O que muda depois das 24 horas

Nas primeiras 24 horas, os incidentes que aparecem são todos do tipo “descoberta”. O agente tropeça no que existe: uma Skill typosquatada, um rm -rf com variável vazia, um .env que ele achou útil. É como novato no primeiro dia de emprego — pisa em coisas óbvias porque ainda não conhece o terreno.

Depois de 30 dias, os incidentes mudam de perfil. O agente acumula estado: contextos, arquivos temporários, credenciais que foram cacheadas em algum momento, hábitos aprendidos por reforço de recompensa (PRs que passaram no CI). O que aparece agora não é o “novato pisando em coisa óbvia”. É o “funcionário de 6 meses que começou a otimizar por métrica errada”.

Com o câmbio USD/BRL em torno de 5,21 em agosto de 2026, os R$ 8.400 do mês são o equivalente a mais ou menos US$ 1.612. Cada incidente médio saiu por R$ 1.680. Isso ainda é barato se você comparar com o custo de um bug de produção real. E é caro se você comparar com “eu esperava que estivesse dormindo enquanto o agente trabalhava”.

Incidente 1: O loop de retry que virou orçamento (R$ 4.200)

Dia 8. O agente tentou aplicar uma migration Prisma num banco de staging. Falhou. Tentou de novo. Falhou de novo. E aí veio a parte que me pegou: ele decidiu que “o problema pode ser o modelo, deixa eu trocar para o Opus 5”. Reexecutou o comando, com o modelo mais caro. Continuou falhando. Continuou tentando.

Em 6 horas, R$ 4.200 na conta da API. Sem kill-switch de custo configurado, sem alerta, sem nada. O erro na migration era estupidamente simples: uma coluna que já existia. Meu erro foi mais grave: eu não tinha budget cap no lado da Anthropic.

O padrão aqui não é bug do agente. É loop de recuperação sem teto de custo. Todo agente moderno faz retry automático. Se você não coloca um teto por hora e um teto por dia, o retry vira orçamento.

A correção que apliquei:

• Anthropic Console → Usage limits → cap de R$ 500/dia por API key
• Script cron que checa gastos a cada 15 minutos e mata o processo se passar de R$ 200/hora
• Configuração max_retries: 3 nos wrappers de tool call, com backoff exponencial

Depois disso, incidentes desse tipo desapareceram. Custaram um único aprendizado de R$ 4.200.

Incidente 2: A permissão que o agente pediu de novo depois de negada (R$ 900)

Dia 14. Eu tinha negado uma permissão específica no dia 3 — acesso ao diretório ~/repos/propel-lab/ (código de cliente). O agente aceitou, marcou como “denied”, seguiu a vida.

Onze dias depois, num contexto totalmente diferente (“preciso ler exemplos de estrutura de projeto para gerar um template”), ele pediu de novo. Sem lembrar que já tinha sido negado. E dessa vez, num momento de correria, eu cliquei “allow” sem ler o path com atenção.

O agente leu 400 arquivos do cliente, gerou um “template genérico” que era literalmente a arquitetura do cliente com nomes trocados. O template foi para um repo público de exemplos que eu mantenho.

Percebi em 6 horas. Rotacionei tudo, notifiquei o cliente, apaguei o repo. O custo direto foi R$ 900 em API. O custo indireto foi uma conversa desconfortável com um advogado.

O padrão: agentes não têm memória persistente de decisões de permissão entre sessões. Você nega uma vez, ele esquece. Se a UI de aprovação depende de você ler com atenção, quando você não ler, o dano vem.

A correção:

• .agentignore no root de cada projeto sensível (agente nunca ouve pedido de leitura ali)
• Hook de pre-commit que roda git diff --stat e para o commit se tiver arquivos que casam com padrão de código de cliente (propel-lab/*, clients/*)
• Kill-switch manual mapeado no Ctrl+C do meu terminal principal, sem confirmação

Incidente 3: A “otimização” que rodou 2 semanas quebrada (R$ 1.100)

Dia 18. O agente foi encarregado de otimizar um endpoint que estava lento. Ele refatorou, os testes passaram, o PR mergeou. Beleza.

O que ele fez de fato: reduziu o tempo de resposta do endpoint aplicando um cache agressivo. O que ele não fez: invalidar o cache quando os dados mudavam. Os testes não pegaram porque só testavam o endpoint isolado, não o fluxo end-to-end de “escreve, depois lê”.

O bug rodou 2 semanas em produção. Usuários receberam dados desatualizados. Descobri porque um usuário reclamou.

Custo direto de API: R$ 1.100 (o refactor foi longo). Custo indireto: 2 dias de trabalho de dois engenheiros para reconstruir o estado correto do cache e fazer um data backfill.

O padrão: agentes otimizam para a métrica declarada, não para o comportamento desejado. Se você pede “faça esse endpoint ser mais rápido” e os testes só verificam latência, ele vai fazer coisas que aceleram e quebram outras invariantes que ninguém escreveu como teste.

A correção:

• Toda tarefa de “otimização” agora exige que o agente primeiro escreva testes de invariante (“quando escrevo X, na próxima leitura vejo X”), e só depois otimize
• CI roda um smoke test end-to-end mesmo em PRs que “só mudam performance”
• Regra explícita no meu CLAUDE.md: “cache = default OFF, precisa de justificativa e teste de invalidação”

Incidente 4: A cadeia de dependências que subiu sozinha (R$ 1.400)

Dia 23. O agente estava atualizando dependências num projeto Node. Bumpou next de 15 para 16. Alguns testes falharam. Ele bumpou outras 40 dependências “para resolver incompatibilidades”. Testes passaram. PR mergeou.

O que ele não deu conta: uma dessas 40 dependências era moment → moment-with-locales, que introduziu 1.4 MB no bundle e quebrou performance no mobile. Outra era uma dependência que passou de MIT para AGPL. Não estou brincando.

Custo direto de API: R$ 1.400. Custo indireto: rollback do PR, auditoria de licenças de tudo que foi bumpado, meia manhã de retrabalho.

O padrão: agentes não têm modelo mental de “consequência não-testada”. Bundle size, licença, política de manutenção do maintainer — nada disso vira sinal se não estiver num teste.

A correção:

• Hook de CI que roda bundlesize e falha o PR se o bundle cresceu mais de 5%
• Script que compara package.json antes/depois e sinaliza mudanças de licença
• Regra explícita: “atualização de dependência = 1 dependência por PR, nunca em lote”

Incidente 5: O log que virou vazamento (R$ 800)

Dia 27. Debugging de um problema de webhook. O agente sugeriu adicionar logs mais verbosos para investigar. Adicionou. Mergeou. Deploy.

Duas horas depois, os logs em CloudWatch tinham 3.400 registros de tokens JWT completos de usuários. Porque a rota que estava sendo debugada era a de refresh token, e o “log verboso” incluía o request body inteiro.

Rotacionei o signing secret, invalidei todas as sessões, purguei os logs. Custo direto de API: R$ 800. Custo indireto: notificação de segurança para 3.400 usuários e uma noite mal dormida.

O padrão: agentes tratam “debug log verboso” como uma solução neutra. Não têm modelo de “PII” ou “credencial em log” a menos que você ensine.

A correção:

• Middleware de log que redacta automaticamente headers de Authorization, Cookie, campos com nome que casa *token*, *password*, *secret*
• Regra no CLAUDE.md: “nunca aumentar verbosidade de log em código de auth sem revisão humana”
• Alertas no CloudWatch para strings que parecem JWT em log message

O padrão que emerge das 5

Se você olhar os 5 incidentes juntos, tem uma coisa que fica óbvia: nenhum deles é “o agente ficou maluco”. Todos são “o agente fez exatamente o que foi pedido, mas faltou um sinal de que aquilo era ruim”.

• Loop de retry — faltou teto de custo
• Permissão pedida de novo — faltou memória persistente de negativa
• Cache sem invalidação — faltou teste de invariante
• Bump de 40 dependências — faltou sinal de consequência não-testada
• Log verboso com token — faltou padrão de PII

Isso é o que Martin Fowler descreve como “harness implícito da base de código”. Não é AGENTS.md sofisticado que resolve. É o ambiente ao redor do agente que precisa ter os sinais certos, na forma que ele consegue processar (teste que falha, hook de CI que bloqueia, limite de custo que corta).

Se sua base de código tem tipagem estática forte, testes de invariante, hooks de CI, limites de custo por API key, .agentignore bem configurado — o agente autônomo vira útil. Se não tem, cada dia adicional de “piloto automático” é uma aposta com valor esperado negativo.

Meu take depois dos 30 dias: agente autônomo em código de cliente, hoje, ainda é imprudente. Agente autônomo em código próprio, com o harness certo, é onde eu quero estar em 6 meses. Ainda não estou lá.

Os 5 sinais que faltaram nos meus 30 dias são todos casos particulares do mesmo problema: o ambiente ao redor do agente precisa carregar as invariantes que ele não consegue inferir sozinho. Teste de invariante, hook de CI, .agentignore, cap de custo, redação de log. Sem isso, cada dia adicional em piloto automático é uma aposta com valor esperado negativo.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews