Human-in-the-Loop Checkpoints for Autonomous Code Agents

An agent that restarts a production workload or deploys a service has done something no pull request review was ever built to catch. Reviewing a diff is a habit engineers already carry: a human reads the proposed change, checks it against intent, approves or rejects, and the system waits. That habit worked as long as agents only proposed code. Shipping agents now close the loop on their own, generating pull requests and responding to review comments without a human initiating each step, and the old constraint on development speed, typing speed, has inverted into a new one: human verification capacity. Two responses to that inversion are already visible across engineering teams, and both of them are wrong in instructive ways.

A human checkpoint in front of every agent action makes the humans the fracture point: they either slow the agents down to a pace no faster than manual development, or they start approving code they have not actually verified, producing the appearance of oversight without its substance. Remove the checkpoints to preserve speed, and actions that used to pass through deliberate human judgment now execute at machine cadence with no pause. Both responses share a flaw: they treat oversight as a single dial to turn up or down, rather than a design decision about which specific actions warrant a human's authority. The real question a team faces is what event should pull a human into the loop.

What makes an agent action consequential

The distinction between a coding assistant and a coding agent is a distinction in what can go wrong. The risk shifts from a model saying something incorrect to a system doing something irreversible, and that shift makes "human in the loop" an engineering requirement.

Detectability, reversibility, and consequence are the three properties that set whether an agent's action deserves a checkpoint. Detectability asks how quickly a flaw becomes visible: a small logic error that an agent repeats autonomously across many executions can compound into serious damage long before anyone notices it, precisely because no single instance looks alarming on its own.

Regulators have already moved to treat oversight as an engineering requirement. Taken together, the regulatory direction is clear even where the implementation detail is left to the builder: an approval step that exists only to be clicked through no longer satisfies the intent of oversight. It has to be built as a control that actually does something.

Where the loop stands today

The autonomous engineering loop, as documented across shipping agents as of July 2026, now reliably closes through six stages that all happen before code merges. Planning and task decomposition run autonomously for well-scoped work, demonstrated in Cognition's Devin Manages Devins release in March 2026 and in Copilot's issue-to-PR flow. Bug reproduction and fixing run autonomously as well: the Government of Alberta has used Claude Code since 2025 to review its systems, find vulnerabilities, and fix them. Opening pull requests is autonomous, a capability GitHub extended to all paid Copilot subscribers when its coding agent reached general availability on September 25, 2025, and one also visible in Devin's merged-PR activity. Responding to review comments is autonomous too, through Copilot's 2026 cloud agent and Devin Review.

Every one of those six stages sits before a single, consistent line: the merge decision. No primary source documents a shipping agent merging its own code without explicit human approval. The industry has converged on one consequential checkpoint, even though it arrived there more by convention, the place where pull request workflows have always paused for review, than by any deliberate analysis of where risk actually concentrates. Beyond that line, production deployment and live monitoring remain stages no primary source documents as autonomous agent patterns, and teams largely treat them as high-blast-radius territory that still requires a human hand.

Cognition's own November 2025 performance review of Devin described the agent as "senior-level at codebase understanding but junior at execution," a characterization that explains why this boundary has settled where it has. An agent can read and reason about a codebase with real sophistication while still lacking the judgment to be trusted unsupervised at the moment a change takes effect in a running system. That gap is why the pre-merge loop has stabilized into something teams trust, and why the stages beyond it, deployment, infrastructure modification, incident response, have not. But the merge line was drawn before agents routinely acted beyond it. As agents move further into production operations, the actions that matter most are increasingly ones that never pass through a pull request at all, which means the industry's one converged checkpoint is already failing to cover the territory where consequence is highest.

The right criterion checkpoints at every step and checkpoints at the merge both miss

Gating every step and gating only the merge look like opposite strategies, but they share the same mistake: both locate the checkpoint by the action's position in a workflow.

Putting a human in front of every agent action produces the fracture point described earlier in concrete form. The checkpoints keep firing on schedule, but the judgment behind each approval has quietly hollowed out.

Gating only at the merge fails for a different reason: merge is a structural boundary in a version control system, not a boundary defined by consequence. A merged change can be trivially reversible, a single commit revert undoes it, while an un-merged agent action, a dropped table, credentials exfiltrated through a tool call mid-task, can be irreversible and never pass anywhere near the merge gate. As agents take on production operations, deploying services, modifying infrastructure, responding to live incidents, the actions that matter most increasingly happen outside the pull request lifecycle entirely, in territory the merge gate was never built to see.

A reasonable objection follows from both failures: doesn't abandoning position-based rules sacrifice the predictability and auditability that make a gate trustworthy? Teams are right to distrust approval logic that behaves unpredictably from one run to the next. A gate's predictability comes from how it is built. A gate placed at the point where an action crosses from reversible to irreversible can fire with exactly the same determinism as a gate placed at the merge step, and it has the advantage of actually corresponding to where risk concentrates. The right criterion for a checkpoint is reversibility and consequence, evaluated on the action itself.

Placing checkpoints at the boundary between reversible preparation and irreversible action

A checkpoint belongs wherever an agent's next action would cross from something that can be undone into something that cannot. That boundary, not a fixed position in the development lifecycle, is where human authority does the most good at the lowest cost to speed.

