Salimos ahora de la semana en que Anthropic afirmó que su modelo podía reemplazar el COBOL; hasta ahora, las consecuencias se han limitado a crisis de llanto y algún que otro grito en los pasillos todavía llenos de cintas magnéticas y archivadores.
Si la noticia hubiera salido en octubre, habríamos tenido a alguien a mano a quien preguntar si todo ese pánico tenía fundamento.
Mely Lerman, en los últimos sesenta años, ha navegado por las trincheras del desarrollo de software global, desde sistemas mainframe en COBOL hasta modernos intentos de arqueología asistida por IA. No es una evangelista que vende sueños, ni una académica que teoriza sobre el código perfecto. Es una arquitecta de software veterana que ha dedicado su carrera al mantenimiento de sistemas cruciales para no creer en los eslóganes del “low-code” o del “fin de los programadores”.
Actualmente colabora como experto en proyectos empresariales de transformación digital, proporcionando mentoría sobre problemas Legacy y COBOL. Escribe porque ve un peligroso vacío entre la narrativa tecnológica mainstream —toda IA y disrupción— y la realidad operativa de las empresas, donde los ingresos dependen de sistemas de sesenta años de antigüedad. Cree en la tecnología que resuelve problemas, no en la que crea nuevos problemas para justificar presupuestos.
IA, COBOL y el arte del mantenimiento del negocio
Mientras caminaba por los stands de Codemotion, rodeado del habitual bullicio sobre LLM, agentes autónomos y frameworks de JavaScript recién nacidos, tuve la sensación de que todos estábamos mirando el dedo y no la luna. O mejor, que estábamos observando la pintura fresca de la carrocería ignorando que el motor bajo el capó tiene sesenta años.
Luego escuché a Mely Lerman. No el clásico joven startupper de Silicon Valley con sudadera reglamentaria, sino un señor brasileño, residente hoy en Madrid, que programa desde hace 60 años. Uno que empezó cuando el monitor era papel impreso y el cloud era, literalmente, una nube en el cielo.
Su intervención fue un baño de realidad fría, casi brutal, para quien piensa que “Legacy” es sinónimo de obsoleto. Lerman nos recordó un dato que debería hacer temblar a cualquier CTO: el 75% de las transacciones financieras globales todavía pasa por COBOL. Si hoy sacas dinero de un cajero, hay un 95% de probabilidad de que tus fondos se muevan gracias a ese código.
No estamos hablando de reliquias arqueológicas inertes. Hablamos de 800 mil millones de líneas de código activas, a las que se suman aproximadamente dos mil millones nuevas cada año. Es la infraestructura invisible del mundo. Y tenemos un problema gigantesco: quienes la construyeron se están jubilando y nosotros no tenemos la menor idea de cómo funciona realmente.
Sputnik, minifaldas y Batch Processing: la herencia invisible
Para entender por qué no podemos liberarnos de estos sistemas, hay que mirar cómo nacieron. Lerman trazó un paralelo histórico fascinante, recordándonos que COBOL es hijo de los años 60, igual que los Beatles, los Rolling Stones, la minifalda y la carrera espacial iniciada con el Sputnik.
Nació en una época de disrupción total, social y tecnológica. Pero a diferencia de FORTRAN, que era cosa de académicos y científicos, COBOL (Common Business Oriented Language) fue diseñado por un pequeño grupo liderado por Grace Hopper con un objetivo puramente pragmático: gestionar negocios.
Cuando IBM lanzó el System/360 en 1964, la combinación con COBOL se convirtió en el estándar de facto. ¿Por qué? Porque manejaba la precisión decimal de manera nativa. Para un banco, un redondeo incorrecto en mil millones de transacciones no es un bug, es un desastre legal.
Lerman recuerda haber aprendido el lenguaje en un fin de semana leyendo cuatro folletos de IBM: Identification, Environment, Data, Procedure. Era simple: Input, Process, Output. Nada de gráficos, nada de adornos. Solo lógica de negocio pura.
Y aquí está el punto: esos programas funcionaron. Funcionaron tan bien que nadie los tocó durante décadas. “If it’s not broken, don’t fix it”. Así, capa sobre capa, parche sobre parche, construimos el sistema nervioso de las finanzas globales.
La ilusión de la “Traducción”: por qué Java no mató al Mainframe
“He visto decenas de proyectos de migración fracasar miserablemente, quemando presupuestos faraónicos”. Lerman, con su experiencia en Suiza, Israel, Reino Unido, China y República Dominicana, confirma lo que muchos susurramos en las reuniones de presupuesto: la idea de reescribir estos sistemas core desde cero suele ser una locura.
Las empresas, en pánico por la modernización, buscan atajos. Lerman fue tajante en este punto: los intentos de traducción automática “COBOL a Java” casi siempre están condenados al fracaso. Y tiene toda la razón.
El motivo es sutil pero fundamental: Java nació en la era de Internet, es orientado a objetos y tiene un paradigma completamente distinto. COBOL es procedural, diseñado para batch processing. Traducir 10.000 líneas de COBOL a una clase Java genera un monstruo ingobernable que funciona peor que el original y que nadie sabe mantener. Es como traducir un poema usando Google Translate: las palabras están, pero el sentido se pierde.
Además, los sistemas “off-the-shelf” (paquetes preconfigurados como SAP) funcionan muy bien para contabilidad general o recursos humanos. Pero no puedes reemplazar un Core Banking o un sistema de gestión de pólizas personalizado —con décadas de reglas de negocio acumuladas— con un paquete estándar sin perder ventaja competitiva o paralizar la operativa.
Así que seguimos con COBOL. Pero hoy COBOL enfrenta enormes desafíos: no hay documentación. Esos programas fueron escritos antes de que existiera Word. A menudo son un enredo de spaghetti code, fruto de 40 años de modificaciones urgentes hechas por distintas personas, sin estándares modernos. Mientras lo cuenta, riendo pero no demasiado, dice que ha encontrado bloques de código que son “puro nonsense”, lógicas incomprensibles que nadie se atreve a borrar por miedo a derrumbar todo el castillo de cartas.
El Bus Factor Global: cuando la edad promedio es 58 años
Aquí llegamos al punto crucial que plantea Lerman, que va más allá de la tecnología y toca la demografía. No es un problema de stack, es un problema de personas.
La edad promedio de un programador COBOL hoy es de 58 años. En los próximos diez años, asistiremos a un éxodo masivo por jubilación. Las empresas enfrentan lo que Lerman llama “escasez de talento”.
Quien mantiene estos sistemas hoy no es solo un programador, es un guardián de la lógica de negocio. A menudo no existe documentación fuera del código fuente. El código es la especificación. Y si la única persona que sabe por qué ese PERFORM apunta a ese párrafo se jubila mañana, la empresa enfrenta un grave problema de continuidad operativa.
Lerman estima que bancos y aseguradoras necesitarán un millón de programadores COBOL en la próxima década para gestionar esta transición. No para crear sistemas nuevos desde cero, sino para mantener, modernizar y trasladar los existentes hacia el futuro.
IA y Legacy: no sustitución, sino “Arqueología Asistida”
Y aquí el discurso se vuelve actual y anti-hype. En un momento en que Jensen Huang de Nvidia dice que ya no harán falta programadores, mientras Bill Gates asegura que sí, durante otros 100 años, la visión de Lerman es pragmática:
La IA no reemplazará a los programadores COBOL en los próximos 10 años.
Dos razones muy prácticas:
- Seguridad: los bancos nunca expondrán su código core a un LLM público en la nube. Ese código es secreto industrial.
- Patrones: la IA aprende de patrones. En el COBOL legacy, especialmente el escrito hace 40 años sin estándares, los patrones son escasos. Es el reino del caos creativo.
Sin embargo, Lerman ve la IA como una herramienta de empoderamiento extraordinaria. Su startup, Cobalt Toolkit, apunta precisamente a esto: usar análisis estático y IA no para reescribir, sino para comprender.
Un caso de uso que cita en Morgan Stanley es ilustrativo: entrenaron un modelo en sus repositorios internos (on-premise, por supuesto) para ayudar a los nuevos empleados a navegar la base de código. Resultado: los junior developers se vuelven productivos en uno o dos meses, en lugar de dos años.
La IA no reemplaza al experto. La IA elimina la parte frustrante de la arqueología digital —entender a dónde apunta un GO TO o generar un diagrama de flujo de un listado ilegible— y permite al humano concentrarse en la lógica de negocio. Visualizar automáticamente flowcharts de código de hace 40 años es el tipo de “magia” útil que hoy necesitan las empresas.
Más allá del Hype: el futuro es para quienes construyen puentes
En un mercado saturado de desarrolladores frontend y data scientists, la verdadera oportunidad de carrera (“no un trabajo, sino una carrera”, enfatiza Lerman) podría estar justo donde nadie mira.
Trabajar con COBOL significa estar muy cerca del negocio. En los lenguajes modernos hay mil capas de abstracción, frameworks, middleware, ORM. En COBOL, la distancia entre una regla de negocio (“si el cliente tiene más de 60 años, calcula X”) y el código es mínima. El programador es el verdadero enlace entre la necesidad empresarial y la solución digital.
La innovación verdadera, nos recuerda Lerman, no siempre es destruir lo viejo para crear lo nuevo. Es crear valor revitalizando lo existente, preservando la “sabiduría tecnológica” cristalizada en esos sistemas. Es construir puentes entre generaciones de expertise tecnológico.
Para quienes trabajamos en tecnología, el mensaje es claro: la IA nos hará más eficientes (Lerman estima un 30% más), pero no nos exime de la responsabilidad de entender lo que construimos. Y a veces, para construir el futuro, hay que abrir un terminal de fósforo verde, leer la historia y ensuciarse las manos con la complejidad real del mundo.
Como dijo Lerman al cerrar su charla: “Have a nice life”. Pero recuerden: alguien tendrá que gestionar ese código.
