Español

Stop Being The Verification Loop

Ask what verifies your agent's output and the honest answer is usually: you do, by reading it. That arrangement scales badly. Every mistake sits there, costing nothing to produce and waiting for a human to notice, and the human gets worse at noticing the longer the session runs.

The bottleneck isn't the prompting

When output quality disappoints, the reflex is to improve the prompt. Sometimes that helps. But there's a structural difference between an agent that produces and an agent that produces and checks, and no amount of prompt refinement crosses it.

An agent that can verify its own work catches issues before you have to ask for fixes. The loop closes without you in it. An agent with no check produces confident output at machine speed, and the review capacity is one tired person reading diffs. Adding a verification target changes what the agent is able to do; rewording the request only changes what it attempts.

The practical test: could the agent tell, on its own, whether it succeeded? If not, you're the verification layer, regardless of how well the request was phrased.

Four layers, cheapest first

These escalate in cost and in strength. Most work needs the first one; some work justifies the fourth.

1. Ask for the check in the same prompt. Include the verification step in the request itself — run the tests, check the output against this example, confirm the endpoint returns 200. Nearly free, and it covers a lot. Giving verification targets is what lets the agent catch its own mistakes before handing back.

2. Set a goal. A goal is re-evaluated across turns: the agent keeps working until the condition is met or the goal clears for another reason. The difference from a prompt instruction is persistence — a prompt is checked once by whoever remembers to check it, a goal is a condition the session keeps returning to.

3. A blocking hook. A Stop hook exiting with code 2 prevents the agent from stopping and continues the conversation. This is the first layer that isn't advisory: it's enforcement, run as a shell command at a fixed lifecycle event, and it applies regardless of what the agent decides. If your linter must pass before a turn can end, this is the mechanism — instructions in a rules file are context and can be missed, a hook cannot.

4. An adversarial reviewer. A separate agent whose job is to attack the work. The strongest and most expensive option, and the one with a failure mode worth understanding before you use it.

Scoping the reviewer so it doesn't manufacture findings

An agent told to find problems will find problems. If the work is clean it will keep lowering its bar until something qualifies, because it's been given a goal that is only satisfied by output. You get a list of stylistic preferences and hypotheticals presented with the same confidence as real defects, and the signal drowns.

The fix is to define what counts before it starts. Scope the reviewer to flag only what breaks correctness or your stated requirement, and treat everything else as explicitly optional. Give it permission to return nothing.

Weak:
  "Review this and find any problems."

Strong:
  "Review this against the requirement: <requirement>.
   Flag only defects that break correctness or that requirement.
   Everything else is optional — list it separately or omit it.
   Returning no findings is an acceptable result."

The same discipline applies to review panels. Giving several reviewers distinct lenses — correctness, security, does-it-actually-reproduce — beats several identical reviewers, because diversity catches failure modes that redundancy can't.

Build the loop the agent can run against

Underneath all four layers is the same requirement: something the agent can execute that tells it whether it succeeded. The stronger that signal, the less any of this matters.

• A test suite it can run, with failures it can read
• A build or type check that surfaces errors mechanically
• A way to drive the actual artifact — hit the endpoint, open the page, read the log
• Concrete expected output pasted into the prompt

This is also where verification stops being a cost and becomes a saving. Errors caught by a check the agent ran itself cost one extra turn. Errors caught by you cost a context switch, an explanation, and a re-run — assuming you catch them at all, which is the assumption the whole arrangement rests on.

A related habit worth adopting: put the verification steps into the task list as their own items. "Run the tests" as a separate to-do gets done. "Run the tests" appended to a sentence about implementing a feature frequently doesn't.

The takeaway

If there's no check, you're the check — and you're the slowest, most expensive, and least reliable part of that loop. Start with the cheapest layer: state the verification in the same prompt. Escalate to a goal when it needs to persist, a blocking hook when it must be enforced, and a reviewer when the work justifies an adversary. Then scope the reviewer to correctness and your stated requirement, or it will invent findings to satisfy the instruction you gave it.