La arquitectura de la comprensión: más allá de la sintaxis en la modernización de sistemas heredados empresariales

Resumen ejecutivo

La modernización de los sistemas heredados empresariales—específicamente la migración de mainframe arquitecturas a entornos nativos de la nube—ha alcanzado un punto de inflexión crítico a mediados de la década de 2020. Durante décadas, los sectores financiero y gubernamental han operado bajo un paradigma paradójico: el imperativo de modernizar es existencial, y sin embargo la tasa de fracaso de tales iniciativas permanece catastróficamente alta, oscilando entre el 70% y el 80%. ¹ La reciente llegada de los Large Language Models (LLMs) prometió una revolución, ofreciendo la tentadora posibilidad de traducción automatizada de código. Sin embargo, los primeros ciclos de adopción han revelado una crítica y sistémica deficiencia en los enfoques estándar de IA generativa cuando se aplican a complejos y monolíticos repositorios.

Estamos presenciando actualmente el surgimiento de una nueva categoría de fallo de ingeniería, tipificada por el escenario apócrifo pero altamente realista de un gran banco que intenta reescribir treinta años de COBOL a Java usando un asistente comercial de código. La IA, funcionando como un traductor localizado sofisticado, convirtió la sintaxis a la perfección. Sin embargo, la aplicación resultante hizo fallar la base de datos al desplegarse. El fallo no fue de sintaxis, sino de contexto. La IA, limitada por el síndrome «Lost in the Middle» y una comprensión basada en texto del software, pasó por alto una dependencia crítica de variable definida miles de líneas antes del bloque de ejecución. ³

Este whitepaper, presentado por Veriprajna, sostiene que el enfoque predominante de «LLM Wrapper» enfoque—que trata el código como una secuencia lineal de tokens de texto—es fundamentalmente inadecuado para la complejidad no lineal de la modernización empresarial. El software no es texto; es un grafo. Es un sistema altamente estructurado de dependencias lógicas, flujos de datos y cambios de estado que existe en un espacio topológico multidimensional. ⁵

Postulamos que el único camino viable hacia adelante es la adopción de conocimiento consciente del repositorio Grafos . Al pasar de la predicción estocástica de texto al razonamiento determinista basado en grafos, podemos mapear las dependencias de variables a lo largo de millones de líneas de código, resolviendo el fenómeno «Lost in the Middle» y transformando la modernización de una apuesta arriesgada en un proceso de ingeniería matemáticamente verificable. ⁷ Este documento describe la transición técnica de la traducción sintáctica superficial a la transformación estructural semántica profunda.

Capítulo 1: La crisis silenciosa de la infraestructura heredada

1.1 La paradoja de la modernización

En la economía digital actual, la infraestructura del comercio global depende precariamente de tecnología desarrollada durante la Guerra Fría. Es una realidad sorprendente, a menudo no reconocida, que, en 2025, una mayoría significativa de los sistemas financieros, sanitarios y gubernamentales del mundo funcionan con bases de código heredadas—aplicaciones monolíticas escritas en lenguajes como COBOL, PL/I y RPG que hace tiempo que desaparecieron del plan de estudios convencional de informática. Estos sistemas no son meramente «viejos»; son el lecho de roca fundacional de la economía global, y sin embargo se erosionan a un ritmo alarmante.

Las estadísticas pintan un panorama sombrío de esta dependencia. Aproximadamente el 70% del software que ejecutan las empresas Fortune 500 se desarrolló hace más de dos décadas. ⁹ En el sector bancario, la situación es aún más aguda: el 43% de los sistemas bancarios están construidos sobre COBOL, y estos sistemas procesan el 95% de todas las transacciones en cajeros automáticos. ¹ Estamos ejecutando de hecho la economía moderna de pagos instantáneos sobre un cimiento digital anterior a internet.

El coste de mantener este statu quo se dispara. La deuda técnica se ha acumulado hasta un estimado de $1.52 trillion solo en EE. UU. ¹ Las organizaciones están atrapadas en un ciclo de «mantener las luces encendidas», con el 80% de los presupuestos federales de TI dedicados a operaciones y mantenimiento, dejando un escaso 20% para la innovación. ⁹ Esta sangría de recursos se agrava con una grave escasez de talento; a medida que se jubila la generación de desarrolladores que escribió estos sistemas, el conocimiento institucional necesario para mantenerlos desaparece. ¹⁰

Tabla 1: La carga económica de los sistemas heredados

Métrica	Estadística	Fuente
Coste de la deuda técnica (EE. UU.)	$1.52 Trillion	1
Mantenimiento de TI federal Presupuesto	~80% del gasto total	9
Dependencia bancaria	95% de las transacciones en cajeros automáticos en COBOL	1

