La estructura de colaboración que creé para trabajar en proyectos de largo plazo moviéndome entre varios modelos de IA

En la colaboración con IA, la memoria debe estar en el repositorio, no en el chat

En los últimos meses he estado desarrollando alternando entre varios modelos de IA, como la familia GPT-5, Claude, Copilot y Gemini. Antes bastaba con usar una sola herramienta, pero ahora se ha vuelto natural elegir el modelo más adecuado según el tipo de tarea.

Por ejemplo, para el diseño de arquitectura los modelos grandes como GPT-5.4 son más estables; para escribir código, las familias Claude Sonnet / Opus a veces son más precisas; y para diseño frontend o exploración de ideas, en ocasiones resulta más eficiente usar otros modelos. Además, como la velocidad de actualización de los modelos es muy alta, en lugar de quedarse fijo con una herramienta específica, uno termina cambiando la elección según la situación.

El problema empieza aquí.
Cada vez que cambias de modelo, cada vez que cambia la sesión, la IA no recuerda absolutamente nada del proyecto. Al final hay que repetir siempre la misma explicación. Hay que volver a transmitir una y otra vez el contexto básico: qué es este proyecto, hasta dónde se ha avanzado, qué decisiones ya se tomaron, qué estructura hay que mantener y qué no se debe hacer.

Al principio era solo una molestia, pero a medida que el proyecto crecía este costo aumentó de forma visible. En especial, al ir y venir entre varios modelos, empecé a sentir que se invertía más tiempo en volver a explicar el contexto que en el desarrollo real. Así que naturalmente llegué a hacerme esta pregunta.

"En la colaboración con IA, ¿la memoria debería estar en el chat, o el proyecto mismo debería tener memoria?"

Un problema que no se resuelve con Prompt Engineering

Se habla mucho de Prompt Engineering como forma de usar bien la IA. Pero cuando trabajas en proyectos de largo plazo, hay un problema más importante que el prompt: la falta de persistencia del contexto.

El prompt es una forma de construir bien una sola solicitud, mientras que un proyecto es un proceso en el que múltiples tareas se conectan entre sí. Para avanzar un proyecto con estabilidad, como mínimo la siguiente información debe mantenerse de forma continua.

• Requisitos actuales
• Registro de decisiones tomadas hasta ahora
• Plan de trabajo
• Trabajo completado
• Historial de cambios
• Próximas tareas

Si esta información no se mantiene, por muy bueno que sea el modelo, terminará repitiendo los mismos errores. Por eso, en lugar de enfocarme en hacer mejores prompts, empecé a construir una forma de gestionar el contexto en sí. A este enfoque normalmente se le llama Context Engineering, y yo también, al enfrentar problemas similares, empecé a aplicar este concepto a la colaboración por proyecto.

No el chat: el repositorio debe tener la memoria

Lo primero que cambié fue el lugar donde se guarda el contexto. Antes todo el contexto estaba dentro del chat, pero el chat desaparece cuando termina la sesión. Por eso construí una estructura para guardar el contexto dentro de la raíz del proyecto.

Creé una carpeta llamada .cowork/ y la usé para registrar el estado del proyecto. Por ejemplo, cosas como requirements, architecture decision record, lista de tareas, registro de pruebas, registro de releases y logs de sesión.

Al comenzar una sesión, siempre sigo el flujo de leer el estado actual, planear, aprobar, ejecutar y registrar el resultado. La conversación es efímera, pero los documentos permanecen. Por eso, aunque cambie el modelo, el proyecto puede continuar.

Regla Plan → Approve → Execute

Uno de los problemas más frecuentes que encontré al colaborar con IA fue que el modelo modificaba el código de inmediato. Se repetían casos en los que ignoraba decisiones previas, rompía la estructura o hacía cambios distintos a la dirección ya acordada.

Por eso definí una regla de trabajo: respetar siempre el orden Plan → Approve → Execute. Primero se crea un plan, luego una persona lo revisa, y después se ejecuta. Solo con esta regla, los errores en proyectos de largo plazo se redujeron mucho.

Artifact is Memory

El principio más importante de este framework se puede resumir en la frase "Artifact is Memory". La memoria no debe estar en el chat, sino en los artefactos del proyecto.

Solo así, aunque cambie el modelo, la sesión, la herramienta o incluso el IDE, se puede mantener el estado del proyecto. En especial, en entornos donde se usan varios modelos al mismo tiempo, este principio resulta mucho más importante de lo que parece.

Los artefactos aquí no se refieren solo a documentos escritos desde el inicio. Incluso dentro de las conversaciones con la IA siguen apareciendo informaciones que realmente deberían quedar en el proyecto: refinamiento de requisitos, decisiones de diseño, planes de trabajo, resultados de revisión, etc. El problema es que, mientras todo eso permanezca dentro del chat, se consume fácilmente como contexto de una sola vez.

Por eso considero importante una forma de registrar y clasificar automáticamente el contenido significativo de las conversaciones con la IA, para reutilizarlo luego como artefactos del proyecto. No se trata simplemente de acumular logs de conversación, sino de organizar el contenido clave surgido en el diálogo en formas como registros de decisiones, documentos de requisitos, planes de trabajo o logs de sesión, y dejarlo en un estado reutilizable.

De esta manera, la conversación deja de ser una interfaz efímera y se convierte en material de trabajo que sigue empujando el proyecto hacia adelante. Al final, lo que hay que recordar no es la conversación en sí, sino los resultados estructurados que se extraen de ella.

Problemas que aparecen al trabajar moviéndose entre varios modelos

Hoy en día casi nunca se usa un solo modelo. Como cada modelo tiene fortalezas distintas, se termina usando uno diferente según la etapa de la tarea, y trabajos como diseño, edición de código, revisión y análisis de contexto se repiten entre múltiples sesiones y múltiples modelos.

En ese momento, si el contexto existe solo dentro del chat, hay que volver a explicar el proyecto cada vez que se cambia de modelo. Por eso creé una estructura en la que el contexto no está en el chat, sino dentro del repositorio.

Lo que hice: cowork-context-framework

Organicé todo este proceso y lo convertí en un framework. Es una estructura que guarda el contexto dentro del proyecto, restaura sesiones, registra decisiones, hace seguimiento del trabajo y permite continuar aunque cambie el modelo.

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

Antes lo usaba en forma de plantilla y lo apliqué a proyectos reales, con lo que pasó por cierto nivel de validación. A partir de esa experiencia organicé la estructura y la elevé a formato de framework. Creo que esta es la forma mínima de estructura de colaboración necesaria para hacer proyectos de largo plazo con IA.

Me gustaría saber si alguien ha probado algo parecido

• Personas que hayan usado varios modelos de IA en conjunto
• Personas que hayan tenido que repetir la misma explicación porque la sesión se cortó
• Personas que hayan construido estructuras como agent / workflow / harness
• Personas que hayan gestionado por separado el contexto del proyecto

Si han tenido experiencias similares, me gustaría escuchar sus opiniones.