$31 mil millones en un día: qué le dijo el mercado a IBM

Cuando vi la noticia el lunes, lo primero que pensé fue en tres clientes nuestros que llevan años discutiendo si migrar su mainframe. La discusión siempre terminaba igual: “los costos no cuadran”.

Ese mismo lunes, IBM perdió el 13.2% de su valor en bolsa — el peor día para la acción desde el año 2000. Más de $31 mil millones en capitalización de mercado desaparecieron en una sola jornada. Y no fue por un trimestre malo, un escándalo corporativo o una crisis macroeconómica.

Fue por un blog post.

Anthropic publicó un artículo técnico mostrando cómo Claude Code puede automatizar la modernización de código COBOL. El mercado leyó entre líneas: si la IA puede hacer lo que IBM cobra millones por hacer, el modelo de negocio de IBM tiene un problema.

Según CNBC, la acción acumula una caída del 27% en el último mes — la peor racha mensual desde al menos 1968. Tom’s Hardware reportó que fue la mayor caída porcentual en un solo día en más de dos décadas.

El mercado no le está diciendo a IBM que COBOL va a desaparecer mañana. Le está diciendo que el monopolio sobre la modernización de COBOL tiene fecha de vencimiento.

COBOL: 67 años y sigue procesando el 95% de las transacciones en cajeros

Para entender por qué esto importa, hay que entender la escala de lo que está en juego.

Según el blog de Anthropic, el 95% de las transacciones en cajeros automáticos de Estados Unidos todavía pasan por código COBOL. Cientos de miles de millones de líneas en producción a nivel mundial. Sistemas bancarios, aseguradoras, gobiernos, cadenas de suministro. La infraestructura que mueve la economía real funciona sobre un lenguaje creado en 1959.

El talento se está agotando. COBOL se enseña en un puñado de universidades. Los ingenieros que escribieron estos sistemas se están jubilando, y cada año la brecha entre el código en producción y las personas que lo entienden se hace más grande.

¿Por qué las empresas no migran? No por falta de voluntad. La razón es económica: entender el código legacy costaba más que reescribirlo. Un sistema COBOL de 30 años tiene dependencias no documentadas, flujos de negocio que nadie recuerda haber diseñado, y lógica enterrada en miles de archivos que interactúan de maneras que solo el sistema original “conoce”.

Mapear todo eso requería ejércitos de consultores especializados. Ahí es donde IBM encontró su mina de oro. La consultoría mainframe era un centro de ganancias para ellos, un centro de costos para sus clientes. Cuanto más complejo y opaco fuera el sistema, más dependiente era el cliente de IBM para cualquier cambio.

Ese modelo funcionó durante décadas. Hasta ahora.

Lo que Anthropic demostró (y lo que no)

El blog de Anthropic no muestra un sistema que reescribe COBOL automáticamente. Lo que muestra es algo más sutil y, en mi opinión, más peligroso para IBM.

Claude Code puede mapear dependencias en código COBOL: entender qué programa llama a qué otro, qué datos fluyen por dónde, qué módulos están realmente en uso y cuáles son código muerto. Puede documentar flujos de trabajo olvidados, esos procesos que nadie en la empresa actual diseñó pero que siguen corriendo porque nadie se atreve a tocarlos. Y puede identificar flujos de datos ocultos que serían invisibles sin semanas de análisis manual.

La metodología tiene cuatro fases: descubrimiento, análisis de riesgo, planificación estratégica e implementación incremental. No es diferente de lo que cualquier firma de consultoría propondría. La diferencia es quién hace la fase más cara.

El descubrimiento (mapear qué tienes, cómo se conecta, qué riesgos hay) es donde se va la mayor parte del presupuesto en cualquier proyecto de modernización legacy. Leer miles de archivos, rastrear llamadas entre módulos, reconstruir lógica de negocio que ya nadie recuerda. Ahí la IA tiene una ventaja difícil de igualar: puede procesar volúmenes de código que ningún equipo humano revisaría en el mismo tiempo.

Ahora, lo que la IA no hace: reemplazar el criterio humano sobre prioridades de negocio, cumplimiento regulatorio, o la secuencia correcta de migración. Decidir qué migrar primero, qué puede esperar, y cómo garantizar que el sistema siga funcionando durante la transición requiere experiencia y conocimiento del negocio que ningún modelo tiene.

Si ya conoces el concepto del patrón Strangler Fig para migración incremental, lo que Anthropic propone es que la etapa previa, el mapeo, deje de ser el cuello de botella.

Por qué el mercado reaccionó con tanta violencia

