The Verify Loop
Everyone says stop prompting and write loops. The loop is the easy part — this is the part that makes it work
The Idea
The hot take of 2026 is "stop prompting, start writing loops." Boris Cherny, who built Claude Code, put it bluntly: "I don't prompt Claude anymore. I write loops." And he's right. But there's a catch everyone skips.
A loop is three lines of bash — anyone can write one. The trouble is a loop with nothing checking its work is just the agent confidently agreeing with itself twenty times in a row. It'll declare victory on code that was never run. When you look at what Boris actually does, the loop is the boring bit: the real machinery is verification — giving the agent a way to run the thing and see that it's genuinely right. He says it 2–3x's the quality.
So this skill is the loop done properly. You give it a goal; it works one task at a time and verifies each one for real before moving on — committing on green, tracking progress on disk, and stopping itself before it can run away. It runs supervised by default, so you can't accidentally let it grind the wrong direction for an hour.
Install It (No Terminal Needed)
The easiest way: let Claude install it for you. Open a new chat — in Claude Code or on the web at claude.ai — and paste this in. Claude grabs the file straight off GitHub and drops it in the right place.
Once it's installed, kick off a loop by saying:
Prefer to grab the file yourself? Copy or download it and drop it into your project.
verify-loop.mdThe Verify Loop skill
One file. Drop it into your project's .claude/skills/verify-loop/ folder (or ~/.claude/skills/ to use it everywhere), then say verify loop and give it a goal.
What Makes It More Than A While-Loop
Four things separate this from the "paste a prompt in a bash loop and pray" version going round. Three of them are guardrails. The first one is the whole point.
It verifies for real, not on vibes
Run the thingAfter every change it actually checks the result — starts the app and drives the flow, or runs the tests. "The code looks right" doesn't count. This is the step that 2–3x's the quality, and it's the one the hype posts skip.
The checker isn't the maker
No grading its own homeworkThe verification is done from a fresh perspective — a separate subagent whose only job is to run it and report pass or fail. An agent marking its own work will happily tell you it's done when it isn't.
Its memory lives on disk
Survives a fresh contextThe goal and a progress checklist sit in files, not in a bloating chat. One task per iteration, committed on green — so the git history is a list of known-good states you can roll back to.
It stops itself
Brakes, not just an engineMax iterations, a no-progress detector, and green-commits-only. The same error three times means stop and get a human. This is the difference between "ships while you sleep" and "burns the budget while you sleep."
How A Loop Runs
You give it a goal. From there each lap is the same four beats — and it checks in with you between tasks until you tell it to run unattended.
Pin the goal
It turns your request into a checkable "done" and finds the strongest way to verify it — run the app, or run the tests.
Pick one task
Smallest next step from a progress checklist it keeps on disk. One task per lap keeps context tight and history clean.
Implement, then verify
It makes the change, then a separate check actually runs it and reports pass or fail with evidence — not the agent's opinion.
Commit on green, then check in
Green means commit and tick it off. Then it reports what it verified and asks whether to carry on.
The Honest Bit
Loops are not magic, and the "ships an entire app while you sleep" demos need a near-perfect spec to work. That's exactly why this one runs supervised by default — it does a task, verifies, and checks in, instead of grinding twenty laps unattended before you find out it went the wrong way.
When you trust the goal and the verification is solid, you tell it to run unattended with a max-iteration cap and it'll go full auto. Just remember the rule: a loop is only as good as the thing that can tell it "no." Weak verification plus full autonomy is how you get twenty confident, wrong commits.
Don't just write a loop. Write the one that checks its own work.
Install it once, give it a goal, and watch it work a task, prove it, and commit — then ask before the next one. Read the skill, copy it, or fork it on GitHub.
View the skill on GitHub →Built on the loop-engineering ideas of Boris Cherny (head of Claude Code) and Peter Steinberger, and the Ralph-loop pattern. This is my own packaging of the part they say actually matters — verification.