Por que pedir para a IA “resumir o chat” é um paradoxo matemático: o que descobri analisando a perda de memória das IAs em projetos longos · trsthales

Fala pessoal!

Se você usa ChatGPT, Claude, Gemini ou Cursor para programar projetos que passam de alguns dias de desenvolvimento, com certeza já passou por isso: no começo do chat a IA é genial, mas na 15ª mensagem ela começa a sugerir refatorações destrutivas, esquece contratos de API que vocês definiram no início e passa a propor bibliotecas que você já tinha testado e descartado.

O ritual que 99% dos desenvolvedores adotaram é mandar: “Resuma o que fizemos até aqui para eu abrir uma nova sessão”.

Depois de analisar a perda de consistência em dezenas de sessões longas, resolvi mapear os motivos pelos quais essa abordagem falha e o que a engenharia de software precisa fazer para resolver a amnésia das IAs.

Aqui estão as 5 descobertas que mudaram a forma como estruturo meus projetos com IA:

1. O paradoxo da amnésia recente:
   Pedir para um modelo cuja janela de contexto já está saturada resumir o próprio estado é pedir para alguém com amnésia lembrar do que acabou de esquecer. A IA descarta silenciosamente as nuances mais críticas (ex: regras de concorrência e constraints de banco) e mantém apenas uma visão superficial das tarefas.

2. Por que RAG e Bancos Vetoriais falham para arquitetura de software:
   Busca por similaridade de cosseno (embeddings) não entende a passagem do tempo. Se você decidiu usar PostgreSQL na semana passada, mas ontem decidiu migrar para SQLite por tenant, o banco vetorial traz ambas as decisões como “relevantes” pela semelhança do texto. A IA recebe informações contraditórias e alucina tentando misturar as duas.

3. Requisito de Negócio NÃO é Decisão Arquitetural:
   Descobri que o maior erro é misturar o “Espaço do Problema” com o “Espaço da Solução”. Um requisito (ex: “isolar dados por escola para conformidade com a LGPD”) é permanente. A decisão técnica (ex: “usar schemas separados vs arquivos de banco isolados”) pode mudar. Quando esses dois conceitos se misturam no histórico, uma refatoração faz a IA esquecer a regra de negócio original.

4. Conhecimento Negativo vale mais que o positivo:
   Registrar o que NÃO funcionou é mais importante do que registrar o que deu certo. Se você gastou 2 horas descobrindo que o erro 403 não era CORS, mas sim o proxy reverso limpando headers, isso precisa ser persistido como “Hipótese Descartada”. Caso contrário, a cada 3 sessões a IA tentará sugerir a mesma correção errada de CORS.

5. A tese: Stateless CPU vs Canonical RAM:
   A conclusão matemática é simples: modelos de IA são unidades de processamento sem estado (stateless compute). O projeto é estado persistente. Tentar guardar a memória viva de um software dentro da thread de chat é uma arquitetura ruim. O único guardião da verdade canônica precisa ser o repositório Git.

Para resolver isso na prática, criei um protocolo de loop fechado e construí uma CLI open-source em TypeScript chamada pactx (@trsthales/pactx).

O motor inspeciona o Git e arquivos canônicos locais (.ai-context/), gera um pacote de contexto compacto (~400 tokens) para o clipboard e ingere atualizações da IA com Write-Ahead Logging (WAL), escrita atômica e proteção contra corrupção em caso de crash.

Documentei toda a arquitetura, o modelo de estado e o código no GitHub:

GitHub: https://github.com/trsthales/pactx
NPM: https://www.npmjs.com/package/@trsthales/pactx

Como vocês têm lidado com a perda de memória e o esquecimento das IAs quando os projetos começam a ficar grandes? Alguém mais já notou esse problema com bancos vetoriais ou resumos manuais?