¿Por qué Cline olvida mi estilo de codificación?

Cline olvida tu estilo de codificación porque cada nueva tarea comienza con una conversación fresca, y las reglas de estilo viven ya sea en tus Instrucciones Personalizadas o en un archivo memory-bank/ o .clinerules mantenido manualmente dentro de un espacio de trabajo. Cualquier cosa que solo le dijiste al agente en el chat se ha perdido. La solución es almacenar el estilo como memoria consultable que el agente carga automáticamente en cada tarea.

Cline es un agente de codificación de VS Code que funciona en modo plan/act y está delimitado al espacio de trabajo actual. Tres decisiones de diseño empujan tus reglas de estilo fuera de la memoria de trabajo del modelo:

1. Las conversaciones son locales a la tarea. Cada Nueva Tarea abre una ventana limpia. Las reglas de estilo que escribiste en medio del chat — "usa clases utilitarias de Tailwind, no styled-components" — solo existieron en esa conversación. La siguiente tarea no las ve.

2. Las Instrucciones Personalizadas son globales, no específicas del proyecto. El campo de Instrucciones Personalizadas de Cline en la configuración aplica las mismas reglas a cada espacio de trabajo. Útil para "siempre escribir pruebas", incómodo para "este repositorio usa Vitest, ese usa Jest". Puedes dividir las reglas en archivos .clinerules por espacio de trabajo, pero tienes que recordar escribirlas y mantenerlas actualizadas.

3. El Banco de Memoria no captura automáticamente las decisiones de estilo. El patrón de memory-bank/ de la comunidad incluye un archivo systemPatterns.md, pero las actualizaciones son manuales. Si decidiste en el chat preferir Result<T, E> en lugar de lanzar, esa decisión vive en la transcripción de la tarea cerrada, no en tu Banco de Memoria.

El resultado: el estilo se aplica durante la duración de una conversación, luego se olvida.

El costo de la deriva de estilo es mayor de lo que parece:

• Diferencias inconsistentes. La mitad de los nuevos archivos usan exportaciones nombradas, la otra mitad usa exportaciones predeterminadas. La mitad usa el helper cn(), la otra mitad importa clsx directamente. Los revisores de código pasan su tiempo en detalles de estilo en lugar de lógica.
• Decisiones re-litigadas. "Acordamos la semana pasada dejar de lado las exportaciones de barril" es algo que Cline propone alegremente de nuevo porque la regla nunca se escribió donde el agente mira.
• Fricción en la incorporación. Un compañero que inicia Cline en el mismo repositorio no hereda tu comprensión del estilo a menos que lo hayas comprometido en .clinerules o en el Banco de Memoria.

La solución no es "escribir Instrucciones Personalizadas más estrictas" — es mantener las reglas de estilo como memoria del proyecto que se carga en cada tarea.

Cline te ofrece tres formas de persistir reglas. Ninguna sobrevive a un cambio de espacio de trabajo sin mantenimiento manual.

Instrucciones Personalizadas es un único campo de texto global en la configuración de Cline. Se aplica a cada proyecto, lo que hace que las reglas de estilo por repositorio sean desordenadas. Terminas ya sea hinchando el campo con las peculiaridades de cada proyecto o escribiendo reglas genéricas que el agente sobrescribe con valores predeterminados razonables.

Archivos `.clinerules` te permiten registrar reglas específicas del repositorio en el control de versiones. Esto se acerca más a lo que quieres, pero el archivo es markdown estático — no hay captura automática, no hay versionado más allá de git, y no hay forma de agregar una regla "desde dentro de una tarea" sin editar manualmente el archivo.

Banco de Memoria (patrón comunitario) almacena convenciones en systemPatterns.md y techContext.md. Mismo compromiso que .clinerules: útil, manual y atrapado dentro de un repositorio. La base de código de código abierto y la documentación de convenciones se encuentran en github.com/cline/cline, si quieres ver cómo la extensión lee estos archivos.

El problema más profundo es que el estilo es un activo del proyecto, no un activo del chat. Probablemente cambias entre Cline, Cursor y Claude Code dependiendo de la tarea. Ejecutas Cline en una laptop y un escritorio. Ninguno de estos comparte .clinerules, y el Banco de Memoria solo viaja si recuerdas comprometerlo.

El estilo de codificación necesita vivir por encima del editor, o se desvía en el momento en que dejas el editor.

MemoryLake es una capa de memoria cruzada que Cline lee en cada tarea. En lugar de editar .clinerules a mano, almacenas decisiones de estilo como Memorias en el proyecto y dejas que cada nueva tarea se abra con ellas ya cargadas.

• Estilo como memoria consultable. "Usamos exportaciones nombradas, Tailwind y tipos Result" vive como Memorias estructuradas, no enterradas en un archivo markdown. Cline recupera las reglas relevantes por archivo que tocas, no un gran volcado de estilo.
• Las mismas reglas en todas las máquinas, compañeros y editores. La memoria de estilo del proyecto es la misma ya sea que abras Cline en tu laptop, tu compañero lo abra en la suya, o cambies a Cursor o Claude Code para una tarea rápida.
• 10,000× el alcance de recuperación de la solicitud en bruto. El motor de recuperación de MemoryLake lee de miles de millones de tokens de memoria del proyecto y alimenta a Cline solo las reglas de estilo que importan para el archivo frente a él.

MemoryLake obtuvo un 94.03% en el benchmark de contexto largo de LoCoMo, el mejor resultado publicado hasta 2026, con recuperación en milisegundos y cifrado de extremo a extremo AES-256.

1. Crea un proyecto y carga tu contexto. Inicia sesión en MemoryLake, abre Gestión de Proyectos, haz clic en Crear Proyecto y nómbralo "Cline — Estilo web de Acme". Sube tus .clinerules existentes, guía de estilo, configuración de ESLint y ADRs a través del Document Drive. Agrega reglas de estilo explícitas — "solo exportaciones nombradas", "clases utilitarias de Tailwind" — como Memorias en la pestaña de Memorias.
2. Genera un endpoint de servidor MCP. Abre la pestaña de Servidores MCP dentro de tu proyecto, haz clic en Agregar Servidor MCP, nómbralo "Memoria de estilo de Cline" y haz clic en Generar. MemoryLake devuelve un ID de clave API, secreto y URL de endpoint. Copia el token Bearer inmediatamente — se muestra solo una vez.
3. Conecta Cline a través de la configuración MCP de VS Code. Abre el panel de Servidores MCP de Cline en VS Code, haz clic en Agregar Servidor, pega la URL del endpoint de MemoryLake y agrega el token Bearer en el encabezado de autenticación. Recarga la ventana. Cada nueva tarea ahora se abre con tus reglas de estilo recuperadas por archivo, sin necesidad de copiar y pegar.