MÓDULO 2.1 / 4 DE 9
Claude → Codex: separa el cerebro del modelo
Explicar por qué el lock-in está en el runtime y cómo el método Auditar → Adaptar → Probar → Handoff lleva el conocimiento del proyecto a un núcleo portátil.
Página del área: eventos.inema.pro/claude-codex/es/ · en el menú: “migra o mantente independiente”
1La tesis: separa el cerebro del modelo
Qué es
El área Claude → Codex parte de una frase: "No migres tu cerebro. Separa el cerebro del modelo." El "cerebro" es todo lo que has acumulado en un proyecto: contexto, reglas, decisiones, tareas, skills, handoffs y memoria. Según la página, solo CLAUDE.md y AGENTS.md dependen del proveedor; todo lo demás es Markdown portátil, texto simple que cualquier agente puede leer. Cuando ese material está en una capa portátil dentro del proyecto, Claude Code, Codex CLI, Gemini o un modelo local en un contenedor se convierten únicamente en ejecutores, es decir, programas que hacen el trabajo a partir de esos archivos. Cambiar de modelo pasa a ser cambiar un borde, no el centro. El área reúne la tesis, el método, un curso de 3 rutas, un kit de scripts y megaprompts que lo ponen en práctica.
Por qué aprender
Los modelos cambian con frecuencia por precio, acceso o calidad. Si el conocimiento del proyecto está en el lugar correcto, cada cambio cuesta poco en vez de exigir una reconstrucción.
Conceptos clave
cerebro = contexto, reglas, decisiones, tareas, skills, handoffs y memoria; Markdown portátil; ejecutor; cambiar el borde, no el centro
En la práctica
Una analista usa un asistente de código desde hace meses y el equipo decide probar otro. Como las reglas y decisiones del proyecto están en archivos Markdown del repositorio, el nuevo ejecutor lee los mismos archivos y continúa el trabajo.
✓ Hazlo
Enumera tres cosas que tu agente "sabe" hoy sobre un proyecto y anota dónde está guardada cada una.
✗ Evítalo
Juzgar el área por su nombre: lee la idea central en la página antes de decidir si es para ti.
2El lock-in está en el runtime
Qué es
Lock-in significa quedar atado a un proveedor porque salir cuesta caro. La página afirma: "El lock-in no está en el modelo. Está en lo que dejaste dentro del runtime." Runtime es el programa que ejecuta el agente, como Claude Code o Codex CLI. Quien usa un asistente de código durante algunos meses ha acumulado instrucciones, memoria, skills, hooks y miles de sesiones en un formato que solo ese runtime puede leer. La página describe tres cambios: el lock-in es invisible hasta el día del cambio; el mismo conocimiento puede servirle a cualquier modelo; y pasas a tener menos dependencia y más control. El contenido perdura, el formato es desechable, y mezclarlos es lo que bloquea la migración.
Por qué aprender
El área es para quienes usan Claude Code o Codex en proyectos reales y temen cambiar de modelo. Entender dónde está la dependencia muestra qué debe salir del runtime antes de que el cambio sea obligatorio.
Conceptos clave
lock-in; runtime; CLAUDE.md, la memoria nativa y las sesiones JSONL son almacenamiento del trabajo, no el trabajo; contenido duradero, formato desechable
En la práctica
Un desarrollador descubre que las decisiones más importantes del proyecto solo están en el historial de sesiones del asistente. Al cambiar de herramienta, nadie sabe por qué se tomaron ciertas decisiones, porque no se anotó nada fuera del runtime.
3El método: auditar antes de cambiar
Qué es
El método tiene cuatro pasos, en este orden: Auditar, Adaptar, Probar y Handoff, «nunca implementar antes de auditar». Auditar consiste en hacer un inventario de solo lectura de los dos entornos de ejecución: skills, comandos, subagentes, hooks y MCP; cada skill se clasifica como reutilizable, adaptador, nativa o sin resolver. Adaptar consiste en dividir el CLAUDE.md: las reglas portátiles van al AGENTS.md, y lo que depende de un plugin, hook o menú de Claude queda en el archivo específico, que solo importa el contenido portátil. Probar consiste en abrir una sesión nueva y hacer cinco preguntas de continuidad: objetivo y criterio para darlo por listo, una regla con su archivo de origen, la última decisión, la próxima acción y los conflictos. Handoff consiste en registrar decisiones, pendientes, próximos pasos y rutas en un Markdown que la próxima sesión lea antes de actuar.
Por qué aprender
El orden evita el error más costoso: cambiar archivos antes de saber qué existe. Y la regla de prueba evita que confundas un archivo creado con conocimiento realmente utilizado.
Conceptos clave
Auditar → Adaptar → Probar → Handoff; MODE: audit; portátil × residuo; cinco preguntas de continuidad; que el archivo exista no es una prueba
En la práctica
Un equipo quiere llevar un proyecto a Codex. Primero ejecuta la auditoría, que solo lee y clasifica; después separa el CLAUDE.md; por último, abre una sesión nueva y comprueba si el agente responde con la próxima acción y cita el archivo correcto.
Pasos para probarlo
- Abre la página del área junto a esta lección.
- Escribe las cinco preguntas de continuidad en un archivo y responde cada una señalando el archivo de origen.
- Anota en una frase qué cambió en tu comprensión.
4El núcleo portátil, archivo por archivo
Qué es
El núcleo portátil tiene siete ubicaciones, cada una con un responsable y una regla de actualización. AGENTS.md guarda reglas estables y el orden de lectura; context/overview.md, datos verificados con fuente y fecha; context/current-state.md, lo que funciona y lo que está pendiente; context/sources.md, de dónde viene cada información. context/decisions/ contiene una decisión aceptada por archivo; tasks/current.md indica el objetivo, el responsable, el criterio para darlo por listo y la próxima acción; handoffs/latest.md permite continuar en la próxima sesión. La página advierte que estos nombres son convenciones: ningún entorno de ejecución carga esas carpetas por sí solo; lo que indica que deben leerse es el orden de lectura al inicio de AGENTS.md. Cada información tiene un tipo: hecho, preferencia, hipótesis o decisión, y «provenance vence timestamp», es decir, el origen importa más que la fecha y nada se borra; se usa superseded_by.
Por qué aprender
Mezclar hechos con hipótesis, o decisiones con preferencias, hace que el agente repita errores antiguos y contradiga lo que ya se resolvió. El responsable y la fecha permiten promover una información al contexto aprobado, siempre con tu aprobación.
Conceptos clave
AGENTS.md; context/; decisions/; tasks/current.md; handoffs/latest.md; hecho, preferencia, hipótesis, decisión; provenance vence timestamp; secretos fuera del repositorio
En la práctica
En un proyecto con decisiones antiguas en conflicto, cada decisión aceptada pasa a un archivo en context/decisions/. Cuando se sustituye una, no se borra: se le añade la marca superseded_by y el agente deja de seguir la regla anterior.
✓ Hazlo
Crea en un proyecto de prueba el archivo tasks/current.md con el objetivo, el responsable, el criterio para darlo por listo y la próxima acción.
✗ Evítalo
Saltar a la herramienta o al curso sin entender el problema que resuelve el área.
5Migrar o mantener la independencia
Qué es
La página divide la decisión en tres niveles de esfuerzo, no en opiniones. El nivel 1 es importar en la app con un clic: es rápido, pero se limita a lo que acepta el otro lado; por ejemplo, el CLI de Codex no tiene importación nativa. El nivel 2 es migrar con el kit y un comando: ejecutar los scripts de agente-claude-codex para auditar, adaptar, instalar el núcleo, portar skills y probar. El nivel 3 es la capa personal portátil y duradera: el conocimiento vive en el proyecto y el entorno de ejecución se puede intercambiar. Mantener la independencia, es decir, no depender de ningún modelo específico, corresponde al nivel 3 y, según la página, es lo único que sobrevive al próximo cambio. Mantener la independencia no significa abandonar Claude: sigues eligiendo qué herramienta ejecuta cada tarea.
Por qué aprender
No todo el mundo necesita el nivel 3 ahora. La página indica cuándo conviene migrar ya, por costo, acceso o políticas, y cuándo conviene mantener la independencia, por ejemplo, si usas dos herramientas de ejecución o tienes trabajo de clientes.
Conceptos clave
Nivel 1: importar; Nivel 2: migrar con el kit; Nivel 3: capa personal portátil; migrar ahora × mantener la independencia; costo de no hacer nada
En la práctica
Un consultor necesita usar Codex esta semana por la política de un cliente y tiene pocas skills, casi todas en Markdown simple: le conviene migrar ahora. Otra persona ya cambió de herramienta una vez y no quiere rehacer el trabajo: le conviene mantener la independencia.
6Curso, kit y el primer paso
Qué es
El curso Claude → Codex: migra o mantén tu independencia es abierto, está en portugués y tiene versiones en inglés y español; según el programa, son 3 rutas, 18 módulos y 108 temas. La Ruta 1 cubre fundamentos y vocabulario; la Ruta 2 es el kit, comando por comando; y la Ruta 3 presenta seis proyectos sobre un sistema real. El kit agente-claude-codex combina bash y Markdown, y tiene tres formas de uso: scripts, mega-prompts y la plantilla del núcleo portátil. doctor.sh responde «¿mi entorno está listo?» y audit.sh guarda un informe de solo lectura; también están adapt-instructions.sh, init-core.sh, sync-skills.sh con polyskill, readback-test.sh, drift-report.sh y promover-memoria.sh. La página lo resume así: «El mejor primer paso es un proyecto tuyo, en modo audit».
Por qué aprender
El curso explica por qué y el kit hace el trabajo sin borrar nada: no copia en masa ni borra nada de ~/.claude o ~/.codex, e instalar una skill crea una copia de seguridad al lado. Empezar por la auditoría muestra en una sesión qué es portátil y qué depende de un hook.
Conceptos clave
curso de 3 rutas; kit agente-claude-codex; doctor.sh; audit.sh; mega-prompts A y B; Mapa del tema; área hermana Codex + Claude
En la práctica
Una gerente de TI quiere evaluar el cambio de herramienta sin riesgos. Clona el kit, ejecuta doctor.sh, lee la auditoría y solo después decide qué nivel de migración le conviene al equipo.
Criterios para revisar tu ficha
Usa esta rúbrica después del laboratorio. Cada fila pide una evidencia; marcar como leído no significa que completaste la ficha.
| Criterio | Evidencia esperada | Si no cumple |
|---|---|---|
| Idea central | Puedes resumir el área en una frase propia, fiel a la página. | Vuelve a leer la parte superior de la página y el tema 1. |
| Público | Sabes decir para quién es el área y para quién no. | Vuelve al tema 2 y escribe un ejemplo de tu trabajo. |
| Bloques | Puedes nombrar las partes centrales del área. | Usa el diagrama del módulo como guía. |
| Primer paso | Elegiste un paso concreto y pequeño. | Copia el primer paso que recomienda la propia página. |
| Punto de entrada | Sabes qué curso, kit o proyecto abrir primero. | Consulta el tema 6 y la sección de acceso de la página. |
| Fuente | Cada afirmación de la ficha se basa en la página. | Cambia lo que supusiste por lo que dice la página. |
A PRACTICAR / ~10 MIN
Tu primera auditoría en modo audit
Deja abierta la página del área: https://eventos.inema.pro/claude-codex/es/. Usa un ejemplo de tu trabajo, sin datos personales ni de clientes.
Prompt: auditoría de solo lectura de tu proyecto
Pégalo en Claude, ChatGPT o Codex. Cambia lo que está entre < y > por tu situación.
MODE: audit
Lee https://eventos.inema.pro/claude-codex/ para entender el método Auditar → Adaptar → Probar → Handoff.
Después, sin modificar ningún archivo, haz un inventario de este proyecto: <ruta de la carpeta de tu proyecto>.
1. Enumera las instrucciones (CLAUDE.md, AGENTS.md), skills, comandos, hooks y MCP que encuentres.
2. Clasifica cada skill como reutilizable, adaptador, nativo o sin resolver.
3. Separa CLAUDE.md en líneas portátiles (van a AGENTS.md) y residuos específicos de Claude.
4. Di cuáles de las cinco preguntas de continuidad (objetivo y criterio de listo, una regla con archivo de origen, última decisión, próxima acción, conflictos) ya responden los archivos actuales.
Devuelve solo el informe y un plan. No implementes nada.
Criterio de finalización
Explicar por qué el lock-in está en el runtime y cómo el método Auditar → Adaptar → Probar → Handoff lleva el conocimiento del proyecto a un núcleo portátil. Guarda la ficha con la idea central, el público, el primer paso y el punto de entrada.
Abrir la página del área ↗Revisa lo que quedó
Un colega dice que migrar de Claude a Codex es solo copiar el CLAUDE.md a otro lugar. ¿Qué le falta a esa idea?
Ver respuesta comentada
Falta separar lo que es portátil de lo que es residuo y probarlo en una sesión nueva. Como dice la página, que el archivo exista no es una prueba; que el agente lo haya leído y usado, sí.
Si tu respuesta fue distinta, vuelve al tema correspondiente y escribe la diferencia en una frase. La revisión no impide que continúes estudiando.
Resumen del módulo
- cerebro = contexto, reglas, decisiones, tareas, skills, handoffs y memoria; Markdown portátil; ejecutor; cambiar el borde, no el centro
- lock-in; runtime; CLAUDE.md, la memoria nativa y las sesiones JSONL son almacenamiento del trabajo, no el trabajo; contenido duradero, formato desechable
- Auditar → Adaptar → Probar → Handoff; MODE: audit; portátil × residuo; cinco preguntas de continuidad; que el archivo exista no es una prueba
- AGENTS.md; context/; decisions/; tasks/current.md; handoffs/latest.md; hecho, preferencia, hipótesis, decisión; provenance vence timestamp; secretos fuera del repositorio
- Nivel 1: importar; Nivel 2: migrar con el kit; Nivel 3: capa personal portátil; migrar ahora × mantener la independencia; costo de no hacer nada
- curso de 3 rutas; kit agente-claude-codex; doctor.sh; audit.sh; mega-prompts A y B; Mapa del tema; área hermana Codex + Claude
Consulta la fuente
Páginas leídas el 28/09/2026. El contenido de las áreas cambia; la página oficial tiene más validez que este resumen.