Give the Agent a Check to Run: The Verification-First Approach

You know how to describe work. You know when to let the agent explore before planning. This chapter covers what lets you walk away from a session without watching every step: give the agent a check it can run.

The Core Principle

Give the agent a check it can run: tests, a build, a screenshot to compare.

The difference between a session you must watch and one you can walk away from isn’t the cleverest prompt. It’s whether the agent has a way to verify its own output.

The mechanism behind this is the generate → test → repair primitive. The agent makes a change, runs a check, reads the result, and fixes failures. Without a check, this loop can’t close.

When the agent says “done,” you have two choices:

• Trust the agent’s claim
• Or have independent evidence to verify that claim

Verification-first chooses the latter.

Verification-First Engineering

This concept can be called verification-first engineering: designing workflows where verification is part of the control loop from the start, not an activity added after implementation is complete.

So the main question isn’t:

“Did the agent get it right?”

But rather:

“Which check proves this work is correct?”

When you can answer this question, you can put the check in the task’s done-when and let the agent use the result as feedback.

The basic pattern becomes:

Specify → Explore → Plan → Execute → Check → Repair → Check

When the check passes and no significant gaps remain, the loop has a clear stopping condition.

Your role shifts from babysitting the agent to designing a good verification system.

Choosing the Right Check

Not all checks are equally valuable. A useful concept:

Run the cheapest discriminating validation immediately after each change.

Two words matter here.

Cheapest means the check with the lowest cost that provides enough information to make a decision.

Examples:

• Type error → type checker
• Syntax error → compiler/parser
• Logic bug → targeted test
• API contract → contract test
• UI change → screenshot or visual comparison
• Build configuration → targeted build

There’s no reason to run the full test suite every time if a type checker can verify the failure class you just created in seconds.

Discriminating means the check must be able to separate “correct” from “incorrect.”

A check that always passes isn’t good verification.

For example:

echo "looks good"

might give confidence but proves nothing.

Whereas:

npm test -- session.test.ts

can fail if the related behavior is wrong, and thus has discriminating power for that task.

This principle also prevents the other side of verification-first: don’t create verification bigger than the problem being verified.

The goal isn’t maximum checks, but minimum sufficient evidence to support the agent’s claim.

Making the Loop Self-Closing

The simplest way to make this principle work is to put the check in done-when from the start when writing the prompt.

Instead of:

Finish the authentication and make sure it works

Write:

Run npm test -- auth and npm run lint before stopping, and fix any failures that occur.

The key difference is the latter gives the agent an executable stopping condition.

The loop pattern becomes:

1. Read specification
2. Explore codebase
3. Create plan
4. Edit code
5. Run check
6. Read result
7. Fix failure
8. Run check again
9. Stop when condition passes

Three details make this workflow work in practice.

1. Specify Commands Clearly

“Make sure it works” is an ambiguous goal.

“Run npm test and npm run lint before stopping” is an operation the agent can actually perform.

Agents follow instructions better than they interpret sentiment.

2. Agent Must See Results

A check the agent can’t run isn’t a check for the agent.

If tests are in CI the agent can’t access, the agent can’t use failures as feedback in its own loop.

This is one reason the harness environment interface matters so much: the agent must have access to the compiler, test runner, shell, or verification tools it needs.

3. Failure Must Feed Back Into the Loop

When a check fails, don’t rush to fix it yourself.

Let the failure become input for the next round:

Change → Check → Failure → Diagnose → Repair → Check

The ability to use failure as a feedback loop is a key part of what distinguishes a code-generation tool from a coding agent.

Incremental Execution: Check as Part of the Step

Verification-first works best when paired with incremental execution.

Instead of having the agent make ten changes and verify everything at the end, break the work into units that can be independently verified.

Example:

Step 1
Add OAuth provider
→ run provider tests
→ known-good

Step 2
Add callback
→ run OAuth integration test
→ known-good

Step 3
Connect session
→ run session tests
→ known-good

Step 4
Adjust middleware
→ run auth suite
→ known-good

The importance isn’t in the number of steps, but in creating known-good states.

Each step should have:

• Narrow scope
• Clear change
• Appropriate validation
• Identifiable stop point

If a failure occurs, you know which step it happened in and can roll back to the most recent known-good state.

This is why incremental execution shouldn’t be understood as merely “accumulating small diffs.”

It’s:

Accumulating changes from one known-good state to the next known-good state

Without verification, incremental work is just unproven accumulation.

Verification Isn’t Trust

Verification-first doesn’t assume the agent “can’t be trusted.”

The point is trust isn’t a correctness verification mechanism.

Even if an agent has high accuracy, you still want deterministic, repeatable checks, because the ability to reason and the ability to prove results are different things.

The agent might say:

“I fixed the problem”

But your system should answer a more independent question:

“Did the tests pass?”

This is why checks matter more than agent confidence.

And verification doesn’t mean humans stop reviewing.

What checks can prove doesn’t need visual re-inspection every time. But what checks can’t prove still requires reviewer attention, such as:

• Architectural fit
• Security assumptions
• Unnecessary complexity
• The invisible 20%
• API compatibility outside the test suite
• Behavior without automated tests

So the correct division of labor is:

Checks close the correctness loop.

Human review closes the verification gaps.

They work together. They don’t replace each other.

From Check to Autonomous Workflow

When you bring this principle back to the workflow from the previous two chapters, the picture becomes clear:

Chapter 9 — Specify

Define Goal, Context, Constraints, and Done-When

↓

Chapter 10 — Explore & Plan

Have the agent explore the system, build hypotheses, and turn them into verifiable plans

↓

Chapter 11 — Verify

Give each implementation step a check the agent can run, and use the result as feedback

This is where agentic coding starts to differ from using LLMs to write code.

You’re not just telling the agent to “write this.”

You’re building a loop that tells it:

“Do this → verify → learn from result → repair → verify again → stop when evidence is sufficient”

The clearer and more discriminating the checks, the more autonomy you can add without increasing human oversight.

This is the key principle of this book:

Autonomy doesn’t come from trusting the agent more—it comes from designing better feedback loops.

A session you can walk away from isn’t a session where the agent is smart enough to never be wrong.

It’s a session where when the agent is wrong, the system can detect it and feed failure back into the loop.

---

This article is adapted from Chapter 11 of the Agentic Coding book.