I Am Jack’s Human in the Loop

I am Jack’s human in the loop.

I have been placed here for safety.

Nothing may proceed without me.

Unfortunately, I am in another meeting.

The machine has completed the implementation. The tests it can run have passed. The remaining uncertainty has been identified. The pull request is waiting for review. The infrastructure change is waiting for approval. The deployment is waiting for its window. The next piece of work is waiting because beginning it before the current piece has crossed every gate would imply dangerous enthusiasm.

The organization has successfully kept a human in the loop.

The loop has stopped.

This is not an argument for removing people from consequential decisions.

It is an argument for deciding what the people are there to do.

“Human in the loop” sounds like a safety design because it names a human and places that human somewhere near a machine. It does not specify the human’s function. It does not say which events deserve intervention, what evidence the person should inspect, which decisions require judgment, how quickly the decision must occur, what work may continue while the decision is pending, or how the state of that work will survive until the person returns.

Without those answers, human oversight can become a familiar organizational primitive wearing an AI badge.

A gate.

A queue.

A permission.

A delay with a person attached to it.

The loop was already there

Software did not wait for artificial intelligence to discover caution.

Review matters.

Authentication deserves skepticism.

Infrastructure changes should not be waved through because an application developer is pleased with a local result.

Deployment windows exist because production is not an improvisational theater exercise, despite recurring evidence that several companies have misunderstood the genre.

We already had humans in loops.

We called them reviewers, approvers, security engineers, operators, product owners, change managers, release managers, architects, and the person who knows why touching that one configuration file on a Thursday afternoon ruins everyone’s weekend.

The machinery existed because software changes state.

Code moves from private thought to shared branch.

A branch moves toward merge.

A service receives authority to act on behalf of a user.

Infrastructure changes what is reachable.

A deployment changes what customers experience.

Each transition can increase the cost of being wrong.

A gate can therefore be useful.

The problem begins when we confuse the purpose of the gate with the existence of the gate.

A pull-request review is valuable because another person can challenge the implementation, catch an assumption, bring knowledge the author does not have, or decide that the evidence is insufficient for merge.

The review is not valuable because software spent thirty-six hours awaiting review.

A deployment approval can be valuable because production has a larger blast radius than a local environment.

The approval is not valuable because a calendar cell turned green.

The human contributes judgment.

Waiting contributes time.

These are not the same resource.

The human is not a mutex

A mutex is useful when two things cannot safely happen at once.

A human being is not a mutex.

Yet many organizations implement people as serialization primitives.

Work reaches a point requiring human judgment. Everything behind that point stops. The person is unavailable. The work is therefore considered unavailable. The engineer is instructed not to continue because the prior work is not officially complete. The next problem remains untouched because touching it would create work in progress.

The organization has reduced concurrency by converting an unanswered question into a prohibition against thought.

This may be defensible when the next action would amplify an unverified assumption into expensive or irreversible work.

It is not defensible as a universal operating model.

The gate should constrain commitment.

It does not automatically need to constrain cognition.

Do not merge the unreviewed change.

That does not mean nobody may understand what follows from it.

Do not deploy the unapproved infrastructure.

That does not mean the dependent application cannot be prepared, locally exercised, documented, or arranged so the remaining uncertainty is explicit.

Do not accept an authentication design without security scrutiny.

That does not require every unrelated question in the system to remain unanswered until security appears.

The boundary matters.

A good gate says: this consequence may not occur until this judgment has been made.

A bad gate says: nothing useful may occur until this person becomes available.

The first manages risk.

The second manages traffic.

Challenge assumptions

Today an AI generated a requirement and then began producing tests from the requirement it had generated.

The tests were coherent.

The implementation path was coherent.

The explanation was coherent.

I did not stop it because I had detected a syntax error or because a policy required me to inspect every line produced by a model.

I stopped because I did not understand why it was doing what it was doing.

Why does this requirement apply to that thing?

The answer was an assumption.

The model had interpreted the requirement one way, promoted the interpretation into working context, and begun building evidence that its own interpretation was correct.

This is an efficient way to be wrong.

It is also not particularly alien.

Humans do this constantly.

We infer intent. We convert inference into premise. We forget that the premise began as inference. Then we defend the resulting structure because several dependent decisions now make the original assumption expensive to revisit.

The useful difference was that the AI was cheap to challenge.

There was no status injury.

No meeting had to be scheduled.

No one needed to explain that the question was not criticism.

No one had spent political capital becoming the person associated with the assumption.

The question could simply be asked.

The assumption could be exposed.

The work could change direction.

That was the human-in-the-loop event.

Not continuous supervision.

Not manual duplication.

