The loop I run

The previous essay ended on a claim with a hole in it: iterating without a reliable check buys you nothing. So where does a reliable check come from?

The question splits in two, and only one half can be settled mechanically. Does the implementation satisfy the stated criterion? Inside the boundary where the criterion is formal, a machine can answer, though not with one instrument: a type checker settles a typing judgement, property tests exercise generated cases, a proof checker discharges a proposition under stated assumptions. Each is decisive about a different thing, and each has its own way of being fooled. Is the criterion what people actually need? No checker answers that. It stays human judgement, revisable, fed by domain knowledge, examples and what production says afterwards.

So the criterion is not found, it is authored, and authoring it is most of what the loop below does. A reliable check is the formal half resting on the human one, which is why the human half never stops being somebody’s job. Here is the whole loop in one picture.

Read it clockwise. A demand arrives; the loop onboards the engineer, resolves the ambiguity into decisions, writes them down as a specification and a knowledge base, lets the agent produce a change, and runs the harness against what comes out. What passes ships, what fails feeds back. At the centre sits a persistent model of the engineer’s knowledge, consulted and updated by four of the five activities, so whoever signs off still understands what they are signing.

That is the shape, and a shape is all a picture gives you. It cannot show the decisions inside each station: what gets written down, when a human is required, who owns a failure, when to stop. If the shape was all you came for, the tools are at the end.

Where the check comes from

Two things have to happen before a line of code exists: someone has to understand the domain well enough to have an opinion, and that opinion has to be written down precisely enough to check. So the loop starts with the engineer, not with the writing. Write first and the document records the agent’s guess, not an engineer’s judgement. An onboarding step aligns the humans and the agent on the domain: what the engineer masters, what they hold vaguely, which assumptions differ. What gets explained, and at what depth, is calibrated against a persistent model of their knowledge, since the budget spent here is attention. That mechanism is the next essay, and inbrief is the tool that runs this step.

Then the ambiguity is resolved: the vague demand turns into precise questions, the answers into a specification the harness can check. There can be fifty of them, and fifty is a good sign: each is a decision that would otherwise be taken for you, quietly, by whoever writes the code. forebrief is the interface I use to put those questions to the engineer and preserve the decisions. One step here is easy to skip and expensive to skip, sizing: a demand that is not one bounded change gets cut into changes that are, each with its own acceptance criteria, before any reaches the agent.

What that produces is the knowledge base: specifications, properties, invariants, acceptance criteria and the development plan, written once for the agent to read, so nothing the team settled lives only in a chat scroll.

This arc felt slow the first time and has repaid itself since, because it is where the checks get their content. You can always write a regression test from what the code happens to do; nobody can check an intention nobody articulated.

One cycle

Only then do the implementation loops start. Hand the specification, the codebase and the goal to the agent, then run the harness: deterministic checks, auditors, a human for whatever escapes. Not a human on every merge request and every line; a human wherever the checks stop being conclusive.

The harness is what lets you sleep after shipping: everything that can say no without me in the room, from a type checker up to a proof obligation, plus an auditor for what none of them can express. Auditors get a rule of their own, flag what affects correctness or a stated requirement and stay quiet otherwise, because one that comments on everything trains you to skip its comments.

Not every change deserves that ceremony. Rename a function, correct an error message, bump a dependency: I write one sentence, the agent runs, the harness decides. No layer was skipped: for a change that small the sentence is the whole specification, and the checks covering it were written down long ago. The knowledge work waits for a demand that needs more than a sentence.

If the output passes, the release policy for that change class decides whether it ships: which checks were required, whether a human signs off, the risk class, the boundary being trusted, what watches it in production, and how to roll back. For a rename that is a formality; for a change to the part where being wrong is silent it is not. Passing is a precondition, not the decision, and the fifth essay is a case where every check was green and the product was still wrong.

When it fails

If it fails, the question is not what broke but who owns it, since “the agent produced nonsense” is a symptom rather than an answer. I go down this list looking for every line that explains the failure, not just the first, because a failure can have more than one owner and the interesting ones usually do:

• Generation variance, when inputs and criterion were adequate and this run came out badly: run it again.
• The codebase, when structure, interfaces or tools made the wrong thing easy to write, or the right thing difficult.
• The specification, when the intent was ambiguous, incomplete or wrong.
• The harness, when the failure was real and nothing caught it.
• My own understanding, when I cannot tell which of those it was, which is the failure the next essay is about.

Generation variance is where the two ways of repeating meet, the ones the previous essay left undecided: sample candidates and keep whichever survives, or repair one on feedback. I repair, under conditions rather than as a general rule. The change has to be small, the checks have to point at a place rather than just saying no, and the repair has to keep what passed. When a check gives a bare verdict, or the second repair breaks what the first fixed, I stop repairing and either resample or go back to the specification.