Probabilidad de filtración de datos	3x mayor en sistemas >10 años de antigüedad	11
Rotación de desarrolladores	El 58% considera dimitir debido a stacks heredados	1

Estos datos indican una vulnerabilidad sistémica. El imperativo de modernizar no se trata meramente de reducción de costes; se trata de supervivencia. Los sistemas de más de diez años tienen estadísticamente tres veces más probabilidad de sufrir una brecha de seguridad en comparación con las aplicaciones modernas. ¹¹ A medida que los requisitos regulatorios de privacidad de datos e informes en tiempo real se endurecen (p. ej., GDPR, DORA), la incapacidad de los sistemas heredados para adaptarse se convierte en un riesgo de cumplimiento del más alto orden.

1.2 La anatomía del «fallo bancario»

Para comprender la necesidad de un nuevo enfoque, debemos diseccionar el escenario que se ha convertido en el «Paciente Cero» de los fallos de modernización con IA. Este caso de estudio, citado por el liderazgo de Veriprajna, ilustra el mecanismo específico por el cual la IA estándar falla en entornos empresariales.

Una gran institución financiera inició un proyecto para migrar un sistema central de procesamiento de transacciones desde un IBM Mainframe (COBOL/DB2) a una arquitectura de microservicios Java nativa de la nube. El banco utilizó un popular asistente de código con IA—esencialmente un envoltorio alrededor de un modelo de fundación—para traducir el código.

La IA ingirió un programa COBOL responsable de procesar transferencias electrónicas de alto valor. El programa contenía una sentencia COMPUTE compleja que involucraba una variable que llamaremos TRN-LIMIT. La IA tradujo la sintaxis a la perfección. Convirtió la sentencia COMPUTE en una operación Java BigDecimal. El código compiló. Las pruebas unitarias—generadas por la misma IA a partir de el bloque de código local—pasaron.

Sin embargo, al desplegarse en el entorno de User Acceptance Testing (UAT), la primera transacción hizo fallar la comprobación de consistencia de la base de datos.

La autopsia: La variable TRN-LIMIT no estaba definida en el archivo fuente que la IA tradujo. Estaba definida en un COPYBOOK (un archivo de cabecera compartido) incluido miles de líneas antes en la cadena de ejecución. Más importante aún, ese COPYBOOK contenía una cláusula REDEFINES—una construcción COBOL que permite interpretar la misma dirección de memoria como dos tipos de datos distintos dependiendo de un flag establecido en un módulo completamente diferente. La IA, operando sobre un «chunk» de texto, vio TRN-LIMIT como un campo numérico simple. No vio la cláusula REDEFINES porque estaba ubicada en un archivo distinto que no estaba en la inmediata ventana de contexto. «Alucinó» una definición estándar para la variable. En el mainframe entorno, la dirección de memoria contenía un packed decimal; en el entorno Java, la IA la trató como un entero estándar. El desajuste hizo que la aplicación Java escribiera corruptos datos binarios en la columna de la base de datos, disparando un fallo de integridad referencial. ⁴

El fallo no fue de sintaxis; el código Java era sintácticamente perfecto. El fallo fue de ceguera contextual . La IA pasó por alto una dependencia que existía fuera de su «campo de visión», lo que condujo a una divergencia semántica catastrófica.

1.3 El dilema «Lift and Shift» frente a la refactorización

El historial de la industria en modernización es abismal, incluso antes de la introducción de la IA generativa. La investigación indica que entre el 70% y el 80% de los proyectos de transformación digital y modernización de sistemas heredados no cumplen sus objetivos. ²

Tradicionalmente, las organizaciones se han enfrentado a una elección binaria:

1.​ Rehost (Lift and Shift): Mover la aplicación compilada a un emulador en la nube. Esto conserva el «spaghetti code» y la deuda, cambiando meramente la factura de hosting. No logra desbloquear la agilidad de la nube. ¹⁴

2.​ Rewrite (Refactor): Reescribir manualmente el código en un lenguaje moderno. Esto es astronómicamente caro, lento y arriesgado por la falta de documentación y la arquitectura «Big Ball of Mud», donde la lógica de negocio está inextricablemente enredada con el acceso a datos. ¹⁰

Se suponía que la IA generativa ofrecería una «tercera vía»—la refactorización automatizada. Sin embargo, el «fallo bancario» demuestra que, sin una comprensión más profunda de la topología del software, la IA meramente acelera la creación de código defectuoso.

Capítulo 2: El fracaso de la traducción estocástica

2.1 La economía del «Wrapper» y sus límites

En este entorno de alto riesgo irrumpió el «LLM Wrapper». La reacción inmediata del mercado de consultoría de software ante el lanzamiento de GPT-4 fue la proliferación de herramientas que actúan como capas de software delgadas entre un desarrollador y un modelo de fundación. ¹⁵ Estas herramientas prometen «chatear con tu código», permitiendo a los desarrolladores pegar un párrafo COBOL y recibir un método Java a cambio.

