Verification Belongs Inside the Agent Loop

Boris Cherny’s #1 piece of advice for working with Claude Code: use auto mode .

Agents are no longer built to stop. They don’t want feedback. They want to work in a loop of read, write, run, edit, read, run, push. Move on to the next task in the markdown doc.

So, where is testing? Where is verification? Outside this loop, in the same place it has always been: CI. But by that point, the agent has already made every decision that mattered on what to build, how to structure it, and where the complexity goes.

With an agent moving at this speed, a gate firing after the work is done and the path locked in shows up too late to change anything.

The quality gate is in the wrong place

This is the simple problem. This is the basic SDLC:

(Source: Devops.com )

The sequence, for humans, goes:

1. Write a small piece of code
2. Debug it, finding the errors
3. Build it locally, confirming it compiles
4. Push the branch and open a pull request
5. Tests run as part of the CI process before review
6. …all the other DevOps work

Points 1 through 4 are the inner loop, happening on the developer's local machine. Everything after the push is remote and no longer part of the software developer's actual coding process. This was fine for humans, running a slower cycle, but it simply doesn’t work for agents. They need the feedback in their inner loop.

The inner loop of the agentic developer lifecycle (the ADLC?) optimizes entirely for speed. It isn’t that quality is an afterthought; it isn’t a thought at all in this human-derived process.

The velocity bump leaves debt behind

Velocity begets slop. So much so, you can measure it.

A 2026 study from Carnegie Mellon tracked hundreds of open-source GitHub projects before and after they adopted an agentic coding assistant, comparing each against matched projects that never adopted one.

The speed gain was real and large, and it didn't last. Lines added jumped sharply in the first month, then faded back to baseline within a couple of months. The quality cost behaved differently. Static analysis warnings rose around 30%, and code complexity rose around 41%, and neither came back down.

(Source: Speed at the Cost of Quality )

The mechanism is the part worth sitting with. Their models show accumulated warnings and complexity drag down future velocity, so the early speed quietly finances a slowdown that arrives later. Complexity climbed even after they controlled for sheer volume, which means the generated code was more complex per line, not just more of it.

When output accelerates, and verification stays at the same pace, production runs ahead while quality slips, and the slippage taxes production down the line. That's the debt ratchet, and each turn makes the next turn slower.

Verification has to feed the next decision

The fix is to move verification to a point where it can change what the agent does next while the agent is still working.

The loop you want looks like this:

1. Plan the change and its scope.
2. Make the edit.
3. Run tests and static analysis against what just changed.
4. Read the results, including warnings and complexity, not just pass/fail.
5. Simplify or refactor when the signals show quality sliding.
6. Decide whether to keep going or stop and consolidate.

The difference from CI is the direction the result flows.

In a gate, the verdict points outward, at a human or a merge queue. In a loop, it points back into the agent's next move. A complexity spike at step 3 should trigger step 5 before the agent starts the next feature.

This is also where the study's authors land. They argue quality assurance has to become a first-class concern inside agentic tools, not a stage bolted on at the end. Their two concepts:

• An assistant that proposes tests as it writes the code, calls out complexity the moment it creeps in, and pushes a refactor when the signals trend the wrong way.
• Self-throttling that would allow an agent to quiet its own suggestions once a project's complexity or debt crosses a healthy threshold, prompting you to consolidate before it generates more code.

They want the assistant to be a “pair programmer for quality, not just velocity.” Every one of those behaviors is a verification signal that serves as input to the next action, rather than a report filed after the work is done.

Behavior needs to be verified in the loop

If verification is in the loop, what should the agent actually check? The easy answer, and the one the research measures, is the shape of the code. Does it compile? Do the unit tests pass? Is the linter quiet? Is complexity climbing? Those signals are worth having, but they aren’t what make a product a product.

A codebase can clear all of them and still be wrong. When the agent writes the unit test and then the code to satisfy it, both go green while the feature does the wrong thing, or nothing a real user would recognize as working. The agent is checking its own intent against itself.

The harder question is behavioral. When someone actually uses this, does the right thing happen? You can't answer that by reading the diff. You have to run the app and watch what it does.

The loop needs both kinds of checks, and they answer different questions:

• Structural checks ask whether the code is internally sound: compile, lint, unit tests, and complexity. The agent can write and pass these on its own.
• Behavioral checks ask whether the app does the right thing in front of a user. That answer comes from driving the running app, not from inspecting the source.

The behavioral target can't come from the agent. It has to come from you and be decided before the agent starts building. Write down what "working" means in plain language, the outcome you expect rather than the code that produces it: after checkout, a confirmation banner shows the new order ID. That sentence is the truth the agent builds toward.

Momentic works this way. You describe the expected behavior in regular language, and an agent drives the real app, an actual browser or build, to check whether it holds. The check is evaluated against what's on the screen the way a person would read it, so it passes because the app works, not because a literal string happened to match.

Two things make this the signal the loop wants:

• You own the definition of done. The agent can make its own unit tests pass, but a behavioral check is harder to fake, because a human wrote it and it describes the outcome rather than the implementation. There's no test the agent can quietly rewrite to turn the check green.
• It changes the next move. A failed behavioral check doesn't just say a string didn't match. It says the app didn't do what you asked, which is exactly the signal that should send the agent back to fix the work before it starts the next thing.

That's the verification that belongs inside the loop. Static analysis keeps the code clean. A behavioral truth that a human wrote keeps the agent pointed at the thing you actually asked for.

Move the checking into the loop

Agents work in a tight loop: read, write, run, edit, move on. Every decision that determines quality occurs within that loop while the agent is still running. So that's where the checking has to happen, too, close enough to the work that the result can change what the agent does next.

What runs there are two kinds of checks. Structural ones keep the agent from piling up complexity it can't dig out of later. A behavioral truth, written by a human in plain language, tells whether it built the thing you asked for or just something that compiles. Both run while the agent works, and both change the next move instead of grading the last one.

The research already showed the cost of getting this wrong. Speed with no verification keeping pace buys a fast month and a slower year, the debt ratchet tightening one pass at a time. The agents won't slow down, and you wouldn't want them to. Give the loop something to check against on every pass, and the speed stops coming at the cost of quality.