IA para modernizar código antiguo: qué funciona y qué es humo

La IA no va a reescribir tu COBOL mientras duermes.

Pero tampoco es humo. Entre esos dos extremos hay un espacio muy útil que casi nadie explica bien, porque a los que venden herramientas les conviene el primero y a los que llevan 30 años manteniendo el sistema les conviene el segundo.

Parto por algo que se ve en Google. Si escribes "programador cobol" en Chile, el buscador completa con "trabajo cobol chile" y "desarrollador cobol chile". No lo busca gente curiosa. Lo buscan empresas que necesitan a alguno de los pocos que todavía entienden sistemas que mueven pagos, inventario o remuneraciones todos los días. Esa escasez es el dolor real, y es por donde la IA puede ayudar primero.

Qué hace bien la IA para modernizar código legado

Hay trabajo en una modernización que es de alto volumen y bajo juicio de negocio. Ahí la IA rinde de verdad.

Entender y explicar código ajeno. Le pasas un programa de 4.000 líneas sin comentarios y en minutos tienes una explicación razonable de qué hace cada sección, qué archivos lee y qué escribe. No es perfecta, pero es un punto de partida que antes tomaba semanas de lectura.

Documentar lo que nunca se documentó. Diagramas de flujo, diccionario de datos, lista de reglas de cálculo. La persona que conoce el sistema pasa de escribir documentación (que nunca tuvo tiempo de hacer) a revisarla, que es mucho más rápido.

Escribir pruebas de caracterización. Son pruebas que registran lo que el sistema hace hoy, esté bien o mal, para detectar si algo cambia cuando lo tocas. Escribirlas a mano es tedioso y por eso casi nadie las tiene. La IA las genera en volumen y tú decides cuáles valen.

Migrar versiones de lenguaje o framework. Este es el caso con mejores números públicos. Amazon reportó en 2024 que, usando IA para actualizar la versión de Java de sus aplicaciones internas, se ahorró el equivalente a más de 4.500 años de trabajo de desarrollo frente a hacerlo a mano. Ojo con lo que dice esa cifra: es subir de versión dentro del mismo lenguaje, con reglas conocidas. No es traducir lógica de negocio de un lenguaje a otro.

Mi propia experiencia va en la misma línea. Hace 15 años, integrar una pasarela de pago era un dolor: documentación escasa, ejemplos que no calzaban, semanas de prueba y error. Hoy, con buen uso de la IA, es mucho más simple. La palabra que importa ahí es "buen uso". Con el mismo modelo, un equipo que revisa y prueba lo que genera avanza rápido; uno que copia y pega sin mirar llena el sistema de errores nuevos.

Qué hace mal (y dónde está el humo)

El humo aparece cuando alguien promete que la IA "migra COBOL a Java" de punta a punta. La traducción de sintaxis sale. Lo que no sale es el juicio.

Reescribir lógica de negocio sin supervisión. Un cálculo de comisiones con 40 condiciones anidadas se puede traducir línea por línea y quedar funcionando. También se puede traducir "mejorado", con la IA simplificando una condición que parecía redundante y que en realidad cubría un caso de un cliente grande. Nadie se entera hasta el cierre de mes.

Entender reglas no escritas. Muchos sistemas legados tienen reglas que viven en la cabeza de la gente y en la forma en que se usa el sistema, no en el código. Un proceso nocturno que se corre dos veces a fin de mes porque la primera falla siempre. Un campo de "observaciones" que el área comercial usa como código de descuento. La IA no ve eso porque no está en el código.

Decidir qué comportamiento raro es un bug y cuál es una regla. Este es el punto más delicado. Un sistema de 25 años tiene cosas que parecen errores. Algunas lo son. Otras son decisiones de negocio que alguien tomó en 2003 y que hoy nadie recuerda. Si la IA "corrige" una de esas, rompiste algo que funcionaba. Esa decisión es de una persona que conoce el negocio, siempre.

La IA es muy buena para decirte qué hace el código. Todavía es mala para decirte si eso es lo que el negocio quiere que haga.

---

Un método seguro de modernización con inteligencia artificial

Este es el orden que seguimos en AW. No tiene nada de novedoso; lo que cambia con la IA es la velocidad de cada paso.

