The Generator-Verifier Gap

Generation Is Easy; Verification Is Hard

There is a classic asymmetry in human cognition. Writing a great poem is hard, but judging whether someone else’s poem is great is comparatively easier. Playing a creative move in Go is hard, but verifying whether that move is legal can be done by a computer instantly. This is the Generator-Verifier Gap: the difficulty of generating something and the difficulty of verifying it are asymmetric.

In LLM agents, this relationship has an important inversion. Generation is what the model does naturally and fluently. But verifying whether what it just generated is actually correct is often harder. Because models are trained to produce fluent and plausible text, they produce wrong answers confidently. A loop that only generates without verifying is fully exposed to this vulnerability.

┌──────────────────────────────────────────────────────────────┐
│          The Generator-Verifier Gap in Two Directions         │
├─────────────────────────────┬────────────────────────────────┤
│  Human Cognition             │  LLM Agent                    │
├─────────────────────────────┼────────────────────────────────┤
│  Generation > Verification  │  Generation ≈ easy (fluent)   │
│  "Writing poetry > judging" │  "Generating answer >          │
│                             │   verifying answer"            │
│  → Verification is          │  → Verification is actually   │
│    relatively easy           │    the harder problem         │
│    (rules, rubrics)          │    (model is overconfident)   │
└─────────────────────────────┴────────────────────────────────┘

Failure Patterns in Loops Without Verification

An agentic loop that only generates, without verification, exhibits the following failure patterns.

Pattern 1: Premature Success. The model declares the task complete before it actually is and exits the loop. Anthropic’s long-running agent guide explicitly flags this as a critical failure mode. Without an external verifier — a test runner, a separate LLM judge — there is no way to catch this failure when it occurs.

Pattern 2: Self-Confirmation Bias. When asked “Is the code you just wrote correct?”, the model tends not to be genuinely critical of what it just created. The model acting as both generator and verifier is a conflict of interest.

Pattern 3: Plausible Wrong Answers Propagating Downstream. An LLM can produce text that is factually wrong but sounds confident, logical, and well-structured. If that wrong answer is used as the premise for the next step without verification, the error propagates through the entire downstream pipeline.

Inserting a Verification Step into the Loop

The most direct way to close the Generator-Verifier Gap is to explicitly separate the generator and verifier within the loop structure.

# Pseudocode for conceptual illustration; actual API may differ.

def run_loop_with_verification(task: str, tools: list, max_iters: int = 20):
    messages = [{"role": "user", "content": task}]

    for _ in range(max_iters):
        # Stage 1: Generation (Generator)
        response = model.generate(messages, tools=tools)

        if response.stop_reason == "end_turn":
            candidate = response.content

            # Stage 2: Verification (Verifier) — separate from the generator
            verification = verify(candidate, task)

            if verification.passed:
                return {"status": "success", "result": candidate}
            else:
                # Verification failed: add feedback to context and retry
                messages.append({
                    "role": "user",
                    "content": (
                        f"Verification failed: {verification.reason}\n"
                        "Please try again."
                    )
                })
                continue

        # Execute tools and continue
        for call in response.tool_calls:
            result = run_tool(call)
            messages.append(tool_result(result))

    return {"status": "max_iters_exceeded"}

The verify() function here can be implemented in many ways. The following chapters each cover one implementation approach.

Verification Method	Properties	Chapter
Test runner	Deterministic, fast, ideal for coding tasks	6-4
LLM-as-Judge	Flexible, suited for language tasks, has biases	6-3
Human review	Highest reliability, slow and costly	6-5
Rule-based checks	Fast, limited scope	—

Aligning Verification Difficulty with Generation Difficulty

In an ideal loop design, verification should be clearly easier or more reliable than generation. Coding agents exemplify this principle. Generating code is hard; checking whether that code passes tests is deterministic and fully automated. The binary test-pass signal measures generation quality unambiguously.

Conversely, in tasks where verification is as hard as (or harder than) generation, the limits of automated loops become clear. Evaluating the quality of creative writing, or determining the rightness of a complex strategic decision, does not yield to automatic verification. In those cases, human review (Chapter 6-5) or a carefully calibrated LLM-as-Judge (Chapter 6-3) is the realistic approach.

What Does a Loop Without Verification Produce?

A loop without a verification step technically “runs.” But there is no way to guarantee the quality of its output. When the loop runs for thirty iterations and returns end_turn, that means only that the model is satisfied — not that the work was actually completed correctly. Recognizing the Generator-Verifier Gap is the starting point for designing a verification stage into the loop. The next two chapters examine the two major automated verification strategies for closing this gap: LLM-as-Judge and test-driven loops.