La caída de IBM no fue una reacción al código generado por IA. Fue una reacción a algo que Wall Street entiende mejor que nadie: alguien acaba de abaratar tu producto más rentable.

La consultoría COBOL era ingreso recurrente para IBM porque la barrera de entrada era alta. No cualquiera podía sentarse frente a un mainframe con un millón de líneas de COBOL y entender qué estaba pasando. Se necesitaban años de experiencia, conocimiento del hardware específico, y familiaridad con las particularidades del cliente. IBM tenía eso. Sus clientes no.

Esa asimetría de conocimiento era la base del pricing. No cobrabas por líneas de código analizadas; cobrabas por ser el único que podía hacerlo.

Cuando el costo de entender COBOL baja de “millones en consultoría” a “herramienta de IA + ingenieros que guían el proceso”, la propuesta de valor de IBM queda en cuestión. No porque IBM deje de saber de mainframes (sigue sabiendo más que nadie), sino porque sus clientes ya no están obligados a pagarle solo a IBM para entender sus propios sistemas.

En IQ Source hemos visto algo parecido con clientes que dependían de un único proveedor de ERP para cualquier cambio en su sistema. Durante años pagaban lo que les pidieran porque no había alternativa realista. Cuando apareció una, los márgenes del proveedor se comprimieron en cuestión de meses.

IBM está en una versión gigante de eso mismo.

Qué debería hacer tu empresa si tiene sistemas mainframe

Si tu empresa opera sobre COBOL o cualquier sistema mainframe, este momento es una oportunidad. Los costos de exploración acaban de bajar, y eso cambia qué proyectos son viables.

Lo primero es saber qué tienes. Suena obvio, pero la mayoría de las empresas con mainframe no saben exactamente qué código está en producción, qué porcentaje es código muerto, y qué dependencias existen entre módulos. Con IA, ese mapeo que antes tomaba meses de consultoría puede completarse en semanas. No es perfecto (necesitas ingenieros que validen los resultados), pero te da una línea base que antes era prohibitivamente cara de obtener.

Después viene la pregunta difícil: ¿qué se queda y qué se mueve? No todo el COBOL necesita reemplazarse. Hay módulos que funcionan bien, que son estables, y cuyo costo de migración supera cualquier beneficio. Para esos, la decisión correcta es dejarlos donde están y construir capas de integración alrededor. Otros, en cambio, dependen de talento que se está jubilando, y ahí la migración es urgente.

¿Evaluaste un proyecto de modernización hace dos años y los números no cerraban? Vale la pena rehacer el cálculo. La fase de análisis, que siempre fue el componente más caro, ahora cuesta una fracción. Los costos generales de IA empresarial también bajaron, lo que cambia la ecuación completa.

Y un consejo que damos a todos nuestros clientes en esta situación: antes de migrar cualquier cosa, pon APIs frente a tus sistemas legacy. Eso permite que lo nuevo y lo viejo coexistan, reduce el riesgo de cada fase, y te da flexibilidad para priorizar qué mover primero. Una estrategia de APIs bien diseñada es lo que separa una migración controlada de un proyecto que se sale de presupuesto.

El negocio de la consultoría COBOL ya no será el mismo

La caída de IBM no es una anomalía puntual. El mercado está descontando un cambio estructural en cómo las empresas van a abordar sus sistemas legacy de aquí en adelante.

COBOL no va a desaparecer mañana. Ni en cinco años. La infraestructura financiera mundial depende de él, y reemplazarla se mide en décadas, no en trimestres. Pero la dinámica de poder cambió, y eso no tiene reversa. Las empresas que operan sobre mainframe ya no están cautivas de los precios de un solo proveedor para entender qué tienen y planificar qué hacer con ello.

Para empresas en América Latina hay un ángulo que pocos están discutiendo. La modernización de mainframe siempre estuvo dominada por consultoras con tarifas norteamericanas. Cuando la fase más cara del proceso se abarata, proyectos que antes quedaban descartados en la primera reunión de presupuesto se vuelven viables. Esto cambia la conversación para muchas empresas de la región que sabían que tenían un problema pero no podían pagarse la solución.

En IQ Source trabajamos con empresas que operan sobre sistemas legacy y quieren entender sus opciones reales, no las que les vende el proveedor que se beneficia de que no cambien nada. Si tu empresa tiene código COBOL o mainframe y quiere saber qué tiene, qué puede mover, y cuánto costaría, podemos hacer un diagnóstico de tu infraestructura legacy: mapear dependencias, documentar flujos críticos, y entregarte un plan de migración con costos y plazos concretos. Conversemos sobre tu caso.