Dafny accepte 99,1% du code d'Opus 4.7 sur HumanEval, mais seuls 1,9% sont liés à la spécification

Quand un pipeline de génération de code annonce que « N% des solutions sont vérifiées », ce chiffre peut cacher une garantie quasi vide. Prasenjit Dey, Ashish Jagmohan et Ravi Kokku ont publié sur arXiv un article intitulé « Verified but Vacuous ». Ils proposent de décomposer la notion de « code vérifié écrit par un LLM » en trois niveaux mesurables indépendamment, et montrent, données à l'appui, que ces niveaux divergent fortement. Dans l'une des expériences, le vérificateur Dafny a accepté 99,1% des solutions sur HumanEval, alors que seules 1,9% comportaient une postcondition liée à la spécification.

Trois surfaces de défaillance

Les auteurs les nomment surfaces A, B et C. La surface A correspond à l'acceptation de la preuve par le vérificateur (pour Dafny, un code de retour nul). C'est la condition nécessaire, mais aussi la plus faible. La surface B détermine si l'énoncé prouvé se rattache à quelque chose de significatif : au moins une postcondition (ensures) doit faire référence à un prédicat ou à une fonction de la spécification associée. La surface C vérifie si la spécification elle-même reflète l'exigence initiale de l'utilisateur.

L'audit suit une chaîne : B est calculée sur les échantillons qui ont passé A, et C sur ceux qui ont passé B. Les auteurs précisent qu'il s'agit d'échantillons conditionnels, et non d'une hiérarchie logique entre les propriétés.

Pour la surface B, ils ont conçu un ensures-binding gate, un parcours statique de l'AST qui s'exécute en quelques millisecondes par composant. Pour la surface C, ils s'appuient sur le contrôle Post2Exe du benchmark VeriContest : la postcondition est compilée en prédicat exécutable, puis évaluée sur des tests positifs et négatifs. Si le prédicat laisse passer une réponse qu'un test négatif devrait rejeter, la spécification est incomplète.

Deux exemples sur la tâche « renvoyer le maximum d'un tableau » illustrent la différence. Le vérificateur accepte la méthode r := 0 sans ensures : il n'y a tout simplement aucune garantie fonctionnelle. Si en revanche ensures fait référence au prédicat r >= 0, la liaison existe formellement, mais la spécification est trop faible, et seule une vérification comportementale permet de le détecter.

Ce que montre la reproduction de Li et al.

L'équipe a reproduit avec Claude Opus 4.7 le pipeline de Li et al., dans lequel Dafny sert de représentation intermédiaire. Trois benchmarks Python de tâches de niveau LeetCode ont été testés : HumanEval, LeetCodeDataset et LiveCodeBench v6. Le vérificateur acceptait 92–99% des échantillons, alors que la part liée à un prédicat de la spécification restait très faible. Sur HumanEval, elle s'élève à 1,9%. Pour 3,4% d'échantillons supplémentaires, une postcondition existait, mais ne faisait référence à aucun prédicat de la spécification. Selon les auteurs, l'écart entre acceptation et liaison est d'environ quarante fois.

La part d'échantillons dotés d'une postcondition augmente avec la difficulté : de 5,3% sur HumanEval à 10,61% sur LiveCodeBench v6 (1 032 sur 9 731 ; 10,9% sur le sous-ensemble de 9 448 échantillons ayant passé les tests). Le modèle écrit plus de postconditions sur les tâches difficiles, mais cela n'augmente pas le nombre de celles qui sont liées à la spécification.

Les auteurs soulignent qu'il ne s'agit pas d'un défaut du pipeline de Li et al. Le prompt few-shot de leur article contient une méthode sans corps et sans postcondition, ainsi qu'une fixture qui vérifie les attentes à l'exécution. Avec une telle forme d'entrée, l'acceptation par le vérificateur signifie seulement que les autres obligations statiques sont correctes, pas que le code est fonctionnellement juste. Le problème, selon eux, tient à la manière dont on décrit habituellement ce type de pipeline.

Même par construction, vérifié ne signifie pas correct

Le pipeline des auteurs, VCG, est conçu différemment : un Planner découpe la tâche, SpecAgent écrit les spécifications en Dafny, ImplementationAgent les implémentations, et ProverAgent exécute une boucle de vérification et de correction avec l'ensures-gate. Les composants vérifiés sont transpilés en Rust. La liaison à la spécification y est assurée pour 100% des composants, par construction. Pourtant, 11,48% des échantillons sur MBPP-Rust et 14,82% sur la tranche LC de VeriContest ont échoué aux tests cachés. Les auteurs y voient une approximation opérationnelle de la conformité aux exigences, et non un diagnostic précis d'erreur de spécification.

Sur la tranche LC de VeriContest, la métrique de bout en bout End2End de VCG atteint 7,79% (535 sur 6 870). Les résultats externes publiés sont de 5,51% pour GPT-5.5 et de 1,88% pour un lancement unique d'Opus 4.7. Cela représente un écart de 2,3 points de pourcentage et un rapport de 4,14. Mais les budgets par tâche, le nombre de tentatives de correction et les harnais de test diffèrent (VCG utilise dix échantillons par tâche, la comparaison externe un seul) ; les auteurs ne revendiquent donc pas de supériorité comparable.

Limites et enseignement pratique

L'étude fournit des estimations ponctuelles, sans intervalles de confiance. L'ensures-gate lui-même est grossier : il peut rejeter une postcondition inline pourtant pertinente, tout en laissant passer une tautologie affublée d'un nom ronflant. Les 27% de rejets structurels annoncés dans l'audit pré-release de VCG et les 98% pour Li@Opus n'ont pas été vérifiés par un étiquetage indépendant portant sur la vacuité sémantique.

La recommandation pratique est concrète. Tout pipeline qui délivre des certificats doit publier, en plus de l'acceptation par le vérificateur, au moins l'une des métriques B ou C, et de préférence les deux. B seule laisse un angle mort sémantique, comme sur VCG. C seule laisse un angle mort syntaxique, comme sur Li@Opus. Pour les équipes qui comptent mettre en production du code « formellement vérifié » par un LLM, c'est une checklist toute prête des questions à poser au fournisseur.