Are LLMs Reliable Code Reviewers? Systematic Overcorrection in Requirement Conformance Judgement

1. Problema y Contexto

Los Grandes Modelos de Lenguaje (LLMs) se han convertido en herramientas esenciales para la ingeniería de software, utilizadas para la generación de código y la revisión automática. Sin embargo, existe una brecha crítica en la fiabilidad de estos modelos cuando deben verificar si una implementación de código cumple con especificaciones de requisitos en lenguaje natural, especialmente en ausencia de casos de prueba o implementaciones de referencia.

El problema central identificado es la sobre-corrección sistemática (over-correction bias). Los autores descubren que los LLMs tienden a clasificar incorrectamente implementaciones de código correctas como defectuosas o no conformes (falsos negativos). Contrariamente a la intuición común de que las instrucciones más detalladas mejoran el razonamiento, el artículo demuestra que los prompts más complejos (que solicitan explicaciones y correcciones) exacerban este sesgo, llevando a tasas de rechazo de código correcto extremadamente altas.

2. Metodología

El estudio emplea un enfoque empírico a gran escala para evaluar la capacidad de juicio de los LLMs bajo diferentes configuraciones.

• Conjunto de Datos: Se construyó un benchmark unificado combinando tres conjuntos de datos populares: HumanEval, MBPP y QuixBugs.

  • Se crearon pares de instancias para cada tarea: una implementación canónica (correcta, etiqueta 1) y una versión con errores inyectados (incorrecta, etiqueta 0).
  • El conjunto final contiene más de 1400 instancias.
  • Se normalizaron las etiquetas de errores (tipos de bug y síntomas de fallo) para permitir un análisis cruzado.

• Modelos Evaluados: Se probaron cinco LLMs representativos:

  • Cerrados: GPT-4o, Claude-4.5-sonnet, Gemini-2.0-flash.
  • Abiertos: Llama-3.1-8B, Mistral-Small-3.2.

• Diseño de Prompts (Estrategias de Evaluación): Se compararon tres modos de prompting bajo un marco unificado:

  1. Directo: Solo pregunta "¿Cumple el código el requisito?" (Sí/No).
  2. Directo + Explicación: Pide el veredicto y una justificación breve.
  3. Completo (Full): Estructura de tres pasos: Veredicto, Justificación detallada y Propuesta de corrección (fix) si el veredicto es negativo.

• Métricas de Evaluación:

  • Matriz de Confusión: Cálculo de Tasa de Falsos Negativos (FNR: rechazo de código correcto) y Tasa de Falsos Positivos (FPR: aceptación de código con errores).
  • Taxonomía de Rechazo: Clasificación de las razones dadas por el modelo para rechazar código correcto (ej. "Requisito añadido", "Error de lógica", "Límites imaginados").
  • Auto-consistencia (A1): Evaluación de si la explicación del modelo es coherente con su propio veredicto.
  • Conciencia de Fallos (A2): Evaluación de si la explicación identifica correctamente el tipo de error y los síntomas en casos de código defectuoso.

3. Contribuciones Clave

1. Descubrimiento de Falsos Negativos Sistemáticos: Se revela que los LLMs sufren de un sesgo fuerte hacia la sobre-corrección, rechazando frecuentemente código correcto como si no cumpliera los requisitos.
2. Caracterización del Sesgo por Prompting: Se cuantifica cómo el diseño del prompt altera el perfil de error. Se demuestra que aumentar la complejidad del prompt (solicitando explicaciones y arreglos) no mejora la precisión general, sino que desplaza el equilibrio hacia un rechazo excesivo (aumento drástico de FNR) a costa de reducir ligeramente la aceptación insegura (FPR).
3. Análisis de Fiabilidad de las Explicaciones:
   • Se introduce una medida de auto-consistencia que muestra que las explicaciones a menudo contradicen el veredicto final.
   • Se evalúa la "conciencia de fallos", encontrando que los modelos son buenos describiendo síntomas de fallo pero pobres diagnosticando la causa raíz (tipo de bug).
4. Propuesta de Mitigación: Se presenta un Filtro de Verificación Guiado por Corrección (Fix-guided Verification Filter) que utiliza la corrección propuesta por el modelo como evidencia ejecutable para validar el veredicto original.

4. Resultados Principales

