🧠 Por qué separar el cerebro del modelo
Todo el mundo pregunta "¿cómo migro de Claude a Codex?". La pregunta correcta es otra: ¿qué parte de tu trabajo sobrevive al cambio de modelo? Este módulo muestra dónde estás atrapado sin darte cuenta, qué es duradero de verdad, y el principio que guía todo el curso: no migres el cerebro, separa el cerebro del modelo.
🔒 El lock-in invisible
No firmaste ningún contrato, pero estás atrapado. Cada regla que escribiste en un CLAUDE.md, cada dato que Claude guardó en su memoria, cada sesión que quedó grabada en un archivo JSONL: todo eso solo lo lee Claude. Si mañana abres Codex, empieza desde cero, como si nunca hubieras trabajado. Eso es lock-in, y es invisible porque creció un archivo a la vez.
¿Nuevo por aquí? Lock-in es quedar atado a un proveedor porque salir cuesta caro. CLAUDE.md es el archivo de instrucciones que Claude Code lee al abrir una carpeta. JSONL es un formato de texto con un objeto JSON por línea; así es como Claude graba el historial de cada sesión. A ningún otro programa le importan esos archivos.
📊 El tamaño del problema en una máquina real (diagnóstico del 2026-09-14)
- •165 proyectos con CLAUDE.md, y solo 54 con AGENTS.md (el archivo que lee Codex).
- •869 archivos de memoria en 227 carpetas, que solo Claude abre.
- •6.859 sesiones JSONL, 2,3 GB de historial que ninguna otra herramienta puede usar.
- •Codex, instalado en la misma máquina, sin instrucciones globales y sin MCP: cada sesión empieza a ciegas.
✓ Señales de que vas bien
- ✓Tus reglas están en un archivo que cualquier herramienta lee.
- ✓Un colega abriría tu proyecto y entendería el estado sin ti.
- ✓Sabes dónde está la última decisión tomada.
✗ Señales de lock-in
- ✗"Claude lo sabe" es la respuesta a dónde está alguna información.
- ✗Cambiar de herramienta significa volver a explicar todo.
- ✗El historial de la sesión es la única fuente de lo que se decidió.
Conceptos clave
Dependencia que crece sin contrato, un archivo a la vez.
Instrucciones que solo Claude Code lee.
Hechos guardados en el formato de una sola herramienta.
Historial en bruto, gigante, ilegible para otra herramienta.
🗂️ Qué es durable y qué es desechable
No todo merece ser migrado. La mayor parte de lo que está en la carpeta de Claude es rastro: sesiones viejas, intentos descartados, archivos muertos. Lo que vale la pena es pequeño y tiene forma de documento: qué es el proyecto, qué se decidió, qué está en curso, cómo se hace cada cosa. Separar los dos es el primer trabajo, y es más limpieza que ingeniería.
Mira el centro: lo que es tuyo vive en Markdown dentro del proyecto. Las cajas azules en los bordes son solo ejecutores; cualquiera puede cambiarse sin que el centro cambie.
✓ Durable: vale la pena migrar
- ✓Contexto del proyecto: qué es, para quién, qué funciona.
- ✓Decisiones aceptadas, con fecha y motivo.
- ✓Playbooks y skills: cómo se hace cada tarea.
- ✓Handoffs: dónde quedó y qué viene después.
✗ Desechable: archiva por defecto
- ✗Sesiones JSONL enteras (2,3 GB de conversación en bruto).
- ✗Memoria automática sin aprobación (869 archivos que nadie revisó).
- ✗Configuración de plugin y hook: es de la herramienta, no tuya.
- ✗Skills archivadas que no usas desde hace meses.
💡 Consejo práctico
Regla del texto base: archiva por defecto, trae de vuelta solo cuando lo necesites. Antes de migrar cualquier cosa, haz la limpieza de tu "segundo cerebro". Migrar rastro solo transporta ruido a la herramienta nueva.
Conceptos clave
Contexto, decisiones, playbooks, handoffs: lo que sobrevive al cambio.
Historial en bruto y configuración de herramienta.
Lo normal es guardar lejos; el contexto entra solo cuando se usa.
Texto simple que cualquier herramienta lee. Es el formato del cerebro.
🔄 Los modelos cambian, tu estructura se queda
Mira la línea de tiempo de los últimos meses: un modelo nuevo cada pocas semanas, cada uno con su nombre, su harness y sus manías. Si tu forma de trabajar depende de un modelo específico, envejece a la misma velocidad. Si depende de una estructura de archivos, envejece a la velocidad del Markdown, es decir, casi nunca.
¿Nuevo por aquí? Modelo es el cerebro de IA en sí (Claude, GPT, DeepSeek). Harness es el programa que le da manos y ojos al modelo: lee archivos, ejecuta comandos, mantiene el historial. Claude Code y Codex CLI son harnesses. El módulo 1.2 profundiza en estos términos.
Ayer: un harness, un modelo
Elegiste una herramienta y moldeaste todo en ella: reglas, memoria, atajos. Funcionaba, y el precio quedó escondido.
Hoy: dos o tres harnesses en la misma máquina
Claude para una cosa, Codex para otra, un modelo local para la tarea barata. Cada uno empieza de cero porque el cerebro se quedó en el primero.
Mañana: el modelo que todavía no conoces
Va a aparecer. La única pregunta es si vas a volver a explicar todo o vas a apuntar a una carpeta y decir "lee esto".
🧭 La frase que resume el curso
"Lo que realmente debe sobrevivir al cambio de modelo no es Claude, Codex ni Gemini. Es tu capa de contexto, conocimiento, Markdown, procesos, handoffs, memoria y herramientas."
Los modelos pueden cambiar. Tu estructura de trabajo debe seguir funcionando.
Conceptos clave
Modelo: semanas. Markdown: años.
Cualquier harness que lee la capa portátil y actúa.
Carpetas y archivos con un rol definido, no una conversación.
La prueba: ¿apuntar a una carpeta reemplaza volver a explicar?
⭕ El Diagrama de Venn: común vs específico
El texto base da un ejemplo con dos clientes, North Star y Harbor: descubre lo que los dos tienen en común, centraliza esa parte y mantén carpetas separadas solo para lo que es exclusivo de cada uno. La misma lógica vale para herramientas. Lo que Claude y Codex tienen en común es casi todo: reglas, contexto, decisiones, skills en Markdown. Lo que es específico cabe en dos archivos.
El área verde del centro es donde vive tu trabajo. Las puntas azules son pequeñas a propósito: solo lo que la herramienta exige. Si las puntas crecen, estás reescribiendo lo común dos veces.
📐 La parte específica es más pequeña de lo que parece
Según el texto base, solo AGENTS.md y CLAUDE.md están fuertemente ligados al proveedor. Gemini también lee AGENTS.md; a GLM se le puede indicar que lo respete. CLAUDE.md es la excepción. Prácticamente todo lo demás es Markdown portátil.
En la máquina auditada: del CLAUDE.md global de 72 líneas, 71 eran portátiles y 7 eran específicas de Claude (menús interactivos, plugins, hooks). Esa es la proporción que debes esperar.
Conceptos clave
Lo que todas las herramientas usan. Centralízalo aquí.
Lo que es exclusivo de cada una. Mantenlo pequeño.
El archivo de instrucciones que Codex, Gemini y otros leen.
Cuanto más grande es el centro, menos escribes dos veces.
💸 El costo de no hacer nada
No separar el cerebro del modelo parece gratis, porque hoy nada se rompe. El costo aparece en pequeñas dosis: el Codex que responde mal porque no leyó tus reglas, la decisión tomada dos veces porque se perdió en una sesión, la skill copiada a mano que se desvió de la original, el colega (o tú dentro de tres meses) que no sabe por dónde empezar.
✗ Lo que pagas sin darte cuenta
- ✗Volver a explicar el proyecto a cada herramienta nueva.
- ✗Skills que se desvían: en la máquina auditada, 4 lugares distintos consumían skills sin una fuente única.
- ✗Decisiones contradictorias porque la versión "correcta" era la más reciente en la conversación.
- ✗Imposible delegar: solo tu cuenta de Claude "sabe".
✓ Lo que la separación te devuelve
- ✓Cualquier ejecutor entra al proyecto y lee la misma verdad.
- ✓Una skill, N copias generadas, con verificación de divergencia.
- ✓Cada decisión tiene archivo, fecha y responsable.
- ✓Puedes cambiar de modelo en una tarde, no en un mes.
⚠️ Advertencia honesta del texto base
"Todo esto es iterativo. Cada cambio puede mejorar una skill para un modelo y romper esa misma skill para otro." Separar el cerebro no elimina el mantenimiento; pasa a ocurrir en un solo lugar, en vez de en cada herramienta.
Conceptos clave
Se paga en pequeñas dosis, nunca en una factura.
Copias que se desvían de la original con el tiempo.
¿Otra persona u otro agente puede continuar?
Un lugar para editar, N lugares para generar.
🧩 El principio central
Siete palabras forman la capa que sobrevive: contexto, conocimiento, Markdown, procesos, handoffs, memoria y herramientas. Cada una se convierte en una carpeta o un archivo de tu proyecto, y cada ruta de este curso muestra cómo. Guarda la lista; es el mapa de lo que vas a construir.
Contexto y conocimiento
Qué es el proyecto, qué es verdad hoy, de dónde salió cada hecho. Se convierte en context/overview.md, current-state.md y sources.md.
Markdown y procesos
El formato y los "cómo se hace": AGENTS.md, skills, scripts. Portátiles porque son texto.
Handoffs y memoria
Dónde se quedó y qué se aprendió: handoffs/latest.md y hechos promovidos con aprobación.
Herramientas
MCP y scripts, registrados por herramienta pero haciendo referencia a las mismas claves y a los mismos datos.
🎯 Resumen en una frase
No migres tu "cerebro" de Claude a Codex; separa el cerebro del modelo.
Claude, Codex, Gemini o modelos locales pasan a ser solo ejecutores sobre una capa de contexto portátil.
Conceptos clave
Contexto, conocimiento, Markdown, procesos, handoffs, memoria, herramientas.
Lo que corre por encima de la capa. Intercambiable.
Lo que se queda. Tuya, en Markdown, dentro del proyecto.
El verbo de todo el curso.
Autoevaluación (opcional): ¿qué frase resume mejor la tesis de este módulo?
🎯 Resumen del módulo
Próximo módulo:
1.2 — El vocabulario: runtime, harness, skill, MCP, hook, handoff