Routing says where a fix goes. A different decision says whether to go round again at all, and forgetting it is how a loop runs all night for no result. Two clocks run here: a cycle is one turn of the whole ring, from a demand to something shipped, and an iteration is one re-run of the agent inside a cycle, the Ralph loop. When iterations stop moving the checks, and especially when they keep failing the same one the same way, stop. Leave the inner loop and change the strategy: the same repeated failure can indict the model, the tooling, the environment, the decomposition, the feedback, the specification or the demand, and which one is itself a diagnosis. The repeated failure class is the signal; the count is only how you notice it.

Keeping the engineer in it

After each cycle, an alignment checkpoint: what changed that the engineer has not yet integrated? The objective it serves is that the mental model still tracks the project well enough to steer it. That minute is my favourite of the cycle, the one where the project stops being a stranger.

Steal that piece first: you can run it by hand tonight. Ask the question at the end of your next session and watch for the answer that surprises you, because the useful artifact is not the length of the reply but the thing you did not know and correct on the spot. If nothing surprises you, that is a reading too: a small cycle and a lapsed attention look identical from the inside.

It is not the discipline. Whether a criterion matches the need is not decided by any checker, but it is not undecidable either: a human stays accountable for it, and tests with users, worked examples, experiments and production evidence all check the alignment without settling it once and for all. How to measure what an engineer holds, how much alignment a decision needs, and what it costs at team scale are all open, and a model per person raises privacy, ownership, access and departure questions that naming owners does not answer. I draw one engineer because that is how I run it, and the next essay is the one I find hardest to write.

What comes back

The change meets the users, the load and the data no specification described, and what it does there returns as the next demand. This loop assumes, rather than replaces, the practices that keep a deploy low-risk and feedback short: continuous delivery, monitoring and observability and working in small batches, each measured on its own by DORA. A rollback that works is my own requirement on top, since the stop rule is worth little when leaving a bad direction is expensive.

A production defect comes through a second door, better dressed than a feature request. It arrives well when it carries a reproduction and the behaviours that must not change while it is fixed, and those become specification before anything is repaired. Often it arrives with neither, and then producing the reproduction is itself the first knowledge task, the one that turns “it sometimes breaks” into something a check can hold.

Each new piece of work re-enters through onboarding, usually shorter because the model persisted, though a genuinely new area or a model gone stale can make it longer instead. Over a run of related work the loop amortises its engineer.

And on the slowest clock, the loop itself comes back for inspection. Is the harness still auditable, or has it become its own engineering problem? Where would an unknown-unknown enter? A process nobody questions converges fast to the wrong place.

What it buys, and what it does not

What this buys is not only speed. Decisions that used to be one-way doors become reversible, at a cost once reserved for sketches, so more of the work becomes exploration, as long as whoever explores has a map. The equal-risk framing holds only where the change really is reversible: an irreversible migration, a security exposure, a legal or external commitment, or an effect that surfaces months later is not a sketch, and the loop’s cheapness does not make it one.

What stays when the agent is replaced is the specification, the knowledge base, the harness and the engineer’s calibrated understanding. On my projects those four have carried value into later demands more reliably than any patch or any tuning aimed at one model, which is the hypothesis this series is really testing. Swapping the agent has been my cheapest move so far, and it stays cheap only if the loop avoids assuming the model of the month.

It does not decide what the system should do, only makes that decision explicit and checkable, and it does not make the choice of model irrelevant, only less structural. It also has no evidence at team scale: all of this is young, I am the loop’s first user, and it is a few weeks old.

What you can take today

The ring’s zone labels place the four disciplines it leans on: software engineering where the agent reads and writes code, knowledge engineering where intent becomes checkable, harness engineering where the checks and the runtime live, and engineer engineering at the centre. An essay each will follow.

I did not draw this diagram after the fact. It runs on tools, all experimental, to use as they are or raid for parts:

• agentic-loop-kit, the methodology kit I use: it sets up the loop described here and enforces the process rather than describing it.
• laconic, a Claude Code plugin that maintains a model of what the engineer knows and uses it to say less.
• three interfaces for engineer engineering: inbrief onboards you onto a project, its knowledge base and its harness; backbrief realigns your model after a cycle; forebrief clears ambiguity before deciding, while it is still cheap.
• rocqeteer, certified, efficient programs with Rocq and OCaml; in loop terms, how the harness gets its strongest check.

Every one needs polish. If you try one, tell me what broke: issues, pull requests, and a plain “this made no sense to me” all welcome. My TezDev talk Stop pedaling: First principles for spec-driven agentic development walks the same loop on worked examples, minus the engineer at the centre. Video, twenty minutes, or the slides.

Keep the engineer in the loop takes the centre of this diagram, the part no other loop I could find carries. One lap of the loop then walks a full development cycle by cycle, so none of this stays a description, and one essay per discipline follows.

Appendix