1. Inventario. Qué programas existen, cuáles se ejecutan de verdad, qué datos leen y escriben, qué sistemas dependen de ellos. La IA acelera mucho este paso leyendo el código y los registros de ejecución. Casi siempre aparece código que nadie ejecuta hace años, y eso no se migra.
2. Pruebas que fijan el comportamiento actual. Antes de cambiar una línea, se capturan entradas y salidas reales del sistema (con datos anonimizados) y se convierten en pruebas automáticas. Esa es la red de seguridad. Sin ella, todo lo que sigue es fe.
3. Cambios chicos con IA y revisión humana. Un módulo a la vez. La IA propone la migración o el cambio, las pruebas dicen si el comportamiento se mantuvo, y una persona revisa las diferencias. Si una prueba falla, se decide caso a caso: ¿era un bug o una regla?
4. Paralelo. El sistema nuevo corre al lado del antiguo con datos reales durante un periodo definido, y se comparan los resultados. Solo cuando coinciden se apaga el antiguo. Con fecha de término, porque sin fecha el sistema viejo nunca se apaga.

Si el sistema está tan enredado que ni el inventario sale limpio, revisa primero cuándo conviene pagar la deuda técnica y cuándo reescribir desde cero. A veces la respuesta honesta es no migrar ese módulo y envolverlo con una API.

Cómo cambia la economía de la modernización

Durante años, la razón para no modernizar un sistema legado fue el costo de entenderlo. Antes de escribir una línea nueva había meses de lectura, entrevistas y arqueología. Con la IA, esa parte baja bastante.

Lo que no baja igual es la validación. Alguien tiene que confirmar que el sistema nuevo calcula lo mismo que el antiguo en los casos que importan, y ese alguien necesita conocer el negocio. El riesgo del proyecto se mueve: antes estaba en escribir el código, ahora está en verificar que el código hace lo correcto.

Eso tiene consecuencias prácticas para presupuestar. Si una propuesta de modernización con IA promete bajar el plazo a la mitad, pregunta dónde está el tiempo de validación y quién de tu empresa lo va a hacer. Si la respuesta es "la IA lo valida", es humo.

También cambia qué conviene hacer primero. Antes se partía por el módulo más importante. Ahora tiene sentido partir por el que más cuesta entender, porque es donde la IA ahorra más y donde el riesgo de perder conocimiento es mayor. Más contexto sobre cómo priorizar en modernización de sistemas legados en Chile.

---

El riesgo que no es técnico: la persona que sabe

En casi todas las empresas con un sistema legado hay una persona. Lleva 15 o 20 años ahí, entiende por qué el proceso nocturno corre dos veces y sabe qué significa el código 7 en el campo de observaciones. Cuando se va de vacaciones, nadie toca nada.

Esa persona es tu mayor activo y tu mayor riesgo. Y buscar un programador COBOL en Chile para reemplazarla no resuelve el problema, porque el conocimiento que importa no es el lenguaje: es el negocio que está escrito en ese lenguaje.

La IA cambia el rol de esa persona. En vez de pedirle que documente todo (nunca va a tener tiempo), le pides que revise lo que la IA documentó y explicó. Revisar es mucho más rápido que escribir. En pocas semanas, parte de lo que vivía en una sola cabeza queda en documentos y en pruebas automáticas que cualquiera puede ejecutar.

Un aviso sobre esto, porque lo hemos visto en otros contextos. Cuando una empresa cambió de sistema sin involucrar a quienes tenían el conocimiento, esas personas no se adaptaron y terminaron trabajando meses el doble manteniendo dos sistemas. Pasó en una migración de Excel a un ERP empaquetado a inicios de 2026, y pasa igual con código legado. La persona que sabe tiene que estar dentro del proyecto, con tiempo asignado, no como consultora de pasillo.

Por dónde empezar la próxima semana

No necesitas un proyecto de modernización para probar esto. Toma el programa que más miedo le da a tu equipo tocar y haz tres cosas: pídele a una herramienta de IA empresarial que lo explique, pídele a tu persona experta que revise esa explicación, y genera un primer set de pruebas de caracterización. En dos semanas vas a saber cuánto te sirve la IA con tu código real, que es lo único que importa.

Si ya usas IA en otras áreas, hay más ejemplos concretos en automatización con IA en empresas chilenas. Y si quieres ver cómo abordamos proyectos completos, está en modernización de sistemas legados.

Si tienes un sistema que depende de una o dos personas y quieres saber qué parte se puede modernizar con IA sin arriesgar la operación, en 45 minutos lo revisamos contigo. Agenda un diagnóstico.