Not ceremonial approval.

A moment in which meaning mattered more than execution.

Challenge assumptions.

Everything else follows.

The rightful triggers

The phrase “human in the loop” becomes useful only when the loop has triggers.

The trigger should not be that AI touched the work.

That criterion is too broad to be meaningful. A spelling suggestion and a production authorization would receive the same governance label because both involved a machine.

The better question is what kind of uncertainty is crossing what kind of boundary.

Humans belong naturally at several of those boundaries.

When intent is ambiguous

Machines can generate interpretations faster than organizations can notice they have not agreed on the question.

A human should intervene when the system must decide what somebody meant, especially when multiple plausible interpretations would produce materially different behavior.

This is where “why are you doing that?” earns its keep.

When trust changes

Authentication, authorization, identity, privacy, secrets, access, and delegation deserve scrutiny because they determine who or what may act.

A correct implementation of the wrong trust assumption remains wrong.

The human is not there merely to inspect code.

The human is there to ask whether the authority being granted is the authority intended.

When consequences become expensive to reverse

Local experimentation is cheap.

Production data loss is not.

A private branch can be discarded.

A customer-facing migration may have downstream effects the author cannot personally observe.

As reversibility decreases and blast radius increases, human authorization becomes more valuable.

When evidence conflicts

Tests pass.

The requirement says otherwise.

The model is confident.

The logs are strange.

The implementation is elegant.

The user says it is wrong.

This is not a condition to average away.

It is a reason to stop and decide which evidence deserves authority.

When risk is being accepted rather than measured

Automation can tell us many things about a change.

It can run tests, scan dependencies, compare schemas, inspect plans, evaluate policies, verify formatting, detect known vulnerabilities, and repeat the same procedure without becoming bored enough to click Approve just to make the notification disappear.

But eventually a question may remain that is not “did the test pass?”

It may be “is the remaining uncertainty acceptable?”

That is a decision.

The human belongs there.

The human does not belong everywhere merely because the decision exists somewhere.

Dead time is not safety

A review waiting in a queue can feel safer than a change moving quickly.

Nothing is happening.

Nothing can therefore go wrong.

This is true in the narrow sense that an undeployed change cannot break production.

It is false in the larger sense that waiting itself has no cost.

Complex work is held partly in artifacts and partly in the temporary arrangement of a human mind.

Why this implementation was chosen.

Which alternatives were rejected.

Which failure was observed before the current fix.

Which test is trustworthy and which is merely present.

Which line looks suspicious but is necessary because of something two repositories away.

Which unresolved question matters next.

Then the gate closes.

The engineer moves to another problem because refusing to do so would be called idleness.

A day passes.

Another conversation begins.

Another model is opened.

Another architecture enters working memory.

The review arrives.

The engineer returns.

The code is still there.

The context is not.

Research on interrupted programming work has been documenting this problem since long before anyone decided to put a chatbot in the IDE. Developers report interruption and task switching as cognitively expensive, and experiments on task resumption show that cues about prior activity can materially improve the ability to resume work.

The process did not eliminate risk.

It relocated some risk into forgetting.

A delayed review may still be necessary.

A deployment window may still be correct.

A specialist may genuinely be unavailable.

The mistake is pretending the only state worth preserving is the artifact waiting at the gate.

The human state matters too.

The model needs a context window

One of the fundamental engineering problems in applied AI is context.

What does the model know right now?

Which instructions still apply?

Which files matter?

What happened earlier?

Which observations are authoritative?

What changed since the last run?

What should be retrieved, summarized, discarded, or refreshed?

The more capable the agent and the longer the work, the more obvious the problem becomes.

A model without the right context can reason beautifully about the wrong world.

So we build machinery around the model.

Conversation history.

Retrieval.

Structured memory.

Compaction.

Checkpoints.

Tool results.

State stores.

Execution plans.

We preserve context because intelligence without state continuity keeps rediscovering its own past.

This is treated, correctly, as an engineering requirement for AI.

Then we send the human to a two-hour meeting and preserve nothing.

The second inversion

Here is the part I had missed.

While preserving context for AI is a fundamental requirement of using AI,

using AI to preserve context for humans may be essential for unleashing human productivity.

The relationship runs both ways.

The model needs context from me so it can continue intelligently.

I need context from the model so I can continue intelligently.

Before I leave a problem, the AI can help preserve the state I am about to lose:

What was I trying to accomplish?

What is already known?

What did we test?

Which assumptions are explicit?

Which assumptions are still suspicious?

What decision is waiting on another human?

What work can safely continue without that decision?

What must not proceed?

What changed in the code?

Which files, branches, pull requests, logs, or documents carry the evidence?

