💻 computer science

Articulate but Wrong: Self-Review Failures in LLM-Based Code Modernization

Este artículo demuestra que la modernización de código basada en LLM introduce con frecuencia desviaciones conductuales silenciosas que los propios modelos no pueden detectar ni autocorregir de manera fiable, revelando que este modo de fallo es estructural de la tarea y no depende de la escala o capacidad del modelo.

Autores originales: Gokul Chandra Purnachandra Reddy, Aditya Lolla, Harsha Sanku

Publicado 2026-05-22

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Gokul Chandra Purnachandra Reddy, Aditya Lolla, Harsha Sanku

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que contratas a un arquitecto muy elocuente y seguro para renovar una casa vieja y chirriante (código heredado) en un hogar moderno y elegante. Les pides que hagan el trabajo y, luego, para ahorrar dinero, les pides al mismo arquitecto que revise sus propios planos y diga: "¿Cambie por accidente cómo funciona la casa?".

Este artículo plantea una pregunta simple pero aterradora: ¿Podemos confiar en que el arquitecto detecte sus propios errores silenciosos?

Los investigadores descubrieron que, aunque estos "arquitectos" de IA son excelentes para hacer que la casa parezca nueva, son sorprendentemente malos para notar cuando han roto silenciosamente la fontanería o han cambiado la instalación eléctrica de formas que no provocan un incendio, pero que simplemente hacen que la casa se comporte de manera diferente.

Aquí está el desglose de sus hallazgos utilizando analogías cotidianas:

1. El problema del "Desplazamiento Silencioso"

Cuando la IA intenta actualizar código antiguo, a veces realiza un cambio que parece perfecto. El código se ejecuta, no se bloquea y parece correcto. Pero bajo el capó, los números salen ligeramente diferentes.

La analogía: Imagina que la casa vieja tenía una regla donde "media hogaza de pan" significaba cortarla por la mitad y darte la mitad entera. La casa nueva cambia la regla para que "media hogaza" signifique darte una migaja diminuta. La casa sigue en pie y el pan sigue ahí, pero la cantidad que recibes es incorrecta.
El hallazgo: Los investigadores probaron 60 escenarios específicos y complicados. Cuando la IA tenía que realizar actualizaciones reales y complejas, cometió estos errores silenciosos el 40 % de las veces. Cuando les dieron tareas fáciles que en realidad no necesitaban cambios, solo cometió errores el 7 % de las veces. Esto demuestra que la IA no es simplemente descuidada; tiene dificultades específicas con la lógica de la actualización.

2. La "Trampa Aritmética"

El principal culpable de estos errores fue cómo la IA maneja los números.

La analogía: En la casa vieja (Python 2), si divides 5 galletas entre 2 personas, obtienes 2 galletas cada una (la mitad extra se desecha). En la casa nueva (Python 3), obtienes 2,5 galletas.
El hallazgo: La IA a menudo olvida esta regla. Actualiza el código pero mantiene la lógica de "desechar la mitad", o viceversa. Este error matemático específico ocurrió en el 57 % de los casos difíciles. Es como si la IA supiera cómo pintar las paredes pero hubiera olvidado cómo contar los ladrillos.

3. El "Mentiroso Seguro" (Fallo en la autoevaluación)

Esta es la parte más impactante. Después de que la IA termina la renovación, los investigadores le preguntaron: "¿Cambió cómo funciona la casa?"

La analogía: La IA mira sus propios planos, ve la fontanería rota y dice: "Sí, la cambié, pero no te preocupes, ¡está bien!". O peor aún, ve la fontanería rota, explica exactamente por qué está rota y luego concluye: "Por lo tanto, la casa es perfecta".
El hallazgo: Cuando la IA realmente cometió un error silencioso, falló en detectarse a sí misma el 32 % de las veces. Aprobó con confianza su propio trabajo defectuoso.
- Algunos modelos eran como un inspector paranoico que detectaba cada error (0 % de fallos).
- Otros modelos eran como un mentiroso seguro que se perdía cada error (100 % de fallos).
- Crucialmente, los modelos "mejores" o más caros no fueron necesariamente los que detectaron sus propios errores. Un modelo barato a veces lo hizo mejor que uno costoso al detectar sus propias fallas.

4. El "Espejo Mágico" no funciona

Los investigadores probaron si pedirle a la IA que fuera su propia "red de seguridad" funcionaba.

La analogía: Podrías pensar: "Si le pido al arquitecto que verifique su trabajo dos veces, lo arreglará".
El hallazgo: No. La "autoverificación" no es una red de seguridad fiable. La IA es demasiado buena para salirse de problemas hablando. Puede escribir un párrafo explicando la diferencia entre las reglas antiguas y las nuevas, y luego concluir inmediatamente que las reglas son las mismas. Es como un estudiante que escribe un ensayo perfecto explicando por qué 2+2=5, y luego rodea la respuesta "5" con una sonrisa.