Aunque estos envoltorios bajan la barrera de entrada a la adopción de IA, son fundamentalmente defectuosos cuando se aplican a la reingeniería de sistemas a gran escala. Los envoltorios suelen basarse en Naïve RAG (generación aumentada por recuperación). En este proceso, el sistema toma una consulta del usuario, busca en una base de datos vectorial fragmentos de código que son textualmente similares a la consulta, y alimenta esos fragmentos al LLM como contexto. ¹⁷

Las limitaciones de este enfoque en un contexto empresarial son graves:

1.​ Miopía contextual: Un envoltorio ve el código como segmentos de texto. No comprende que una variable ACCOUNT-BALANCE modificada en SECTION-A impulsa una lógica de decisión en SECTION-Z a cinco mil líneas de distancia.

2.​ Éxito sintáctico, fallo semántico: Como se señaló, un LLM puede producir código Java que compila a la perfección pero no replica el comportamiento exacto en tiempo de ejecución del COBOL original porque pasó por alto un cambio de estado global. ⁴

Veriprajna se distingue al rechazar la filosofía del «Thin Wrapper». Afirmamos que las profundas soluciones de IA deben comprender la estructura del repositorio, no solo el texto del archivo.

2.2 El síndrome «Lost in the Middle»

Para comprender por qué la IA estándar falla en la modernización de sistemas heredados, debemos comprender la arquitectura cognitiva de los Large Language Models. Estos modelos se basan en la arquitectura Transformer, que usa un «mecanismo de atención» para ponderar la importancia de distintas partes del texto de entrada. ¹⁸

Aunque los LLM modernos presumen de ventanas de contexto masivas (hasta 1 millón de tokens), su capacidad para usar eficazmente ese contexto no es uniforme. La investigación empírica ha demostrado un fenómeno conocido como el efecto «Lost in the Middle» . Cuando se les presenta una larga secuencia de información, los LLM exhiben una curva de rendimiento en forma de U:

●​ Sesgo de primacía: Son altamente precisos al recordar información al principio del prompt.

●​ Sesgo de recencia: Son altamente precisos al recordar información al final del prompt.

●​ El valle: El rendimiento se degrada de forma significativa para la información situada en el medio. ³

En un proyecto de modernización, un solo programa COBOL puede tener miles de líneas, y puede referenciar copybooks (dependencias) que a su vez tienen miles de líneas. Si la definición de una variable crítica—por ejemplo, MAX-TRANSACTION-LIMIT—aparece en el medio de este contexto masivo, es estadísticamente probable que la IA la pase por alto. ²¹

Cuando la IA pasa por alto una definición de variable, no se detiene. «Alucina». Asume un tipo o valor por defecto para la variable basado en probabilidad, no en hechos. En un sistema bancario, asumir que una variable es un Integer cuando en realidad es un Packed Decimal puede provocar errores de redondeo que corrompen los datos financieros. ²²

Tabla 2: Las limitaciones cognitivas de los LLM estándar

Fenómeno	Descripción	Impacto en la modernización
Lost in the Middle	Atención degradada en el centro de prompts largos.3	Definiciones de variables omitidas enterradas en archivos grandes.
Alucinación	Fabricación de hechos plausibles pero incorrectos.22	Inventar dependencias o lógica para llenar huecos en el contexto.
Sesgo de primacía/recencia	Enfoque en el inicio/final del texto.20	Ignorar la lógica de negocio central situada en el medio de un procedimiento.
Generación estocástica	Predicción probabilística de texto.	Código inconsistente generación; volver a ejecutar el prompt produce distinta lógica.

2.3 La «bolsa de palabras» frente al «árbol de la lógica»

Los LLM estándar y los sistemas Vector RAG procesan el código principalmente como una secuencia de tokens. Se basan en la similitud semántica—comprobando si las palabras de la consulta coinciden con palabras en el documento espacio vectorial. ¹⁷

Sin embargo, el código no es lenguaje natural. En el lenguaje natural, «The cat sat on the mat» tiene un significado en gran medida independiente de una oración cincuenta páginas antes. En software, x = y + 1 tiene cero significado a menos que conozcamos las definiciones, tipos y estados actuales de x e y. Estas definiciones pueden existir en un archivo distinto, un módulo distinto, o heredarse de una clase padre. ⁵

Cuando una IA «wrapper» recupera contexto para una consulta como «Refactor the payment logic,» puede traer cinco fragmentos de código que contienen la palabra «payment». Es probable que omita el fragmento llamado GlobalVarDef.cbl, que define el tipo impositivo usado por la lógica de pago, porque ese archivo nunca menciona la palabra «payment.»

