Modernizar sistemas heredados con IA como arqueóloga

Todo sistema heredado que sigue funcionando tiene algo en común: funciona. Puede ser feo, caro de mantener y aterrador para quien llega, pero alguien depende de él todos los días. Por eso la modernización es un problema de riesgo antes de ser un problema de código.

El cuello de botella es entender, no escribir

Quien ya participó en un proyecto de modernización sabe que la parte lenta no es teclear el código nuevo. Es descubrir por qué el código viejo hace lo que hace.

Esa condición extraña en el cálculo de flete probablemente resuelve un caso real que nadie documentó. El campo que parece muerto alimenta un reporte que alguien de la dirección abre una vez por trimestre. La regla que contradice la especificación se escribió después de un incidente.

Ese es el costo dominante, y es exactamente donde la IA cambia la economía del trabajo.

La IA como arqueóloga

El uso de IA que mejor paga en sistemas heredados no es generar el sistema nuevo. Es reconstruir el entendimiento del antiguo.

Cuatro tareas funcionan bien hoy:

• Explicar un fragmento denso en lenguaje natural, lo que da un punto de partida a quien nunca vio ese módulo.
• Mapear dependencias e indicar quién llama a qué, incluso en lenguajes que el equipo actual no domina.
• Extraer reglas de negocio candidatas de código procedural largo, produciendo una lista para que el especialista de dominio confirme o niegue.
• Generar pruebas de caracterización, que describen el comportamiento actual en lugar del deseado.

El último punto es el más subestimado. Las pruebas de caracterización son lo que convierte una refactorización riesgosa en una verificable, y escribirlas a mano para un módulo grande es lo bastante tedioso como para que el equipo siempre lo posponga.

Dónde se equivoca y tú pagas caro

El modo de falla característico es la explicación plausible y equivocada. El modelo lee la estructura del código y produce una narrativa coherente que puede ignorar el motivo histórico real.

Tampoco ve lo que no está en el repositorio: el procedimiento almacenado en la base, el job agendado en el servidor, la integración que solo existe en un archivo de configuración, el acuerdo verbal con el equipo de operaciones.

Por eso la regla práctica es: usa la salida de la IA como hipótesis, nunca como documentación. Toda regla extraída necesita confirmación de alguien del dominio o una prueba que la ejercite contra el sistema en ejecución.

La higuera estranguladora sigue siendo el patrón

Martin Fowler describió el patrón de la higuera estranguladora a partir de una imagen literal: la planta crece alrededor del árbol huésped hasta reemplazarlo, sin derribarlo nunca de una vez.

Aplicado al software, significa poner una capa de enrutamiento delante del sistema antiguo y mover funcionalidad al nuevo por rebanadas, una a la vez, con la posibilidad de retroceder en cada una. AWS publica una guía prescriptiva del mismo patrón con detalles de implementación, para quien necesita un camino concreto.

La IA no reemplaza el patrón, lo acelera. Ayuda a decidir qué rebanada tiene menos acoplamiento, genera el código de adaptación entre los dos mundos y mantiene ambas versiones en paridad durante la transición.

La reescritura completa sigue siendo mala idea

La tentación es obvia. Si la IA escribe código rápido, ¿por qué no reescribir todo?

Porque lo que hace peligrosa a la reescritura completa nunca fue la velocidad de tecleo. Es la pérdida de conocimiento acumulado en años de correcciones, el congelamiento de funcionalidad durante la transición y la incapacidad de validar equivalencia en un salto grande.

El Technology Radar de Thoughtworks viene registrando esta advertencia sobre la generación de código a gran escala: volumen alto sin revisión proporcional crea un sistema nuevo que nadie entiende, que es el mismo problema del legado, solo que sin los años de estabilidad.

La refactorización sigue siendo la disciplina que sostiene el resultado

El catálogo de refactorizaciones de Martin Fowler describe movimientos pequeños con comportamiento preservado, cada uno verificable.

Ese tamaño de paso no es preciosismo. Existe porque un error en un paso pequeño se encuentra en minutos, y un error en un paso grande se encuentra en producción. Con IA la tentación es agrandar el paso, ya que generar quinientas líneas cuesta lo mismo que generar cincuenta. El costo aparece en la revisión y en el incidente, no en la generación.

Qué significa esto para tu equipo

Empieza por la arqueología, no por la reescritura. Elige el módulo que más asusta y usa IA para producir un documento de entendimiento más una suite de pruebas de caracterización. Valida ambos con quien conoce el dominio.

Después elige una rebanada pequeña y estrangúlala, con enrutamiento delante y rollback disponible.

Si al final de tres meses el equipo entiende el legado mejor que antes y reemplazó dos rebanadas sin incidentes, la modernización va bien. Si reemplazó diez y nadie sabe explicar las reglas, el problema solo cambió de lugar.