You're using AI at half power. Here's the missing half.

Last week I shipped a full submission flow in an afternoon.

I wrote zero manual test cases.

I clicked through the finished flow exactly once.

The same AI that built the flow also submitted a real test entry, caught two edge cases I would have shipped straight past, and wrote down what it learned so the next flow would go faster.

I didn’t verify its work. But I did make it verify its own.

Welcome to the agent loop.

Most people are using AI at half power. They delegate the building and keep the checking for themselves. That is becoming backwards.

Many builders are now realising: The building is no longer the expensive part. The checking is. And the checking is precisely the thing AI can now do for itself, if you ask.

This is the shift I want to walk you through: how to close the loop, and then how to make that loop compound.

Think about where your build time actually goes now that AI is writing the code for your team (pretty much).

You describe a simple feature.

The AI writes it in ninety seconds.

Then you spend the next forty minutes clicking every button, filling every field, trying to break the form, checking the empty state, reloading to see if it persisted. On a good day the code was fine and you wasted the forty minutes. On a bad day you find the bug on click number thirty and start over.

That forty minutes is what’s called the Verification Tax.

In the new AI era, it scales with every feature. Ship ten features, pay it ten times.

Many builders still assume AI can generate but cannot judge. So we let it do the fun, fast part and we reserve the slow, boring part for ourselves. We treat verification as the human’s job by default.

But AI’s real weakness was never generation. It was confidence without contact with reality. Ask an AI “does this work?” and it will happily tell you “yes, this should work correctly.”

Should.

That word is doing enormous load-bearing work.

The fix is not to trust it less. The fix is to stop letting it guess and force it to touch reality. Below is how.

Here is the three step framework I now run on almost everything I build. The first one you already do. The other two are where the leverage hides.

Stage 1: The Build. You describe what you want. AI writes it. Nothing new here.

Stage 2: The Proof. AI does not tell you it works. AI shows you it works, by actually running it against the real thing.

Stage 3: The Compounding Skill. Every proof teaches the system something. You capture that, and the checking gets smarter, faster, and more tailored to you each time.

Key to note here:

Skipping Stage 2 and trusting vibes is what is still keeping you in the Vibe-Coding prototype zone.

Skip Stage 3 and you are paying the same tax on every single build, forever.

Let me make the last two concrete.

Below are two examples I use constantly:

Building a UI feature? Give it a browser.

Instead of clicking through every state yourself, hand the AI a browser (if you want to also see it, you call it headed. Else, the agents would default to headless browsers, i.e., something you won’t see but they will still run and check the full flow) and let it drive the real thing against what you actually built. Not what it thinks it built. What is genuinely rendering on the page.

The Chrome team put the problem better than I can. Before tools like this, they said, coding agents were effectively programming with a blindfold on. They could write the code but never see what it did when it ran. The whole game here is taking the blindfold off.

A few ways to do it.

Playwright MCP lets an agent open a browser and read the page through its accessibility tree, so it navigates and clicks based on what is actually there. It is a one time setup and yes, like everything else, you can simply ask your coding agent in natural language to set it up for you.

Chrome DevTools MCP goes deeper and hands the agent real DevTools: it can read the console, watch network requests, and inspect the live DOM. If you would rather describe things in plain English, tools like Stagehand and browser-use let the AI act on instructions like “sign up with a test email and confirm the welcome screen loads.”

Whichever you reach for, the behavior is the same.

Building a submission flow? Make it submit.

It clicks the button. It watches what happens. It fills the form with hypothetical information and confirms the validation fires.

It submits, reloads, and checks the data stuck.

It reads the console and sees the error you would have missed, then confirms the error is gone after its own fix.

This process is what is commonly known as Healing in AI coding parlance.

This is the difference between “the login should redirect to the dashboard” and “I clicked login, waited for navigation, and confirmed the URL is now live.”

You are no longer the human clicking through twelve states hoping to catch the broken one. The AI does the tedious part, and it does it every single time without getting bored on click number nine : )

Further, connect the agent to your database with something like Postgres MCP and it does not just tell you the submission “went through.”

It queries the table and shows you the real row.

