Evaluating LLM-Generated Code: A Benchmark and Developer Study

Planteamiento del Problema
Los métodos de evaluación actuales para los Modelos de Lenguaje de Gran Escala (LLM) en la generación de código (NL2Code) dependen predominantemente de benchmarks que miden la corrección de la solución mediante pruebas unitarias en tareas aisladas a nivel de función (por ejemplo, HumanEval, MBPP). Si bien son efectivos para establecer capacidades base, estos benchmarks no logran reflejar los escenarios de programación del mundo real. La programación en el mundo real a menudo implica la creación de proyectos de múltiples componentes con dependencias, requiere un prompting secuencial y necesita código que no solo sea correcto, sino también legible, mantenible y listo para producción. Además, existe una escasez de investigación que involucre a expertos humanos para evaluar la calidad y la usabilidad del código generado por LLM, ya que la mayoría de las evaluaciones dependen únicamente de métricas automatizadas o enfoques de "LLM-as-a-Judge" (LLM como juez), que pueden no capturar plenamente las preocupaciones centradas en el desarrollador, como la estructura y la documentación.

Metodología
El artículo propone una metodología de evaluación de tres vertientes personalizada, diseñada para cerrar la brecha entre las pruebas de funciones aisladas y la evaluación holística de proyectos. Este marco integra pruebas de corrección automatizadas, verificación de calidad de código automatizada y evaluación humana estructurada.

1. Asignación de Programación: El estudio utiliza un proyecto de ciencias de la computación complejo y de múltiples componentes titulado "Construyendo el Árbol de la Vida desde Cero", adaptado de la lista de asignaciones NIFTY. La tarea involucra bioinformática (árboles filogenéticos) y requiere la implementación de programación dinámica, recursión, grafos y estructuras de árboles. Los LLM son instados mediante un conjunto fijo de 14 prompts secuenciales para generar la solución desde cero, sin código inicial, imitando un flujo de trabajo de un desarrollador real.
2. Benchmark de Corrección: Se desarrolló un benchmark personalizado para verificar la solución en múltiples puntos de control en lugar de solo en la salida final. Esto incluye:
   • Verificar las puntuaciones de Needleman-Wunsch.
   • Validar la sintaxis del formato Newick (para la estructura del árbol y las distancias de los nodos).
   • Comprobar la estructura del árbol filogenético.
   • Validar los resultados de agrupamiento (clustering) basados en umbrales.
   • Confirmar la generación de un archivo PNG de dendrograma.
   • Verificación Técnica: Se incluyó un paso manual donde los investigadores corrigieron errores menores de sintaxis, compilación y dependencias para asegurar que el código pudiera ejecutarse, documentando estas correcciones para evaluar la "capacidad de reparación" (fixability).
3. Verificación de Calidad Automatizada: El código generado fue analizado utilizando SonarQube para medir la fiabilidad, la mantenibilidad y la seguridad, así como para contar los "code smells" (olores de código) y la deuda técnica.
4. Evaluación de Calidad Basada en Humanos (Estudio de Desarrolladores): Se diseñó una encuesta estructurada para recopilar revisiones de código de desarrolladores voluntarios. La encuesta utilizó una escala de Likert de 5 puntos a través de 14 métricas categorizadas en:
   • Estructura de la base de código (nomenclatura, formato, separación de preocupaciones).
   • Calidad de los comentarios y explicaciones (utilidad, ubicación, calidad del README).
   • Facilidad de uso (modificabilidad, capacidad de prueba).
   • Un campo de texto abierto para comentarios adicionales y una pregunta final preguntando qué código elegiría el desarrollador para trabajar.

Configuración Experimental
La metodología se aplicó a tres LLM de propósito general: GPT-4.1, DeepSeek-V3-0324 y Claude Opus 4. Cada modelo se ejecutó tres veces con parámetros fijos (temperatura 0.2, máximo de 4096 tokens) para dar cuenta de la no determinismo. Para la encuesta humana, un desarrollador revisó una solución por modelo (seleccionada basándose en la tasa más alta de paso de pruebas de corrección) realizada por 10 desarrolladores voluntarios reclutados vía LinkedIn.

Resultos Clave

• Corrección: DeepSeek-V3-0324 logró la puntuación de corrección más alta, pasando 5 de 7 casos de prueba en su mejor ejecución. GPT-4.1 fue el único modelo en generar soluciones que se ejecutaron sin intervención manual en dos de sus tres intentos, aunque pasó menos casos de prueba en total (3-4/7). Claude Opus 4 tuvo el desempeño más bajo en términos de corrección, con un intento que pasó cero pruebas.
• Calidad Automatizada: Todos los modelos recibieron calificaciones 'A' en seguridad, fiabilidad y mantenibilidad en SonarQube. Sin embargo, las soluciones de DeepSeek tuvieron la menor cantidad de "code smells" y el menor tiempo estimado para corregir problemas. Las soluciones de GPT-4.1 tuvieron la mayor ratio de deuda técnica y los tiempos de corrección más largos.
• Encuesta Humana: A pesar de que DeepSeek tuvo las mejores métricas automatizadas, la encuesta de desarrolladores reveló una divergencia en la preferencia. Los desarrolladores calificaron a GPT-4.1 de la forma más baja, citando comentarios deficientes, estructura caótica y argumentos codificados de forma fija (hard-coded). Mientras que DeepSeek fue elogiado por su parametrización, Claude Opus 4 recibió los comentarios más positivos respecto a la facilidad de modificación y de prueba. Notablemente, cuando se les preguntó qué código elegirían para trabajar, 6 de cada 10 desarrolladores seleccionaron la solución de Claude, mientras que solo 4 eligieron la de DeepSeek.
• Alineación: El estudio encontró que las métricas de corrección automatizadas y las evaluaciones de calidad humana se complementan pero no siempre se alinean. Un modelo con mayor corrección (DeepSeek) no fue necesariamente el preferido por los desarrolladores sobre un modelo con una corrección ligeramente inferior pero con mejor estructura y legibilidad (Claude).

Significancia y Contribuciones
El artículo afirma realizar cuatro contribuciones primarias al campo:

1. Un marco de evaluación de tres vertientes que combina pruebas automatizadas, verificación de calidad de código y encuestas de desarrolladores para capturar tanto la corrección como la usabilidad.
2. Un benchmark de corrección a nivel de proyecto basado en una asignación compleja de múltiples archivos, yendo más allá de las tareas aisladas a nivel de función.
3. Un diseño de encuesta estructurado dedicado a recopilar revisiones de código de desarrolladores de manera estandarizada, abordando la falta de evaluación centrada en el humano en la investigación de LLM.
4. Una demostración del marco mediante la evaluación de tres LLM, mostrando que las revisiones de los desarrolladores pueden arrojar hallazgos críticos —particularmente sobre la preparación para producción y la mantenibilidad— que los benchmarks de corrección estándar pasan por alto.

Los autores concluyen que, si bien los benchmarks automatizados son útiles, una evaluación exhaustiva de los LLM para la generación de código requiere integrar la retroalimentación humana para comprender la utilidad práctica y la experiencia del desarrollador con las soluciones generadas. El estudio destaca que el código "correcto" no siempre es código "bueno" en un contexto de producción.