VerifierBench: Benchmarking the Generation of Executable Verifiers for LLM Agents
VerifierBench tests whether agents can write executable verifiers for their own output.
Paper (from PDF)
Read full textVerifierBench: Benchmarking the Generation of Executable Verifiers for LLM Agents
JianingYin1 ZiyiChen2 HaoWang3 YiyouSun3 ZijianJin4 DawnSong3 DaoanZhang5 1UniversityofPennsylvania 2UniversityofIllinoisatUrbana-Champaign 3UniversityofCalifornia,Berkeley 4NewYorkUniversity 5UniversityofRochester Abstract etal.,2026). Theseverifiersjudgecandidatesolu- --- -------- --- --- --- ------------ --- --------------------------------- --- --- --- --- tions,determiningwhichreceiverewardsorenter Agentsneedreliablewaystovalidatetheirout- 6202 tcO 91 ]ES.sc[ 1v97682.0162:viXra the training data. An incorrect verifier can there- puts, both when completing tasks and when ---------- --------------- --- --------- ---- --- --- --- --- --- --- --- forerepeatedlyrewardaviolationordiscardavalid filteringsynthetictrainingdata. Westudyveri- ------------------------------- --- --- ------------ --- --- --- --- --- --- --- --- solution,makingthereliabilityofagent-generated fiergeneration: fromtheinstructionandenvi- --------------- -------------------------- --- --- --- --- --- --- --- --- --- --- verifierscriticaltothislearningprocess. ronmentavailableforsolvingatask,anagent writesanexecutableverifierthatmustaccept Toexaminethisreliability,westudyverifiergen- everyvalidsolutionandrejectinvalidones. We eration (Zhang et al., 2025; Dinella et al., 2022): introduceVerifierBench,abenchmarkof222 given the instruction and environment a solver tasksfromsixagentbenchmarksspanningtool- wouldreceive,anagentwritesanexecutableveri- call, state-based, and code verification, with fierthatreturnsPASSorFAILforanycandidate 4,993hiddentestcasesthatincludealternative solution. Unlike a solver, which needs one valid --------------- --- -------- ----------------- --- --------- --- …
Explained
What happened
VerifierBench (Penn, UIUC, Berkeley and others) measures how well AI agents write executable verifiers: programs that return PASS or FAIL for any candidate solution to a task. These verifiers decide rewards in reinforcement learning and filter synthetic training data, so a wrong verifier silently teaches the wrong thing.
The benchmark: 222 tasks from six agent benchmarks (tool calling, environment state, code changes) with 4,993 hidden test cases, including reference solutions, alternative valid solutions, ordinary mistakes, and deliberate attacks on the verifier.
Across 19 models, normalized balanced accuracy ranges from 10.6 to 62.1. Verifiers are consistently better at rejecting bad solutions than accepting good ones.
Why it works
A solver needs one valid answer. A verifier must accept every valid answer and reject every invalid one, so it has to separate true requirements from incidental choices. Agents fail at exactly that:
- Over-restrictive checks. Example from the paper: a verifier rejects a valid read-only query because the agent left that tool off its allowlist. Most false rejections came from verifiers that accept no tested valid solution at all.
- Unsupported assumptions about output format, which tools must be used, or how code must change.
- Self-testing doesn't catch it, because the agent tests with solutions that share its own wrong assumptions, or submits without confirming any correct solution passes.
The apparent strength (rejects bad solutions well) hides the weakness: a verifier that rejects almost everything looks "safe" but throws away valid training data or punishes correct behaviour.
The bigger pattern
Who tests the tests? Writing a correct spec is harder than writing one correct implementation. This is the same problem as flaky or over-specified unit tests in normal code, just amplified because AI training loops run the verifier millions of times.
What it means in practice
- When an agent writes tests for its own code, check that the tests pass on a known-good alternative implementation, not only on the agent's version.
- Prefer property-style checks (invariants about the result) over checks that pin the exact path or format.
- If you build LLM eval pipelines (for example grading AI outputs in a product), measure false rejections as well as false acceptances. A grader that rejects everything looks strict but is broken.