Resumen Técnico: Reingeniería Basada en Especificaciones de Código–Texto–Código para la Evolución de Software Mediada por LLM

1. Declaración del Problema

Los Modelos de Lenguaje Grande (LLM) se utilizan cada vez más para la migración de software, la refactorización y la regeneración de código. Sin embargo, los enfoques de transformación directa de Código a Código enfrentan limitaciones significativas. Estas incluyen:

• Deriva Semántica: Los modelos pueden preservar la sintaxis superficial mientras alteran la lógica de negocio subyacente o introducen cambios de comportamiento ocultos.
• Salida No Idiomática: El código generado puede retener constructos del lenguaje de origen que son inapropiados para el entorno objetivo.
• Pérdida de Trazabilidad: A menudo no existe un vínculo claro entre el código fuente, la interpretación del modelo y el artefacto regenerado.
• Brechas Contextuales: La traducción directa a menudo no tiene en cuenta las dependencias de datos, el manejo de excepciones y las suposiciones no funcionales.

El artículo argumenta que la evolución de software mediada por LLM no debe considerarse meramente como generación de código, sino como un proceso de reingeniería controlado que requiere capas de representación intermedia para garantizar la consistencia semántica y la preservación estructural.

2. Metodología: El Marco Código–Texto–Código

El marco propuesto introduce un modelo de reingeniería Basado en Especificaciones de Código–Texto–Código. El flujo de transformación central se define como:
$$C_0 \rightarrow S_n \rightarrow C_1$$
Donde $C_0$ es el código fuente, $S_n$ es una especificación textual neutral, y $C_1$ es el código objetivo regenerado.

A. La Especificación Textual Neutral ($S_n$)

A diferencia de un simple resumen de código, $S_n$ es un artefacto estructurado y verificable diseñado para capturar:

• Comportamiento del programa, identificadores y flujo computacional.
• Condiciones, efectos secundarios y dependencias de datos.
• Intención específica del dominio sin sesgo de sintaxis del lenguaje de origen.
• Sirve como un "mediador semántico" que separa qué hace el software de cómo se implementa.

B. Capa de Representación del Conocimiento

El marco integra múltiples capas de representación para apoyar la trazabilidad y la validación:

• Extracción de AST y Metadatos: Extracción estructurada de hechos (nombres de funciones, firmas, dependencias) para restringir el proceso de generación y reducir las alucinaciones.
• Ontología y Anotación Semántica: Mapeo de representaciones intermedias a conocimiento estructurado (OWL/SKOS) para apoyar el razonamiento y la reutilización.
• Representación Gráfica: Utilización de Grafos de Propiedades de Código (CPG) para rastrear dependencias (llamadas, lecturas, escrituras) y estimar pérdidas de transformación.
• Recuperación Híbrida: Combinación de búsqueda vectorial (para similitud semántica) con recorrido de grafos (para dependencias estructurales) y filtrado de metadatos para fundamentar tanto las fases Código2Texto como Texto2Código.

C. Arquitectura del Pipeline

El pipeline de extremo a extremo incluye:

1. Extracción de Contexto Factico: Recopilación de identificadores y dependencias antes de la generación de especificaciones.
2. Generación Código2Texto: Creación de la especificación neutral inicial utilizando RAG y contexto factico.
3. Validación y Refinamiento Iterativo: Comparación de la especificación con el código fuente para detectar comportamientos faltantes o suposiciones excesivas.
4. Humano en el Bucle: Corrección opcional por expertos para lógica de negocio ambigua o suposiciones ocultas.
5. Generación Texto2Código: Generación de código objetivo basado en la especificación validada, asegurando una implementación idiomática en el lenguaje objetivo.
6. Verificación del Objetivo: Validación de sintaxis, equivalencia funcional y estabilidad de la interfaz.
7. Retroalimentación del SGBD (para SQL): Uso de validación basada en ejecución para garantizar la corrección específica del dialecto.

D. Segmentación Consciente Semánticamente

El artículo enfatiza que la segmentación ingenua rompe unidades semánticas. Propone un "bloque de código ideal" definido por atomicidad, autoanalizabilidad y conciencia semántica, evaluado mediante métricas como F1 de Límite y Certidumbre del Bloque.

