Cómo migrar de Devin a Claude Code sin perder el contexto (2026)

Cualquier cosa que Devin haya aprendido de tu repositorio no necesita migración. Esto es lo primero que hay que establecer, porque reduce enormemente el trabajo. La documentación de Devin indica que genera Knowledge automáticamente a partir de los README existentes, la estructura de archivos y el contenido de los repositorios conectados, y que extrae y actualiza Knowledge de los archivos de instrucciones del agente, incluidos CLAUDE.md y AGENTS.md. Si una nota de Knowledge es una reformulación de tu README, ya está en el repositorio que leerá Claude Code.

Lo que escribiste directamente en Devin es la parte insustituible. Las notas que no existen en ningún otro lugar —el orden de despliegue, la peculiaridad de una herramienta propietaria, la razón por la que un directorio está fuera de los límites— viven en la aplicación web de Cognition. La documentación de Devin describe Knowledge como "una colección de instrucciones y consejos que Devin puede consultar en todas las sesiones", y documenta cómo crearla, activarla y fijarla. No documenta una exportación, y no hay ninguna forma de evitarlo. Leer y copiar es el camino.

Los disparadores importan tanto como el texto. Esta es la pieza que la mayoría de la gente pierde. La recuperación de Devin es condicional: "Knowledge se recupera en función del disparador (Trigger) que configures. Cuanto más específico sea el disparador (por ejemplo, a qué archivo, repositorio o tipo de tarea se aplica Knowledge), mejor será la recuperación". Una nota más su disparador es una regla con alcance. Una nota sin su disparador es una frase que cargarás en cada sesión o que olvidarás por completo. Cuando recopiles, recopila ambas columnas.

Fijar (pinning) también es información de alcance. Puedes fijar una nota de Knowledge a todos los repositorios o a un repositorio específico. Eso se mapea directamente en la jerarquía de memoria de Claude Code, así que anótalo a medida que avanzas: una nota fijada en todas partes se convierte en una instrucción a nivel personal o de organización, y una nota fijada a un solo repositorio se convierte en las instrucciones confirmadas (committed) de ese repositorio.

Lo que te ofrece Claude Code del otro lado. Archivos CLAUDE.md, cargados al inicio de cada sesión, resueltos de lo general a lo específico: un archivo gestionado por la organización, luego ~/.claude/CLAUDE.md para tus preferencias personales, luego el ./CLAUDE.md o ./.claude/CLAUDE.md del proyecto confirmado para tu equipo, y luego ./CLAUDE.local.md para notas privadas por proyecto. Los archivos que están por encima de tu directorio de trabajo se cargan por completo al inicio; los archivos en subdirectorios se cargan cuando Claude lee archivos allí. Para la carga condicional existe .claude/rules/, donde un archivo de regla puede llevar frontmatter paths: y solo entrar en contexto cuando Claude toca archivos que coinciden; el equivalente estructural más cercano a un disparador de Devin que existe en Claude Code.

Dos notas honestas antes de empezar. Knowledge de Devin es una función real que hace un trabajo real, y la razón por la que esta migración es molesta es que estás dejando algo funcional en lugar de escapar de algo roto. Y Claude Code tampoco es un sistema de memoria: su documentación es explícita al señalar que los archivos de instrucciones son "contexto, no configuración obligatoria", sin garantía de cumplimiento estricto. Si una regla debe cumplirse siempre, la documentación te remite a los hooks, no a una frase mejor redactada.

Paso 1: Recopila Knowledge antes de perder el acceso y clasifícalo por origen

Abre tu lista de Knowledge y copia cada nota en un archivo borrador, capturando tres cosas por nota: el texto, el disparador y a qué está fijada. Haz esto mientras tu suscripción esté activa. Todo lo demás en esta migración es repetible; esto no.

Luego clasifica cada nota en uno de tres montones según su origen:

Derivado del repositorio. Reformulaciones del README, el diseño del directorio, el comando de prueba tal como está escrito en package.json. Elimina estos. Claude Code leerá el repositorio y /init generará un CLAUDE.md inicial a partir de lo que encuentre. Copiarlos solo crea un archivo largo que reduce el cumplimiento de las instrucciones.

Escrito por ti, aún vigente. El orden de despliegue, la herramienta que necesita un flag específico, el módulo que nadie debería refactorizar este trimestre y por qué. Estos son la migración.

Escrito por ti, ya no vigente. Cada colección de Knowledge tiene de estos: notas para un servicio que fue desmantelado, una solución temporal para un error que ya se solucionó. Dejar una regla obsoleta en un archivo de instrucciones es peor que perderla, porque Claude la seguirá. Elimina deliberadamente, ahora, mientras recuerdes cuál es cuál.

