Você configurou sua ferramenta de código com IA no mês passado. Escolheu o modelo, escreveu o arquivo de regras, definiu o style guide. Configuração completa. Seguiu pra trabalhar de verdade, como alguém que tem coisa pra entregar.

Agora a parte que ninguém te avisou: sua ferramenta também seguiu em frente. Só que não abriu um PR antes.

A config que se configura sozinha

Entre 8 e 15 de abril, Anthropic e OpenAI lançaram features que permitem ao seu assistente de código reescrever o próprio manual de instruções. Sem code review. Sem ping no Slack. Sem "opa galera, mudei fundamentalmente como eu abordo todas as decisões de arquitetura de vocês." Apenas mutação comportamental silenciosa, sessão após sessão.

Em 8 e 9 de abril, a Anthropic lançou Managed Agents em beta público. A feature de auto-memory do Claude Code agora grava um arquivo MEMORY.md — um caderninho de "lições aprendidas" que acumula entre sessões. A documentação da Anthropic é direta: "Auto memory permite que o Claude acumule conhecimento entre sessões sem que você escreva nada. O Claude salva anotações para si mesmo enquanto trabalha."

Leia de novo. Para si mesmo. Não pra você. Pra ele mesmo.

Uma semana depois, a OpenAI lançou o Agents SDK v0.14.0 com Sandbox Agents — workspaces persistentes onde o agente gera seus próprios MEMORY.md e memory_summary.md. O SDK injeta esses arquivos na inicialização, moldando o comportamento antes do agente tocar uma única linha do seu código.

Duas empresas. Uma semana. Ambas decidiram que sua IA deveria escrever as próprias instruções operacionais e nunca te mostrar o diff.

Como funciona o diário

Depois de cada sessão, a IA extrai padrões que notou ("esse time prefere tabs"), preferências que inferiu ("eles sempre usam Redis pra cache"), e erros que corrigiu ("não importar aquela biblioteca deprecated"). Grava tudo em arquivos markdown ou stores server-side. Na sessão seguinte, lê o diário primeiro — e aí decide como abordar seu codebase.

O Claude Code também roda um processo de consolidação em background após 24+ horas e 5+ sessões. (A comunidade chama de "Auto Dream", embora a Anthropic não tenha usado esse nome em anúncios oficiais do produto.) Ele comprime transcrições de sessões em memória estruturada, convertendo datas relativas em absolutas. A documentação da Anthropic descreve a consolidação de 913 sessões em aproximadamente 8 a 9 minutos.

Eficiente? Com certeza. Auditado? Absolutamente não.

O buraco de governança

Aqui é onde a coisa fica absurda de verdade. Em qualquer time de engenharia minimamente competente, um typo de uma linha no README gera um pull request. Um ajuste de config exige dois reviewers. Uma atualização de .env dispara uma thread no Slack com três opiniões e um "na verdade..."

Mas a memória auto-escrita da sua IA — o arquivo que determina como ela escreve todo código futuro — recebe zero review. Zero. Nenhuma ferramenta oferece um "PR de memória" pra aprovação do time. O MEMORY.md da OpenAI não tem workflow de revisão. O Memory Store da Anthropic nos Managed Agents guarda blobs opacos server-side que você nem consegue dar git diff.

E a deriva aparece rápido. Desenvolvedores relataram mudanças comportamentais perceptíveis em 10 a 15 sessões. Num caso amplamente discutido, o Claude silenciosamente começou a sugerir Tortoise ORM em vez do SQLAlchemy que o projeto usava — porque uma única sessão de debugging async "ensinou" a ele que o time preferia padrões async-first. Ninguém pediu a migração. Ninguém aprovou. O arquivo de memória decidiu, e o arquivo de memória entregou, em todas as sessões seguintes.

Isso não é um caso hipotético de borda. Mal-entendidos pequenos se acumulam em hábitos persistentes. Sua ferramenta recomenda padrões arquiteturais diferentes na segunda-feira do que recomendava na sexta. Ela sobrescreve as convenções explícitas do seu projeto com preferências que inventou daquele trecho do Stack Overflow que você colou às 2 da manhã enquanto debugava em pânico um incêndio em produção. E como a memória persiste, cada inferência errada vira contexto estrutural pras próximas cem sessões.

O tradeoff honesto

Memória ajuda. Erros repetidos são capturados. Contexto do projeto se mantém entre sessões. Não tenho argumento contra memória — meu argumento é contra memória não auditada com raio de explosão em toda a produção.

Como uma análise da implementação da OpenAI coloca: "Se suas ferramentas não conseguem mostrar o que o agente recuperou e por quê, a memória vira uma caixa preta assombrada."

Você não faria deploy de código que seu colega escreveu sonâmbulo. Então por que está fazendo deploy de mudanças comportamentais que sua IA escreveu sobre si mesma, revisadas por ninguém, com escopo em cada arquivo de cada repo que ela toca?

O que fazer na prática

Trate MEMORY.md e ~/.claude/projects/*/memory/ como configuration-as-code. Isso não é higiene opcional — é a mesma disciplina que você já aplica ao docker-compose.yml e ao .eslintrc:

  1. Versione. Commite os arquivos de memória junto com seu código. Faça diff de cada mudança.
  2. Revise. Adicione diffs de arquivos de memória ao checklist do seu PR. Se a memória mudou, um humano lê antes de ir pra frente.
  3. Audite semanalmente. Coloque um lembrete recorrente pra ler o que sua ferramenta acredita sobre seu codebase. Você vai se surpreender — e ocasionalmente ficar horrorizado.
  4. Resete agressivamente. Quando a memória derivar, apague e comece do zero. É um arquivo markdown, não uma personalidade.
  5. Congele pra trabalho crítico. Em projetos críticos de produção, congele o arquivo de memória e desabilite auto-updates completamente. A auto-melhoria da sua IA não é mais importante que a estabilidade do seu deploy.

Ciclo completo

A ferramenta que você configurou mês passado não é a ferramenta rodando na sua máquina hoje. Ela reescreveu a própria descrição de cargo enquanto você revisava o fix de typo de uma linha de outra pessoa. E vai fazer de novo amanhã, e depois de amanhã, cada vez acumulando o que entendeu errado ontem nas decisões arquiteturais de amanhã.

Seu time exige dois approvers pra fixes de um caractere no README. Comece a revisar o arquivo que controla como sua IA pensa — ou não, e divirta-se descobrindo o que sua ferramenta "aprendeu" sobre seu codebase da pior maneira possível.