The bottleneck in your agent loop isn't the model. It's the check
Loading...
Loading...
Join JS Mastery Pro to apply what you learned today through real-world builds, weekly challenges, and a community of developers working toward the same goal.
You've probably felt the shift this year. You stopped writing careful prompts and started setting up loops. You type one line, walk away, and come back to finished work: a branch, a few pull requests, tests that ran.
The interesting part isn't just that agents can run longer now. It's that we've started designing systems around them: plan, generate, execute, check, retry, and let them run.
It's real, and it works. But there's a question sitting underneath all of it that doesn't get enough attention, and it decides whether any of that motion was worth anything. When the loop comes back and says it's done, how do you know it's actually right?
Strip a loop down and it's two parts. A generator that produces the work, which is the model, and a verifier that decides whether the work is good enough to keep. That's it. The model proposes, the check disposes: ship it, retry it, or stop.
Here's the part every guide skips. The generator was never the only thing that mattered. Models got cheaper and better at producing work, and they'll happily run a hundred times before lunch. But all that output still has to pass through something that decides whether it's worth keeping.
That's the verifier. And it's the part that's easiest to underbuild.
Automating a loop with a bad check doesn't necessarily save you time. It can produce wrong work faster, unattended, at scale. That's worse than working by hand, because when you're typing every prompt you're at least looking at what comes back.
Set a loop loose with a check that just asks the model "did you do it?" and you've built a machine that can confidently generate slop and stamp it done.
The model is very likely to say done. Done is the model's opinion of its own work, and it's a generous grader.
"I've implemented the feature" is a claim. The feature existing and working is evidence. You needed proof. The model gave you a vibe.
For a lot of agent tasks this is genuinely hard, because there's no clear ground truth to check against. How do you verify "write a good market summary"?
Coding is different. You can run the thing. You can drive the actual feature and watch it do the job, or fail to. You have tests. You have an app that either behaves or doesn't. The ground truth is sitting right there, executable.
Which means for software, a weak check isn't something the world forced on you. It's often a choice. The proof was available and you skipped it.
Take something simple like adding password reset to an existing application. A weak loop might generate the code, run the tests, see green, and declare success.
A stronger loop asks a different question: can a real user request a reset, receive the email, open the link, set a new password, and actually log in with it? That's a check.
The difference is subtle. One verifies the work. The other verifies the outcome.
Most of what people call verification is theater. Re-reading the diff and nodding. Trusting the tests the agent wrote for its own code, which it tuned until they went green. Green tests are not automatically tests that would catch a failure.
Asking the same model that wrote the code whether the code is correct, when the author is usually the least independent judge of its own work.
All three feel like checking. But they don't give you much independent evidence.
There's a good question that cuts straight through it: how would you verify this without reading every line?
If your honest answer is "I'd trust it," you don't have a check. You have hope.
This is the standard I use: a real check needs to be capable of failing for reasons the agent can't simply talk its way out of.
If the agent can change the code, change the tests, run the tests, and then declare success, the loop has no independent source of truth.
A useful verifier isn't there to confirm the agent's story. It's there to contradict it when necessary.
Decide what good and done mean before the loop runs. Not "make it work," which can never be true or false, but something observable: this input gives that output, this flow completes end to end, this edge case is handled.
If you can't say how you'd know it's done, neither can the loop.
Check the running behavior, not the description of it. Drive the real feature against those criteria and watch it pass. The model reporting success is a claim. Watching the app do the thing is evidence.
Leave real failures visible. A check whose instinct is to quietly turn red things green is worse than no check at all. When something is broken, the check has one job: say so, loudly.
For anything that matters, get a second, independent look, and run it on a different model with fresh eyes, so the thing that wrote the code isn't the thing grading its own paper.
And match the proof to the stakes. A throwaway script and a payment flow do not earn the same scrutiny. Deciding how much checking each change is worth is part of the skill, not a step you skip.
The model got good enough to run the loop. What it cannot do is decide what "good" means for your work, or reliably hold that line when the pressure is on.
That judgment, defining the check and refusing to lower it, is the real craft of loop engineering.
The automation is the easy half. The verifier is the job.
This idea is part of the agentic engineering workflow we teach in our Agentic Engineering course. The implementation of the check itself is open on GitHub. The course goes deeper into designing these loops, building skills around them, working with real codebases, and handling what happens when the loop fails.
But the important part isn't the tool or the procedure.
What "done" means for a real feature, how much proof a change has earned, and how to keep that bar from sliding at 1am when the loop says done and you badly want to believe it... that's an engineering judgment.
The procedure is downloadable. The standard is you.
Your agent will always be able to tell you it's finished. Saying done is the easiest thing in the world. The whole game is being able to prove it.
