Always-On Verification: Why CodeLoop Runs After Every Change Without You Asking
Always-On Verification: Why CodeLoop Runs After Every Change Without You Asking
Every QA tool we have used has the same failure mode. You set it up, it works for a week, and then it quietly stops being part of the workflow. The agent edits ten files, you forget to run npm test, and a regression slips through. The tool was technically installed, but practically dormant.
CodeLoop solves this with a deliberate design choice: verification is not a tool the agent reaches for, it is a contract the agent operates inside. After every code change, no exceptions, the loop runs.
This post explains how the always-on pattern works, why it changes the shape of agent-driven development, and how to enable it in under a minute.
The problem with on-demand QA
Almost every developer-facing QA tool is on-demand. Think of npm test, pytest, playwright test, even Bugbot — they all assume *you* will invoke them at the right moment. That assumption breaks for two reasons.
npm test after each one is unreasonable, and batching means you lose the ability to localize regressions.The result is the most common failure mode in agent-driven development: the agent declares the feature complete, the tests have not been run since the third iteration, and now you have to re-test by hand to find out which iteration broke things.
What "always-on" actually means
Always-on verification means the verification step is not optional. After every code change the agent makes, a deterministic process fires that:
The agent is not asked to do this — it is structurally unable to declare "done" without it. If the verifier returns continue_fixing, the agent loops. If it returns ready_for_review with confidence ≥ 94 %, only then can the agent claim completion.
How CodeLoop ships this
The mechanism is intentionally boring: a single rule file that lives in your project's agent context, plus a small MCP server that exposes the verification tools.
In Cursor, the rule file is .cursor/rules/codeloop.mdc and is installed automatically by codeloop init. In Claude Code, it is AGENTS.md at the project root. The rule reads, verbatim:
> After EVERY code change, you MUST call codeloop_verify from the CodeLoop MCP server. If .codeloop/config.json does not exist, call codeloop_init_project FIRST. After verify: diagnose failures with codeloop_diagnose, fix, re-verify until codeloop_gate_check returns ready_for_review with confidence ≥ 94 %. For UI projects: screenshots + video capture are MANDATORY. Never declare a task complete without passing codeloop_gate_check.
That single paragraph is what turns a normal Cursor/Claude Code session into one that cannot ship unverified code. The agent reads it on every turn, and its model card already biases it toward following project rules to the letter.
Why a rule, not a hook
We considered building this as a Cursor hook (onPostEdit) or a git pre-commit hook. Both options were rejected for the same reason: they are bypassable. A hook can be skipped with --no-verify, disabled in settings, or simply not fire if the IDE is configured differently. A rule baked into the agent's context is read every turn, by every agent, on every machine.
The rule pattern also has a side benefit we did not anticipate: it composes with other rules. You can layer your own coding standards on top of the CodeLoop rule, and the agent treats them as a single set of constraints. There is no precedence problem and no plugin order to debug.
What the always-on rule changes in practice
The first time you see always-on in action it feels slow. The agent makes a 5-line change and spends 20 seconds running the verifier. The instinct is to disable it.
A week in, the math reverses. You stop running tests by hand. You stop opening the browser to check screens. You stop asking "did the agent test this?" because the answer is structurally yes. The cumulative time saved on the human side dwarfs the per-iteration cost.
The secondary effect is more interesting: the agent's own quality improves. Knowing that every change will be verified by an external gate, the agent stops emitting "this should work" code and starts emitting code that actually compiles and passes assertions on the first try. There is no incentive to bluff when bluffing fails the gate.
Turning it on
Three steps. Most projects finish in under a minute.
1. Install the CLI globally
npm install -g codeloop
2. Link your agent's CodeLoop account (one-time)
codeloop auth
3. Drop the rule + MCP server into the current project
codeloop init
That writes .cursor/rules/codeloop.mdc (Cursor) or AGENTS.md (Claude Code), registers the MCP server, and creates a default .codeloop/config.json. The very next message you send the agent will trigger the always-on loop.
If you are working in a brand-new repo, that is all. If you have an existing project, codeloop init also writes a baseline so the first verification run has something to diff against.
When always-on is wrong
We are not absolutist about this. There are two cases where always-on hurts:
codeloop pause for the session..codeloop/config.json.For everything else — features, refactors, bug fixes — always-on is the default we wish every QA tool shipped with.