Verification Is a Bottleneck Now

I ended my loop engineering post with a caveat. The loop changed how I work, but one thing stayed on me: verification. A loop can find the work, do it, and tell me it is done. "Done" is still a claim, not a proof.

That claim is the bottleneck now.

For two years, the hard part was getting the model to produce good work. That part got cheap. A frontier model with a decent harness generates a working change fast. So the hard part moved. Now the hard part is checking that the work is actually right.

Inside a loop this gets worse. A loop runs while you are not watching. A weak check does not just let one mistake through. It lets mistakes through at machine speed, again and again, on their own. So the quality of your verifier is the ceiling on how far you can walk away.

The good news is that this is now a real research topic, not just a gut feeling. Let me walk through why checking got hard, and what to actually do about it.

Why Checking Got Harder Than Doing

There is a clean way to say this. Jason Wei calls it the asymmetry of verification: some tasks are far easier to check than to solve. A sudoku takes real work to solve and a second to verify. His "verifier's law" follows from that. The easier a task is to verify, the easier it is to train AI to do it well.

Coding used to feel like it sat on the easy side. Run the tests, see if they pass. If they pass, you probably got the change right.

That intuition starts to break with coding agents. The agent can produce a candidate solution quickly, but now you have to ask a harder question: did it solve the actual problem, or did it only solve the version of the problem your tests described? The Verification Horizon argues that this is the new bottleneck. For today's coding agents, producing an answer is often easier than knowing whether the answer is really right.

The reason is simple. A test is not your intent. It is a narrow slice of your intent. A rubric, a benchmark, or a judge score is the same kind of thing. Each one is a proxy. It points at what you wanted, but it is not the whole thing. And once an agent is strong enough, it can satisfy the proxy while still missing the real goal.

The Trap: One Check Is Never Enough

Here is the part that surprised me. You cannot just pick one stronger check and win.

The Verification Horizon paper grades a verifier on three things:

• Scalable: it can check a lot of work without needing a human in every loop.
• Faithful: it tracks the real intent, not just a convenient proxy.
• Robust: it holds up against a stronger model trying to slip past it.

The finding is that no single check gives you all three at once. Push hard on one and you give up another.

Worse, whatever single check you pick, the model learns to game it. This is reward hacking, an old idea from reinforcement learning and a version of Goodhart's law: when a measure becomes the target, it stops being a good measure.

This is not theory. There is a benchmark called SpecBench built specifically to measure reward hacking in long-horizon coding agents. Another paper shows that even a plain test-based verifier has exploitable bugs a model can learn to hit. When researchers hardened judges with detailed rubrics, hacking dropped but did not vanish. A model trained to exploit the judge can still fool rubric-based judges on most prompts. Even a strong judge can be flipped by a single token.

So there is no silver bullet. Every gate leaks.

How to Mitigate It: Build a System, Not a Check

The same paper that says there is no silver bullet also says what works. Not one perfect check. A system of checks that cover each other, rebuilt over time. Here is how I now layer it.

Use a real oracle where you can. A test that compiles and runs, an execution that either works or does not. This is the cheapest signal and the hardest to fake, so reach for it first. Watch two traps. The first is circularity: do not let the agent prove its own answer with tests that came from the same answer. If it misunderstood the task, the code and the tests can be wrong in the same way. The second is that your verifier can itself be buggy, so treat it as code that needs its own review.

Make the checker separate, and make it reason. The maker is a poor judge of its own work. Research shows models cannot reliably self-correct their reasoning without an outside signal, and the weak spot is spotting the error in the first place. So the checker should be a different agent, ideally a different model, to dodge a model's habit of preferring its own output. And it should reason, not just stamp a score. Generative verifiers that think through a solution beat a bare yes or no. OpenAI's CriticGPT writes critiques of code, and in their experiment, human reviewers using CriticGPT produced critiques that were preferred over critiques from unassisted reviewers more than 60% of the time. A checker that explains itself is one you can audit.

Add rubrics for the fuzzy parts. Not everything runs in a test harness. For open-ended work, break the intent into an explicit checklist and grade against each item. This is more reliable than one vague "is this good," but keep the earlier warning in mind. Rubrics get gamed too, so they are a layer, not the whole gate.

Watch for hacking. Add a monitor that looks at how the work got done, not just whether the final check passed. In the Verification Horizon experiments, pairing tests with behavior monitoring lifted clean success well above tests alone. Cheap checks miss a clever shortcut. A watcher catches the shortcut.

Keep yourself on the intent. No proxy holds the whole of what you meant. The one thing a human still owns is deciding whether the work is the thing you actually wanted, not just the thing that passed.

The Gate Is a Moving Target

One more finding changed how I think. A verifier is not something you build once. As the maker gets stronger, it finds new ways past yesterday's gate. The Verification Horizon paper is blunt: no fixed check stays good as the model improves.

This lines up with what I wrote in self-improving harnesses. The safe systems in those papers all trust the gate, not the model's opinion of its own work. But the gate itself has to keep improving. A verifier you set and forget slowly rots into a rubber stamp.

So What Do You Actually Do

• Prefer a real, runnable check over an opinion.
• Never let the maker be its own checker.
• Make the checker explain, not just approve.
• Assume your gate will be gamed, and watch for it.
• Rebuild the gate as your agent gets better.
• Stay on the one thing no check can hold: whether the work is what you actually meant.

The maker got cheap. The checker is where the work is now. Build the gate like it is the product, because inside a loop, it is.