3. Contribuciones Clave

El artículo presenta cinco contribuciones principales:

1. Interpretación Conceptual: Reencuadrar Código–Texto–Código no como un pipeline de traducción, sino como un proceso de reingeniería basado en especificaciones donde el texto neutral es un artefacto de conocimiento controlado.
2. Arquitectura del Pipeline: Un sistema integral que integra extracción factica, validación iterativa, corrección humana y retroalimentación con soporte de SGBD.
3. Modelo de Representación del Conocimiento: Un modelo unificado que combina metadatos AST, ontologías, dependencias gráficas y texto neutral para vincular código fuente, documentación y artefactos regenerados.
4. Evaluación Experimental: Un conjunto de datos que abarca múltiples lenguajes (Java, Python, C++, dialectos SQL) y un protocolo de evaluación que compara representaciones intermedias (Pseudocódigo, IR Gráfica, IR de Compilador, IR de Lenguaje Natural).
5. Estimación Formal de Pérdidas: Una formalización basada en grafos para cuantificar las pérdidas de transformación utilizando:
   • Preservación Estructural Direccional ($\alpha$): Medición de la retención de dependencias de origen.
   • Compatibilidad Inversa ($\beta$): Medición de la introducción de dependencias objetivo innecesarias.
   • Preservación de Interfaz ($\delta_{IO}$): Garantía de estabilidad de entrada/salida.
   • Similitud Total del Grafo ($S$): Una media armónica ponderada de los anteriores.

4. Resultados Experimentales

Los autores realizaron experimentos utilizando un conjunto de datos de 1.000 scripts por lenguaje en nueve lenguajes de programación y cinco dialectos SQL.

• Comparación de Representaciones Intermedias: La IR de Lenguaje Natural (la especificación neutral) demostró la mayor idoneidad práctica para la transformación mediada por LLM en comparación con el pseudocódigo, la IR basada en grafos o la IR estilo compilador.
• Evaluación de Recuperación: La recuperación vectorial demostró ser más precisa para la relevancia semántica, mientras que la recuperación gráfica ofreció menor latencia para la navegación de dependencias. Se recomendó un enfoque híbrido.
• Transformación de Documentación: En los experimentos de TechDoc a BusinessDoc, 22 de 24 bloques aprobaron la validación. Los fallos involucraron distorsión lógica u omisión de alcance, destacando la necesidad de bucles de validación.
• Ajuste de Prompts: Utilizando DSPy/MIPROv2, los autores encontraron que el prompt base original, cuidadosamente restringido, superó a las variantes generadas automáticamente. Esto sugiere que, para tareas de reingeniería restringidas, las restricciones explícitas (neutralidad, estructura) son más críticas que la complejidad del prompt.
• Métricas Gráficas: Las métricas formales cuantificaron con éxito la preservación estructural y la estabilidad de la interfaz, proporcionando un método para detectar transformaciones "plausibles pero incorrectas".

5. Significado y Afirmaciones

El artículo afirma que la reingeniería Código–Texto–Código basada en especificaciones ofrece una alternativa controlada, trazable y monitorizable a la generación de código directa opaca.

• Transparencia: Al hacer explícita la especificación intermedia, la interpretación del modelo se vuelve visible, revisable y corregible.
• Control de Calidad: El marco va más allá de la corrección sintáctica local para evaluar la cobertura semántica, la fundamentación de la recuperación y la preservación estructural.
• Monitorización Inteligente: Los autores posicionan el marco no solo como una herramienta de transformación, sino como un objeto de "monitorización inteligente", donde la consistencia semántica y las pérdidas de transformación se evalúan continuamente.
• Reingeniería vs. Traducción: El trabajo afirma que la evolución de software mediada por LLM requiere un cambio de la traducción simple a un proceso de representación multinivel que involucra código, documentación técnica, requisitos de negocio y estructuras gráficas.

El artículo concluye que, aunque el enfoque muestra promesa, requiere un manejo cuidadoso de la segmentación, la fundamentación de la recuperación y la validación con humano en el bucle para mitigar los riesgos de deriva semántica y alucinación, particularmente en dominios de alto riesgo como sistemas financieros o de atención médica.