The human loop is the one nobody is engineering | Kahtaf Alam
Back to blog
Jul 9, 2026<br>•11 min read
The human loop is the one nobody is engineering
Peter Steinberger’s post is now the slogan of the moment.
Peter Steinberger@steipete
Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore.<br>You should be designing loops that prompt your agents.
Jun 7, 2026 · View on X
The idea is real. A loop can wake an agent on a schedule, find work, hand it off, run checks, save state, and decide what happens next. Anthropic’s Claude Code guide describes turn-based, goal-based, time-based, and proactive loops. OpenAI’s agent-improvement example connects traces, feedback, evals, and an implementation handoff into a repeatable cycle.
In much of the current conversation, the interesting engineering still sits on the machine side of the human–machine boundary.
What wakes the agent? How many subagents can it spawn? Does it use worktrees? Which model judges the goal? What is the token budget?
All good questions. Too often, the loop then emits twelve PRs, each with a green test run and a friendly summary, and the human side of the system is: “please review.” The missing artifact is a review packet that states the change, the evidence, the gaps, and the decision a person actually needs to make.
That is not a review loop. It is an inbox.
The hard problem is not merely letting an agent work unattended. It is designing the moment when a human can still understand what happened, catch the thing the loop missed, and make a decision that means something.
“Human in the loop” is not a design
People reach for “human in the loop” as if it closes the safety argument. It does not.
A human can be technically in the loop while functionally absent. Give someone fifty opaque agent reports, an unfamiliar diff, and a green checkmark from a test suite they did not write. Put an Approve button at the bottom. You have not added meaningful oversight. You have created a rubber stamp with a person’s name on it.
The difference matters because agent loops change the shape of failure. The obvious failure is a runaway loop that spends too much money or keeps retrying the same broken task. It can be detected if someone built budgets, stop rules, and alerts. The quieter failure is the loop that exits cleanly and produces something plausible enough that nobody looks closely.
Oversight helps only when the person has enough context, time, and ability to detect or correct the failure. A confirmation gate after an opaque plan does not create those things. It mostly records who to blame later.
For software teams, I’ll call the missing layer review-loop engineering : designing the review packet, escalation rules, and feedback path so the person accountable for a change can still understand and redirect it.
Loop engineering designs the system that prompts the agent. Review-loop engineering designs the handoff between that system and the engineer who must decide whether the work is acceptable.
There are really three loops
Andrew Ng recently described three loops for building products: an agentic coding loop, a developer feedback loop, and an external feedback loop from users and the world. That is a better frame than the popular story that agents simply replace a developer’s loop.
For day-to-day engineering, I use a different operational decomposition. The external-feedback loop stays outside this table; it is the thing that tells you whether the product should change at all. Inside the engineering workflow, the useful split looks like this:
LoopRuns atJobTypical failureAgent loopmachine cadenceMake a change, use tools, react to feedbackWrong implementation, hallucinated progress, repeated failureVerifier loopmachine cadence, after changesTest, inspect, score, or challenge the changeWeak test, reward hacking, correlated reviewer mistakesHuman loophuman attention cadenceSet direction; decide escalations; turn review findings into better specs, checks, and guardrailsComprehension decay, review fatigue, rubber-stamping<br>Review-loop engineering is the interface to that third loop: it decides what reaches a person, what evidence arrives with it, and what becomes durable after the decision.
The first two are getting a lot of attention. They should. A loop without a real check is just a model agreeing with itself.
But the third loop is where the organization pays for everything the first two get wrong.
The agent loop is fast. The verifier loop can be fast. The human loop is slow because understanding is slow. It takes time to recognize that a passing test proves the wrong thing, that a change violates a product constraint the agent never saw, or that a clean local fix quietly created an operational mess somewhere else.
You cannot solve that mismatch by asking humans to review more output faster. You have to design for it.
The verifier is necessary, but it is not the finish line
Do not rely on the maker’s...