Esta desconexión representa la brecha fundamental entre la recuperación textual y la estructural comprensión . Para cerrar esta brecha, debemos dejar de tratar el código como literatura y empezar a tratarlo como un grafo. ²³

Capítulo 3: La física del software –

El código como grafo

3.1 El software como sistema relacional

En Veriprajna reconocemos que un repositorio de software es fundamentalmente una base de datos relacional de lógica . Cada entidad del codebase—variables, funciones, clases, módulos, base de datos esquemas—existe en una densa red de relaciones.

●​ Contención: Un archivo contiene una clase; una clase contiene un método; un método contiene una declaración de variable.

●​ Herencia: La clase B hereda propiedades y métodos de la clase A.

●​ Invocación: El método X llama al método Y.

●​ Flujo de datos: La variable Z es modificada por la función Q y leída por la función R.

Estas relaciones constituyen la «verdad de terreno» de la aplicación. No son probabilísticas; son deterministas. Si el método X llama al método Y, eso es un hecho duro, no una estadística probabilidad. Los LLM estándar operan en el dominio probabilístico. Para modernizar con seguridad los heredados sistemas, debemos anclar sus capacidades de generación probabilística a la realidad determinista de la estructura del código. ⁷

3.2 El árbol de sintaxis abstracta (AST)

La unidad fundacional de esta comprensión estructural es el árbol de sintaxis abstracta (AST) . El AST es una representación en árbol de la estructura sintáctica abstracta del código fuente. A diferencia de una cadena cruda de texto, un AST captura la jerarquía y las reglas gramaticales del lenguaje. ²⁴

Por ejemplo, la sentencia COBOL: COMPUTE INTEREST = PRINCIPAL * RATE no son solo cinco palabras. En un AST, es un AssignmentNode con un Target (Interest) y una Expression. La Expression es un MultiplicationNode con un LeftOperand (Principal) y un RightOperand (Rate).26 Al parsear el código heredado en AST, vamos más allá de las ambigüedades del texto. Podemos identificar programáticamente cada uso de variable, cada operación aritmética y cada rama de flujo de control. Esto nos permite realizar ingeniería de «ida y vuelta»—convirtiendo código a AST y de vuelta a código sin pérdida de datos—asegurando que nuestro análisis estructural sea preciso. ²⁷

A diferencia del «troceado de texto» usado en el RAG estándar—donde un archivo se corta a ciegas en 500-token segmentos, a menudo partiendo una función por la mitad—el parseo AST respeta los límites lógicos del código. Una función se trata como una unidad discreta de lógica, no como un tramo aleatorio de texto. ²³

3.3 El grafo de llamadas y la matriz de dependencias

Mientras que el AST representa la estructura de un solo archivo, el grafo de llamadas representa el nervioso sistema de toda la aplicación. Visualiza el flujo de control, mapeando qué párrafos o subrutinas invocan a otras. ²⁹

En los sistemas COBOL heredados, los grafos de llamadas suelen quedar oscurecidos por llamadas dinámicas o lógica GOTO que crea «spaghetti code». Un análisis estático de texto no puede resolver fácilmente dónde aterriza un GOTO LABEL_X si LABEL_X se define de forma dinámica o condicional.

Al construir un grafo de llamadas riguroso, Veriprajna identifica «código muerto» (código que nunca se llama) y «God Classes» (módulos demasiado acoplados). Este análisis es crítico para descomponer monolitos en microservicios. Si no conocemos la cadena de llamadas completa, no podemos extraer con seguridad un servicio; corremos el riesgo de dejar atrás una «referencia colgante» que provocará un fallo en tiempo de ejecución—el escenario exacto que aquejó al banco en nuestro caso de estudio inicial. ³¹

Tabla 3: Análisis estructural frente a análisis de texto

Característica	Análisis de texto (estándar IA)	Análisis estructural (Veriprajna)
Unidad de análisis	Token / Palabra	Nodo (elemento AST)
Límite de contexto	Límite arbitrario de tokens	Ámbito lógico (función/clase)
Resolución de dependencias	Coincidencia de palabras clave	Recorrido del grafo
Manejo de GOTO	Lo trata como cadena de texto	Mapea aristas de flujo de control
Precisión	Probabilística	Determinista

3.4 Inyección de dependencias e inversión

Las arquitecturas Java modernas y Cloud-Native dependen en gran medida de la inyección de dependencias (DI) y de la inversión de control (IoC). El COBOL heredado, por el contrario, se basa en dependencias cableadas y estado global. Pasar de uno a otro exige identificar cada dependencia en el grafo e «invertirla».

Debemos cambiar el paradigma de «el módulo A cablea una conexión a la base de datos B» a «el módulo A acepta una conexión a base de datos como parámetro». Este cambio arquitectónico es imposible si la IA no puede ver la dependencia de entrada. El grafo de conocimiento hace explícitas estas dependencias, permitiendo a la IA generar el boilerplate de DI necesario automáticamente, asegurando que el nuevo sistema sea modular y comprobable. ⁴

