Modernizar código legacy con IA: qué funciona y qué sale mal

El mayor beneficio de la IA en los sistemas heredados no está en reescribir, sino en comprender. Un modelo puede explicar código sin documentar, hacer visibles las dependencias y escribir pruebas para el comportamiento existente: justo las tres cosas que hacen planificable una modernización. La traducción automática a un nuevo lenguaje o a un nuevo framework es, en cambio, el uso más arriesgado.

¿Qué es el código legacy?

La definición más útil procede de Michael Feathers: el código legacy es código sin pruebas. No código antiguo, no código mal escrito, sino código del que no se puede comprobar si un cambio ha roto algo.

Esta definición es tan práctica porque nombra el problema real. Un sistema antiguo bien probado puede modificarse sin peligro. El código recién generado sin pruebas es, según esta definición, legacy de inmediato: el mismo día en que nace.

¿En qué ayuda realmente la IA con los sistemas heredados?

En tres tareas que preceden a toda modernización y que hasta ahora eran las más caras.

• Comprender. Un modelo puede resumir un procedimiento de 900 líneas, enumerar las ramificaciones y nombrar qué casos especiales se tratan. Esto no sustituye una revisión, pero reduce la familiarización de días a horas.
• Documentar. Generar a partir del código existente una descripción del estado actual, con la indicación expresa de que es el estado real y no el estado deseado.
• Asegurar. Escribir pruebas que fijen el comportamiento actual. Es el requisito para cualquier cambio posterior y el trabajo que a nadie le gusta hacer.

El tercer punto tiene un inconveniente que hay que conocer: estas pruebas cementan también los errores existentes. Es intencionado (se asegura el comportamiento, no la corrección), pero debe estar claro para todos los implicados; de lo contrario, una ejecución de pruebas en verde se tomará más tarde como prueba de corrección.

¿Por qué es tan arriesgada la reescritura automática?

Porque el conocimiento que hay en el código antiguo no está en el código. Una condición que a primera vista parece absurda suele ser la huella de un caso especial real: un cliente con un contrato distinto, un día festivo, una peculiaridad de un antiguo conjunto de datos.

Un modelo que traslada el código a un nuevo lenguaje ve esa condición como una rareza y, con cierta probabilidad, la simplifica hasta eliminarla. El resultado es más legible, compila, pasa las pruebas y se comporta de otra manera en el único caso para el que existía la condición. Ese caso suele notarse solo en producción, y entonces la causa es difícil de encontrar porque el código nuevo parece correcto.

¿Cómo abordo una modernización con ayuda de la IA?

En cuatro fases, de las cuales las dos primeras aportan la mayor parte del beneficio.

• Fase 1 — Cartografiar. ¿Qué hay, qué depende de qué, qué se usa realmente? Aquí la IA es fuerte y el riesgo es nulo, porque no se modifica nada.
• Fase 2 — Asegurar. Pruebas para el comportamiento actual de las áreas que se van a tocar. No para todo, sino para lo que entra en juego.
• Fase 3 — Acotar. Encapsular la parte antigua tras una interfaz y sustituirla pieza a pieza, en lugar de cambiarla de golpe. El sistema antiguo sigue funcionando hasta el final.
• Fase 4 — Sustituir. Ahora sí puede traducir un modelo: pieza a pieza, con las pruebas de la fase 2 como criterio de verificación y una persona que cuestione cada simplificación.

Quien empieza por la fase 4 se salta justo el trabajo que marca la diferencia entre una modernización y una reconstrucción cara con comportamiento desconocido.

¿Cómo reconozco que una modernización merece la pena?

Por el coste de los cambios, no por la antigüedad del código. Un sistema de doce años en el que se cambia un detalle dos veces al año no es un problema, sino una inversión amortizada.

Las señales que cuentan: los cambios tardan desproporcionadamente; las correcciones de errores generan errores nuevos; nadie se atreve con determinadas áreas; un requisito ya no puede implementarse técnicamente; ya no hay actualizaciones de seguridad de las bibliotecas utilizadas. Este último punto gana peso porque las obligaciones de notificación del Reglamento de Ciberresiliencia de la UE (Cyber Resilience Act) se aplican a partir del 11 de septiembre de 2026: quien deba notificar en 24 horas las vulnerabilidades explotadas activamente necesita un sistema en el que las vulnerabilidades puedan realmente cerrarse.

Si desea que le acompañemos en este camino: en eso trabaja precisamente nuestro desarrollo de SaaS y software.

Preguntas frecuentes sobre código legacy

¿Desde cuándo se considera legacy un código?

Según Michael Feathers, desde el momento en que no tiene pruebas. La antigüedad no cuenta en esta definición: lo que se generó ayer y no se aseguró entra en ella.

¿Puede una IA reconstruir por completo una aplicación antigua?

Puede construir una aplicación que parece hacer lo mismo. Si trata los mismos casos especiales se decide con las pruebas de la fase 2; sin ellas no tiene un criterio, sino una esperanza.

¿Qué ocurre con COBOL, ABAP y lenguajes antiguos similares?

Para explicar y documentar, los modelos funcionan de forma útil también ahí. En la traducción rige lo mismo que en otros casos, solo que agravado: cuanto más especial es el lenguaje, menos material de entrenamiento hay y más fácilmente se simplifican las peculiaridades hasta eliminarlas.

¿Cuánto dura una modernización así?

Depende casi por completo de cuánto haya que asegurar en la fase 2, y eso puede estimarse con seriedad después de la fase 1, no antes. Una estimación previa a la cartografía es una conjetura.

En la fase 4 todo depende de que se note cada simplificación. Code Guardian comprueba los cambios frente a lo existente y no frente al encargo: una mirada fría al diff que pregunta qué ha desaparecido aquí en realidad.

Fuentes

• Michael Feathers, Working Effectively with Legacy Code (definición: código sin pruebas).
• Reglamento (UE) 2024/2847 (Cyber Resilience Act): obligaciones de notificación a partir del 11 de septiembre de 2026, obligaciones principales a partir del 11 de diciembre de 2027.

Actualizado a 27 de julio de 2026. Clasificación técnica general, no asesoramiento jurídico.