5. No se trata de lo "inteligente" que es la IA

Podrías asumir que los modelos de IA más potentes y costosos cometerían menos errores y los detectarían mejor.

La analogía: Pensarías que contratar a un "Arquitecto Maestro" sería más seguro que contratar a un "Arquitecto Junior".
El hallazgo: El estudio no encontró un vínculo claro entre el precio de la IA y su fiabilidad. Los modelos más caros cometieron tantos errores silenciosos como los más baratos. El problema no es que la IA no sea lo suficientemente "inteligente"; es que la tarea de actualizar código tiene una trampa estructural específica que confunde a todas ellas, independientemente de cuánto cuesten.

La conclusión

Si estás utilizando la IA para actualizar software antiguo, no confíes en que la IA verifique su propio trabajo.

El artículo concluye que pedirle a la IA: "¿Rompió algo?", es como pedirle a un mago: "¿Hice desaparecer al conejo?". El mago dirá "Sí", incluso si el conejo sigue ahí, o incluso si accidentalmente convirtió al conejo en una paloma.

Para estar seguro, necesitas un "oráculo" externo (una prueba automatizada estricta) que verifique la salida contra las reglas originales, en lugar de confiar en la propia opinión de la IA. La IA es elocuente, pero en este trabajo específico, también es peligrosamente errónea.

Resumen Técnico: Articulado pero Incorrecto: Fallos de Autoevaluación en la Modernización de Código Basada en Modelos de Lenguaje Grande

Declaración del Problema

A medida que los agentes de Modelos de Lenguaje Grande (LLM) se implementan cada vez más para migrar código heredado (específicamente de Python 2 a Python 3) a pilas modernas, persiste una brecha crítica de fiabilidad: la ausencia de garantía automatizada de corrección. Mientras que los errores sintácticos (por ejemplo, APIs eliminadas) se detectan fácilmente mediante fallos de compilación, la deriva conductual silenciosa es el modo de fallo más insidioso. Esto ocurre cuando el código modernizado se compila y ejecuta sin excepciones, pero produce resultados plausibles pero incorrectos que violan el contrato heredado original.

La pregunta de investigación central es si el mismo LLM que genera la migración puede confiarse para reconocer cuándo su propia salida ha alterado silenciosamente el comportamiento observable. El artículo investiga la viabilidad de la autoevaluación (pedir al modelo que produce el código que juzgue su propia salida) como una red de seguridad para estas derivas silenciosas.

Metodología

Los autores construyeron un marco experimental riguroso para medir la deriva y la fiabilidad de la autoevaluación:

Corpus: Un conjunto de datos equilibrado de 60 fragmentos de código heredado en Python 2 divididos en tres categorías:
- Trampas Semánticas (20 fragmentos): Modismos donde la modernización puede cambiar silenciosamente el comportamiento (por ejemplo, semántica numérica como la división de enteros, evaluación perezosa, diferencias en el modelo de tipos).
- Trampas Sintácticas (20 fragmentos): Modismos con equivalentes en Python 3 inequívocos (por ejemplo, has_key, xrange).
- Control Benigno (20 fragmentos): Código que no requiere cambios semánticos (por ejemplo, a+b), que sirve como línea base para la deriva inherente del modelo.
Modelos: Se ejecutaron 1.980 llamadas de modernización en 11 LLMs de producción de 7 familias distintas (incluyendo OpenAI, Google, Anthropic, Meta, DeepSeek, Alibaba, Mistral y Cohere), abarcando un rango de costos de aproximadamente 200x.
Evaluación (El Oráculo): Las salidas se evaluaron contra el contrato heredado utilizando un oráculo conductual estricto en cuanto a tipos. A diferencia de las comprobaciones de igualdad estándar (==), este oráculo impone una igualdad estricta de tipo y valor (por ejemplo, distinguir 2 de 2.0), lo cual es crucial para detectar la deriva de entero a flotante común en la migración de Python 2/3.
Sondeo de Autoevaluación: Después de la generación y la evaluación del oráculo, se pidió al mismo modelo que produjo el código que juzgara si su salida preservaba el comportamiento, sin saber que estaba evaluando su propia salida anterior.
Variaciones del Prompt: Se probaron tres formulaciones distintas de prompts para evaluar la sensibilidad al encuadre de las instrucciones.

Contribuciones Clave

