Close the Loop

I recently rediscovered this while rebuilding this website.

The agent changed the source and committed it. The static-site build passed. The deployment completed.

The image on the actual mobile site was broken.

The uploaded image was corrupted, but none of the intermediate checks looked at the user-visible result. They established that source could build and deploy, then those successes were treated as evidence for a different claim: that the page worked.

The requirement did not live in Hugo. It was that a person opening the site on a phone should see the right page.

So verification had to happen on the deployed domain, in a browser, at the relevant viewport.

That leads to a rule I use aggressively now: verify at the layer where the requirement exists.

If the requirement is visual, inspect the rendering. If it is an API contract, exercise the API. If it is a deployed service, observe the deployed service. If it is a data pipeline, check the resulting data.

Intermediate checks are useful. They establish narrower claims.

This changed how I think about specification.

Before writing code, I increasingly want to know what done means, what could create a false green, what signal we can observe while work is underway, how expensive that signal is, and what fallback exists when there is no cheap automated check.

A final acceptance test tells you whether you arrived. A feedback loop tells you whether you are still driving in the right direction.

I eventually made this explicit in my Socrates tooling. Earlier versions concentrated on end-state validation. Later versions required a Feedback Loop Design: a signal, its cost and cadence, and a fallback when no fast automated check exists.²

That change came from watching execution discover too late that it had no useful way to tell whether it was making progress.

The verification path is part of the design.

Tests are the obvious feedback mechanism for code. But a test harness can itself be wrong.

A selector can match the wrong element. A mock can hide a disconnected integration. A regression test can be green because it was never wired into the suite.

For a new or uncertain harness, I want to deliberately break the relevant behavior, confirm the signal turns red, restore the implementation, and confirm green.³

The point is not ritualistic TDD. It is to demonstrate that the verifier can detect the failure it claims to detect.

The same principle applies outside tests. If a browser check is supposed to catch horizontal overflow, create overflow and make sure it catches it. If a policy gate claims to prevent a class of writes, try the prohibited write in an isolated environment.

A signal is useful only if it discriminates between success and failure.

There is a temptation with AI to construct increasingly capable monoliths: more tools, more context, more rules, more responsibility concentrated in the agent.

That is not how I generally like to build software.

The Unix instinct is to decompose: narrow jobs, explicit interfaces, specialized tools, inspectable behavior. My own Constitution for Claude tooling carries that forward.⁴

So I increasingly put formatters, validators, tests, browser checks, and policy enforcement outside the model’s reasoning. The model calls those tools, reads their results, and handles the parts they cannot settle.

The interesting direction is not necessarily a smarter monolith. It is carving deterministic pieces out of the agent until the model is concentrating on work that genuinely requires judgment.

I learned this one empirically.

I had a rule that forked agents should not write files under certain circumstances. The rule was clear. An agent violated it.

I strengthened the instruction. It happened again. I documented the failure. It happened again, including immediately after an agent had read the history explaining that exact failure.⁷

At that point the wording was no longer the useful place to invest. The boundary belonged in the harness.

This is a systems-design lesson that predates AI. Policy and mechanism are different things. If correctness requires a model to remember an instruction at the right time, what you have is a preference, not an invariant.

One of my newer tools makes the distinction explicit.

I have a small bug-and-feature dispatcher for a scoped set of repositories. An AI worker receives the task, investigates it, writes the change, and adds a test.

But its claim that it succeeded is not evidence for the merge decision.

A separate script inspects the worktree. It reruns the test suite, checks whether the diff includes a test file, and flags changes to sensitive paths. Independent code review remains a judgment step. The dispatcher combines that review with the mechanical results instead of trusting the worker’s completion message.⁸

The current checks are useful but not omniscient. Touching a test file does not prove meaningful coverage, and a passing suite does not prove the tests measure the right requirement.⁹

That boundary is the point: conventional software obtains observations that conventional software can obtain consistently; the model handles interpretation and judgment around them.

There is an opposite failure mode.

At one point I added a hard gate requiring an independent high-capability model to critique every plan before Claude could exit plan mode.

It also fired for small, obvious, low-risk plans where the second review added little. I removed the universal gate and made additional critique contextual instead.⁷

The lesson is not “turn everything into hooks.” Mechanize invariants. Preserve judgment for decisions that depend on context, risk, ambiguity, or competing goals.

There are really two timescales here.

The execution loop is act → observe → correct → verify.

The learning loop is failure → reflection → lesson → skill, rule, or mechanism → future behavior.

My tooling has gradually accumulated both. Incidents become lessons. Repeated lessons become operating rules. Repeated procedures become skills. Mechanically checkable boundaries become candidates for enforcement.⁴

That is the part of AI-assisted engineering I find most interesting. A model can help discover which parts of our own reasoning should eventually stop being model work.

When I build an AI-assisted workflow now, I want to know the desired state, the observation that tells us whether we are getting closer, what could create a false green, and which parts of the procedure still require judgment.

Then I want the repeated mechanical parts to migrate outward into ordinary software.

The goal is not an AI that never makes mistakes. It is a system where mistakes become observations, observations improve the process, and repeated process eventually becomes mechanism.