Keep the engineer in the loop

What breaks when the loop runs well

Run the loop the last essay describes, the one where the agent writes most of the code while you steer and review the pieces that carry the risk, and keep running it. The work goes well: specifications hold, proofs close, artifacts ship. What quietly comes apart is you. One reasonable cycle at a time, your grasp of the system you are shipping thins, and nothing in the work tells you it is happening, until it surfaces as a behaviour you cannot explain.

The engineers I work with put the same words on it. Once the loop has run a while they feel uncomfortable: can they still be accountable for this version of the system, still steer it, still explain it the day it does something nobody predicted? I have run no survey and report no rate. But the answer comes back “no” often enough, from people whose judgement I trust, that I stopped reading it as an individual failing.

This drift matters because the engineer is the one who signs off. A solid verification stack settles correctness against the stated properties, so you do not have to re-derive every guarantee by hand to trust that what ships meets them. Following those arguments still feeds your understanding of the system, but it is not the whole of it. Steering is the part no stack discharges for you: judging whether this is still the right system, where it can go, what the specification quietly fails to say, and, the day it does something nobody predicted, explaining why. And you cannot fall back on your own sense of how well you understand it, because that sense is the first thing to mislead you.¹

Which is why the process itself has to supply what intuition cannot: keep the engineer’s mental model tracking the project closely enough to steer it. I call that the alignment objective, objective and not invariant on purpose, because nothing here measures understanding well enough to prove the property holds; the process pursues it and can fall short. The discipline of pursuing it I call engineer engineering, a name awkward on purpose: the last component of the system is the person, and a person needs engineering too.

My aim is narrow: to make that objective precise enough to work on, and to show something that has started to meet it. The rest of this essay poses it as four concrete problems, shows the experimental tools that begin to answer each, and ends with what is still open. The tools are public; point one at your own next session and tell me what broke. Then the fifth essay runs the whole thing on a real development.

The human is already there, as reviewer

Everything on the ring of the loop the last essay described is common practice by now, under one name or another: onboarding, ambiguity resolution, written specifications, an agent producing changes, checks deciding what ships. The piece in the middle, a model of the person, is the one I could not find.

I went reading the prominent loops for the human’s place in them. Anthropic has you watch, redirect, or step away, and treats “you become the verification loop” as a failure mode to engineer away. Cursor casts you as plan approver and diff reviewer: “the faster the agent works, the more important your review process becomes.” OpenAI asks you to “manually review and validate all agent-generated code.” That division of labour, reviewer, approver, spot-checker, is sound, and it is the one I would pick myself: the human decides, the machine produces.

But look at what review has to mean for that to work. It cannot mean reading every line the agent writes: at the volume these loops run, line-by-line proofreading is the rubber stamp, not the safeguard. The review that keeps you accountable is of the load-bearing things at the moment they are decided: the specification, the design choice that closes off alternatives, the check that failed and what it points at, the diff that touches the core. That is an act of understanding, not of proofreading, and it holds only as long as the person doing it can still read what they approve. Keeping the human labelled “reviewer” does nothing to keep that true. It assumes it.

Kief Morris puts it well: the human belongs on top of the work, setting the goal, auditing the specification, deciding when to ship, not in its path as a bottleneck. I agree, and I would add that standing on top only works if you can still see.

In the loops I went looking through, none carried a mechanism that keeps the engineer’s understanding current. That is a claim about a search, not about the whole field. In mid-2025 I looked through the vendor loops named above, the practitioner discourse around them, and the research neighbours I could reach, for anything that models what the human knows and spends words accordingly. I found none. The sources are in the footnote.² Point me at one published loop that carries this and the claim is wrong, which is the outcome I would most like.

There is a close ancestor in programming-language studies. Peter Naur argued in 1985 that what programmers build is a theory of the program: a grasp of how its text maps to the world and why it is shaped as it is. That theory is the part documentation cannot hand over. A team that has lost it can still run the program and still edit the text, but can no longer say with confidence what a change will mean, and that is the sense in which he calls the program dead. Agents now produce so much source so fast that they put us there every day.

Others are starting to name the same gap, which is how I know it is not a private complaint. Margaret-Anne Storey calls it cognitive debt, debt that sits in developers’ minds rather than in the code, piling up while the AI-generated code stays locally clean. Birgitta Böckeler poses “how can I get a quick overview of what AI did while I went to get a coffee?” as an open question and proposes no mechanism. The nearest academic neighbour, ToM-SWE, models the user so the agent can follow the engineer’s goals, useful, and pointing the arrow one way only. Engineer engineering needs it reversed: the process maintaining what the engineer understands.

The four problems

Accept the objective and the work turns concrete. Keeping an engineer’s understanding current, against a project an agent is changing faster than any human reads, runs into four problems. None is solved. For each there is an experimental tool that starts to answer it, and a residual I gather at the end.

You cannot feel the drift

The instrument that would warn you, your own read on how well you understand the system, is the first one to fail. So the process cannot ask you how much you understand and believe the answer; it has to watch what you do. The persistent model at the centre of this discipline is therefore evidence-based: it records which concepts you have demonstrated command of, which you have merely encountered, which are still foreign, and it moves a concept only on an observation, a question you asked, a correction you made, a use that was yours and unprompted, never on what you say about yourself. Every observation is fallible and dated. A question is weak evidence a concept is not yet held, though it might be probing an edge; correct use is evidence it is held, though use can be copied or locally lucky. So an observation nudges the state by a step and carries what was seen and when, and it decays as it ages. laconic, a Claude plugin, is the implementation. What it does not give you is a trustworthy measure of understanding: a quiz answer is evidence, not proof, and I will not pretend the state is more than a calibrated guess.