Capítulo 4: La semántica de Veriprajna Forja

4.1 Arquitectura del grafo de conocimiento consciente del repositorio

La solución al síndrome «Lost in the Middle» y a la fragilidad de la migración basada en texto es el grafo de conocimiento consciente del repositorio . Se trata de una base de datos de grafos unificada que combina la estructura estática del código (AST, grafos de llamadas) con el significado semántico de la lógica de negocio (documentación, comentarios, intención de las variables). ⁵

Veriprajna emplea un pipeline propietario, a menudo denominado en la investigación avanzada como una «forja semántica», para construir esta inteligencia. No es un proceso ETL genérico; es un motor construido a propósito para la modernización de sistemas heredados. ³³

4.2 Fase 1: parseo inteligente con Tree-sitter

Utilizamos parsers robustos, principalmente Tree-sitter, para ingerir el codebase heredado. Este proceso admite más de 13 lenguajes, incluidos COBOL, JCL, PL/I y Java. El parser genera un AST para cada archivo del repositorio.

De forma crucial, empleamos troceado semántico . Los pipelines RAG estándar usan «partición ingenua», cortando el texto cada n tokens. Esto con frecuencia secciona la firma de una función de su cuerpo o una definición de variable de su uso, destruyendo el contexto. El troceado semántico usa el AST para identificar límites lógicos. Troceamos el código por SECTION, PARAGRAPH o METHOD, asegurando que cada nodo de nuestro grafo represente una unidad de lógica completa y ejecutable. ²³

4.3 Fase 2: extracción de entidades y relaciones

Una vez generados los AST, la forja semántica extrae las entidades y relaciones para poblar la base de datos de grafos (p. ej., Neo4j, Memgraph).

●​ Entidades: Clases, párrafos, variables, tablas de base de datos, endpoints de API.

●​ Relaciones:

○​ CALLS: Conecta un párrafo con la subrutina que invoca.

○​ UPDATES_TABLE: Conecta un bloque de lógica con la tabla DB2 que modifica.

○​ IMPORTS_COPYBOOK: Conecta un archivo fuente con su dependencia.

○​ DEFINES_VARIABLE: Conecta una data division con las variables que crea.

Esta fase transforma el texto estático en una topología dinámica. Ahora podemos consultar el grafo: «Muéstrame cada párrafo que actualiza el campo CUSTOMER-ID». Esta consulta devuelve exactos resultados al instante, una hazaña imposible con grep o búsqueda vectorial. ¹⁴

4.4 Fase 3: resolución de entidades y fusión

Este es el punto crítico de diferenciación. Un parser estándar ve ACCT-NUM en el archivo A y ACCT-NUM en el archivo B como dos cadenas distintas. Nuestro sistema realiza resolución de símbolos . Determina que ambas se refieren a la misma entrada en un Copybook compartido. Las fusiona en un único nodo de variable en el grafo.

Además, realizamos fusión cross-modal . Si el codebase contiene un documento PDF de requisitos que describe la «User API», y el código contiene una clase llamada UserAPI, el sistema calcula embeddings para reconocer que son el mismo concepto. Fusiona el nodo de documentación con el nodo de código. Esto vincula la intención (docs) con la implementación (código), proporcionando a la IA el «porqué» junto al «cómo». ⁸

4.5 Fase 4: cálculo de la clausura transitiva

El «fallo bancario» fue causado por una dependencia transitiva: A depende de B, B depende de C. La IA vio A pero omitió C.

El grafo de conocimiento de Veriprajna calcula la clausura transitiva . Cuando el sistema analiza el módulo A, no se detiene en los vecinos directos. Recorre el grafo en profundidad (A -> B -> C) para identificar la «raíz de la verdad» de cada variable. Esto asegura que, cuando la IA genera código para el módulo A, importe las definiciones correctas del módulo C, aunque el módulo C esté en un directorio o repositorio distinto. ⁸

Capítulo 5: generación aumentada por recuperación con grafos (GraphRAG)

5.1 Las limitaciones del Vector RAG

La generación aumentada por recuperación vectorial (RAG) es el estándar de la industria para añadir conocimiento a los LLM. Convierte texto en vectores (representaciones numéricas) y encuentra vectores similares. Aunque excelente para consultar texto no estructurado como las FAQ, es insuficiente para el código.

●​ Renombrado de variables: Si un desarrollador renombra Account a Acct, la similitud semántica cae, aunque la lógica sea idéntica.

●​ Lógica frente a palabras clave: Buscar «Interest Calculation» puede omitir la matemática real si la función se llama FNC-001 y no contiene comentarios.

