← Últimos artículos
💻 computer science

Beyond Resolved Rate: A Non-Functional Quality Study

Este estudio revela que, si bien los modelos de IA más nuevos resuelven más tareas de codificación a nivel de repositorio que las versiones anteriores, no demuestran mejoras consistentes en métricas de calidad no funcionales, tales como el análisis estático, la complejidad del código o el uso de recursos, en las tareas que ambas generaciones resuelven con éxito.

Autores originales: Xin Sun, Daniel Ståhl, Kristian Sandahl, Christoph Kessler

Publicado 2026-07-22
📖 5 min de lectura🧠 Análisis profundo

Autores originales: Xin Sun, Daniel Ståhl, Kristian Sandahl, Christoph Kessler

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 un mundo donde las computadoras han aprendido a escribir código, actuando como incansables programadores junior que pueden corregir errores, construir funcionalidades e incluso refactorizar proyectos de software enteros. Este es el reino de los Modelos de Lenguaje Extensos (LLM) en la ingeniería de software. Durante mucho tiempo, la única forma en que juzgábamos a estos programadores digitales era haciendo una pregunta simple: "¿Corrigieron el error?". Si el código pasaba las pruebas, recibía una estrella dorada. Esto se llama "corrección funcional". Pero el hecho de que el motor de un coche arranque no significa que los frenos funcionen, que la pintura sea duradera o que la eficiencia de combustible sea buena. En el mundo real, el software debe ser seguro, fácil de actualizar más adelante y lo suficientemente rápido como para no colapsar tu computadora. Estas son las "cualidades no funcionales". La gran pregunta que los investigadores se plantean ahora es: A medida que estos modelos de IA se vuelven más inteligentes y nuevos, ¿están simplemente volviéndose mejores para solucionar el problema inmediato, o también están escribiendo código más limpio, seguro y eficiente?

Este artículo, titulado "Beyond Resolved Rate" (Más allá de la tasa de resolución), se sumerge en ese mismo misterio. Los autores, un equipo de la Universidad de Linköping en Suecia, decidieron dejar de simplemente contar cuántos errores corregía la IA y empezar a inspeccionar cómo los corregía. Trataron a los modelos de IA como concursantes en un concurso de cocina. Los jueces (los investigadores) les dieron una tarea específica: arreglar una receta rota (un error en un proyecto de software). Los modelos antiguos eran los veteranos y los modelos nuevos eran las estrellas emergentes. El objetivo no era solo ver quién podía servir un plato que supiera bien (pasara las pruebas), sino ver si los nuevos chefs estaban usando mejores ingredientes, creando menos desperdicio y haciendo la cocina más segura para el siguiente cocinero.

Los investigadores configuraron un experimento riguroso utilizando un benchmark popular llamado SWE-bench Lite, que contiene tareas de reparación de software del mundo real. Enfrentaron a dos generaciones de modelos entre sí de dos familias diferentes: la familia comercial "Claude" y la familia de código abierto "DeepSeek". Tomaron los parches (las correcciones de código) generados por los modelos antiguos y los nuevos y los sometieron a una batería de inspecciones de alta tecnología. Utilizaron herramientas como CodeQL y CodeScene para escanear riesgos de seguridad, estructuras de código desordenadas y problemas de mantenibilidad. También cronometraron cuánto tiempo tardaba el código en ejecutarse y midieron cuánta memoria devoraba, tratando a la computadora como una bestia hambrienta que necesita ser alimentada eficientemente.

Los resultados fueron un giro en la trama. Los modelos más nuevos y "más inteligentes" definitivamente corrigieron más errores. Resolvieron más instancias que sus hermanos mayores, ganándose una mayor "tasa de resolución". Sin embargo, cuando los investigadores analizaron la calidad del código para las tareas que ambos modelos lograron resolver, la historia cambió. Los modelos más nuevos no mostraron ninguna mejora consistente en las cualidades no funcionales. De hecho, los datos sugirieron que los modelos más nuevos eran tan propensos a introducir "olores de código" (code smells), riesgos de seguridad o problemas de rendimiento como los anteriores.

Específicamente, el estudio encontró que, para las tareas que ambos modelos resolvieron, los modelos más nuevos no produjeron un código significativamente más limpio. Las herramientas de análisis estático mostraron que el número de problemas nuevos introducidos era aproximadamente el mismo para ambas generaciones. En términos de rendimiento, los modelos más nuevos fueron ligeramente más "codiciosos" con los recursos. En las tareas comunes, el modelo Claude más reciente utilizó aproximadamente 0.048 segundos más de tiempo de CPU y alrededor de 4.5 MiB más de memoria pico que el anterior. El modelo DeepSeek más reciente utilizó aproximadamente 0.5 MiB más de memoria. Aunque estas cifras son pequeñas, indican que mejorar en la corrección del error no significó automáticamente mejorar en la escritura de código eficiente.

Los autores también observaron el "sabor" del código. Comprobaron si los modelos más nuevos estaban evitando ciertos malos hábitos, como nombres de variables confusos o importaciones desordenadas. Los resultados fueron mixtos e inconsistentes; a veces el modelo más nuevo era mejor en una regla específica, otras veces lo era el modelo antiguo, pero no hubo una tendencia clara de que la nueva generación fuera universalmente superior en calidad de código.

En última instancia, el artículo sugiere que, si bien los modelos de IA están mejorando en el "qué" (corregir el error), no necesariamente están mejorando en el "cómo" (escribir código de alta calidad y mantenible) por el simple hecho de ser más nuevos. Los autores advierten que una mayor tasa de éxito en la corrección de errores no garantiza una mejor ingeniería de software en general. Argumentan que necesitamos mirar más allá de la simple puntuación de aprobado/suspenso y empezar a medir los costos ocultos del código generado por IA, como los riesgos de seguridad y los dolores de cabeza de mantenimiento, para entender verdaderamente cómo estos asistentes digitales se están desempeñando en el mundo real.

¿Ahogado en artículos de tu campo?

Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.

Probar Digest →