What is the next meaningful action when I return?

This is not a summary for management.

It is not a status performance.

It is a return path.

The distinction matters.

A status update is optimized for somebody who is not doing the work.

A return path is optimized for the person who must become the person doing the work again.

Those are different artifacts.

One says what happened.

The other restores the conditions under which thought can continue.

AI is unusually well suited to helping construct that artifact because it has been participating in the work itself. It can inspect the conversation, changes, tests, decisions, and unresolved questions while they are still present. It can compress them before the human working set evaporates.

Then, when the gate opens, it can help reconstruct the state.

Not by declaring the summary true.

By presenting the evidence, decisions, and unresolved assumptions in a form the human can challenge.

The model becomes a context cache for a biological processor with an aggressively finite working set.

For decades we have tried to protect human productivity by preventing interruption.

That remains useful.

But some interruption is structural.

Reviewers will be unavailable.

Deployments will happen later.

Dependencies will block.

Production incidents will arrive at inconvenient times because production has never demonstrated respect for personal scheduling.

The more interesting question becomes not only how do we avoid switching?

It becomes how cheaply can we return?

That is a different productivity problem.

And AI changes it.

Leave the loop

There is a strange conclusion hiding inside the phrase “human in the loop.”

Keeping the human effective may require allowing the human to leave.

A person forced to hover over every intermediate action does not provide better judgment merely by remaining present.

Attention decays.

Patience decays.

Review quality decays.

The human becomes a permission surface rather than a thinking participant.

The safer design may be asynchronous.

The AI works within bounded authority.

Automated checks run continuously.

Reversible work proceeds.

Consequential transitions stop at explicit decision boundaries.

The state is checkpointed.

The human returns when human judgment is actually required.

The system presents what changed, why it changed, what evidence exists, what assumption is being made, and what consequence the pending decision authorizes.

The person challenges the assumption.

The loop continues.

This is not autonomy without governance.

It is governance with a job description.

NIST’s AI Risk Management Framework makes a version of this point in less gastrointestinal language: human roles and responsibilities in human-AI configurations should be clearly defined and differentiated. It even identifies the question of whether humans are empowered and incentivized to challenge AI output as an area worth studying.

That is the center of it.

The human should not merely be present.

The human should be empowered to interrupt the machine for a reason.

And the organization should be designed so that the machine does not require the human to interrupt everything else merely to remain available for that possibility.

A gate should inherit knowledge

A useful gate does more than stop movement.

It receives evidence from the stage before it and returns a decision to the stage after it.

That sounds obvious.

It is not how many gates behave.

A pull request may contain the code but not the reasoning that made the code inevitable.

A security review may receive a diagram without the failed experiments that established the trust boundary.

A deployment approval may receive a ticket assembled for process compliance rather than the operational evidence needed to judge the actual change.

Then the human is technically in the loop but informationally outside it.

The reviewer must reconstruct the work from fragments.

The author must remain available to retransmit the missing context.

The gate becomes synchronous not because the decision requires synchronous thought, but because the organization failed to preserve enough state for asynchronous judgment.

This is where AI can help again.

The same system that assisted implementation can prepare the review surface.

Not “here is a cheerful summary of my excellent work.”

A useful review packet should expose disagreement:

Here is the intended behavior.

Here is the evidence that supports it.

Here are the assumptions the implementation depends on.

Here are the alternatives considered.

Here are the tests that passed.

Here are the tests that could not yet run.

Here is the remaining uncertainty.

Here is the exact consequence your approval enables.

That is human-in-the-loop infrastructure.

The purpose is not to convince the human to approve.

The purpose is to make the human capable of disagreeing intelligently without requiring the author to reconstruct the universe in a meeting.

Safety at the speed of understanding

AI makes implementation faster.

This is often described as a governance problem.

The machine can produce more code than humans can review.

It can create more artifacts than humans can absorb.

It can reach consequential decisions faster than existing institutions are accustomed to making them.

All true.

But speed is not automatically the defect.

Speed reveals where the old system was already slow.

When implementation took five days and review took two, review was part of the scenery.

When implementation takes two hours and review takes two days, the queue becomes architecture.

The answer cannot be to slow the implementation until the old proportions feel familiar again.

Nor can it be to remove every human and hope the model has absorbed morality through sufficient token exposure.

The answer is to redesign the boundaries.

Automate what can be tested.

Parallelize what can be safely reversed.

Preserve what is already known.

Escalate what requires judgment.

Make the escalation specific.

Make the decision legible.

Make the return cheap.

The objective is not maximum velocity.

It is safety at the speed of understanding.

Sometimes understanding takes longer than execution.

That is allowed.