Una pista útil mientras haces esto: las sesiones de Devin muestran a qué Knowledge accedieron. Por lo tanto, las sesiones recientes te dicen qué notas se activan realmente en la práctica. Una nota que no se ha recuperado en un mes está mal activada o ya no es relevante, y en cualquier caso es candidata para el tercer montón.

Paso 2: Reconstruye las notas como CLAUDE.md y reglas con alcance de ruta

Ahora coloca las notas supervivientes de acuerdo con el alcance que registraste, no todas en un solo archivo:

• Fijado a todos los repositorios, personal → ~/.claude/CLAUDE.md. Tus hábitos, tu flujo de trabajo preferido. Mantenlo corto; se carga en cada proyecto de tu máquina.
• Fijado a todos los repositorios, estándares de todo el equipo → el CLAUDE.md del proyecto en cada repositorio, o el archivo de política gestionado de tu organización si tu equipo despliega uno de forma centralizada.
• Fijado a un repositorio → el ./CLAUDE.md raíz de ese repositorio, confirmado, para que tus compañeros de equipo lo hereden en lugar de tener que redescubrirlo.
• Activado en archivos específicos o en un tipo específico de tarea → un archivo en .claude/rules/ con frontmatter paths: que coincida con esos archivos. Esto es lo más parecido a lo que hacía tu disparador de Devin: paths: ["src/api/**/*.ts"] carga esa regla cuando Claude trabaja en la capa de la API y la mantiene fuera del contexto en caso contrario.
• Privado y específico del proyecto → ./CLAUDE.local.md, en el gitignore.

Dos detalles mecánicos ahorran problemas aquí. La documentación de Claude Code recomienda apuntar a menos de 200 líneas por CLAUDE.md, porque los archivos más largos consumen más contexto y reducen la consistencia con la que se siguen las instrucciones; por lo tanto, el triaje del Paso 1 no es por orden, es lo que hace que el resultado funcione. Y si tu repositorio ya tiene un AGENTS.md que Devin estaba leyendo, no lo dupliques: crea un CLAUDE.md que lo importe con @AGENTS.md y añade instrucciones específicas de Claude debajo, para que ambas herramientas lean una sola fuente.

Finalmente, ten en cuenta la asimetría que acabas de sortear. Devin estuvo leyendo los archivos de agente de tu repositorio todo el tiempo. Claude Code puede leer archivos .devin/rules/ de una configuración de Devin Desktop cuando ejecutas /init con el nuevo flujo interactivo habilitado, e /import puede traer la configuración de un agente compatible. Lo que ninguna herramienta puede leer es el Knowledge que solo existió en una aplicación web. La lección no es sobre Devin; es que el conocimiento almacenado en la interfaz de usuario de un proveedor es conocimiento que copiarás a mano algún día.

Acabas de pasar una hora convirtiendo el almacén de conocimiento de un proveedor en archivos. Esos archivos son una mejora real: controlados por versiones, revisables, buscables con grep, portátiles. Pero mira lo que tendrías que hacer de nuevo si añadieras Codex el próximo trimestre, o si un compañero de equipo quisiera el mismo contexto en ChatGPT mientras escribe las notas de la versión: estarías copiando, una vez más, desde un lugar que solo lee una herramienta.

La solución es mantener el material duradero en un almacén que lean todos los asistentes, y dejar los archivos de instrucciones para lo que son buenos: las reglas cortas y estrictas que un agente de programación necesita tener frente a él en todo momento.

MemoryLake es una capa de memoria para eso: las decisiones, el historial de incidentes y los documentos de origen detrás de tus reglas en un solo lugar, legibles directamente desde herramientas compatibles con MCP como Claude y Codex, y desde ChatGPT a través de la API. Las reglas se quedan en el repositorio; las razones dejan de vivir en la base de datos de un solo producto.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Manténla en tu entorno o en un gestor de secretos en lugar de pegarla en una sesión.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos detrás de las notas que acabas de migrar: el manual de procedimientos (runbook) del que provino el orden de despliegue, el informe de incidentes que hizo que un directorio estuviera fuera de los límites, las decisiones de arquitectura, las peculiaridades de la API del proveedor que documentaste una vez. Sube las fuentes en lugar de la versión de una sola línea; la versión de una sola línea es lo que acabas de pasar una hora reconstruyendo.

Paso 3: Conecta tu IA y agentes

