Cómo resolver el problema de memoria en proyectos de software desarrollados con IA
A modo de introduccion: Plasmaré alguna cuestiones que resolvi junto con Claude Code, Codex Geminis, Copilot, utilizando Sonnex 4.6, 5 Opus 5.5, Fable, Astra, todo sirve. tambien mas abajo estan los plugins utilizados, Snowtrekk.com es un desarrollo que puedes entrar en la pestaña Turismo ski en los Andes pero es una plataforma mundial basado en nuestra experiencia como esquiadores Itinerantes.
Estos Post lo publicaré también en la pestaña Tecnología ya que el nuevo Paradigma obliga
Los modelos de lenguaje olvidan todo al cerrar el chat. En proyectos reales esto se convierte en un problema serio de productividad y consistencia arquitectónica. Acá describo el sistema que desarrollé para Snowtrekk, una plataforma de turismo de ski en producción construida íntegramente con herramientas de IA.
El problema que nadie menciona en los tutoriales
Cuando empezás a desarrollar software con Claude, Copilot o Codex, los primeros días son notablemente fluidos. Le describís el problema, el modelo lo entiende, produce código que funciona. Hay una sensación casi mágica de velocidad.
Esa sensación empieza a erosionarse en la tercera o cuarta semana.
El modelo no recuerda que la semana pasada decidiste no usar cierta librería y por qué. No recuerda que el puerto 1337 es el backend y el 5173 el frontend. No recuerda que en tu stack de producción hay un caso especial en la autenticación que costó dos días resolver. Cada sesión nueva es, para el modelo, el primer día del proyecto.
El resultado concreto: repetís contexto en cada sesión, el modelo toma decisiones contradictorias a las de la semana pasada, y cada vez que encontrás un bug nuevo en realidad estás redescubriendo algo que ya resolviste. Lo que debería ser una ventaja de velocidad se convierte en deuda acumulada de contexto.
Snowtrekk es una plataforma de turismo de ski premium con tres productos activos: una web (React/Vite + Node/Express), una app Android de tracking grupal y SOS llamada Track, y un scraping tool interno para curar datos de negocios en destinos de montaña. Todo desarrollado por 3 personas, un Arquitecto de Proyecto y 2 Analistas mas, con IA como co-piloto permanente.
El sistema que describo a continuación es el que terminamos armando después de enfrentarnos a este problema en las tres capas del proyecto simultáneamente. No lo encontré documentado en ningún lugar. Lo construimos de manera incremental, por necesidad.
La arquitectura: cinco capas de memoria
La solución no es un solo archivo enorme de contexto que le pegás al modelo al inicio de cada chat. Eso no escala: los modelos tienen una ventana de contexto limitada, y un archivo de 500KB no entra. Además, el 90% de ese contenido es irrelevante para la tarea del día.
La solución es un sistema modular jerarquizado. Cinco capas que se complementan y que cargás selectivamente según lo que vas a hacer.
Capa 1 Los módulos de conocimiento
Cada componente del proyecto tiene su propio archivo Markdown. En Snowtrekk
son trece archivos, todos en un repositorio git local (C:\snowtrekk-docs\)
que mantengo sincronizado manualmente con el Project Knowledge de Claude:
├── 00_INDEX_Mapa_Snowtrekk.md ← el maestro jerárquico
├── HANDOFF_MAESTRO_SNOWTREKK_v2.md
│
├── Modulo_MVP-Web.md ← React/Vite + Node/Express
├── Modulo_Auth-Session.md ← autenticación, cookies, JWT
├── Modulo_Data-Collector.md ← scraping tool interno
├── Modulo_Track-Android.md ← app GPS/SOS/Firebase
├── Modulo_Track-iOS.md ← migración iOS (carpeteado)
├── Modulo_SnowtrekIA.md ← chat IA en producción
├── Modulo_Moments.md
├── Modulo_Explore.md
├── Modulo_Commerce.md ← pagos, pases, alojamiento
├── Modulo_Camino2.md ← asistente IA on-device
├── Modulo_Camino4.md ← “Google Maps de la montaña”
├── Modulo_Infra.md ← AWS, Docker, Firebase, MCPs
└── Modulo_Seguridad.md ← deuda de seguridad, auditorías
Cada módulo tiene un esqueleto fijo. Esto es lo más importante del sistema: la estructura predecible es lo que hace que el modelo sepa dónde buscar qué cosa.
## Estado
[en curso / bloqueado / cerrado / carpeteado]
## Depende de
[[Modulo_Auth-Session]], [[Modulo_Infra]]
## Bloquea a
[[Modulo_Commerce]]
## Decisiones clave
- (fecha) Decisión tomada — y por qué. Siempre el por qué.
## Deuda técnica
- Lista de cosas conocidas que están mal o incompletas
## Pendiente inmediato
← Esta sección se reemplaza al cierre de cada sesiónEl campo más importante es Decisiones clave. No alcanza con documentar qué se decidió: hay que documentar por qué. "Usamos snapping simple en vez de OSRM" no dice nada en tres meses. "Descartamos OSRM porque la red de pistas de Las Leñas tiene solo 24 elementos y un motor de ruteo urbano es sobreingeniería para ese caso" sí dice algo.
Capa 2 El índice maestro y el árbol de relaciones
Este es el único archivo que se carga en todas las sesiones, sin excepción. Tiene que ser liviano — no más de dos o tres páginas — porque entra siempre en el contexto junto con el módulo de trabajo del día.
El árbol de relaciones de Snowtrekk se ve así:
├── Auth / Session (Modulo_Auth-Session) ← bloquea todo login
├── SnowtrekIA (Modulo_SnowtrekIA) ← en producción
├── Moments (Modulo_Moments) ← Fase 1 backend completa
├── Explore (Modulo_Explore) ← en curso
└── Commerce (Modulo_Commerce) ← bloqueado por Auth
Track Android (Modulo_Track-Android)
├── Camino 1 — features activas
├── Camino 2 — asistente IA on-device ← diseño pendiente
└── Camino 4 — ruteo de montaña ← diseño pendiente
Track iOS (Modulo_Track-iOS) ← carpeteado
Data Collector (Modulo_Data-Collector) ← pausado, esperando campo
Infra (Modulo_Infra) ← depende de todos, bloquea deploy
Seguridad (Modulo_Seguridad) ← transversal, deuda abierta
El índice también incluye una tabla de carga selectiva: qué módulos cargar según la tarea del día.
| Si vas a trabajar en… | Cargá estos módulos |
|---|---|
| Bug en el login | Modulo_Auth-Session + Modulo_MVP-Web |
| Feature nueva en el mapa de Track | Modulo_Track-Android + Modulo_Camino4 |
| Datos de un destino nuevo | Modulo_Data-Collector |
| Deploy a producción | Modulo_Infra |
| Auditoría de seguridad | Modulo_Seguridad + Modulo_Auth-Session + Modulo_Infra |
Y los principios no negociables del proyecto — los que nunca deben romperse y que el modelo tiene que conocer en cualquier sesión. En Snowtrekk uno de ellos es: groupCode siempre opcional. Las funciones de SOS, tracking y mapa nunca pueden requerir que el usuario esté en un grupo. Este principio aparece explícitamente en el índice porque si no está ahí, en alguna sesión el modelo va a proponer algo que lo viola.
Capa 3 El protocolo de cierre de sesión
Esta es la pieza que más cuesta adoptar como hábito, pero es la que mantiene el sistema vivo.
Al final de cada sesión de trabajo, le pedís al modelo que genere un párrafo
de cierre con formato fijo. Ese párrafo lo pegás en la sección
## Pendiente inmediato del módulo correspondiente,
reemplazando el contenido anterior — no acumulando.
## Cierre de sesión — 2026-09-24
Módulo a actualizar: Modulo_Auth-Session.md
Qué cambió: implementado fetchWithAuth() compartido en 3 service files
(userService, bookingService, momentsService). Los otros 13 quedan como deuda.
Estado: en curso
Próximo paso exacto: correr grep -r "Authorization" src/services/ para
mapear los 13 files restantes antes de la próxima sesiónLa regla de reemplazar en vez de acumular es deliberada. Si acumulás, en tres semanas tenés cuarenta líneas de pendientes que nadie lee. Una sola sección, siempre fresca, siempre accionable.
Capa 4 El CLAUDE.md por repositorio
Claude Code lee automáticamente un archivo CLAUDE.md en la raíz
de cada repositorio al iniciar cada sesión. Es el lugar donde viven las reglas
operativas del repo: paths, puertos, comandos de deploy, gotchas del entorno.
# CLAUDE.md — snowtrekk-server
## Protocolo de cierre
Al terminar cada sesión, actualizar el Modulo_*.md correspondiente
con el cierre de sesión estándar. Los archivos viven en
C:\snowtrekk-docs\ — escribir directo ahí.
## Reglas permanentes
- Sin Plan mode. Implementación directa.
- git status/diff antes de cualquier commit
- Para deploy: docker compose up -d --force-recreate [servicio]
Nunca usar reload en nginx — hay un bug de inode staleness
- En Windows: pkill no mata procesos node.exe reales.
Usar PowerShell: Get-Process node / Stop-Process -Force
El ítem de Windows merece una aclaración. En un entorno Linux/Mac, pkill
funciona como se espera. En Windows corriendo Claude Code vía WSL o PowerShell,
no mata los procesos node.exe reales del sistema. El resultado:
el proceso viejo sigue sirviendo código antiguo en el puerto, y cualquier fix
parece no funcionar. Costó horas identificarlo. Ahora está en el CLAUDE.md
y nunca más pasó.
Capa 5 La memoria de Claude.ai Projects
Para trabajo de arquitectura y diseño — no implementación — se usa Claude en el navegador dentro de un Project dedicado por proyecto. Claude.ai mantiene memoria persistente entre chats del mismo Project, y los archivos de los módulos se sincronizan manualmente como Project Knowledge.
Esta capa cubre lo que no vive en código: sesiones de diseño de features, decisiones estratégicas, contexto de negocio.
Nota sobre migración: en septiembre de 2026 Claude migró su sistema de memoria interna. Si tu proyecto tiene varios meses de historia, exportá la "memoria heredada" antes de que expire (hay un aviso en la UI con contador de días) y pedile a Claude Code que la importe al sistema nuevo. El contexto acumulado de meses de trabajo no se recupera si se pierde.
El stack de herramientas
El sistema de memoria no funciona en el vacío. Acá está el stack completo que usa Snowtrekk, porque las decisiones de herramientas también son parte del contexto que hay que preservar.
División de trabajo entre modelos
| Herramienta | Uso en Snowtrekk | Nota |
|---|---|---|
| Claude Code (VS Code) | MVP Web — backend y frontend | Prompts en inglés, sin Plan mode |
| Codex (JetBrains, GPT-5.5) | Track Android | Siempre incluir regla de pre-existing changes |
| Claude (claude.ai Projects) | Arquitectura, diseño, diagnóstico | Un Project por producto |
MCPs instalados (scope global — disponibles en todos los repos)
| MCP | Para qué |
|---|---|
| Playwright | Testing automatizado E2E |
| Chrome DevTools | Debugging de frontend en tiempo real |
| Context7 | Documentación actualizada de librerías dentro del contexto del modelo |
| code-graph-mcp | Análisis de símbolos, call graph, impacto de cambios ("blast radius") |
Los MCPs se instalan con scope user para que estén disponibles
en todos los repositorios sin reinstalar. En Windows, al agregar un MCP con
flags adicionales, omitir el flag -y — causa un error de
"unknown option" en PowerShell que no es obvio de diagnosticar.
Cómo iniciar una sesión con este sistema
El flujo completo de una sesión de trabajo:
- Abrís el repo en Claude Code. El
CLAUDE.mdse carga automáticamente. - Pegás el
00_INDEX_Mapa.mdal inicio del chat como contexto. - Agregás el o los módulos relevantes para la tarea del día.
- Trabajás normalmente.
- Al terminar: pedís el cierre de sesión → lo pegás en el módulo → guardás.
El contexto total por sesión es el índice (dos o tres páginas) más uno o dos módulos (una o dos páginas cada uno). Entra cómodo en cualquier ventana de contexto. Y la próxima sesión arranca donde terminó la anterior, en vez de arrancar de cero.
Lo que este sistema no resuelve todavía
Ser honesto sobre los límites es parte del valor de documentar esto.
El sistema depende de sincronización manual. Los módulos no se actualizan solos: hay que pegar el cierre de sesión, hay que subir los archivos al Project Knowledge. Cuando no lo hacés — porque la sesión terminó rápido, porque era tarde — el sistema se desactualiza y pierde valor. La disciplina del protocolo de cierre es más difícil de sostener que la arquitectura del sistema en sí.
Para ese problema específico estamos evaluando claude-mem-lite, un MCP que mantiene memoria persistente entre sesiones de Claude Code vía SQLite local, sin dependencias externas. Todavía en evaluación.
La otra limitación: Track (la app Android) queda fuera del sistema por ahora porque se desarrolla con Codex, no con Claude Code, y el flujo de actualización de módulos está pensado para el segundo. Cuando se cierre el frente activo de Track, habrá que decidir si vale la pena integrarlo o mantenerlo separado.
El resultado
El sistema no es elegante. Es un conjunto de archivos Markdown en un repositorio git local, un archivo de texto en la raíz de cada repo, y el hábito de escribir tres líneas al final de cada sesión.
Lo que produce es que cada sesión nueva con el modelo arranca con contexto real del estado actual del proyecto, no con lo que yo recuerde contarle en ese momento. Las decisiones de arquitectura no se repiten. Los bugs no se redescubren. Los módulos que están bloqueados por otros permanecen bloqueados, y el modelo no propone soluciones que los violan.
En un proyecto de la escala de Snowtrekk — tres productos activos, un operador, decisiones que deben resistir escrutinio de inversores — la coherencia del contexto entre sesiones no es una comodidad. Es una condición de posibilidad.
Snowtrekk es una plataforma de turismo de ski premium en producción, desarrollada
bajo Bigua Group LLC. Este sistema de gestión de contexto emergió de la práctica
real del proyecto, no de un diseño previo.
Si implementás algo similar en tu proyecto y encontrás variantes que funcionan
mejor, me interesa saberlo.
Escribime a sfv2007@gmail.com o info@snowtrekk.com