The form filled out via the browser —> the record confirmed in the database, both by the AI in one pass.

You can push the same idea into the API layer.

Contract testing tools like Pact let the agent pin down exactly what a request and response should look like and prove the backend still honors it. Schema-based tools like Schemathesis throw a flood of generated inputs at a new endpoint to see if any of them crash it.

If the submission silently drops a field, you find out now, from the AI, in the same breath as the build. Not in a bug report the week after.

The rule underneath all of it:

Never accept “should work.” Only accept “I ran it, and here is what happened.”

In Claude Code you do this with Hooks.

A hook is just a script that fires on an event.

You can set a “stop” hook to block the agent from declaring itself finished until your tests actually pass. If they fail, the failures get handed back and it keeps working (remember Loops and Healing from above).

There is a whole category of tools built on this instinct too.

Qodo Cover and Diffblue Cover generate their own tests, then throw away any test that will not compile or pass, so what survives is only the stuff that genuinely holds.

Meticulous watches real sessions and replays them on every change to catch regressions the agent introduced.

On the visual side, tools like Applitools and Percy compare what rendered against a known-good baseline, so a layout that quietly breaks gets flagged before a human looks.

The common thread, again: the check runs against reality, and it runs whether or not you remembered to ask.

This is Stage 3, and it is the actual superpower. Everything above just closes the loop once.

But Skills make the loop compound.

Before you start building anything serious, set up a Skill whose entire job is testing your work. Then treat it as a living thing, not a static checklist.

If you have not used them, Agent Skills are just reusable prompts the AI loads on demand: a set of instructions plus scripts it can pull in when a task calls for them.

There are already plenty floating around, like a web app-testing skill that spins up the app, drives the critical journeys, and screenshots whatever fails.

Start from one of those if you like. The magic is not the starting version. It is what you let it become and customise to your own work.

Here is how I personally bootstrap it:

1. After every proof, the Skill logs what it found.

Which tests it ran, what broke, what the fix was, what turned out to be a recurring pattern in your particular stack.

Maybe your forms always need a specific auth header. Maybe your submissions have a race condition on double-click. Maybe your empty states are where bugs love to hide. The Skill notices all of that.

2. Once it has enough runs behind it, it starts rewriting itself.

It promotes the checks that keep catching real bugs to the top. It drops the ones that never fire. It bakes in your project’s specific failure modes so it stops rediscovering them from scratch.

The generic “test a form” Skill you started with slowly becomes a “test a form the way things break in your codebase” Skill.

3. It customizes to how you work. Your definition of done, your naming, your edge cases, the states you personally always forget to check. Over a few weeks it stops being a tool you point at your work and becomes a teammate who knows your work.

The first ten builds, the Skill saves you a bit of time. By build fifty, it is catching bugs you did not know to look for, because it has seen your failure patterns more times than you have.

That is the whole game.

Most AI tooling gives you a flat benefit: it is as useful on day one as on day one hundred. A self-improving testing Skill gives you a compounding one.

The tax on verification does not just reduce. It shrinks faster the more you build.

There are two I have noticed:

1. An AI verifying its own work shares blind spots with the AI that built it. If it misunderstood the requirement, it will build the wrong thing and then confidently prove the wrong thing works. Proof against reality catches broken behavior. It does not catch a correct implementation of a wrong idea. You still own the “is this the right thing” question. The AI owns “does this thing actually do what it claims.”

2. Self-checking is not free the first time. Wiring up Playwright, giving it a test account, setting up the Skill, it is real setup cost. The payoff is entirely on the back end, in every build after the first. If you are shipping one thing once, skip it. If you are shipping continuously, this is the highest-leverage hour you will spend all month.

Pick your next build. Before you write a line of the prompt, add one sentence to the end: “After you build it, prove it works by actually running it, and tell me exactly what you observed.”

This one sentence starts moving the Verification Tax off your plate.

Then, once you have run it a handful of times, turn the pattern into a Skill and let it start learning.

Do the doing. Delegate the proving. Compound the learning. That is the loop.

What is the one feature you keep manually testing that you could hand off tomorrow?

Tell me in the comments. I am collecting the most common ones for a follow-up on how to wire each type up.