A. Rendimiento y Sesgo (RQ1 y RQ2)

• Alta Tasa de Falsos Negativos (FNR): Incluso con prompts directos, los modelos rechazan una porción significativa de código correcto. Con prompts complejos (Full), la FNR se dispara.
  • Ejemplo: GPT-4o en HumanEval pasa de un 26.2% de FNR (Directo) a un 73.2% (Full).
  • Ejemplo: Llama-3.1-8B alcanza FNR superiores al 88% en MBPP bajo el modo Full.
• Compensación (Trade-off): Aumentar la complejidad del prompt reduce los Falsos Positivos (aceptar código malo) pero incrementa masivamente los Falsos Negativos. Esto implica que los revisores basados en LLM se vuelven extremadamente conservadores, generando una carga de trabajo innecesaria al rechazar código válido.
• Inestabilidad de Modelos Abiertos: Los modelos de código abierto mostraron tasas de error más altas y una mayor sensibilidad a los cambios en el diseño del prompt.

B. Causas de los Errores (RQ3)

• Taxonomía de Rechazo: El 87.2% de las explicaciones de rechazo injustificado se deben a cuatro patrones dominantes:
  1. Error de Lógica (48.2%): El modelo afirma que el algoritmo es incorrecto sin evidencia concreta.
  2. Requisito Añadido (14.1%): El modelo inventa restricciones no mencionadas en la especificación.
  3. Error de Límites (13.2%): Preocupación excesiva por casos borde no especificados.
  4. Malinterpretación de la Especificación (11.7%).
• Hallucinación de Requisitos: Los modelos tienden a "hallucinar" requisitos de rendimiento, tipos de datos o casos borde que no existen en la tarea original.

C. Fiabilidad de las Explicaciones (RQ4)

• Inconsistencia Interna: Una proporción significativa de explicaciones contradice el veredicto (ej. el modelo dice "NO" pero la explicación describe un código correcto).
• Diagnóstico Deficiente: Aunque los modelos identifican bien los síntomas de fallo (ej. "producción de salida incorrecta"), fallan frecuentemente al identificar la causa raíz (tipo de bug). Esto puede llevar a sugerencias de reparación incorrectas o engañosas.

D. Mitigación (RQ5)

• Filtro de Verificación Guiado por Corrección: Se propuso un marco donde, si el modelo rechaza el código y propone un "fix", se ejecutan ambos (el original y el arreglado) contra pruebas de referencia y pruebas aumentadas generadas por IA.
  • Si el código original pasa las pruebas y el "fix" no introduce cambios funcionales necesarios, el filtro invierte el veredicto a "Aprobado" (YES).
  • Resultado: Esta técnica redujo drásticamente la FNR (ej. de 90.8% a 23.6% en Llama-3.1 en MBPP) con un aumento marginal y controlado en la FPR.

5. Significado e Implicaciones

• Advertencia para la Automatización: El uso de LLMs como "revisores virtuales" en pipelines de CI/CD sin salvaguardas es peligroso debido a la alta tasa de falsos negativos. Pueden bloquear despliegues válidos y generar "ruido" en el flujo de trabajo.
• El "Mejor Prompt" no es el más complejo: Contrario a la creencia popular, pedir explicaciones y correcciones no mejora la precisión de la evaluación de requisitos; de hecho, introduce un sesgo de sobre-análisis.
• Necesidad de Evidencia Ejecutable: La fiabilidad de la revisión de código no debe depender únicamente del razonamiento textual del modelo, sino de la validación mediante ejecución de pruebas. El enfoque propuesto de usar la corrección del modelo como "evidencia contrafactual ejecutable" ofrece una vía práctica para mitigar estos sesgos.
• Guía para la Integración: Los resultados sugieren que los sistemas automatizados deben incorporar filtros de verificación basados en pruebas (como el propuesto) y tratar las explicaciones de los LLMs con escepticismo, especialmente cuando implican la detección de errores sutiles o de rendimiento no especificados.

En resumen, el artículo demuestra que, aunque los LLMs son potentes, su capacidad para juzgar la conformidad de requisitos sin ejecución de pruebas es inherentemente inestable y propensa a la sobre-corrección, requiriendo mecanismos de validación externa para ser utilizados de forma fiable en entornos de ingeniería de software.