Diversity Beats Brute Force: New Pipeline Doubles Success Rate in Automated Code Verification

Seventy-three formal verification tasks, 292 candidate implementations, and one striking result: generating multiple functionally equivalent versions of the same program dramatically improves the odds that at least one of them can be formally proven correct. That is the central finding behind Diversify2Verify, a new staged pipeline described in a paper submitted to arXiv on July 10, 2026, which targets one of formal methods' most persistent bottlenecks: getting large language models to produce code that verifiers can actually confirm as correct.

The system works against Why3, a platform for deductive program verification, and tackles a problem that has quietly limited how useful LLM-assisted verification can be in practice. Two implementations of the same function, say a list-reversal routine written recursively versus iteratively, can behave identically at runtime while differing enormously in how easily a verifier can prove their correctness. Rather than betting on a single generated implementation and hoping it verifies, Diversify2Verify generates many.

How the pipeline works

The approach unfolds in stages. First, the system infers contracts tailored to the specific data representation being used, whether that's an array or a linked list. It then prompts an LLM to generate a diverse spread of implementations, mixing recursive and imperative styles across integer, array, and list-based tasks. Each candidate is tested, and the pipeline attempts formal verification on the resulting pool. When a candidate fails, a bounded, verifier-guided repair loop kicks in, using the verifier's own feedback to patch annotations and retry, rather than discarding the attempt outright.

The numbers

Applied to a benchmark of 73 verification tasks that together produced 292 implementation variants, the initial verification pass confirmed 96 artifacts. Two rounds of automated repair pushed that figure to 154, lifting artifact-level verification from 32.9% to 52.7%. That is a meaningful jump for a step in the pipeline that typically involves painstaking manual annotation work.

The more consequential figure sits at the task level. Because the pipeline generates several candidate implementations per task, success only requires one variant to clear verification. By that measure, 49 of the 73 tasks succeeded, a 67.1% hit rate, substantially higher than what any single-implementation strategy achieved in the same benchmark.

Why it matters

The paper's broader argument is that implementation diversity is itself a lever for automated verification, not just a byproduct of LLM sampling. Two functionally identical programs can present very different obstacles to a theorem prover, and rather than trying to make one implementation verifiable through repair alone, generating structurally distinct alternatives increases the chance that some version aligns naturally with what the verifier can prove. For teams building LLM-driven tooling around formally verified code, that reframes the design question: instead of optimizing a single generation-and-repair loop, it may be more productive to widen the search across implementation styles before committing repair effort.