●​ Contexto fragmentado: Vector RAG recupera «chunks» según similitud de coseno. Puede recuperar una prueba unitaria y un comentario de UI, pero omitir la lógica de negocio central porque los nombres de las variables no coinciden con las palabras de la consulta. ³⁶

5.2 La ventaja de GraphRAG

GraphRAG opera sobre la estructura del grafo de conocimiento, no solo sobre la similitud textual.

1.​ Identificación de anclas: Cuando un usuario pide «Refactor the Payment Logic,» el sistema usa búsqueda vectorial para encontrar el punto de entrada (p. ej., el párrafo ProcessPayment).

2.​ Recorrido del grafo (expansión): En lugar de detenerse ahí, GraphRAG recorre el grafo aristas. Incorpora:

○​ Las aristas CALLS para encontrar subrutinas.

○​ Las aristas READS para encontrar definiciones de variables.

○​ Las aristas INCLUDES para encontrar Copybooks.

3.​ Construcción de contexto: Estas piezas conectadas—que pueden ser textualmente disímiles pero son lógicamente inseparables—se ensamblan en un prompt coherente.

Esta expansión de relevancia asegura que el LLM reciba una rebanada auto-contenida y ejecutable de lógica. Comprende no solo el texto del cálculo, sino la maquinaria del mismo. ³⁶

5.3 Razonamiento multi-salto

La investigación muestra que GraphRAG supera de forma significativa a Vector RAG en tareas que requieren «razonamiento multi-salto»—conectar hechos separados por varios pasos. En software, casi cada bug es un fallo de razonamiento multi-salto (p. ej., A llama a B, B cambia X, C lee X. Si A cambia, ¿se rompe C?).

GraphRAG permite a la IA responder preguntas complejas de análisis de impacto: «Si cambio el interés lógica de tipos en el módulo A, ¿qué pantallas de reporting del módulo Z se verán afectadas?» Vector RAG no puede responder esto porque el módulo A y el módulo Z no comparten similitud textual; están vinculados solo por una cadena de llamadas a funciones. El grafo recorre esta cadena para ofrecer una definitiva respuesta. ³⁸

Tabla 4: Vector RAG frente a GraphRAG

Característica	Vector RAG	GraphRAG
Clave de recuperación	Similitud (distancia de coseno)	Relación (arista del grafo)
Calidad del contexto	Alto recall, baja precisión (ruido)	Alta precisión, conectado Contexto

Razonamiento multi-salto	Pobre (omite vínculos indirectos)	Excelente (recorre cadenas)
Riesgo de alucinación	Alto (adivina los faltantes vínculos)	Bajo (los vínculos recuperados son explícitos)
Mejor caso de uso	Texto no estructurado (FAQ)	Sistemas estructurados (código, biología)

Capítulo 6: Ingeniería de la migración – Inmersión técnica

6.1 Resolver la trampa de la «variable global»

Uno de los aspectos más peligrosos de COBOL es el uso de variables globales definidas en la DATA DIVISION y modificadas por diversas sentencias PERFORM a lo largo del programa. En Java, las mejores prácticas dictan encapsulación; un método no debe depender de estado oculto.

La solución: Los agentes de Veriprajna realizan análisis de flujo de datos sobre el grafo. Trazamos el ciclo de vida de cada variable.

●​ Si un párrafo CALC-TAX lee GROSS-INCOME, el grafo identifica GROSS-INCOME como una dependencia de entrada .

●​ Al generar el método Java calcTax(), la IA añade explícitamente BigDecimal grossIncome a la firma del método.

●​ A continuación actualiza el caller del método para pasar el valor correcto.

Esta refactorización automática de «estado global implícito» a «paso explícito de parámetros» previene los bugs de efectos secundarios que aquejaron al banco en nuestro caso de estudio. ⁴

6.2 Deconstruir el spaghetti GOTO

Uno de los obstáculos más feroces en la migración COBOL es la sentencia GOTO. GOTO permite que la ejecución del programa salte a cualquier sitio, creando flujos de control no lineales anatemas para la programación estructurada moderna. ⁴⁰ Java no tiene sentencia GOTO.

Traducir la lógica GOTO exige más que traducción de sintaxis; exige flujo de control aplanamiento .

1.​ Análisis de grafo: Mapeamos los destinos GOTO como aristas en el grafo de flujo de control (CFG).

2.​ Reconocimiento de patrones: El grafo identifica patrones.

○​ Un GOTO que salta atrás a una etiqueta anterior se identifica como un bucle .

○​ Un GOTO que omite un bloque se identifica como un condicional (if/else).

○​ Un GOTO a un párrafo de salida es un return .

3.​ Reestructuración: La IA, guiada por el grafo, refactoriza estos saltos en bucles while, bucles do-while o sentencias break/continue en Java.

