Dafny acepta el 99,1% del código de Opus 4.7 en HumanEval, pero solo el 1,9% está ligado a la especificación

Cuando un pipeline de generación de código informa de que «el N% de las soluciones está verificado», esa cifra puede esconder una garantía casi vacía. Prasenjit Dey, Ashish Jagmohan y Ravi Kokku han publicado en arXiv el trabajo «Verified but Vacuous». Proponen descomponer el concepto de «código verificado escrito por un LLM» en tres niveles que se miden de forma independiente, y muestran con datos que esos niveles divergen mucho. En uno de los experimentos, el verificador de Dafny aceptó el 99,1% de las soluciones de HumanEval, pero solo el 1,9% tenía una poscondición ligada a la especificación.

Tres superficies de fallo

Los autores las llaman superficies A, B y C. La superficie A es que el verificador acepte la prueba (en Dafny, un código de retorno cero). Es la condición necesaria, pero también la más débil. La superficie B pregunta si la afirmación que se demuestra se ata a algo con sentido: al menos una poscondición (ensures) debe referirse a un predicado o una función de la especificación emparejada. La superficie C pregunta si la propia especificación refleja el requisito original del usuario.

La auditoría sigue una cadena: B se calcula sobre las muestras que pasaron A, y C sobre las que pasaron B. Los autores aclaran que se trata de muestras condicionales, no de una jerarquía lógica de propiedades.

Para la superficie B proponen un ensures-binding gate, un recorrido estático del AST que tarda milisegundos por componente. Para la superficie C usan la comprobación Post2Exe del benchmark VeriContest: la poscondición se compila a un predicado ejecutable y se prueba con tests positivos y negativos. Si el predicado deja pasar una respuesta que un test negativo debería rechazar, la especificación está incompleta.

Dos ejemplos con la tarea «devolver el máximo de un array» ilustran la diferencia. El verificador acepta un método r := 0 sin ensures: simplemente no hay garantía funcional. Si el ensures se refiere al predicado r >= 0, el enlace existe formalmente, pero la especificación es demasiado débil y solo una comprobación de comportamiento lo detecta.

Qué mostró la reproducción de Li et al.

El equipo reprodujo con Claude Opus 4.7 el pipeline de Li et al., en el que Dafny actúa como representación intermedia. Probaron tres benchmarks de Python con tareas de nivel LeetCode: HumanEval, LeetCodeDataset y LiveCodeBench v6. El verificador aceptó entre el 92% y el 99% de las muestras, mientras que la proporción con enlace a un predicado de la especificación se mantuvo muy baja. En HumanEval fue del 1,9%. En otro 3,4% de las muestras había poscondición, pero no remitía a ningún predicado de la especificación. Según los autores, la brecha entre aceptación y enlace es de unas cuarenta veces.

La proporción de muestras con poscondición crece con la dificultad: del 5,3% en HumanEval al 10,61% en LiveCodeBench v6 (1 032 de 9 731; 10,9% en el subconjunto de 9 448 muestras que pasaron los tests). El modelo escribe más poscondiciones en las tareas difíciles, pero eso no aumenta las que están ligadas a la especificación.

Los autores subrayan que esto no es un defecto del pipeline de Li et al. El prompt few-shot de su artículo contiene un método sin cuerpo y sin poscondición, además de un fixture que comprueba las expectativas en tiempo de ejecución. Con esa forma de entrada, que el verificador acepte solo significa que el resto de las obligaciones estáticas son correctas, no que el código sea funcionalmente correcto. El error, según ellos, está en cómo se suele describir un pipeline así.

Ni siquiera por construcción «verificado» equivale a «correcto»

El pipeline propio de los autores, VCG, funciona de otra manera: el Planner divide la tarea, SpecAgent escribe las especificaciones en Dafny, ImplementationAgent escribe las implementaciones y ProverAgent ejecuta el ciclo de verificación y corrección con el ensures-gate. Los componentes verificados se transpilan a Rust. El enlace con la especificación se cumple allí en el 100% de los componentes por construcción. Aun así, el 11,48% de las muestras en MBPP-Rust y el 14,82% en el subconjunto LC de VeriContest fallaron en las pruebas ocultas. Los autores lo describen como una aproximación operativa al cumplimiento de los requisitos, no como un diagnóstico exacto de un error de especificación.

En el subconjunto LC de VeriContest, la métrica de extremo a extremo End2End de VCG es del 7,79% (535 de 6 870). Los resultados externos publicados son del 5,51% para GPT-5.5 y del 1,88% para una sola ejecución de Opus 4.7. Eso supone una diferencia de 2,3 puntos porcentuales y de 4,14 veces. Sin embargo, los presupuestos por tarea, el número de intentos de corrección y los arneses de prueba difieren (VCG usa diez muestras por tarea; la comparación externa, una), por lo que los autores no reclaman una superioridad comparable.

Limitaciones y conclusión práctica

El trabajo ofrece estimaciones puntuales, sin intervalos de confianza. El propio ensures-gate es tosco: puede rechazar una poscondición en línea con sentido y dejar pasar una tautología con un nombre llamativo. El 27% de fallos estructurales declarado en la auditoría previa al lanzamiento de VCG y el 98% de Li@Opus no se han contrastado con un etiquetado independiente de vacuidad semántica.

La recomendación práctica es concreta. Todo pipeline que emita certificados debe publicar, junto con la aceptación del verificador, al menos una de las métricas B o C, y mejor las dos. Solo B deja un punto ciego semántico, como en VCG. Solo C deja uno sintáctico, como en Li@Opus. Para los equipos que planean llevar a producción código con «verificación formal» generado por un LLM, es una lista de comprobación lista para usar sobre qué preguntar al proveedor.