Los desarrolladores suelen tratar a un modelo de lenguaje grande como una solución rápida para el código antiguo. Pegan un archivo heredado, escriben "moderniza esto" y esperan la reescritura. Un nuevo artículo publicado en arXiv el 29 de octubre se pregunta si ese atajo realmente deja el código en mejor estado. En la mayoría de los archivos probados, la respuesta fue no.

Los investigadores le dieron a cinco LLM la misma tarea: tomar 100 archivos PHP de WordPress 4.0 y modernizarlos a PHP 8.3 manteniendo intacto su comportamiento. Los modelos trabajaron con cada archivo de forma aislada. No tenían información sobre el proyecto más amplio ni retroalimentación de la ejecución del código.

Para calificar los resultados, el equipo utilizó 630 pruebas de comportamiento ocultas, que verificaban si cada archivo seguía haciendo lo que debía hacer. También contabilizaron 511 hallazgos de modernización señalados por Rector, una herramienta basada en reglas que reescribe el código según reglas fijas. Cada resultado se midió frente a dos líneas base: los archivos originales sin cambios y el resultado de Rector.

Los originales sin cambios salieron ganando. Sin ninguna edición, 83 archivos superaron todas las pruebas. El LLM con mejor desempeño dejó solo 59 archivos en ese estado.

¿La IA rompe código heredado que ya funciona?

Los modelos también causaron daños reales. Cada uno dañó entre 32 y 51 archivos que antes funcionaban. Como máximo, el mismo modelo reparó 10 archivos que habían estado fallando. Rector dañó siete archivos y reparó seis, un movimiento mucho menor en ambas direcciones.

Gran parte de los daños era evitable. Los investigadores encontraron que solo 37 de los 511 hallazgos, cerca del 7 por ciento, requerían un cambio para ejecutarse bajo PHP 8.3. La mayor parte del código no necesitaba ser modificado. Sin embargo, en los archivos que ya eran compatibles y no requerían ningún cambio obligatorio, los LLM dañaron entre el 36 y el 60 por ciento de ellos. Rector dañó el 8 por ciento de ese mismo tipo de archivos.

El modelo con la puntuación de modernización más alta no era más compatible que sus competidores más cercanos. En otras palabras, un modelo que hacía más cambios no tenía más probabilidades de producir código funcional. Modificar más líneas simplemente significaba más oportunidades de romper algo.

La mayoría de las pruebas de regresión se remontaban a archivos que ya no se cargaban. El artículo señala como causa frecuente las declaraciones de tipos que el propio PHP rechaza. Los autores señalan que estos errores no requieren conocer el proyecto más amplio para evitarse. Un modelo que comprendiera las reglas de PHP podría, en principio, haberlos detectado.

Este punto tiene peso para quienes evalúan herramientas de programación con IA. Los autores sostienen que los estudios sobre modernización basada en LLM deberían comparar los resultados con una línea base de no cambios, ya que no hacer nada suele ser la opción más segura. También recomiendan reportar la modernización y la preservación del comportamiento como medidas separadas, para que la capacidad de una herramienta de actualizar código no se confunda con su capacidad de mantenerlo funcionando.

¿Deberían los equipos usar un LLM para modernizar código heredado?

El estudio cubre solo archivos individuales y no refleja cómo un desarrollador podría usar un LLM dentro de un proyecto completo con suites de pruebas y retroalimentación iterativa. Los autores enmarcan sus hallazgos dentro de ese escenario más limitado. Aun así, las cifras sugieren que una instrucción de una sola línea no sustituye una revisión cuidadosa, y que los equipos que evalúan una reescritura de código heredado con IA deberían empezar por preguntarse si el código necesita cambios en absoluto.

Questo articolo è stato scritto con l'assistenza dell'IA.
News Factory APP - notizie agentiche per potenziare il tuo SEO e AEO.