Why verification is not enough

Video segment: 02:23–04:09

The usual reason for a person to understand an AI-written change is simple: someone must check whether the change is correct. In this part of the talk, Geoffrey Litt argues that this reason is real but incomplete. As agents become better able to run verification loops themselves, human correctness checking becomes a smaller part of the work. So verification alone cannot explain why people still need understanding.

Verification asks a bounded question

From the talk: A common justification for human understanding is verification: checking whether an agent's output is correct. Litt says that correctness can mean at least three different things: matching a specification, avoiding a production outage, and being well architected.

Verification means using some procedure to decide whether an output meets stated criteria. It produces evidence for a decision such as accept, revise, or investigate further.

The word correct can hide several different questions:

Kind of correctness named in the talk	Plain-language question	Teaching context
Specification fit	Does the result do what the specification requires?	A specification states the requested behavior.
Production safety	Could the result cause an outage in the live system?	“Production” is the version used by real users. An outage is a service failure.
Architecture	Is the result organized in a sound way for the system?	Architecture is the high-level arrangement of a system's parts and their relationships.

These are not automatically the same check. A change can appear to match a requested behavior while raising a different question about live-system safety or system design. The talk's point is not that one particular check is useless. It is that “correct” is broader than a single yes-or-no test.

Why agents change the verification argument

From the talk: An agent can increasingly receive a verification procedure, ask the relevant questions, and run that process over time. As this improves, the human role in direct correctness checking declines.

A verification loop is a repeatable process: apply the chosen procedure, obtain answers or evidence, and use that result to assess the change. At a high level, the loop the speaker describes looks like this:

flowchart LR
    P[Verification procedure or criteria] --> A[Agent applies it and asks relevant questions]
    A --> E[Answers or evidence]
    E --> A
    A --> J[Correctness judgment]

The important shift is not that every agent is always right. The talk makes a directional claim: agents are taking on more of these loops. If a person's only reason to understand a change is to manually perform the loop, that reason weakens as the agent can perform more of it.

The reasoning is:

1. Human understanding is often justified as a way to verify agent output.
2. Verification can be expressed as a procedure with questions and criteria.
3. Agents can increasingly carry out such procedures.
4. Therefore, verification cannot be the whole reason that humans need to understand the work.

This does not mean that checks no longer matter, that all verification can be automated, or that an agent's output should be accepted without thought. It means that passing a procedure and building human understanding are different outcomes.

Verification and understanding do different jobs

The chapter creates a distinction that the next chapter develops further: understanding for verification versus understanding for participation.

If the goal is…	The central question is…	The immediate result is…
Verification	“Does this output meet the chosen criteria?”	A correctness judgment about this change.
Understanding for participation	“What is happening here, and how can I use that model in the next piece of work?”	A person who can actively contribute, not only approve or reject.

Teaching interpretation: A working understanding is a usable mental map of the important parts of a system, their relationships, and the purpose of a change. It does not require knowing every possible detail. It gives someone enough context to reason, ask better questions, and form the next idea.

An output can be correct according to a procedure without transferring that mental map to the person who receives it. That is the misconception this section challenges: “If the output is correct, human understanding is unnecessary.” Correctness evidence answers a bounded question about an output. It does not automatically make a collaborator able to take part in what comes next.

Teaching example: a passing check is not a transferred model

This is an invented example to explain the distinction; it is not a scenario from the video.

Suppose an agent changes a service so that it rejects an invalid request.

• A specification check asks whether invalid requests are rejected as required.
• A production-safety check asks whether the change could disrupt the live service.
• An architecture check asks whether the change fits the system's existing organization.

If the chosen checks pass, the team has useful evidence about the change. That is a successful verification outcome. But a teammate who only receives the result may still lack a model of where validation happens, what the change affects, or what question to ask when the next related change arrives.

Nothing was wrong with verification in this example. It did its job. The missing point is that its job is narrower than helping a person remain an active participant in the project.

Why code review can become a bottleneck

When agents generate changes quickly, a workflow can treat human code review as a final correctness gate:

agent produces a change → human checks correctness → change proceeds

If the human must manually repeat every verification step, that review work can become the limiting stage. The speaker's challenge is deeper than “how can we review faster?” If agents can take on more correctness checking, the remaining question is: what human work should understanding support beyond a thumbs-up or thumbs-down decision?

The talk's answer begins in the following chapter: understanding matters because it lets people participate in later loops of creative and collaborative work. Here, the essential pivot is simpler: do not treat verification and understanding as interchangeable.

Takeaway

• Correctness has several meanings, including specification fit, production safety, and architecture.
• Agents can increasingly run repeatable verification procedures, so manual human checking is declining as the sole bottleneck.
• Verification gives evidence about an output. It does not, by itself, give a person a reusable model of the system.
• Therefore, the case for human understanding must include more than catching errors; it must include staying able to participate in the work.