Sin un grafo para visualizar los «bucles» creados por GOTO, un LLM basado en texto a menudo generará una llamada de función recursiva que conduce a un StackOverflowError, o simplemente alucinará un flujo lógico que no existe. ⁴

6.3 Manejar el «código muerto»

Los sistemas heredados están llenos de código que ya no se usa—promociones antiguas, productos retirados, rutinas de depuración. Migrar este código es un desperdicio de dinero y añade superficie de ataque de seguridad. La IA basada en texto migra todo lo que se le da; no puede distinguir entre activo y muerto código.

La solución: El grafo de llamadas identifica nodos inalcanzables—párrafos o archivos que no tienen entrantes aristas (sin llamadores). El sistema de Veriprajna marca este «código muerto» para su eliminación antes de que empiece la migración. Esto suele reducir el tamaño del codebase en un 20-30%, lo que se traduce en significativos ahorros de coste y una arquitectura final más limpia.31

Capítulo 7: El futuro agéntico – IA profunda frente a envoltorios superficiales

7.1 Más allá del chatbot: el flujo de trabajo agéntico

Veriprajna no despliega «chatbots». Desplegamos agentes de IA autónomos . Un agente es un sistema capaz de planificar, ejecutar y corregir sus acciones a partir de la retroalimentación. ²

El flujo de trabajo del envoltorio superficial:

1.​ Usuario: «Convierte este código.»

2.​ Envoltorio: Envía texto a GPT-4.

3.​ Salida: Devuelve código Java.

4.​ Resultado: El código no compila ni se ejecuta. El desarrollador depura a mano.

El flujo de trabajo del agente profundo de Veriprajna:

1.​ Planificación: El agente analiza el AST del archivo COBOL objetivo. Identifica dependencias y consulta el grafo de conocimiento.

2.​ Recuperación: Obtiene el contexto GraphRAG necesario para la migración.

3.​ Generación: Genera el código Java usando un «decodificador de restricciones esquemáticas» que impone las reglas de sintaxis Java y la seguridad de tipos. ⁷

4.​ Verificación (el bucle): El agente compila el código Java generado en un sandbox.

5.​ Autocorrección: Si el compilador lanza un error (p. ej., «Variable not found»), el agente lee el error, consulta el grafo por la dependencia faltante y regenera el código.

6.​ Validación: Ejecuta pruebas unitarias (generadas a partir de las trazas COBOL originales) para asegurar que la salida coincida con el comportamiento de entrada.

Este bucle compile-fix desplaza la carga de la validación del humano a la IA, reduciendo de forma dramática el coste de la refactorización. ⁴²

7.2 Supervisión human-in-the-loop

Aunque el agente es autónomo en la ejecución, está supervisado en la estrategia. El grafo de conocimiento proporciona interpretabilidad . A diferencia de una red neuronal «caja negra», el grafo permite a los desarrolladores ver exactamente por qué la IA tomó una decisión. «La IA importó com.bank.logic porque encontró una dependencia de COPYBOOK-X.»

Esta transparencia es vital para industrias reguladas como la banca, donde cada línea de código debe ser auditable. Pasamos de «Confía en mí, soy IA» a «Aquí está la cadena de citas de esta lógica». ⁴³

Capítulo 8: Conclusión y perspectiva estratégica

8.1 El ROI de la conciencia del repositorio

Los datos de McKinsey sugieren que la GenAI puede reducir las tareas de programación en un 50%, pero solo si se despliega correctamente. ¹⁴ El retorno de la inversión (ROI) del enfoque basado en grafos de Veriprajna está impulsado por la eliminación del retrabajo.

●​ Migración manual: Alto coste, alto riesgo, lento time-to-market.

●​ IA wrapper: Coste medio (por depurar «alucinaciones»), alto riesgo (bugs ocultos), time-to-market medio.

●​ IA de grafo de repositorio: Bajo coste (automatización), bajo riesgo (verificación determinista), rápido time-to-market.

Al eliminar la sobrecarga de «cambio de contexto»—donde los desarrolladores pasan horas buscando dónde está definida una variable—Veriprajna aumenta la productividad de los desarrolladores de 2x a 3x en comparación con las herramientas de IA estándar. ²

8.2 Preparación para el futuro mediante modernización continua

La modernización no es un evento puntual; es un ciclo de vida. Una vez que el codebase se convierte en un grafo de conocimiento, permanece como un activo vivo. A medida que el nuevo código Java evoluciona, el grafo se actualiza en tiempo real. Esto habilita:

●​ Documentación automatizada: La IA puede generar documentación actualizada para el nuevo sistema leyendo el grafo. ⁴⁴

●​ Detección de deriva arquitectónica: El sistema puede alertar a los arquitectos si el código nuevo viola las reglas de modularidad definidas en el grafo. ⁴⁵

