Estrutura de colaboração criada para tocar projetos de longo prazo alternando entre vários modelos de IA

Na colaboração com IA, a memória deve estar no repositório, não no chat

Nos últimos meses, tenho feito muito trabalho de desenvolvimento alternando entre vários modelos de IA, como a família GPT-5, Claude, Copilot e Gemini. Antes, usar apenas uma ferramenta já bastava, mas agora se tornou natural escolher o modelo mais adequado de acordo com o tipo de tarefa.

Por exemplo, para projeto de arquitetura, modelos grandes como o GPT-5.4 são mais estáveis; para escrever código, em alguns casos a linha Claude Sonnet / Opus é mais precisa; e para design de frontend ou exploração de ideias, às vezes é mais eficiente usar outros modelos. Além disso, como a velocidade de atualização dos modelos é muito alta, em vez de ficar preso a uma ferramenta específica, acabo mudando a escolha conforme a situação.

O problema começa daqui.
Sempre que trocamos de modelo, sempre que a sessão muda, a IA não se lembra absolutamente nada do projeto. No fim, temos que repetir as mesmas explicações toda vez. É preciso reenviar continuamente o contexto básico: o que é esse projeto, até onde ele já avançou, quais decisões já foram tomadas, que estrutura deve ser mantida e o que não deve ser feito.

No começo era só um incômodo, mas à medida que o projeto cresceu esse custo aumentou de forma visível. Especialmente ao alternar entre vários modelos, tive a sensação de gastar mais tempo reexplicando o contexto do que desenvolvendo de fato. Foi assim que naturalmente cheguei à seguinte pergunta:

"Na colaboração com IA, a memória deve estar no chat ou o próprio projeto deve carregar essa memória?"

Um problema que Prompt Engineering não resolve

Fala-se muito em Prompt Engineering como forma de usar bem a IA. Mas, quando se trabalha em projetos de longo prazo, existe um problema ainda mais importante do que o prompt: a falta de persistência do contexto.

O prompt é uma forma de montar bem uma solicitação única, enquanto um projeto é um processo em que várias tarefas se encadeiam. Para conduzir um projeto com estabilidade, pelo menos as informações abaixo precisam ser mantidas continuamente:

• requisitos atuais
• histórico de decisões tomadas até agora
• plano de trabalho
• tarefas concluídas
• histórico de mudanças
• próximos passos

Se essas informações não forem preservadas, não importa o quão bom seja o modelo: ele acabará repetindo os mesmos erros. Por isso, em vez de focar em criar prompts melhores, comecei a construir uma forma de gerenciar o próprio contexto. Essa abordagem costuma ser chamada de Context Engineering, e eu também passei a aplicar esse conceito à colaboração em nível de projeto depois de enfrentar problemas parecidos.

Não é o chat: o repositório é que deve guardar a memória

A primeira coisa que mudei foi o local onde o contexto fica armazenado. Antes, todo o contexto ficava no chat, mas o chat desaparece quando a sessão termina. Então criei uma estrutura para armazenar o contexto dentro da raiz do projeto.

Criei uma pasta chamada .cowork/ e passei a registrar ali o estado do projeto. Por exemplo: requirements, architecture decision record, lista de tarefas, registros de teste, registros de release e logs de sessão.

Ao iniciar uma sessão, sigo sempre o fluxo de ler o estado atual, montar um plano, aprovar, executar e registrar o resultado. A conversa é efêmera, mas os documentos permanecem. Por isso, mesmo que o modelo mude, o projeto continua.

Regra Plan → Approve → Execute

Um dos problemas que mais encontrei ao colaborar com IA foi a situação em que o modelo já sai modificando o código imediatamente. Ele ignorava decisões anteriores, quebrava a estrutura ou fazia mudanças diferentes da direção que já havia sido acordada.

Por isso, criei uma regra de trabalho: seguir sempre a sequência Plan → Approve → Execute. Primeiro se cria o plano, depois uma pessoa revisa, e só então vem a execução. Só essa regra já reduziu bastante os erros em projetos de longo prazo.

Artifact is Memory

O princípio mais importante desse framework pode ser resumido na frase "Artifact is Memory". A memória não deve estar no chat, e sim nos artefatos do projeto.

Assim, mesmo que o modelo mude, a sessão mude, a ferramenta mude ou a IDE mude, ainda é possível preservar o estado do projeto. Especialmente em ambientes onde vários modelos são usados ao mesmo tempo, esse princípio se torna muito mais importante do que parece.

Os artefatos mencionados aqui não significam apenas documentos escritos desde o início. Nas conversas com a IA, continuam surgindo informações que realmente precisam permanecer no projeto, como refinamento de requisitos, decisões de design, planos de trabalho e resultados de revisão. O problema é que, enquanto esse conteúdo fica preso ao chat, ele tende a ser consumido como contexto descartável de uso único.

Por isso, considero importante uma abordagem que classifique automaticamente e registre os conteúdos significativos das conversas com a IA, para depois reutilizá-los como artefatos do projeto. Não se trata simplesmente de acumular logs de conversa, mas de organizar os pontos centrais que surgiram no diálogo em formas como registros de decisão, documentos de requisitos, planos de trabalho e logs de sessão, deixando tudo em um estado reutilizável.

Desse modo, a conversa deixa de ser apenas uma interface efêmera e se transforma em material de trabalho que continua empurrando o projeto adiante. No fim, acredito que o que precisa ser lembrado não é a conversa em si, mas sim os resultados estruturados extraídos dela.

Problemas que surgem ao trabalhar alternando entre vários modelos

Hoje em dia, é raro usar apenas um único modelo. Como cada modelo tem pontos fortes diferentes, acabamos usando modelos distintos conforme a etapa da tarefa, repetindo atividades como design, alteração de código, review e análise de contexto entre várias sessões e vários modelos.

Nesse momento, se o contexto estiver apenas no chat, será preciso explicar o projeto novamente toda vez que o modelo for trocado. Foi por isso que criei uma estrutura em que o contexto fica no repositório, e não no chat.

O que foi criado: cowork-context-framework

Organizei esse processo e o transformei em um framework. É uma estrutura para armazenar contexto dentro do projeto, restaurar sessões, registrar decisões, acompanhar tarefas e permitir que o trabalho continue mesmo quando o modelo muda.

• GitHub: https://github.com/lim8603/cowork-context-framework

Antes eu usava isso em formato de template e fui validando até certo ponto ao aplicá-lo em projetos reais. Com base nessa experiência, organizei a estrutura e a elevei ao formato de framework. Considero que esta é a forma mínima de estrutura de colaboração necessária para projetos de longo prazo com IA.

Gostaria de saber se alguém já tentou algo parecido

• pessoas que já usaram vários modelos de IA em conjunto
• pessoas que já repetiram a mesma explicação por causa da quebra de sessão
• pessoas que já criaram estruturas como agent / workflow / harness
• pessoas que já gerenciaram o contexto do projeto separadamente

Se você teve uma experiência parecida, gostaria de ouvir sua opinião.