Research, drafting, classification, code generation, running tests, opening pull requests, and responding to review comments all sit on the reversible side of that line. An agent can execute each of these, and a human can inspect, redirect, or simply discard the result without damage done. Merging to production, deploying a service, modifying infrastructure, changing access permissions, deleting data, using stored credentials, and sending external communications sit on the other side, where undoing a mistake after the fact is expensive or, in cases like a deleted production record, impossible.

The five-level autonomy taxonomy developed by Feng et al. gives this design decision a concrete vocabulary. At L1, the Operator level, a human directs every action the agent takes. At L2, the Collaborator level, human and agent plan and execute together. At L3, the Consultant level, the agent leads the work and consults the human for expertise and preferences along the way. At L4, the Approver level, the agent engages the human only in scenarios flagged as risky or specified in advance. At L5, the Observer level, the agent runs fully autonomously under human monitoring, with an emergency off-switch available but not routinely used.

The taxonomy's real value appears once a team stops assigning one level to an entire agent and instead assigns different levels to different stages of the same task. An agent can run at L3 or L4 during preparation, planning, drafting, generating tests, and drop to L2 or even L1 at the exact moment its next action becomes irreversible. The autonomy level is a property of the action, not a fixed setting on the agent as a whole.

Making that drop happen in practice requires interruptibility to be built into the agent's execution architecture rather than left as a policy written in a document somewhere. OpenAI's Agents SDK already implements this as a native capability: a tool call can pause, wait for a human to approve or reject it, and resume from the exact state it paused in. The checkpoint becomes a state transition the system is built to handle, not an external interruption bolted on after the fact.

The Hedwig system, presented at ACM CAIS '26, demonstrates why a single fixed autonomy level applied across an entire agent fails to track where risk actually lives. Hedwig adjusts its autonomy level based on the history of developer-agent interactions across sessions, tightening oversight when the agent moves into unfamiliar territory and relaxing it where trust has accumulated through a track record of approvals. The check-in ratio it settles on differs measurably across developer personas, driven purely by differences in each developer's trust history and approval-rate-derived preferences. Oversight, in other words, is not a static property of the system. It tracks where the system's own history says risk has actually shown up.

Distinguishing reversible from irreversible in practice: rule-based and risk-scored gates

Whether a checkpoint should be a rule-based gate or a risk-scored gate comes down to one test: can the trigger condition be written down in advance as something correct every single time? If yes, a deterministic rule-based gate is the right tool. If the right answer depends on weighing signals that shift with context, the situation calls for a risk-scored gate instead.

Rule-based gates are deterministic. Conditions are written before the agent ever runs, and they fire identically every time that condition is met, with no judgment exercised in the moment and full auditability after the fact. These gates suit actions where the consequence is known in advance and categorical regardless of context: any write to a production database, any change to access permissions, any external API call that sends data outside the system's boundary. The limitation is that a rule-based gate is only as capable as the conditions its author anticipated. It handles the cases someone thought to write down and fails silently on the edge case nobody foresaw.

Risk-scored gates are non-deterministic by design. These gates suit actions whose blast radius depends on context that a static rule cannot capture: the same code change might be low-risk on an isolated service and high-risk on infrastructure that tier-1 systems depend on, a distinction only visible from the dependency graph surrounding the change, not from the change itself. For a risk-scored gate to be trustworthy, three things need to be in place: a threshold the team has set explicitly rather than inherited by default, tracing attached to every scored decision so the reasoning behind a score can be audited after the fact, and a fallback that routes to blocking human review whenever the model's confidence is low or the surrounding context is thin.

These two gate types complement each other. Rule-based gates handle the irreversibility cases that are categorical and known in advance. Risk-scored gates handle the cases where risk is real but only visible in context. A sound approval policy layers both, applied stage by stage across the loop.

Hedwig's finding that oversight preferences shift across tasks and over time implies the risk threshold itself should be a tunable, session-aware parameter, since a static permission setting cannot track that shift. Earned autonomy, trust built up from a visible history of approvals, is more durable than autonomy simply granted at the outset, because it reflects what the agent has actually demonstrated.

Oversight quality when checkpoints are too few, too late, or too shallow

Correct placement solves only half the problem. A checkpoint sitting exactly at the reversibility boundary still fails if the person behind it cannot meaningfully evaluate what the agent is proposing to do, and that failure happens through three distinct mechanisms.

Automation bias is the first: a reviewer facing an agent's output that has been correct many times before starts extending it the same trust without re-verifying each instance, even when the current instance carries different risk. Automation-induced complacency is the second, a closely related but distinct failure in which the reviewer's attention itself degrades under the routine of repeated approval, so that the review becomes a motion performed rather than a judgment exercised. Skill decay is the third, and the hardest to catch: developers who spend extended periods overseeing rather than writing code can lose the depth of comprehension that real evaluation depends on, often without any clear signal to themselves that the loss has occurred. A checkpoint placed with perfect precision at the boundary between reversible and irreversible action still produces nothing but a ceremonial pause if the human behind it has quietly lost the capacity to tell a good action from a bad one.