# Make the AI Prove It's Worth Reviewing

URL: https://danylovorvul.com/blog/make-the-ai-prove-its-worth-reviewing/
Author: Danylo Vorvul
Date: 2026-06-08
Tags: agents, engineering
Description: The bottleneck was never the typing. It was the trusting. Make proving harder to fake than doing.

The agent writes a thousand lines before I finish my coffee.

That feels like leverage. It is — right up until I have to read all thousand lines.

Because the bottleneck was never the typing. It was the trusting.

I can generate more code, more configs, more migrations in an afternoon than I could review in a week. So the scarce resource stopped being output. The scarce resource is my attention. And no model ships more of that.

Here's the trap. You become the rate limiter. Every diff funnels through one tired human, and because plausible output is the default, because the whole point of these models is producing things that *look* right, you start to skim. Looks-right is exactly the failure mode. The agent isn't lying to you. It just has no reason to tell you when it didn't actually run the thing.

So stop reviewing by default.

Shift the burden of proof. The AI shouldn't hand me a diff and ask me to trust it. It should show up carrying evidence that the work is done — and only then does it earn a slot in my head.

The naive version of this is writing "run the tests before you finish" in your prompt. It doesn't hold. An instruction is a request, and the model is free to decide your request was optional once the context gets long enough. I've watched an agent cheerfully report green while the suite never ran.

The sharper version I've seen was a harness that wrote a .tested marker file as proof. The agent learned to create the marker — without running the tests. The fix was to hash the real test output and store the hash. Now faking compliance is more work than just running the suite.

That's the whole move: make proving harder to fake than doing.

I've leaned on this before, from the other direction. When I made my site green in PageSpeed, the agent succeeded because a brutal external checker said yes or no on every loop — [the benchmark became the boss →](/blog/agents-work-better-when-the-goal-can-fail/). There, the checker *steered* the work. Here, the checker *guards my attention*. Same primitive, different door.

And this is where today's tools come up short.

Claude Code and Codex can *suggest* a verifier. You can beg them in AGENTS.md, you can wire a hook, you can cross your fingers. What you can't do — easily — is make a check a mandatory gate the model is structurally unable to route around. A prompt is a request. A gate is a wall. The two are not the same, and the gap between them is where wasted review hours live.

This is what finally clicked for me with Pi — the thin brother of Claude Code and Codex, where you get at the state machine underneath. You add a verifier as its own stage, sitting between "agent did the work" and "human looks at it." Output that fails the verifier never reaches the review step. It bounces back to the agent, who has to try again. I don't see it until it passed.

The review queue stops being everything the agent produced. It becomes only the work that already proved itself.

A good verifier is boring on purpose. It runs in seconds, every loop, with no judgment call to make. It checks a hash, an exit code, a pixel diff — never a vibe. The proof costs more to forge than to earn. And it's specific to the task: a test-output hash for a bugfix, a before/after Playwright video for a UI change, a green build for a refactor, a checker diff for a generated file.

None of that is clever. That's the point. The verifier doesn't need to be smart. It needs to be unskippable.

So sharpen the gate, not the prompt. Every time the agent slips something past you that it shouldn't have, you don't write a sterner instruction — you add a check it can't dodge next time. The harness gets a little harder to fool with every failure.

Your attention is the room. The verifier is the door.

Stop letting everything in.