Punto de Referencia Reproducible: Introducción de un punto de referencia controlado con una línea base benigna, un oráculo estricto en cuanto a tipos y un panel diverso de 11 LLMs de producción.
Cuantificación de la Deriva Semántica: Evidencia de que las trampas de preservación semántica se desvían significativamente más que las sintácticas, con un enfoque específico en la semántica numérica.
Naturaleza Estructural de la Tarea del Fallo: Demostración de que la deriva no es aleatoria, sino que se concentra en fragmentos específicos y difíciles que fallan en casi todos los modelos y variaciones de prompts.
Análisis del Fallo de Autoevaluación: El hallazgo principal de que la autoevaluación no es una red de seguridad fiable, caracterizada por una distribución bimodal de las tasas de fallo y un comportamiento "articulado pero incorrecto" donde los modelos identifican correctamente las reglas semánticas pero declaran incorrectamente que el comportamiento se ha preservado.
Perspectivas Metodológicas: Demostración de que la elección del oráculo conductual (igualdad estricta vs. permisiva) y el método de extracción de código alteran materialmente las tasas de deriva medidas.

Resultados Clave

1. Prevalencia de la Deriva Silenciosa

Tasa de Deriva Semántica: El 39,7% de los intentos de modernización en trampas semánticas resultaron en deriva conductual silenciosa.
Comparación con la Línea Base: Esto es significativamente mayor que la tasa de deriva del 7,0% observada en código de control benigno (que no requiere modernización real), lo que representa un aumento de +32,7 puntos porcentuales.
Deriva Sintáctica: Las trampas sintácticas se desviaron en un 12,7%, solo ligeramente por encima de la línea base.
Modo de Fallo Dominante: La semántica numérica (específicamente la división de enteros en Python 2 frente a la división de flotantes en Python 3) representó el 57% de todos los casos de deriva semántica.

2. Fallo Estructural de la Tarea

La deriva no es aleatoria; los modelos coinciden en qué fragmentos son difíciles. La correlación por pares de las tasas de deriva por fragmento entre modelos tiene una media de Pearson $r = 0,52$ .
Un pequeño núcleo de fragmentos de semántica numérica falló para $\ge 8/11$ modelos independientemente de la formulación del prompt, lo que indica que el fallo es estructural a la tarea de migración y no idiosincrásico de modelos específicos.

3. Fiabilidad de la Autoevaluación

Endoso Silencioso: En todos los 262 casos de deriva semántica identificados, el modelo productor endosó silenciosamente el 31,7% (83 casos) como preservadores del comportamiento.
Distribución Bimodal: Las tasas de auto-fallo son fuertemente bimodales. Cinco modelos fallaron el 0% de sus propias derivas, mientras que otros fallaron hasta el 100%.
Ortogonalidad a la Capacidad: Las tasas de auto-fallo no se correlacionan con la capacidad del modelo ni con el precio. Por ejemplo, el Modelo M5 tuvo la tasa de deriva más alta (65%) pero una tasa de auto-fallo del 0%, mientras que el Modelo M1 tuvo una deriva moderada (42%) pero una tasa de auto-fallo del 100%.
Fenómeno "Articulado pero Incorrecto": Varios modelos articularon explícitamente la distinción semántica correcta entre Py2/Py3 (por ejemplo, explicando que / realiza división de enteros en Py2 y división de flotantes en Py3) pero concluyeron que el comportamiento se había preservado. Esto indica un fallo en la aplicación del razonamiento y no una falta de conocimiento.

4. Capacidad No Monótona

Las tasas de deriva (que oscilan entre el 5,6% y el 46,7%) no siguen limpiamente el precio del modelo ni los niveles de capacidad. Los modelos de menor costo a veces superaron a los modelos de vanguardia, lo que sugiere que la escalada por sí sola no resuelve este fallo estructural específico.

5. Sensibilidad Metodológica

Rigor del Oráculo: El uso de la comparación permisiva == en lugar de la igualdad estricta de tipos redujo la deriva semántica medida del 39,7% a ~26,7%, ocultando el modo de fallo más prevalente (entero $\to$ flotante).
Extracción de Salida: Los analizadores ingenuos que solo buscan delimitadores inflaron la tasa de deriva del control benigno a ~23% al interpretar erróneamente la prosa explicativa como código. Un extractor robusto redujo esto a la verdadera línea base del 7,0%.

Significado y Afirmaciones

El artículo concluye que la autoevaluación por parte del modelo productor no es una red de seguridad utilizable para la deriva semántica silenciosa en las pipelines de modernización de código. El fallo no es meramente una falta de recuperación (omisión de errores), sino un endoso silencioso de alta confianza de código roto.

Los autores afirman que:

La deriva en este dominio es estructural a la tarea (impulsada por las brechas semánticas específicas entre Py2/Py3) y no un error aleatorio ni una simple función de la escala del modelo.
La selección de modelos basada en el proveedor o el tamaño no protege contra esta clase de deriva; se requiere un oráculo conductual explícito.
Las elecciones metodológicas sobre el rigor del oráculo y la robustez de la extracción de código son críticas; trabajos anteriores que carecen de estos controles probablemente subestiman la deriva semántica silenciosa.

El estudio sirve como un piso de advertencia: la autoevaluación simple es insuficiente para la modernización de código de producción, y confiar en ella sin verificación conductual externa arriesga desplegar código que se compila y ejecuta, pero se comporta incorrectamente.