Verified but Vacuous: Three Failure Surfaces of LLM-Driven Verified Code Generation
Abstract
What should ``verified'' mean when evaluating LLM-generated code? Many existing pipelines report a single verification number. We argue this collapses three distinct properties measured in a conditional audit sequence: verifier acceptance (Surface A), \emph{syntactic specification binding (Surface B: does the proof obligation bind to the spec?), and semantic specification fidelity (Surface C: does the spec capture the informal requirement?). Two empirical demonstrations show the surfaces separate. \textbf{First (), via Li@Opus (a same-model reproduction of \citet{li2025dafny}'s Dafny-as-intermediate-representation (IR) pipeline under Claude Opus 4.7) on three Python benchmarks}: it reaches 99.1% verifier acceptance on HumanEval while only 1.9% carry a certificate binding to a spec-defined predicate or function. \textbf{Second (), via VCG on two Rust benchmarks}: we use VCG (which is our own in-house Dafny-as-intermediate pipeline) on Rust because the Rust target lets us enforce fully-verifiable output (every component ships as a Dafny certificate, ensures-binding gate passing by construction). Even inside that construction, 11.48% (MBPP-Rust) and 14.82% (VeriContest LC slice) of structurally-verified samples still fail hidden tests. On the LC slice of VeriContest, VCG's reported End2End rate is 7.79% (535/6870). The cited external rates are 5.51% (GPT-5.5) and 1.88% (single-shot Opus 4.7). These give descriptive differences of 2.3 percentage points and 4.14, respectively; task-budget, repair and harness differences prevent a matched-performance claim.
Figures & tables
| Surface | Check | Catches | Blind spot (deferred) |
|---|---|---|---|
| A: verifier acceptance | dafny verify (or verus ) exits zero | proof gaps, type errors, missing lemmas | vacuous or absent ensures clauses |
| B: syntactic spec binding | some ensures clause references a spec-defined predicate / function | missing references to the paired spec artifact, including meaningful inline contracts | semantically weak predicates that bind but under-specify |
| C: semantic spec fidelity | postcondition accepts positive tests and rejects negatives (Post2Exe) | weak specs whose predicates admit incorrect outputs | requirements no test suite happens to exercise |
| Benchmark | # problems | Samples/prob. | Target | Source |
|---|---|---|---|---|
| HumanEval / HumanEval+ | 164 | 10 | Python | ( Chen et al., 2021 ; Liu et al., 2023 ) |
| LeetCodeDataset | 228 | 10 | Python | ( newfacade, 2024 ) |
| LiveCodeBench v6 | 1,055 | 10 | Python | ( Jain et al., 2024 ) |
| MBPP-Rust | 208 | 10 | Rust | ( Emergence AI, 2026 ) |
| VeriContest LC slice | 687 | 10 | Rust | ( Xie et al., 2026 ) |
| HumanEval | LeetCodeDataset | LCB v6 | |
|---|---|---|---|
| Total samples (attempted) | 1,640 | 2,280 | 10,550 |
| Level 1: verifier-accepted (denom.) | 1,625 | 2,217 | 9,731 |
| Level 2: any ensures clause | 5.3% | 9.6% | 10.61% ∗ |
| Level 3: ensures-binding gate passes | 1.9% | 2.7% | 2.3% |
| (i) Hidden-test failure | (ii) Post2Exe | |
|---|---|---|
| Question asked | Does the implementation match the requirement? | Does the postcondition itself match the requirement? |
| Mechanism | Run the shipped code against hidden tests | Translate the postcondition to an executable predicate; check it accepts positives and rejects negatives |
| Reported in | Table 5 (both Rust benchmarks) | End2End @1 (VeriContest LC) |
| Benchmark (Rust) | Total attempts | Fully-verified | fails | failure rate |
|---|---|---|---|---|
| MBPP-Rust ( Emergence AI, 2026 ) | 2,080 | 1,080 | 124 | 11.48% |
| VeriContest LC ( Xie et al., 2026 ) | 6,870 | 1,545 | 229 | 14.82% |
Appendix figures & tables3 assets
Supplementary material from the paper’s appendix.
Appendix
| System | Surface A | Surface B (syntactic binding) | Surface C (semantic fidelity) |
|---|---|---|---|
| Li et al. (2025) | Yes | Not reported | Runtime fixtures only |
| VeriContest ( Xie et al., 2026 ) end-to-end | Yes | Not reported | Post2Exe on postcondition |
| AxDafny ( Breen et al., 2026 ) | Yes | Missing/trivial ensures , {:axiom} , LLM reviewer | Not reported |
| VCG (our own) | Yes | Ensures-binding gate | Hidden-test proxy on Rust runs; Post2Exe applied on VeriContest LC (7.79% End2End @1, 535/6870) |
| Benchmark (Python) | With ensures | Without ensures | Delta |
|---|---|---|---|
| HumanEval (base tests) | 80.2% ( ) | 94.2% ( ) | pp |
| LeetCodeDataset | 59.6% ( ) | 66.1% ( ) | pp |
| LiveCodeBench v6 | 53.2% ( ) | 62.6% ( ) | pp |
Code Generation Evaluation
Code generation evaluation measures whether AI-produced programs are correct, reliable, secure, efficient, and faithful to their specifications.
See all 220 papers