But when the human needs time, the rest of the system should know exactly what is waiting, why it is waiting, what may continue, and how the human will recover the state needed to decide.

Dead time should not be mistaken for deliberation.

Jack’s rightful place in the universe

I am Jack’s human in the loop.

I am not here because flesh is inherently trustworthy.

I have met flesh.

I am not here to duplicate every operation the machine performs faster than I can.

I am not here to click Approve after enough time has passed for approval to look responsible.

I am not here to become the biological dependency that prevents the automation from embarrassing the organization by being productive.

I am here because meaning remains consequential.

Because requirements contain assumptions.

Because evidence conflicts.

Because authority has boundaries.

Because production changes are promises made to people who were not in the room.

Because someone has to decide when uncertainty is acceptable.

Because sometimes the machine will do something coherent, tested, elegant, and wrong.

And somebody should be able to ask:

Why are you doing that?

The machine does not need me to type every character.

It needs me to notice when the characters are becoming a decision.

It needs me to challenge the premise before the premise becomes infrastructure.

It needs me to carry responsibility where responsibility cannot honestly be delegated.

And when my judgment is not required, I should be allowed to leave.

The work should preserve itself.

The machine should preserve the return path.

The gate should wait for me without requiring me to wait for the gate.

We spent years learning how to preserve enough human context for artificial intelligence to continue working.

Perhaps artificial intelligence can finally help us preserve enough context for humans to do the same.

I am Jack’s human in the loop.

For the first time, the loop may know where I belong.

Receipts

• NIST AI Risk Management Framework 1.0, Appendix C: AI Risk Management and Human-AI Interaction ↗ — NIST says human roles and responsibilities in AI decision-making and oversight should be clearly defined and differentiated, and specifically identifies whether humans are empowered and incentivized to challenge AI output as an open human-AI interaction question.
• NIST AI RMF Core ↗ — GOVERN 3.2 calls for policies and procedures that define and differentiate roles and responsibilities for human-AI configurations and oversight; the framework also treats independent review, testing, documentation, and continuous risk management as distinct mechanisms rather than one universal approval ritual.
• DORA, “Streamlining change approval” ↗ — Summarizes DORA research finding that peer review plus automated testing and feedback supports software delivery performance, while heavyweight external approvals add delay and were not associated with lower change-failure rates. It also recommends applying additional scrutiny according to risk rather than treating every change identically.
• GitHub Docs, “Deployments and environments” ↗ — Documents explicit deployment protection mechanisms including required reviewers, wait timers, branch restrictions, and custom protection rules. These illustrate that a gate can be attached to a consequential transition such as deployment rather than to every preceding act of engineering.
• Robert DeLine and Chris Parnin, “Evaluating Cues for Resuming Interrupted Programming Tasks,” Microsoft Research / CHI 2010 ↗ — Surveyed 371 programmers about interruption and task-resumption strategies and experimentally compared automated contextual cues with note-taking. Developers using either automated cue completed interrupted tasks with twice the success rate of those using note-taking alone, supporting the argument that preserving return context can materially improve resumption.
• Mary Czerwinski, Eric Horvitz, and Susan Wilhite, “A Diary Study of Task Switching and Interruptions,” Microsoft Research ↗ — A week-long diary study of information workers found difficulty shifting among multiple tasks and concluded that reinstatement of complex, long-term projects was poorly supported by contemporary software systems, motivating tools designed specifically to support task recovery.
• Zahra Shakeri Hossein Abad et al., “Task Interruption in Software Development Projects,” EASE 2018 ↗ — Mixed-methods research using 4,910 recorded tasks from 17 professional developers and a survey of 132 developers found that task switching imposes cognitive load and that contextual factors strongly affect how disruptive interruptions are in software development.
• Anthropic, “Effective context engineering for AI agents” ↗ — Describes context as a critical but finite resource for agents and discusses maintaining long-running agent state through deliberate context curation, compaction, structured information, retrieval, and related techniques. This supports the essay’s first half of the second inversion: capable AI systems require deliberate preservation and refresh of context.
• Private AI-assisted development session, August 6, 2026 — The example in which an AI-generated requirement propagated an incorrect interpretation into planned tests is drawn from the author’s own development work. Proprietary code, repository names, and requirement details are omitted. The relevant observation is the intervention: the work changed direction when the author asked why the assumption existed rather than merely reviewing the resulting syntax.
• “I Am Jack’s Undigested Achievement,” August 6, 2026 — Companion essay establishing the preceding problem: completed and locally validated work can remain institutionally unavailable while dependent approvals and environments catch up. This essay extends that argument from what gates do to work into what humans at those gates should actually be doing.