Human In The Loop Required. Or was that On the Loop?
A short history of watching machines work across technology transformations.
Two weeks ago … when Human On The Loop (HOTL) saved me
I almost didn’t run the last check. It was late in the evening, past my usual bed time - 23:05, I was building a small tool for myself and my current AI Augmented PM course. I was a bit disappointed, because the spec-and-eval version of the workflow felt like five times the effort of just letting the model write and ship after talking to it. Then the eval caught a bug the “vibe coded” version would have pushed straight through, causing a bit of annoyance to my course participants.
That’s triggered the whole motivation: I realised that in most of my work, I need to stay in teh loop. That’s because I do “management” stuff. Which - for better or worse (us product guys e.g. have been lazy in caring about this at all) has few correctness checks. I wanted to dig in tech history: whether the human stays in the loop or steps back to watch it run isn’t a new question. And I found out it was never about trust. It’s about whether a test, a second reviewer, a person who has to explain the call out loud exists to find something you wouldn’t have fond yourself. Does a check exist? Software Engineering has spent sixty years building those of those. It’s not complete Most of the rest of knowledge work hasn’t, and where it has, it turns out correctness was never the only job a human in the loop was doing.
But what really triggered me is the whole emphasis on “the human needs to stay in the loop” as taken for grated in AI work.
AI is basically automation and about pushing the boundaries of automation. So I looked into other historic examples of automation to see how the human in the loop question was handled there. We seem to accept red lights, elevators, planes landing to be fully without human in the loop. Often times it gets replaced by humans on the loop - getting in when an automated check tells us to check.
I wanted ti understand why a thing that happened repeatedly is so highly debated these days. It’s probably because white collar elites are impacted big time for the first time in tech history, simply holding a louder megaphone..
So, let’s look at the history of The Human In The Loop vs. The Human On The Loop.
The Terms Are Older Than the Debate
The pattern to wait for the result of the eval, on that that evening, and only stepping in when it flags something - basically trusting the loop - is called “human on the loop”. What I almost fell for: skip the eval, ship whatever came out, only relying on my gut check. There's an even more old school version - reading and approving every line before it ships - that’s the “human in the loop” pattern. Both sound like AI-era vocabulary. And the current fun aspect is that these terms are now used more like moral verdicts than things we have learned about in tech for decades. (“Of course , the human must always stay in the loop for trust” “Only the lame still read code” …as if a traffic light automation would care about our moral verdicts.)
Exhibit: In May 2009, the US Air Force issued a planning document for drone operations that said: “Increasingly humans will no longer be ‘in the loop’ but rather ‘on the loop’ — monitoring the execution of certain decisions.” Three years later, Human Rights Watch turned the phrase into a formal three-way split — in the loop, on the loop, out of the loop — for its campaign against autonomous weapons. The intent of the Air Force was less about philosophy. The document discussed in detail how multi-aircraft control would impact headcount: the headcount of pilots required to keep fifty combat air patrols running dropped from 570 to 150 for the same number of aircraft in the air. The push to adopt “on the loop” was driven by the economic constraints of manpower before it cared about trust, to be frank.
Exhibit: Go back further and you’ll find an actual academic root from 1978 — Thomas Sheridan and William Verplank came up with a ten-level scale for how much of a decision a computer versus a human should get to make, which - at the time - was built for undersea robots, not drones or AI. Interesting details: Level five is “the computer picks an action and does it, but only if you approve first”. Level six is “the computer picks the action, tells you, and does it unless you object in time”. Here we go. That’s human-in-the-loop vs. human-on-the-loop, specified by numbers, half a century before either phrase showed up in any AI keynote or LinkedIn moral complaint or positioning statement.
2: What It Took to Get There
Interesting to note that each of these transitions took a) years, b) at least one near-miss (in potentially lethal context), and c) something new that let people check the machine (yes, a check loop!) before they stopped checking themselves.
London’s first traffic signal went up in December 1868 — a gas-lit semaphore a policeman worked by hand with a rope. It blew up in his face three weeks later, a gas leak under the pavement. Electric signals in 1912 were still hand-operated by cops standing at the corner. Only in the 1920s did timers take over, and the reason cities adopted them was cost, not confidence in the technology: New York reassigned all but 500 of its 6,000 traffic officers once timers went in, and saved $12.5 million doing it. (Guess what the cops who were replaced at the time thought about the tech, its reliability to regulate traffic as well as they did and about the social implications. It’s never easy to be replaced.) By 1952, Denver had a computer running 120 signals off pressure sensors in the road. Elevators followed the same script piece by piece — Otis’s own patents describe stripping the operator’s job down function by function, 1) starting and stopping first, then 2) acceleration, then 3) floor-leveling — years before push-button elevators with no operator at all started showing up, first in private houses, where a mistake cost much less.
Aviation is the most head on example. Lawrence Sperry’s gyroscope flew a plane hands-off over Paris in 1914 — sold as relief for a tired pilot, not a replacement for one; the pilot was still fully in charge, just resting his arms. It took until 1965 for a plane to land itself. It took until 1989 — the Boeing 747-400 — for an airliner to finally not need a flight engineer on board at all. Seventy-five years, during which one function was handed over at a time, each one only after the last one was trusted.
3: Where the Check Loops Were Built First
Software is now running the same script at a unprecedented speed and in the area of what was formerly gain thought as one of the last remaining exclusive human capabilities - writing code (well, and mich more knowledge work). And we can dive onto a short study of the clearest account of it in one persons public development over the last four months.
In February this year, Boris Cherny — who built Claude Code at Anthropic — was still describing a human layer over the machine’s output: “you still do want some of these checkpoints, like you still do want a human looking at the code — unless it’s like pure prototype code.” Then, in March, Anthropic shipped a feature called Code Review, coming with his explanation : “A team of agents runs a deep review on every PR. We built it for ourselves first ... reviews were the bottleneck.” (Read: they did not have enough manpower to manually check all the code they produced. Just like ages before there was not enough manpower to control air traffic.) By June he was saying he hadn’t written a line of code by hand in eight months, that he wakes up most mornings to pull requests Claude had already written, tested end to end, with screenshots attached — and that he’d stopped prompting the model directly. HIs statement now: “I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”
Steve Yegge, a different engineer at a completely different company, landed on the same pattern, describing it with very different words. He describes an eight-stage ladder for how developers work with agents. At one stage “code is just for diffs,” and one stage down: “diffs scroll by. You may or may not look at them.” Two people, two companies, the same year, the same handoff — human review replaced not by nothing, but by other agents reviewing the work, and by tests that run the checks instead of a person reading the code.
I said something like this on a call with my own AI Augmented Product management course in June (and wrote about it here), but about a very different kind of artefact: software had sixty years to build the machinery that checks correctness for you — compilers catching type errors, linters, test suites, now agents reviewing other agents’ pull requests. A strategy deck has none of that. At all. In parts because we are too lazy to define it (we rather rest on terms like intuition, judgement and taste as if that were a good career move), in parts because it is really not formally possible. Neither does a hiring decision, or a PRD. That gap defines why code in huge parts does not need a human in the loop while almost anything else still does. Software Engineering invested 60 years into tons of partial correctness tests of code.
4: Two Different Questions
This makes looking at the course cohort really interesting: the same people that will happily ship code (or have it shipped) overnight without reading the diff still wants a name accountable for the strategy deck, even when the AI’s answer is good (honestly often better and deeper than the human version: you don’t believe me, I’ll happily show you. But that’s not the point.)
What now happens all the time: two people disagreeing. One argues from a stack of AI-generated reasoning (probably the outcome steered by him through a tin of agents), the other with five minutes and their own memory of the situation. It doesn’t matter how good the AI-assisted argument is. The quality may be super high. But the outcome itself is not “accessible” and “explainable”. It’s then a problem is that nobody in the room can tell whether the position was actually decided by the person presenting it, or if it was simply produced on demand to win an argument. While a test can tell you if code runs, no test can tell you that.
The nice option is how I use this in my own workshop prep. These days, I run a simulated version of a strategy session before the real one, multiple angles arguing it out. And believe me, these are not simply “prompts” I run, but fine tuned systems of agents, being fed just the right context each. (I am nowadays always dying in shame, when I see self proclaimed AI experts critique results of a “prompt” they then even dare to publish. Man, the days of smart prompting are over once and for all!) At times, I have clients watch the simulation process instead of just handing them my conclusion. It makes them trust the conclusion faster, because now they can see a position getting fought for, and they know who to ask if they don’t buy it. More so, they can pick uo main lines of the reasoning, accept it, refute it, bring on their own line of thought much more nuanced and basically, we create more relevant friction earlier. Win!
My conclusion is that correctness and explainability are two very different jobs. And we should not confuse them. One asks: is this right. The other asks: who can stand here and account for it. Software mostly only has to answer correctness. It does what we want it to do. Complicated enough! The compiler doesn’t care who wrote the loop, and a user doesn’t ask the codebase to justify itself. It needs to be functionally correct. Management, product, and strategy work has always had to answer both, and we’ve spent approximately no engineering effort building anything like a test suite for the second question. Until we do — and I think it’s partially buildable, just not built — quality improving in the model won’t be the thing that gets a human out of that loop.
The End
I still skip the check some nights. I just know now, when I do, which of the two questions I’m choosing not to ask.
On the moral debates on human in the loop vs. human on the loop that are being done on a certain level of ideology, I think there are two reasons:
The current tech transition is so fast, no one gets ten years to overthink - for better or worse. And that brings a high contrast between the adoption speed of enthusiasts and defenders of the current state.
This is the first time, a highly privileged niche of white collar workers is impacted (me included) which has a bigger megaphone than any of the other groups that was affected before.