Keep the engineer in the loop

What breaks when the loop runs well

The engineers I work with keep telling me the same thing once such a loop has run: they feel uncomfortable. Can they still be accountable for this version of the system? Can they still steer it, explain an unexpected behaviour, name its limits? I have run no survey and I am not reporting a rate. But the answer comes back no often enough, from people whose judgement I trust, that I stopped reading it as an individual failing.

Here is the failure, concretely. Months of agent-heavy development on real projects, and the work itself went well: specifications held, proofs closed, artifacts shipped. What degraded was me. Agent output is abundant, redundant and generically addressed, so that under the flood my understanding of what I was shipping thinned without my noticing. And noticing is exactly where the published evidence gives no comfort: METR’s 2025 randomised trial found experienced developers running 19% slower with AI assistance while estimating themselves faster. The trial measured time, not understanding, so I take it as an analogy, not a finding about comprehension. Experienced engineers misread something as checkable as their own speed. I am not willing to trust their unaided sense of their own understanding either, and I would rather a process not lean on that feeling. Treat it as the reason I look for harder evidence, not as evidence itself.

Nothing in that story is a mistake. Every cycle was reasonable, every review was done, and the drift is what accumulated between them. It matters because the engineer is the accountable person in the room, the one who signs off. With a reliable formal-verification stack, machines discharge correctness against the stated properties, so nobody needs the engineer’s understanding to re-derive it. It is needed to steer: to judge whether the system is still the right system, where it can evolve, which risks are accumulating, what the specification silently fails to say, and, the day the thing does something nobody predicted, to explain why it did.

So here is the claim: the development process must work to keep the engineer’s mental model tracking the project well enough to steer it. I call that the alignment objective, objective rather than invariant on purpose, because nothing here measures understanding well enough to prove the property holds; the process pursues it and can fall short, which the fifth essay shows it doing. The discipline of pursuing it I call engineer engineering, a name awkward on purpose: the remaining component of the system is the person, and it needs engineering too.

What the prominent loops leave out

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 is the one I could not find.

I went reading the prominent loops, looking for the human. Anthropic has you watch, redirect, or step away, while treating “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”. Reviewer, approver, spot-checker. That division of labour is sound, and it is the one I would pick myself: the human decides, the machine produces. It holds as long as the person approving can still read what they approve. None of these documents says how that stays true after the twentieth cycle.

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. But standing on top only works if you can still see. In the loops I went looking through, none carries 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.

Peter Naur got there in 1985. His claim is subtler than a slogan. 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 produce source far faster than any theory is rebuilt by accident.

Why this is a teaching problem

Re-aligning a head with a project is teaching, not reporting. And seen as teaching, the default behaviour of agents is dreadful in an instructive way: they explain everything, to everyone, identically, at length. I spent years teaching at university, and if that time established 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 verifies transfer instead of assuming it.

Which sets the requirement the rest of this essay has to meet. To explain at the right level, something has to know what this person already holds, and keep knowing it as the project moves.

The mechanism

A persistent model of the engineer: which concepts they have demonstrated command of, which they have merely encountered, which are foreign. Kept with the person rather than the repository, so it carries from one project to the next, because understanding belongs to the person and not to any one codebase.

Evidence discipline: the model updates on performance, and every observation is fallible and dated. A question asked is weak evidence a concept is not yet held, though a question can also be verifying a detail or probing an edge; correct unprompted use is evidence it is held, though use can be copied, lucky or locally right without transferring. So an observation moves a concept’s state by a step and carries what was seen and when, rather than flipping a switch, and it decays as it ages. Never self-assessment, which the analogy above gives me reason to distrust.

Calibrated communication: everything the process says to the engineer passes through the model, so explanation lands at the boundary of what they hold, and the process stops re-explaining what the model already records as held. It cannot rule out every redundant word, but the generic flood that caused the problem, the same explanation sent to everyone at length, is exactly what it suppresses.

Do not confuse that model with the project’s rules or the team’s procedures, which I did at first. Those belong to the repository and are the same for everyone; this belongs to a person, and two engineers on the same codebase have different ones.

The budget under management is the engineer’s attention. Agent output is effectively unlimited. The attention that turns output into understanding is fixed and small. Every sentence the process sends an engineer spends from that budget, so redundancy is not a style problem, it is resource mismanagement.