Dale acceso a la memoria a Claude, Codex, OpenClaw y otros agentes de IA a través de MCP o la API. Claude Code lee el almacén directamente sobre MCP junto con tus archivos CLAUDE.md. Para ChatGPT, recupera lo que necesites a través de la API e inyéctalo en el prompt o en el flujo de trabajo que llama al modelo.

La primera diferencia es que la razón viaja con la regla. "Ejecuta la migración antes del despliegue en staging" es una regla que se sigue hasta que alguien decide que parece redundante. "Ejecuta la migración antes del despliegue en staging: los despliegues desordenados tumbaron staging dos veces en marzo, ver el informe" es una regla que sobrevive al criterio de un nuevo ingeniero.

La segunda es que tu CLAUDE.md puede seguir siendo corto. Toda la tensión en los archivos de instrucciones radica en que todo lo útil quiere estar en el archivo que siempre se carga, y el archivo que siempre se carga empeora a medida que crece. Con la recuperación disponible para los detalles, el archivo contiene las restricciones estrictas y nada más, lo cual también es la solución para un agente que vuelve a leer tu base de código en cada sesión en lugar de comenzar desde lo que ya se conoce.

La tercera es que la próxima migración es barata. Esta te costó una hora de copiar desde una interfaz de usuario. La siguiente te costará un cambio de configuración, porque el conocimiento no está dentro de la herramienta que estás dejando.

Y se complementa con lo que Claude Code ya hace. Su memoria automática sigue acumulando comandos de compilación e información de depuración por su cuenta, de manera útil y por repositorio. Vale la pena conocer sus límites: ese almacén es local de la máquina, y su documentación dice que los archivos no se comparten entre máquinas ni entornos en la nube. Por lo tanto, es una buena capa de conveniencia local y un mal sistema de registro, que es exactamente la división del trabajo que deseas.

Recopila mientras aún tengas acceso

Knowledge, las memorias y el contexto guardado son visibles hasta el momento en que expira la suscripción, y ni un minuto después. Haz la copia primero, la reorganización después. Este es el único paso de toda la migración que tiene una fecha límite.

Registra el disparador, no solo el texto

Las condiciones de recuperación son información. Una nota que se activaba cuando Devin tocaba el módulo de pagos se convierte en una regla con alcance de ruta; la misma nota con la condición olvidada se convierte en ruido en cada sesión o en una regla que eliminaste por irrelevante. Copia ambas columnas.

Elimina sobre la marcha

Una migración es el único momento en que alguien lee cada regla con ojos nuevos. Aprovéchalo. Las instrucciones obsoletas son peores que las que faltan, porque el agente las obecece y tú no te das cuenta hasta un mes después.

Pon las razones en un lugar recuperable, las reglas en un lugar cargado

La regla de dos líneas pertenece a CLAUDE.md. El informe de incidentes, el RFC y el hilo del proveedor que la produjeron pertenecen a un almacén del que el agente pueda extraer información cuando necesite explicar o reconsiderar. Meter ambos en archivos de instrucciones es la forma en que esos archivos llegan a las 800 líneas y dejan de seguirse.

No esperes que ningún archivo de instrucciones sea de cumplimiento obligatorio

La propia documentación de Claude Code deja claro que los archivos de instrucciones son contexto en lugar de configuración obligatoria, y señala los hooks para las cosas que deben suceder siempre. Si una regla que estás migrando era fundamental (nunca hacer push a main, ejecutar siempre el linter), impleméntala como un hook o una comprobación de CI, y deja que el archivo de instrucciones explique por qué existe.

Pasar de Devin a Claude Code es una copia unidireccional, y la razón es estructural más que hostil: Knowledge de Devin extrae información de los archivos de tu repositorio, incluidos CLAUDE.md y AGENTS.md, pero nada extrae información de Devin. Cualquier cosa derivada de tu repositorio ya está donde Claude Code buscará. Cualquier cosa que hayas escrito en la aplicación web, además de los disparadores y pines que la delimitaban, tiene que ser recopilada a mano mientras aún tengas acceso.

Haz esa recopilación con la tecla de eliminar en la otra mano, luego reconstruye por alcance: preferencias personales en ~/.claude/CLAUDE.md, estándares del equipo en un CLAUDE.md confirmado, reglas específicas de archivos en .claude/rules/ con frontmatter paths:, notas privadas en CLAUDE.local.md. Mantén los archivos cortos. Luego pon las razones detrás de esas reglas en un almacén que lean tus asistentes, para que la próxima vez que cambies de plataforma, estés cambiando de herramienta y no volviendo a excavar todo lo que sabes.