Coding agents are running longer. Minutes have stretched into hours, overnight sessions, multi-day tasks. At the far end of this timeline, an old question resurfaces in a new form: when the human steps out of the control loop, who picks up the judgments the human used to make?
This article starts from a single premise: the H in Human-in-the-loop isn’t inherently human. It’s the verifier role in the control loop — and humans were just its first implementation. The evolution of coding agents over the past two years is, in large part, the story of harnesses gradually taking over this role.
The analysis proceeds along five dimensions: how many independent judgments HITL actually contains, how the harness takes them over one by one, how /goal turns verification into software behavior, where the human stands once freed from the loop, and which judgments still can’t be handed off.
The H in HITL was never tied to being human. It’s a position — the verifier in the loop. Humans just happened to be the first to occupy it.
HITL Is a Position, Not a Role
Human-in-the-loop sounds like one thing, but it packs multiple independent judgments into a single person. When it’s your turn, you’re doing five things at once:
- Start the next round — What comes after this step? You decide.
- Approve permissions — Should this command, this file write, be allowed? You authorize it.
- Course-correct — The direction is drifting. You pull it back.
- Verify — Did this round succeed? You check.
- Accept responsibility — If something goes wrong, you answer for it.
Control theory already has a vocabulary for these tiers. Watching every step and confirming each one is in-the-loop. Not watching every step, staying on the sidelines and only intervening when something breaks, is on-the-loop. Not watching at all, only reviewing the final output, is out-of-the-loop. The human retreats along this axis — from step-by-step confirmation to reviewing only the final result.
On first glance, it seems natural that one person handles all five. But they are five independent concerns. Once you accept that, the real question emerges: can they be split? Can some be handed to software while others stay with the human?
HITL feels like a single role only because these five concerns happen to land on one person. Once separated, deciding which go to software and which stay with the human becomes a concrete engineering problem.
Changes in tooling have paved the way. Early autocomplete cursors locked the human at the innermost layer: wherever the cursor stopped, your attention had to follow. You couldn’t step away. Only when agents became independent processes running in a terminal could you pull back. Cursor, a product that started in the IDE, moved its agent into the terminal in January 2026 (Cursor CLI). The convergence toward the terminal isn’t about anyone’s aesthetic preference — it’s because only the process form factor can support the human stepping back. Autonomy requires detachability.
This “from cursor to process” arc isn’t the main story. It’s the backdrop. Once the form factor was in place, the real question became: of those five judgments, which ones got taken over, and by whom?
The Harness Is What Takes Over
Looking back at the previous piece, describing the harness as “the loop around the model” was accurate but missed what it’s actually doing: it’s a container, purpose-built to take over those five human judgments one at a time.
First, a definition. What a coding agent actually runs is a loop: read context → decide next step → call tools (read files, edit files, run commands, search) → observe results → decide again. This loop, plus the surrounding machinery for context management, permissions, sub-agents, error recovery, and the “are we done yet” logic — that entire assembly is the harness. The CLI you type into is one entry point to this loop; it is not the loop itself.
The critical mapping: each component of this loop corresponds to a judgment the human used to make. And the order of takeover follows a single rule — whether the judgment can be expressed as an automatically checkable rule:
| Human judgment | How the harness takes over | Maturity |
|---|---|---|
| Start next round | Agent loop: auto-continue, auto-break | High |
| Permission approval | Permissions system (allow/deny/ask) + auto mode | Medium |
| Course correction | Plan mode, AGENTS.md / CLAUDE.md, pre-commit/pre-push hooks | Low (catching up) |
| Verification | /goal, Stop hooks, prompt-based evaluator → this article’s focus | Medium-high |
| Accept responsibility | None | None (always human) |
This table is effectively a map of where to invest effort in a harness. AGENTS.md, CLAUDE.md, plan pre-review, permission boundaries, MCP, sub-agents — these aren’t scattered configuration items. Together they answer one question: which of the five judgments are you handing to the harness?
Choosing an agent means choosing a harness, not just a model. What you’re actually deciding is where to draw the line between human and software responsibilities.
This also adds a layer to the previous Brain ≠ Hands analysis. That piece framed the model as the “brain” and the harness as the “hands” plus orchestration. Looking at it now, the harness has taken over more than execution — it’s also absorbing verification, extending its reach into tasks the model (the “brain”) used to own.
/goal: Turning Verification into Software Behavior
Of the five judgments, verification was the first to be taken over, and the most thoroughly. /goal is the product name for this step.
But /goal didn’t appear out of nowhere. It was preceded by an evolution in permission modes that, viewed chronologically, points in a clear direction.
Initially, the only way to run an agent without waiting for human approval at every step was to skip approval entirely. Claude Code offered --dangerously-skip-permissions; Codex offered --dangerously-bypass-approvals-and-sandbox (later called Full Access). Both carried “dangerous” in their names for a reason — running an autonomous process on a real dev machine, with SSH keys, environment variables, and git credentials, without any guardrails, is not a controllable risk. Nobody used these in daily development; they were confined to disposable containers.
In March 2026, Claude Code shipped auto mode: an independent AI classifier runs in the background, inspecting every tool call the main agent wants to make — safe ones pass through, destructive ones are blocked with an explanation. Around the same time, Codex shipped auto-review: an independent reviewer agent sits at the sandbox boundary. The main agent wants to cross it? The reviewer approves first. A single line in config.toml — approvals_reviewer = "auto_review" — transfers approval authority from the human to another model.
Different implementations, same thing: replacing the human with another model for the question “can this step run?”
Once that was working, the next question followed naturally: if another model can judge “can it run?”, can it also judge “is it done?”
/goal is the version where that question gets answered.
Before /goal, when a turn finished, the agent stopped by default and returned control. In other words, every turn required the human to return to the verifier position and confirm. What /goal does is replace that confirmation with software.
Claude Code: the verifier as an independent evaluator. Claude Code added /goal in v2.1.139 (May 12, 2026). You provide a completion condition. After each turn, a small model from your configuration (Haiku by default) judges: is the condition met? If not, it starts another turn without bothering you. The evaluator doesn’t call tools or run commands — it can only judge facts already surfaced in the conversation transcript. So the condition must be written in a form the transcript can verify: “npm test passes” works; “the code is good now” doesn’t. The position that small model occupies is exactly the one you used to return to after every turn. This is the first time the verification slot in HITL has been explicitly replaced by a software component.
Codex: the verifier as an auditable contract. Codex added Goals in v0.128.0. It shares the same objective as Claude Code’s /goal — set a completion condition, auto-continue across turns — but follows a different path. Claude Code uses an independent Haiku evaluator to judge each turn. Codex has no separate evaluator: it writes the outcome, verification surface, and constraints into a single contract, and has the main model check itself against evidence — not “I think I’m done,” but “files changed, tests passed, benchmark data matches.” The contract defines what done looks like; the model cross-references against auditable evidence after each turn. Like Claude Code, Goals support pause, resume, clear, and automatic restoration on session reconnection.
Once verification is handed off, the human moves from monitoring every turn to observing from the side. No more round-by-round confirmation — you set the condition, keep watch, and only intervene when something goes wrong. The two products take different routes:
Claude Code /goal | Codex Goals | |
|---|---|---|
| Evaluator | Independent small model (Haiku), judges after each turn | No independent evaluator; main model self-checks against evidence |
| Basis for judgment | Facts surfaced in the conversation transcript | Auditable evidence: files, tests, benchmark output |
| Lifecycle | Set condition, auto-continue, /goal clear to stop early | /goal pause / resume / clear; thread-scoped persistence |
| Common ground | Both upgrade from “wait for human approval each turn” to “set condition, check evidence, auto-continue” | Same |
The difference lies in the evaluation mechanism — one splits out an independent model, the other writes the check into the main model’s contract. But the common ground matters more: for the first time, the verification position has a concrete software behavior, not a vague human “let me check” or “looks good to me.”
How to Build a Reliable Verifier
Since you’re handing off the verifier position, all actionable advice converges on one question: how reliable is the implementation you’re handing it to?
If you can’t write a check for it, you can’t hand it off. The first gate for /goal is whether the objective can be reduced to a green light: migrate to the new API until every call site compiles and tests pass; implement per the design doc until all acceptance criteria hold; split the large file until every module is below the size budget; drain the labeled issue queue until it’s empty. Conversely, objectives like “make the code more elegant” — where no checkable condition exists — turn /goal into a self-loop that won’t converge.
How far you can step back depends on how reliable your verification is. The correct sequence is: a failing test, an acceptance script, a runnable check command — then /goal. The reliability of your verifier implementation directly determines how far away you can get. A rough implementation forces you to stay close; a solid one lets you actually walk away. HITL to VITL (Verifier-in-the-loop) is, at bottom, this logic.
Don’t let it run beyond what your verification can cover. Auto-continuing across turns requires caution: when the direction is right, it runs to completion; when it’s wrong, a small early mistake amplifies across rounds into extensive rework. The less complete your verification coverage and the longer the task runs, the more important it is to set up guardrails before starting — lock down the direction with a plan, limit scope with permission boundaries, preserve rollback points with checkpoints.
Long runs eventually hit the verifier’s context retention limit. A multi-day /goal will inevitably trigger context compaction. Compaction isn’t about truncating history — it’s about retaining the facts the verifier still needs and discarding noise. Poor compaction quality means it forgets the acceptance criteria you set on day one by day three — and a verifier with amnesia is functionally equivalent to a broken verifier. I covered this mechanism in detail in From Cursor’s Self-Compaction: How Agent Context Compression Works.
HITL becomes VITL across a single threshold: whether you’ve expressed a judgment as an automatically verifiable check. Write it, and you’re out of the loop for that step. Can’t write it, and you’re still in.
After Stepping Back: Beside the Loop or Gone Entirely
With the verifier handed off, the human’s role in the loop is vacated. The next choice is where you stand. Two approaches sit at opposite ends of a single fork: who owns the workspace?
Walk away: send the task to the cloud. Cursor Cloud Agents, Devin, and Claude Code on the web (claude.ai/code) take this path. Spin up a clean cloud VM, clone the repo, execute on an isolated branch, and deliver a PR for review. You’re not in any round, not watching from the side — you’re only accountable for the final PR. The benefits are concrete: environment isolation, parallelism, reproducible results. The costs are equally concrete — it’s not your environment. Your local toolchain, half-edited working tree, uncommitted changes, private dependencies, and environment quirks that only surface at runtime are invisible to it.
Stay beside it: your own machine as workspace. Claude Code Remote Control (February 24, 2026, v2.1.51+) and Codex Remote Connections (May 2026, embedded in the ChatGPT mobile app) take the other path. The agent runs on your machine; the remote device is just a control panel. Remote Control makes outbound HTTPS requests only, never opens inbound ports — your phone and browser connect to the same local session through Anthropic’s relay. Codex uses codex app-server to let a phone, tablet, or another machine connect in. You haven’t left — you’ve stepped to the outside of the loop, and that window exists precisely so you can switch back in at any moment.
| Send to cloud | Stay beside | |
|---|---|---|
| Workspace | A temporary cloud VM | Your own machine |
| Environment fidelity | Clean, but unfamiliar | Real, dirty state and all |
| Your position | out-of-the-loop · PR review only | on-the-loop · switch back anytime |
| Examples | Cursor Cloud, Devin, Claude Code on the web | Remote Control, Codex Remote Connections |
What Can’t Be Handed Off Is the Real Human-in-the-Loop
At the end of this line sits a judgment worth articulating: what can be moved out of the loop is exactly what can be expressed as a check. What remains — what can’t be handed off — comes down to three things: open-world judgment (a verifier can confirm “the tests passed,” but it can’t confirm “this goal wasn’t wrong to begin with”), what’s actually worth doing (taste and prioritization), and accountability (when something goes wrong, legally and socially, someone has to own it).
So human-in-the-loop won’t disappear. It just contracts to “the fraction that can’t yet be written as a verifier.” Here we can make a falsifiable prediction: the boundary of the human’s remaining role in the loop will advance outward precisely at the rate we learn to express judgments as checks.
To return to where we started: coding agents run longer not because humans matter less, but because the verifier position is being handed to a verifier you built — one reliable enough to be left alone. And you, in turn, have moved to where it can’t reach: deciding what’s worth doing, and standing behind what gets built.
What can leave the loop is exactly what can be written as a check. So the only actionable approach is this: express as many judgments as possible as automatically verifiable checks, build a reliable verifier implementation, and then be clear — the one thing you can’t hand off is where you should actually be. The H in HITL is shifting from Human to Harness. But one H will always be yours.
References
- Anthropic, “Keep Claude working toward a goal” (
/goaldocs), https://code.claude.com/docs/en/goal - Claude Code v2.1.139 release (2026-05-12): introduced
/goal - OpenAI Codex CLI: Goals (
/goal, available since Codex v0.128.0): thread-scoped completion contract; main model self-checks against auditable evidence - Cursor CLI (2026-01-16): https://cursor.com/cli
- Anthropic, “Continue local sessions with Remote Control” (2026-02-24), https://code.claude.com/docs/en/remote-control
- OpenAI Codex Remote Connections (2026-05): embedded in ChatGPT mobile app; connects to local sessions via app-server, https://developers.openai.com/codex/remote-connections
- Anthropic, “How we built Claude Code auto mode” (2026-03-24), https://www.anthropic.com/engineering/claude-code-auto-mode
- OpenAI, “Auto-review of agent actions without synchronous human oversight” (2026), https://alignment.openai.com/auto-review/