6
trsthales
4 min de leitura ·

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

pactx

Fala pessoal!

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

O ritual que quase todo mundo adotou é mandar: "Resuma o que fizemos até aqui para eu abrir uma nova sessão".

Depois de analisar essa 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ê definiu o uso de PostgreSQL na semana passada, mas ontem resolveu mudar 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.

O que construí para resolver isso: pactx (@trsthales/pactx)

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

O projeto evoluiu bastante nos últimos dias e hoje conta com uma infraestrutura completa de governança e memória:

  • Servidor MCP Nativo (pactx serve --mcp): Conexão direta sobre stdio com Cursor, Claude Desktop e Windsurf, permitindo que os agentes consultem contexto e proponham mutações em tempo real sem fricção de clipboard.
  • Motor Transacional com WAL: Toda alteração canônica passa por Write-Ahead Logging durável (.pactx/transactions/), com escritas atômicas (Write-to-Temp + Rename) e auto-recovery no boot contra kill -9 ou quedas de energia.
  • Modelo de Requisitos (requirements.md): Separação formal do espaço do problema com vínculo bidirecional satisfies nos ADRs (decisions/DEC-%03d.md).
  • Extrator Fora da Banda (pactx extract): Permite exportar o transcript de um chat longo do Claude/ChatGPT/Cursor e processá-lo em duas fases (extração determinística local offline + modelo limpo dedicado com Evidence Spans referenciando o turno de cada decisão).
  • Telemetria de Context Health (pactx status --telemetry): Estimador de tokens determinístico e barra visual no terminal alertando sobre a saturação da janela antes que a IA comece a alucinar.
  • Micro-Âncoras e Diretiva /remember: Permite carimbar decisões durante o chat via comentários HTML invisíveis () ou digitando /remember decision: ... no meio da conversa.
  • Suíte de Governança: pactx status (dashboard com --json), pactx doctor (10 regras de integridade com --fix), pactx diff e pactx rollback (reversão transacional determinística).

Testando em 1 minuto:

  1. Inicializa a estrutura no seu projeto:
    npx @trsthales/pactx init

  2. Empacota o contexto para o clipboard:
    npx @trsthales/pactx

  3. No final da sessão de IA, copie a resposta do /handoff e rode:
    npx @trsthales/pactx update

  4. Veja a saúde e o status do repositório:
    npx @trsthales/pactx status

Links do Projeto:

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

Carregando publicação patrocinada...
1

O ponto 1 é onde eu bati de frente. Pedir resumo pra um contexto saturado é o problema em si, então acabei atacando pelo outro lado: avisar antes da saturação.

Aqui um hook roda a cada prompt e calcula a porcentagem de contexto usada direto do transcript. Passando de 60%, avisa. Uma vez só, com três linhas junto: plano ativo, fase atual, última decisão. E quando a compactação acontece de fato, quem escreve o state não é o contexto saturado, é uma chamada separada que lê o transcript inteiro e preenche dez seções fixas.

Tá aqui, MIT, derivado do compact-plus do u-ichi: github.com/kenimo49/compact-ops (preso ao Claude Code, então numa camada bem diferente do pactx).

4

Sensacional essa sacada do compact-ops! O ponto de delegar a escrita do state para uma chamada separada e limpa (fora do contexto saturado) é o desenho perfeito para resolver o paradoxo.
Pedir pro modelo cansado resumir o próprio histórico é o erro comum; fazer um processo limpo ler o transcript bruto e extrair o estado canônico elimina as alucinações de auto-resumo.
Achei muito elegante essa separação de camadas:
-O compact-ops atua como o 'gerenciador de memória de curto prazo / prompt hook' dentro do runtime do Claude Code, monitorando o threshold de 60% em tempo real.
-O pactx atua na camada de 'persistência canônica de longo prazo', garantindo que essas decisões, requisitos e hipóteses descartadas virem commits com garantias transacionais (WAL, ADRs, patch semantics) independentemente da IA ou interface que você usar.

A ideia de disparar o alerta aos 60% com a micro-âncora de 3 linhas (plano, fase, última decisão) é cirúrgica pra evitar degradação de atenção. Dei uma olhada no repo e deixei a estrela lá no GitHub, parabéns pela engenharia do projeto!

2
1