First off, I did not expect that video to blow up like that, so thank you!
I can't say I'm surprised it happened on that video, because verification loops are the secret to getting Claude (or whatever AI you default to) to give you 100x+ more output. Right now, most of you are treating it like a shitty junior hire.
You know, like the kids who get hired right out of college and handed the easy jobs because nobody else has time to watch over them 24/7 to make sure they don't screw it up.
In this article, I'll explain at a high level how these loops work, so you can use them for video editing, QA, engineering, and basically any high-leverage role in a company that would usually need a more expensive hire.
To make your life really easy: if you want to build one of these, paste this whole article into Claude Code, Codex, or whatever you use, and tell it to build these for your project. The gray boxes are written for it.
OK, let's go.
What is a verification loop?
If you want the textbook definition, it's this: "an automated quality control process in agentic AI systems where an output, action, or multi-step workflow is tested, critiqued, or validated against predefined criteria before it is finalized or executed."
To dumb that down, it just means your AI can look at everything it made, fix what it sees, and keep doing that until it's right.
Without one, you're the one telling it whether it's right, every single turn. That means the AI can only work for a few seconds or minutes before it's stuck waiting on you again.
The whole loop is four steps: make it, look at it, compare it to what good looks like, and then fix it.
The whole thing. The step everyone skips is the second one.
That's the whole idea. Boris Cherny, who built Claude Code, calls giving Claude a way to check its own work "probably the most important thing" you can do, and says it will 2 to 3x the quality of the final result. Lauren Tan, who works on agents at Cursor, puts the other half well in her workshop: if your AI can't check its own work, you're the one checking it, and you become the bottleneck.
A paper from this year breaks the loop into the same four parts: execute, observe, compare, correct. One thing they found is why the separate checker you'll see below matters so much. When they swapped their checker for the same AI that did the work, most of the fixes went away. The AI that made the mistake is bad at catching it.
The "look at it" step is also the one almost everyone skips, because for something like video it's not obvious how.
Alright, now onto the meat and potatoes.
How to build a verification loop, step by step
Every loop that works has the same five pieces, whatever the job is. Here they are in plain English. After that, two examples show what each piece looks like for real.
Write down what "right" means. A short checklist the work gets checked against. Any note you've ever had to give twice belongs on it.
Let Claude see the real result. Not its own code or its own description of what it did, but the actual thing: pictures from the video, or the app running in a browser.
Have a separate chat do the checking. The chat that made the work tends to walk right past its own mistakes. The checker starts fresh, only gets the result and the checklist, and isn't allowed to change anything.
Make passing the only way out. Claude can't call the job done until the checker says pass. Cap the number of tries, so it asks you for help instead of spinning forever.
You only look at what passed. Your job stops being finding mistakes. It becomes saying yes to the final version.
Every gray box from here on is for technical folks, or for your AI if you paste this article in. If you're not technical, skip them. You'll still get the whole idea.
I write one of these every week, pulling apart a setup that actually works. Put your email in, and you will get the next one.
Example 1: video editing
The catch: Claude can't watch video
This is the reason most people's attempts don't work. Claude doesn't watch a video the way you do. It looks at still pictures and reads text. So if you ask it to "check the edit," it either reads its own code and assumes the video is fine, or it guesses.
Every video setup that works does the same thing. After each edit, it pulls still pictures out of the video and turns the audio into text, then hands both to Claude. Once it has those, it can see the caption on your face and notice that the words on screen don't match what you said.
Claude cannot press play. It reads pictures and text, so you hand it pictures and text.
1. Write down what "right" means for your videos
This is where most of the value is, and it's specific to your brand. For example:
Captions never cover a face.
Captions stay inside the safe zone, clear of the app's buttons and the caption area at the bottom.
Caption text matches the words actually spoken.
Your voice is clearly louder than the music the whole way through.
No black frames, frozen frames or cuts in the middle of a word.
The hook text in the first two seconds is easy to read on a phone.
For technical folks (or your AI), here's the checklist as a file:
# video-checklist.md A render passes only if every item below is true. For each failure, give the timestamp and what's wrong. - Captions never overlap a face. - Captions stay inside the safe zone (not in the top 10% or bottom 20% of the frame). - Caption text matches the spoken words. - Voice is clearly louder than music everywhere (see loudness numbers). - No black frames, frozen frames, or cuts mid-word. - Hook text in the first 2 seconds is readable at phone size.
2. Let Claude see and hear the video
After every edit, Claude grabs a still picture every second or two and lays them out in one big grid, like a page of thumbnails. The pictures are big enough to read the captions, so it can spot the one sitting on your face.
For sound, it turns the audio into text and checks it against the captions, so it knows if they match what you said. It also measures how loud your voice is next to the music. That way, "the music's too loud" becomes a number it can check, not a guess.
For technical folks (or your AI): the grid is called a contact sheet. Also grab a full-size frame anywhere a caption changes, since that's where most problems show up. Decide how far under the voice the music should sit and write that gap into the checklist.
# contact sheets: a frame every 2 seconds, 20 per sheet mkdir -p review ffmpeg -i final.mp4 -vf "fps=1/2,scale=480:-1,tile=5x4" review/sheet_%02d.png # a full-size frame at a specific moment (here, 12.5 seconds in) ffmpeg -ss 12.5 -i final.mp4 -frames:v 1 review/frame_12_5.png # what's actually said in the render, with word timings whisper final.mp4 --model small --output_format srt --word_timestamps True --output_dir review # loudness of the voice and music tracks before the mix ffmpeg -i voice.wav -af ebur128 -f null - 2>&1 | grep "I:" ffmpeg -i music.wav -af ebur128 -f null - 2>&1 | grep "I:"
3. A second chat watches it back
A fresh chat gets the video, the pictures, the transcript and your checklist. It didn't make the edit, so it has no reason to think the edit is fine. It isn't allowed to change anything either. It just says pass, or lists what's wrong and at what second.
The chat that made it never catches its own mistakes. A fresh one does.
For technical folks (or your AI): in Claude Code, this is a subagent, which runs in its own context.
# .claude/agents/video-reviewer.md --- name: video-reviewer description: Reviews a rendered video against video-checklist.md. Use after every render. tools: Read, Bash --- You review video renders. You never edit project files. 1. Read video-checklist.md. 2. Generate contact sheets and the transcript into review/. 3. Look at every contact sheet and compare the transcript to the caption file. 4. If every item passes, write PASS to review/verdict.txt. Otherwise write FAIL followed by each problem as: timestamp, what's wrong, what would fix it. Be strict. A render you aren't sure about is a FAIL.
4. It can't finish until the edit passes
The first chat fixes what the checker found, makes a new version, and the checker looks again. They keep going back and forth until it passes. After three tries, it stops and hands it to you, so it can't loop forever.
For technical folks (or your AI): enforce this with a Stop hook, which runs every time Claude tries to finish. If the reviewer hasn't written PASS, the hook sends Claude back to work. Claude Code also gives up on its own after a hook blocks it 8 times in a row, so a bug in your script can't trap it.
# .claude/hooks/require-review.sh (make it executable: chmod +x) #!/bin/bash ROUNDS=.claude/review-rounds if grep -q '^PASS' review/verdict.txt 2>/dev/null; then rm -f "$ROUNDS"; exit 0; fi n=$(( $(cat "$ROUNDS" 2>/dev/null || echo 0) + 1 )); echo $n > "$ROUNDS" if [ "$n" -gt 3 ]; then rm -f "$ROUNDS"; exit 0; fi # give up and hand it to you echo "Not done. Run the video-reviewer subagent on the latest render and fix everything it flags." >&2 exit 2
# .claude/settings.json
{
"hooks": {
"Stop": [
{ "hooks": [ { "type": "command", "command": ".claude/hooks/require-review.sh" } ] }
]
}
}Have the editing chat delete review/verdict.txt before each new render so an old PASS doesn't carry over.
5. You approve the final cut
You open the file once, and the caption is already where it should be.
Shortcuts for the video loop
For technical folks (or your AI), a few free, open-source tools already do the seeing and hearing for you:
Remotion's official agent skills, if you make videos in code. It can render single stills to check before doing a full render.
mcp-video-preview, which gives Claude tools to grab evenly spaced frames or a frame at a given second.
watchvideo, which builds contact sheets sized so burned-in captions are readable.
claude-video-vision, if you want audio analysis on top of frames.
You'll still need your own checklist and a separate checker. No tool can write those for you.
Example 2: engineering
This is where verification loops started. It's how the people who build these AI tools work every day, and Boris and Lauren set it up the same way.
If you're still reading, that means you're interested in being one of the few people who actually build this, not just save another reel about it. Below is exactly how Boris and Lauren run it every day, the one file Lauren says makes the whole thing work, and how she wakes up to 20 finished PRs she never touched. Drop your email to keep reading:
1. Write down what "right" means, and make it a hard rule
For code, most of the checklist already exists: tests and automatic checks that catch errors. Lauren splits checks into two kinds. Soft ones are notes and instructions, and the AI can forget or ignore them. Hard ones are checks the code has to pass, so the AI can't get around them.
Her habit is worth stealing even if you never write code. Any time you'd give someone the same note twice, turn it into a check that has to pass, so nobody, human or AI, can make that mistake again.
For technical folks: the hard checks are your linter, compiler, and type errors, and failing tests in CI.
2. Let Claude use the real app
Passing tests doesn't mean the app works. So Claude opens the app and uses it as a customer would. Boris has Claude test every change he ships to claude.ai/code with the Claude Chrome extension: it opens a browser, clicks around, and keeps going "until the code works and the UX feels good." Lauren built a skill that lets her AI drive the app on its own, on a computer or on a phone simulator.
The piece most people miss is a feature map: a simple list of every feature, where to find it and how to test it. Lauren said that without one, the AI "would just be kind of flailing around," and the skill was "basically completely useless."
Her advice is to start on your own computer, where you can watch it work and see where it gets lost. Once you trust it, let it run in the cloud.
For technical folks (or your AI), a feature map can be as simple as this. Lauren's version also has the agent take performance traces and memory snapshots.
# feature-map.md (one entry per feature, keep it short) ## Checkout - Where: /cart, then the "Checkout" button - How to test: add any product, go to /cart, click Checkout, use test card 4242 4242 4242 4242 - What good looks like: order confirmation page with an order number ## Account settings - Where: avatar in the top right, then "Settings" - How to test: change the display name, save, reload the page - What good looks like: new name still shows after reload
3. A separate agent checks the work
Boris keeps checker agents next to the one writing code. One is called verify-app, and it tests the whole app from start to finish. It's the same idea as the video checker: it starts fresh, reads the feature map, uses the real app, and reports back without touching the code.
For technical folks (or your AI):
# .claude/agents/verify-app.md --- name: verify-app description: Tests the running app end to end after a change. Use before finishing any task. tools: Read, Bash --- You test changes. You never edit source files. 1. Read feature-map.md and find every feature the change touches. 2. Start the app locally and use each of those features in the browser the way a user would. 3. If everything works as described, write PASS to review/verdict.txt. Otherwise write FAIL followed by each problem: what you did, what happened, what should have happened.
4. It can't finish until the checks pass
Claude can't say it's done until the hard checks pass and the checker says pass. That's what lets Boris's sessions run for hours on their own. Claude keeps going until the code actually works, instead of stopping when it thinks it does.
For technical folks (or your AI): the Stop hook runs the hard checks itself and also needs a PASS from the checker.
# .claude/hooks/require-checks.sh (make it executable: chmod +x) #!/bin/bash ROUNDS=.claude/check-rounds if npm run lint --silent && npm run typecheck --silent && npm test --silent \ && grep -q '^PASS' review/verdict.txt 2>/dev/null; then rm -f "$ROUNDS"; exit 0 fi n=$(( $(cat "$ROUNDS" 2>/dev/null || echo 0) + 1 )); echo $n > "$ROUNDS" if [ "$n" -gt 3 ]; then rm -f "$ROUNDS"; exit 0; fi # give up and hand it to you echo "Not done. Fix the failing checks, then run the verify-app subagent and fix everything it flags." >&2 exit 2
Swap the npm commands for whatever your project uses. The settings.json entry is the same as the video one, pointing at this script.
5. You review what already went live
Once the loop is solid, the human moves to the very end. Lauren's AI agents now add their own code changes, and she looks them over afterwards: "I woke up today, and there were like 20 PRs landed." (A PR is one code change.) Their bug agent takes every bug report that comes in, opens the app on its own computer in the cloud, and tries to make the bug happen before a person ever looks.
Boris has gone a step further. "I don't prompt Claude anymore," he said this year. The loops do the prompting, and his job is to write the loops.
The same loop works for every job
Video and code are just the two easiest to picture. The five pieces stay the same everywhere. The only things that change are how Claude looks at the work and what counts as right:
Landing pages: it takes a screenshot of the page at phone size and checks it against the design.
Ads: it makes the ad and checks it against your best ads and the platform's rules.
QA: it clicks through the product the way a customer would, with a feature map, and writes up anything broken.
Writing: a separate checker holds the draft up against your best past examples and a list of things that sound like AI, before you ever read it.
Stop babysitting your AI
Go back to that junior hire for a second. The reason you watch over them all day is that nobody gave them a way to check their own work, so you became the check. Claude is stuck in the same spot until you give it a loop.
So pick one job, the one where you give the same notes every single week. Write down what "right" looks like, give Claude a way to see the real result, have a second chat check it, and don't let it finish until it passes. The first time you open a file and the caption is already off your face, you'll see why this is the thing.
One loop for one job is a weekend project. A loop for every job in your business, with checklists that actually match your taste and a person signing off on the stuff that matters, is a real build. That's what we do at Merge Labs.
If you'd rather not build it yourself, here's where to go:
Want our team to build this for you? Fill out this form and tell us which job you'd hand off first.
Not sure yet and want to see what we'd do for your business? Book a call here.
Want your team trained to build these themselves? Email me at cael@mergelabs.co.