8.3 El giro estructural

La lección del «fallo bancario» es clara: El código no es texto. Es un complejo e interconectado sistema de lógica. Intentar modernizarlo con herramientas que solo comprenden texto equivale a intentar navegar una ciudad usando una lista de nombres de calles pero sin mapa. Te perderás «Lost in the Middle.»

Veriprajna ofrece el mapa. Al construir grafos de conocimiento conscientes del repositorio, proporcionamos la IA la inteligencia estructural que necesita para navegar las complejidades de los sistemas heredados. Mapeamos las dependencias, desenredamos los nudos y entregamos una modernización que funciona no solo en la sintaxis, sino en la realidad.

No solo escribimos código; ingeniamos comprensión. Esta es la diferencia entre un chatbot y un proveedor de soluciones. Este es el futuro de la modernización empresarial.

Veriprajna. IA profunda para soluciones profundas.

Obras citadas

1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders, consultado el 10 de diciembre de 2025, https://www.pragmaticcoders.com/resources/legacy-code-stats

2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy, consultado el 10 de diciembre de 2025, https://softprodigy.com/ai-driven-legacy-app-modernization/

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, consultado el 10 de diciembre de 2025, https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs, consultado el 10 de diciembre de 2025, https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation, consultado el 10 de diciembre de 2025, https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

6. Structural-Semantic Code Graph (SSCG) - Emergent Mind, consultado el 10 de diciembre de 2025, https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate, consultado el 10 de diciembre de 2025, https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv, consultado el 10 de diciembre de 2025, https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, consultado el 10 de diciembre de 2025, https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help, consultado el 10 de diciembre de 2025, https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix, consultado el 10 de diciembre de 2025, https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions, consultado el 10 de diciembre de 2025, https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz, consultado el 10 de diciembre de 2025, https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, consultado el 10 de diciembre de 2025, https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs, consultado el 10 de diciembre de 2025, https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome, consultado el 10 de diciembre de 2025, https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch, consultado el 10 de diciembre de 2025, https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium, consultado el 10 de diciembre de 2025, https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

19. A practical guide to the Claude code context window size - eesel AI, consultado el 10 de diciembre de 2025, https://www.eesel.ai/blog/claude-code-context-window-size

20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct, consultado el 10 de diciembre de 2025, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

21. Why Language Models Are “Lost in the Middle” - Towards AI, consultado el 10 de diciembre de 2025, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind, consultado el 10 de diciembre de 2025, https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers, consultado el 10 de diciembre de 2025, https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

24. AST-Based Source Code Migration Through Symbols Replacement, consultado el 10 de diciembre de 2025, https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

25. BMSD 2011, consultado el 10 de diciembre de 2025, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

26. Abstract Syntax Tree Creation - Compiler Design - Meegle, consultado el 10 de diciembre de 2025, https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium, consultado el 10 de diciembre de 2025, https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

28. Daily Papers - Hugging Face, consultado el 10 de diciembre de 2025, https://huggingface.co/papers?q=outlier%20chunk%20handling

29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp, consultado el 10 de diciembre de 2025, https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, consultado el 10 de diciembre de 2025, https://ieeexplore.ieee.org/document/9138056/

31. Enhancing Neural Code Representation with Additional Context - arXiv, consultado el 10 de diciembre de 2025, https://arxiv.org/html/2510.12082v1

32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, consultado el 10 de diciembre de 2025, https://www.ijcai.org/proceedings/2025/0848.pdf

33. Code Graph: From Visualization to Integration - FalkorDB, consultado diciembre 10, 2025, https://www.falkordb.com/blog/code-graph/

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, consultado el 10 de diciembre de 2025, https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv, consultado el 10 de diciembre de 2025, https://arxiv.org/html/2511.07584

36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph, consultado el 10 de diciembre de 2025, https://memgraph.com/blog/rag-vs-graphrag

37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype, consultado el 10 de diciembre de 2025, https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

38. Navigating the Nuances of GraphRAG vs. RAG - foojay, consultado el 10 de diciembre de 2025, https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket, consultado el 10 de diciembre de 2025, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

40. Why not GOTO Statement? [closed] - Stack Overflow, consultado el 10 de diciembre de 2025, https://stackoverflow.com/questions/19766205/why-not-goto-statement

41. Alternative to a goto statement in Java - Stack Overflow, consultado el 10 de diciembre de 2025, https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers, consultado el 10 de diciembre de 2025, https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

43. Legacy IT Modernization with AI | MITRE, consultado el 10 de diciembre de 2025, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, consultado el 10 de diciembre de 2025, https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

45. The AI revolution in application modernization: from manual burden to strategic advantage, consultado el 10 de diciembre de 2025, https://vfunction.com/blog/ai-app-modernization-strategy/