What Happens When Verification Gets Automated Too

"Agents generate, humans verify" is stable partly because verification is hard to automate. Parts of it aren't — and the part that survives isn't reviewing, it's knowing what was wanted.

The current division of labour has agents generating and humans verifying. It's a stable arrangement partly because verification is genuinely hard to automate — checking whether something is right often requires the same understanding as producing it.

Parts of verification are automatable, though, and they're being automated. Thinking about which parts, and what remains, is more useful than treating verification as a permanent human moat.

Verification is several different activities

Mechanical checking. Compiles, passes, validates, reconciles. Already automated, and this was never the human part.

Consistency checking. Does this contradict something elsewhere in the system? Does it violate a stated invariant? Are all callers updated? Automatable, increasingly automated, and genuinely useful — it catches things humans miss because it doesn't get tired.

Requirement checking. Does this do what was asked? Partly automatable where the requirement is precise. If the requirement is executable, this collapses into mechanical checking.

Intent checking. Does this do what was wanted, as opposed to what was written? Requires knowing the intent, which lives outside the artifacts. Not automatable while that's true.

Judgment checking. Is this the right thing to do at all — right trade-off, right level of investment, right given where we're heading? Requires context and preferences that aren't recorded.

→ The first three are going. The last two are the same structural blockers that gate everything else: unwritten context and no oracle.

The self-verification problem

The obvious worry: if an agent checks its own work, the check shares the blind spots that produced the work. Agreement between an attempt and a self-check isn't evidence.

This is real and partly addressable. Independent verification is more useful than self-verification — a different model, a different framing, or better, a mechanically different method. Checking a claim against a quoted source is independent in a way that asking the model to re-read its output isn't.

⚠️ What doesn't work is stacking model-based checks and treating agreement as confidence. Correlated errors survive any number of correlated checks, and the resulting confidence is manufactured.

What stays human, and why

Intent verification. Someone who knows what was wanted has to confirm that's what happened. The only mechanism that catches specification errors, and it's structural — the intent isn't in the artifacts.

Accountability for the verification. Someone has to be the party who confirmed it. A model can't hold that position.

Verification of the verifier. Whether the checks are checking the right things. An eval suite measuring the wrong property passes happily forever.

The tail. Unusual cases where automated checks have no coverage.

💡 What this means for the "verification career"

The advice to move toward reviewing rather than producing is sound, and it needs a qualification: the mechanical parts of review are being automated, and someone whose review consists of catching style issues and obvious bugs is standing on the automatable half.

The durable version is intent verification and judgment — does this solve the actual problem, is it the right investment, what did it miss that nobody specified. ✅ That requires knowing the domain and the intent, which brings it back to context and proximity to the decision rather than to review skill in the abstract.

So: reviewing is a good direction, and "reviewer" isn't the durable role. The person who knows what was wanted is the durable role, and reviewing is one thing they do.

🔍 A practical consequence

If mechanical and consistency checking are automated, human review time should be spent almost entirely on intent and judgment. That means:

  • Don't spend review attention on what tooling covers.
  • Attach the original request, not the ticket, so intent is checkable.
  • Ask what the change missed, since absence is the characteristic defect and no automated check finds it.
  • Sample delivered work against intent, since that gap is invisible to every pipeline check.

The takeaway

Verification isn't one thing. Mechanical, consistency, and precise-requirement checking are automatable and going; intent and judgment checking aren't, because they need context that isn't recorded and preferences nobody wrote down. Independent checks beat self-checks, and stacking correlated model checks manufactures confidence rather than producing it. Position for intent verification rather than review generally — the durable role is knowing what was wanted, not being the person who reads the diff.

Keep reading

Similar posts

Matched on shared tags and category — the more bars, the stronger the overlap with what you just read.