Attention is scarce, and generic explanation wastes it

Agent output is effectively unlimited; the attention that turns output into understanding is fixed and small. The default behaviour of agents makes this worse: they explain everything, to everyone, identically, at length. I spent years teaching, and if that time settled one thing, it is that explanation only lands where a model of the student aims it. Effective teaching starts from what the student already holds, spends words only where understanding is absent, and checks that it transferred rather than assuming it. That is exactly the requirement here, which is why the model earns its keep at output time: everything the process says to you passes through it, explanation lands at the boundary of what you already hold, and what the model records as held is not explained again. It cannot suppress every redundant word, but the generic flood that caused the drift, the same explanation sent to everyone at length, is what it removes. This is the other half of laconic: the model it maintains from evidence is also the filter on every sentence it sends. The open part is a theory of dosage: how much explanation is enough for which decision, I can still only eyeball.

Understanding goes stale as the project moves

A model built once is wrong within days, because the project it is a model of keeps changing. So it has to be maintained where the work happens, at two points in the loop, deliberately its two ends.

Before anything is decided, an onboarding step. What a briefing has to decide is not what is true about the system, which is unbounded, but what this engineer does not yet hold and will need in order to steer the coming work. So it reads the model, finds the load-bearing concepts sitting below demonstrated command, teaches exactly those, and ends with a short quiz whose answers fold back into the model as evidence. Only then does ambiguity resolution start, because a question put to an engineer who lacks the concept behind it yields a confident answer and a wrong system. inbrief runs this step, and forebrief sits at ambiguity resolution itself, reading the model before it turns a decision into the two or three questions whose answers actually change what gets built.

After a cycle, the alignment checkpoint: what changed that you have not yet integrated? A short, calibrated interaction closes the gap, and the objective is re-established. backbrief runs it. After every cycle is the target; the honest rate is lower, and the fifth essay is candid about a run where the first checkpoint came eleven cycles in, by which point a real misconception had grown. That gap between the target cadence and the practised one is itself a measurement: skipping a checkpoint fails silently, accumulates, and charges interest at the worst moment, mid-incident or mid-decision, when steering is suddenly needed and the map is months old. Whether maintaining the model this way actually keeps understanding higher than not doing so is the central claim, and the one still without evidence.

The record is sensitive, and if it is watched it becomes worthless

A persistent record of what a named person does not yet understand is not a neutral artifact, and the design has to answer for it. The commitment that makes the rest work is that it feeds no evaluation. An engineer who suspects that the record of what they do not grasp is read by whoever rates their work will start performing for it, and a model of performances is worth nothing to the person it is meant to serve. So the model belongs to the engineer: plain files under your own home directory, one concept per entry with the observation that moved it, versioned in a git repository you can revert and browse through a console bound to localhost only, with no remote and no telemetry unless you turn them on. You can read all of it, correct what it underrates, delete a bad guess, and a correction outranks the evidence that produced it; entries decay when they stop being exercised, because knowledge does. What this does not solve is scale. laconic’s own security note is candid that the real boundary is the security of the account the files sit under, and a record of what a named engineer struggles with is sensitive the moment it persists across jobs or is read by anything with access to that account. I run it for one subject, myself, and how a team would keep such a thing without turning it into surveillance I have not solved.

What exists today

None of this is a product, and all of it is public and experimental. laconic is the persistent model and the calibrated communication, a Claude Code plugin that injects the communication policy before the first token of a session and promotes no concept without evidence you can inspect; its documentation claims only that it cuts the measured cost of explaining at the wrong level, not that it improves your comprehension. agentic-loop-kit packages the process side, the onboarding phase and the checkpoint cadence as first-class steps rather than good intentions. inbrief, forebrief and backbrief, placed in the loop above, live together in one repository. Writing this series with laconic running has been a small recursive experiment, the assistant maintaining a model of the author while the author writes about assistants maintaining models of engineers.

What is still open

Read the four sections above as implemented behaviour, not as proof the discipline works. The tools do maintain the model, calibrate what they say, and run the phases. Whether doing so keeps an engineer’s understanding higher than not doing so is a separate claim, and the one with no evidence yet. Four things are missing: a trustworthy measure of understanding, rather than the calibrated guess a quiz gives; a theory of dosage, how much alignment is enough for which decision; a way to run this at team scale without turning the model into surveillance; and any independent replication, since to date the laboratory has a single subject.

A few weeks ago, watching an agent pile up work I had stopped understanding, I was the stick figure with the question mark. I still run agents at full speed, and the pile is taller than ever; but the loop briefs me before it asks, checks what it builds, and catches me up after each cycle, and I sign off with a calm I had lost. One engineer, a few weeks, no control group: that is the honest size of the evidence. What would change my mind is stated as plainly: engineers holding steering-grade understanding through months of agent-heavy work with no deliberate alignment mechanism, which would be excellent news and which I have not met; or alignment overhead that costs more attention than it saves, which is a real risk the artifacts have to be measured against.

The worked recording is One lap of the loop, which walks one full development cycle by cycle, checkpoint and misconception included. After it come the three remaining disciplines, software engineering, knowledge engineering and harness engineering, one essay each.

Appendix