Others are starting to name the same gap, which is how I know it is real and not a private complaint. Margaret-Anne Storey calls it cognitive debt: debt that resides in developers’ minds rather than in the code, accumulating while 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. And the nearest academic neighbour, ToM-SWE, models the user so the agent understands the engineer’s goals and preferences; useful, and pointing the arrow one way only. Engineer engineering needs the arrow reversed as well: the process maintaining what the engineer understands.

Where it plugs into the loop

Two places in the loop, deliberately at its two ends.

Before anything is decided, an onboarding step. Consider what such a briefing has to decide: 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 engineer’s model, finds the load-bearing concepts that sit below demonstrated command, teaches exactly those, and ends with a short quiz whose answers are performance evidence folded back into the model. Only then does ambiguity resolution start, because a question posed to an engineer who lacks the concept behind it produces a confident answer and a wrong system. Everything the loop says afterwards is pitched at the level the model establishes.

After a cycle, the alignment checkpoint: what changed that the engineer has not yet integrated into their mental model? A short, calibrated interaction closes the gap, the engineer catches up, the objective is re-established. After every cycle is the target; the honest observed rate is lower, and the fifth essay is candid about a run where the first checkpoint came eleven cycles in and a real misconception had grown in the meantime. That gap between the target cadence and the practised one is itself the measurement: skipping checkpoints does not fail loudly, it accumulates, and you pay the interest at the worst moment, mid-incident or mid-decision, when steering is suddenly required and the map is months old.

Who owns the model

A persistent record of what a person does not yet understand is not a neutral artifact, and I would rather state how I run it than have that stated for me. What follows is how I run it for myself; it is not a deployment I am recommending to a team, for reasons this section ends on.

It belongs to the engineer: plain files under my own home directory, readable in full at any moment, deleted with rm. The schema is deliberately boring, one concept per entry with the observation that moved it, so that nothing is inferred further than what was seen. I can correct or remove any entry, and a correction outranks the evidence that produced it. Entries decay when they stop being exercised, because knowledge does. It serves my steering and feeds no evaluation of me. That line is what keeps it honest. A record of what I have not grasped, read by whoever rates my work, would make me perform for it, and a model of performances is worth nothing.

That governance is enough for one person on their own machine and no further. A record of what a named engineer struggles with is sensitive. The moment it persists across jobs, or is read by anything beyond the person it names, questions open that rm does not answer. Backups copy it elsewhere. Any tool with filesystem access could read it. Entries built on one employer’s code could follow the person to the next. A false or planted entry has nobody’s sign-off. I have not solved those, so I am not proposing this to a team or across employers. It is a local experiment with one subject. The claim I stand behind is only that maintaining such a model is worth doing, not that this is how a team should store one.

What exists today

laconic, a Claude Code plugin, implements the persistent engineer model and the calibrated communication: per-concept knowledge states with recorded evidence, verbosity that adapts to what the reader has demonstrated, and a recording discipline that forbids invented observations. Writing this series with it 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.

agentic-loop-kit, the methodology kit behind this series, integrates the process side: the onboarding phase before ambiguity resolution and the checkpoint cadence, as first-class phases rather than good intentions.

Three interfaces sit on top of the model, one per moment where the loop talks to a person. inbrief runs the onboarding: it reads the project and the model, and teaches the difference rather than the manual. backbrief runs the checkpoint after a cycle: what changed that you have not integrated, in the order that matters to you. forebrief runs ahead of a decision: it turns the ambiguity into the two or three questions whose answers actually change what gets built, and records what you decided.

What would prove it wrong

Read that section as implemented behaviour, not as proof it works: the tools do maintain the model, calibrate what they say, and run the phases. Whether doing so actually keeps an engineer’s understanding higher than not doing so is a separate claim, and it is the one with no evidence yet. What does not exist is the hard part: a trustworthy measure of understanding (quiz performance is evidence, not proof), a theory of how much alignment is enough for which decisions, and any independent replication at team scale, since to date the discipline’s laboratory has one 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 my understanding up after every 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 today. What would change my mind is stated as plainly: engineers sustaining steering-grade understanding through months of agent-heavy work with no deliberate alignment mechanism, or alignment overhead that costs more attention than it saves. The first would be excellent news, and I have not met it. The second is a real risk, and the artifacts have to be measured against it.

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

Appendix