AI-First
¿Se puede modernizar código legacy con Claude Code? Sí, siempre que trates al modelo como un ejecutor rápido cuyo trabajo debe demostrarse con un test, y no como un arquitecto al que se le cree sin más. Claude Code es el agente de programación de Anthropic: lee un repositorio, planifica, modifica los archivos y lanza las compilaciones por sí mismo. Con COBOL, VBA o Java antiguo, las demostraciones públicas convencen, pero los errores documentados también.
- 📊 Primero, la documentación: Claude hace legible un código que ya nadie entiende, antes de cualquier migración.
- ⚠️ Seis errores detectados: un recuento falso, un plan inexacto, una decisión que no le correspondía. Ninguno llegó al commit.
- ✅ La prueba está en los tests: la equivalencia de comportamiento se demuestra, no se declara.
- 🚀 Empezar por lo pequeño: una macro de Excel o un módulo aislado antes que cualquier mainframe.
Formo a pymes en Claude Code, y la pregunta aparece siempre: «tenemos un sistema antiguo que nadie se atreve a tocar, ¿puede la IA sacarnos de ahí?». Mi respuesta cabe en una frase: la IA reduce el coste de entender y de reescribir, no el de verificar. Esto es lo que muestran las fuentes, y dónde pongo yo el límite.
¿Por qué cuesta tanto modernizar el código legacy?
El código legacy sale caro porque su lógica de negocio no está escrita en ningún sitio: vive en el código, y las personas que lo escribieron ya no están. Entender lo que hace el sistema suele costar más que reescribirlo, como resume el webinar de Anthropic «Modernizing Legacy Code with Claude Code» (anthropic.com).
¿De qué magnitud es el problema?
Según un artículo de juteq.ca que cita un informe de Business Wire, el 74 % de las iniciativas de modernización fracasan. El mismo texto, que retoma un estudio de McKinsey, afirma que un desarrollador dedica de media 17,3 horas a la semana a la deuda técnica y al mantenimiento. Cito estas cifras tal como las dan sus autores, sin haber podido llegar a los estudios originales.
En Thoughtworks, un gran fabricante de automóviles tenía que abordar 15 millones de líneas de COBOL. Dos especialistas necesitaban unas seis semanas para hacerse con un módulo de 10 000 líneas. El cuello de botella no era teclear el código, era entenderlo.
El verdadero coste del legacy es el conocimiento perdido.
¿Por qué la IA ataca justo este problema?
Porque leer grandes cantidades de código sin documentar y extraer de él reglas de negocio es exactamente lo que un agente hace bien. La página «Code modernization» de claude.com enumera los usos previstos: mapas de dependencias, detección de código muerto, generación de tests de regresión y de documentación a partir de un código que no tenía ninguna.
En Reddit, un hilo de r/TechnologyNewsIndia afirma que Claude traduce COBOL a Java o Python con un «90 % de precisión». Es una afirmación del autor del post, sin método detallado, y no la tomo como una cifra fiable. Aun así, el hilo recuerda que los tests y el despliegue siguen exigiendo una fuerte supervisión humana, algo que el resto de este artículo confirma.
¿Cómo documenta y migra Claude Code un COBOL antiguo?
En la demostración publicada por Anthropic, Claude Code primero documenta el programa COBOL y después lo migra a Java 17 comparando los resultados con el original. El campo de pruebas es el repositorio de demostración de modernización de mainframe de AWS: un sistema de tarjetas de crédito de unos 100 archivos, sin documentación.
¿Qué hace la fase de descubrimiento?
Se crea un subagente especializado en «documentación COBOL», con su propia ventana de contexto para no contaminar la conversación principal. Claude elabora una lista de tareas que cubre los 94 archivos para que ninguno se olvide ni se procese dos veces. Genera dos archivos de memoria (un catálogo que traduce nombres crípticos como CBAC04C a funciones de negocio y un archivo de dependencias) y después diagramas Mermaid del procesamiento por lotes diario.
Resultado anunciado: más de 100 páginas de documentación en una hora de funcionamiento continuo. Anthropic precisa que Claude Code puede funcionar más de 30 horas de forma autónoma.
¿Cómo se controla la migración?
Claude pasa al modo de planificación, es decir, sin modificar ningún archivo, y propone un plan en cinco fases para la función de cálculo de intereses: estructura del proyecto, modelos de datos como clases Java, capa de entrada y salida compatible con los formatos originales, lógica de negocio y banco de pruebas doble. Este banco compara GnuCOBOL 3.2.0 para el original y Java 17 para la versión nueva.
La verificación abarca los cálculos intermedios, no solo los resultados finales, y Anthropic anuncia una fidelidad «bit a bit». Conviene relativizar: se trata de una aplicación de demostración mucho más pequeña que un sistema bancario real.
Un hilo de r/ClaudeWorkflows describe la misma lógica a mayor escala con el proyecto GitGalaxy: GnuCOBOL como oráculo de test, tests «golden master» bloqueantes en integración continua y un agente nuevo por problema con notas de traspaso, para evitar la deriva. Dos fuentes independientes llegan, por tanto, al mismo esquema: el programa antiguo hace de juez del nuevo.
¿Qué errores comete Claude con código existente?
Claude comete errores verosímiles, y por eso peligrosos; la diferencia la marcan las salvaguardas que los interceptan. El canal Legacy to Latest reprodujo sesiones reales con ShipTrack, una API REST de seguimiento de paquetes: de Java 11 y Spring Boot 2.7 a Spring Boot 4.1 y Java 25. Duración: unas 2 horas de tiempo de agente, por unos 24 $ a tarifa de API, con 47 tests en verde al final.
¿Cuáles son los seis errores y quién los detuvo?
La tabla siguiente recoge los que el vídeo detalla.
| Error de Claude | Qué lo reveló | Lección |
|---|---|---|
| Anuncia 56 tests superados, cuando hay 47 | La salida de compilación de Maven | Un resumen describe el trabajo, no lo demuestra |
| Dos afirmaciones falsas en el plan de Spring Boot 3.5 | Los metadatos de configuración de los JAR | Revisar un plan como una pull request |
| Elige por su cuenta la opción B de un cambio de API | La lectura de la transcripción y el subagente revisor | Una decisión de producto sigue siendo humana |
| Contrato de API modificado pese a tener los tests en verde | Comparación de las respuestas de la versión antigua y la nueva | Un test solo protege lo que afirma |
| Causa raíz errónea: clave de configuración renombrada | Un comando sobre los metadatos | Verificar antes de escribir código de parche |
FUENTE: Legacy to Latest, vídeo en YouTube · ACT. 10/2026
El sexto error es una verificación que ocultaba una compilación defectuosa: la primera compilación no era limpia, así que quedaban clases compiladas antiguas en la carpeta de destino. La transcripción disponible se corta antes del final de este fragmento, así que me quedo con esta constatación.
¿Por qué el tercer error es el que más me marcó?
Porque en parte es culpa de los humanos. Claude había presentado dos opciones y pedido que alguien decidiera. Pero el hook de parada del equipo le impedía detenerse mientras la compilación estuviera en rojo, así que Claude eligió por sí mismo e informó de su elección.
El razonamiento era sólido, pero la decisión no le correspondía. La corrección consistió en permitir la parada cuando solo fallan los tests de caracterización: en ese caso, un rojo significa que el comportamiento ha cambiado, y eso es una cuestión para un humano.
Esto conecta con mi convicción de fondo: la IA debe potenciar al equipo, no sembrar el caos, y el control humano sigue en el centro. Si quieres ver cómo planteo estas salvaguardas para perfiles no técnicos, lee Claude Code sin concesiones para mis clientes pyme.
¿Y una pyme? ¿Por dónde empezar?
Una pyme casi nunca tiene un mainframe de 15 millones de líneas. Tiene una macro de Excel, una herramienta en Access, un script que solo entiende un empleado. Para este caso, la demostración más elocuente es la más pequeña: el canal Hay Kel convierte un formulario VBA de cálculo de gastos de viaje en una aplicación Python con Tkinter personalizado y después la compila en un .exe autónomo con PyInstaller.
¿Qué demuestra la demo de VBA a Python?
Demuestra que una herramienta atrapada en Excel puede convertirse en un programa independiente en una sola sesión. La prueba es sencilla: 100 km en la categoría «compacto» dan 50 $, igual que el código VBA original. Es un único caso de test, lo cual es poco, pero la idea de comparar lo antiguo y lo nuevo con las mismas entradas es la correcta.
En r/devsarg, un desarrollador cuenta cómo transformó un sistema en VB6 y Access en un motor FastAPI y SQLite que expone 59 herramientas mediante MCP. Su regla de diseño: el modelo nunca toca el SQL; el backend valida, ejecuta y audita. Es la misma filosofía que la de ShipTrack, con la responsabilidad del lado del software.
¿Cómo empezar sin correr riesgos?
Esta es la secuencia que recomiendo, a partir de lo que estas fuentes tienen en común:
- Documentar antes de tocar. Pide a Claude Code que describa el sistema y sus dependencias, y haz que lo revise la persona que conoce el negocio.
- Escribir los tests de caracterización sobre el comportamiento actual, incluidos los casos raros.
- Migrar un módulo aislado, en modo de planificación, con un plan revisado como una pull request.
- Comparar lo antiguo y lo nuevo con las mismas entradas, campo por campo.
- Dejar la decisión de producto en manos de un humano.
Una auditoría útil desemboca en una hoja de ruta, no en un gran proyecto de 18 meses. Para plantear este marco técnico con un equipo senior, el equipo de GoLive Software publica la vertiente de desarrollo. Y para el presupuesto de un uso habitual, consulta el presupuesto real de mis automatizaciones con Claude Code.
¿Merece la pena lanzarse? Mi veredicto
Sí, para documentar y para migrar módulos aislados, con una condición innegociable: un banco de tests que compare el comportamiento antiguo con el nuevo. La prueba viene de la compilación y de las respuestas reales, nunca del resumen del agente.
En cambio, no recomiendo confiar un sistema crítico entero a una sesión sin oráculo de test. Los 24 $ y las 2 horas de ShipTrack son un resultado atractivo, pero seis errores por el camino recuerdan que la velocidad sin control fabrica deuda técnica más rápido que antes.
También hay una señal de mercado: un hilo de r/singularity cuenta que la acción de IBM habría caído un 10 % tras el lanzamiento de una herramienta de Claude Code para COBOL. Lo cito como reacción de mercado reportada, no como análisis. Lo que me quedo para un directivo de pyme: el coste de entender un sistema antiguo baja claramente, así que el coste de no hacer nada se vuelve más visible.
Preguntas frecuentes
¿De verdad puede Claude Code convertir COBOL a Java?
Sí, en las demostraciones públicas. Anthropic muestra la migración de un programa de cálculo de intereses a Java 17, verificada frente a GnuCOBOL 3.2.0 con una fidelidad anunciada bit a bit. Se trata de un repositorio de demostración de un centenar de archivos, no de un sistema de producción completo.
¿Cuánto cuesta una migración de framework con Claude Code?
En el caso de ShipTrack documentado por el canal Legacy to Latest, la actualización de Java 11 y Spring Boot 2.7 a Spring Boot 4.1 y Java 25 llevó unas 2 horas de tiempo de agente por unos 24 $ a tarifa de API. Esta cifra corresponde a un pequeño servicio de demostración, no a una aplicación empresarial.
¿Cómo asegurarse de que el código migrado se comporta como el antiguo?
Ejecutando el código antiguo y el nuevo con las mismas entradas y comparando las salidas reales, incluidos los campos de más y los formatos de fecha. Los tests en verde no bastan: en ShipTrack, dos cambios en la API pública pasaron con todos los tests superados.
¿Puede alguien sin perfil técnico modernizar una macro VBA con Claude?
Sí, si se trata de una herramienta pequeña. La demostración del canal Hay Kel convierte un formulario VBA en una aplicación Python compilada en .exe. Después hay que probarla con casos reales y que revise el resultado alguien que conozca el cálculo de negocio.
¿Hay que sustituir al proveedor de mantenimiento por la IA?
No, al menos no de golpe. La IA acelera la documentación y la reescritura, pero la validación, las decisiones de producto y la seguridad siguen siendo humanas. Mejor un desarrollador senior equipado con Claude Code que cualquiera de los dos por separado.
Fuentes
- Claude Code modernizes a legacy COBOL codebase , Anthropic
- Claude Code Made 6 Mistakes on Legacy Code. None Reached a Commit. , Legacy to Latest
- Convert VBA UserForm to Python App (.EXE) with Claude AI , Hay Kel
- How AI accelerated mainframe modernization , A Thoughtworks COBOL modernization case study , Thoughtworks
- Code modernization | Claude by Anthropic , claude.com
- Modernizing Legacy Code with Claude Code | Webinars , anthropic.com
- Modernizing Legacy Enterprise Code with Claude Code | Juteq Insights , juteq.ca
- IBM is the latest company victim of Anthropic , r/singularity
- Anthropic's Claude starts rewriting COBOL code , r/TechnologyNewsIndia
- De un sistema legacy en VB6 + Access a un motor comercial open-source , r/devsarg
- Advanced Workflow: Ensuring Code Equivalence in AI-Driven Legacy Modernization , r/ClaudeWorkflows