The Human in the Loop Is Not Driving

The agent opens the pull request. A person approves it. The company calls that person the human in the loop and files the whole setup under responsible use of AI. Three weeks in, the approver reads the summary line and clicks merge, because the last sixty were fine and forty more are waiting. Then one of them takes billing down for an afternoon, and the postmortem carries one human name: the person who approved it, who decided nothing.

That is the loop working as designed: the approver stands at the back of the boat with a stamp, and nobody is at the wheel.

I run agents all day at my desk and I want them running faster and taking more of the work. So the question I care about is the one the approval queue skips. Who owns the turn? Who decides what the work is, what it must never touch, what done looks like, and when to change heading? That person is at the helm, while the approver is in the loop, and the loop is not driving.

The Surface Problem: The Human in the Loop Queue

When an agent rollout wobbles, most leaders diagnose it the same way. The model is capable and unpredictable, so a person has to check every step before it lands. That belief produces the approval queue: a named engineer who signs each pull request, each ticket update, each customer email the agent drafts.

The symptoms show up within a month. Throughput drops to the speed of the slowest approver. The approver’s calendar fills with review, and the reviews get shorter as the queue grows. When something breaks, the approver takes the blame for a change they did not design, did not write, and did not fully read, while the person who decided the agent could touch that system is missing from the incident report.

The usual fixes make it worse. Add a second approver and you have two people skimming instead of one. Add a checklist and the approver reads the checklist instead of the diff. Pull the model back to suggestion mode and you have paid for a race car to idle in the driveway, with the approver retyping what the model already wrote. I have watched teams try all three inside a quarter and end up slower than before they bought the seats.

The System Underneath: Two Loops

The approval queue fails for structural reasons, and the structure would hollow out your most careful engineer in the same three weeks.

The first loop is the approval loop, and it eats itself. Lisanne Bainbridge described the shape in 1983 in a paper called “Ironies of Automation”: the better an automated system performs, the less practice its human monitor gets, and watching a reliable system for the rare failure is a job humans are bad at. Every clean pull request teaches the approver to read less, and each approval that goes fine lowers the cost of skimming the next one. By the time the agent makes the mistake that matters, sixty good outcomes have trained the approver to click through it.

The approver also holds the least information of anyone in the chain. The model read the codebase, ran the tests, and read the ticket. The person who wrote the task knows what it was for. The approver sees a diff and a summary the model wrote about itself. Accountability without information is a rubber stamp, whatever the org chart calls it.

None of that excuses the person in the seat. Whoever is stamping what they have not read owes the refusal, and owes saying out loud that the seat cannot be done, before the sixty-first change instead of in the postmortem. The structure explains the failure without releasing anyone from it.

The second loop is slower and worse. Seniors in a shop are a stock. Juniors who did enough real work to build judgment are the inflow. Judgment here means picking the right heading on a problem you have not seen before, and it is built from decisions whose results came back to you. A senior is someone who has it on most of the problems the shop sees. For thirty years the inflow ran through the small jobs: the first-draft migration, the flaky test, the small fix under review, the bug nobody senior wanted. Those jobs are exactly what the agent now does before lunch. If the agent takes the small work and nothing replaces it, the inflow stops. The stock stays large for years, because the seniors you have are still here, and then it drains all at once as they leave, promote out, or start companies. That delay is why almost nobody treats it as an emergency. The stock looks fine on the day the inflow dies.

The obvious fix is wrong. Handing the small work back to humans throws away the speed and misses why the small work built anyone. Seniors were made by deciding how to do the migration, being wrong about the index, getting paged, and never being wrong about that index again, and the typing along the way was incidental. People become deciders by deciding, and watching an agent decide does not count. The small job came with a small turn and a real consequence. Typing was the tax on the turn, and when the model removed the tax, most shops removed the turn along with it.

What Owning the Turn Means

Steering a boat is a good picture of the job because nobody at the wheel checks every stroke of every oar. The helmsman reads the water, holds the heading, decides when to turn, and answers for where the boat ends up. The Greek word for that role is kybernetes, the helmsman, and it is the root of both cybernetics and govern. Governing has always meant steering.

The turn is a decision with five parts: what the job is, what the work must never touch, what done looks like, when to stop, and who answers for the result. Anyone who has briefed a good engineer knows the shape. The difference now is that the run starts a minute after the brief is written, so a bad brief costs you within the hour instead of within the sprint.

What the agent must never touch belongs to the harness, and I wrote about that list earlier this month in the sledgehammer piece. Money, identity, deletes, anything that has to be safe to run twice: that is the hull, and the hull is code. The turn sits above the hull. It is the human decision the model cannot make for you, because the model does not own the outcome and you do.

The owner is named before the run. The owner reads outcomes: did the boat end up where I said, and if not, what heading do I set next. That is a different kind of reading from the approver’s. The owner holds the intent, the limits, and the result, which is the information the heading needs, where the approver held a diff and a summary the model wrote about itself. Since the agent carries no consequences, the person who set the turn carries them, and that is the correct place for them to sit. Accountability only sticks to a decision the person made, and setting the heading is the decision.

The control line is worth drawing. The owner controls the five lines, the hull, the reading of the result, and the next heading. The owner does not control what the model does on a given run. Answering for the heading includes answering for a miss you did not foresee, and that is the price of the wheel.

The Leverage Points

Three places in this system move everything else.

The first is the unit of work. Right now the unit is the diff, and a human approves diffs. Change the unit to the turn and the human’s job changes with it: write the turn, run the agent, read the result, set the next turn. The queue disappears, because nothing waits for approval, and what remains is a heading and a result.

The second is where accountability attaches. Attach it to the person who wrote the turn, at the moment they wrote it. The postmortem then names a decision instead of a click. “We told the agent it could restart services in the billing cluster” is a sentence a team can learn from, and “Sam approved the pull request” teaches nobody anything.

The third is who gets turns, and this is the pipeline fix. Juniors need small turns back, dozens of them, with consequences that come back to them, and the typing can stay gone. A junior with an agent and a whole small problem gets more decisions in a week than a junior in the old shop got in a quarter, because the typing tax is gone. The inflow to the senior stock can be larger than it ever was, if you route the turns to juniors instead of the approvals.

The Intervention: What to Change This Month

1. Write the turn before the run. Five lines at the top of every agent task: the goal, what it must not touch, what done looks like, when to stop, and the name of the owner. If you cannot fill in five lines, you are not ready to run the agent, and a queue of approvals will not fix that.

2. Name an owner, not an approver. The owner is the person whose heading it is. Their name goes on the run before it starts. When the run lands wrong, the retro asks what heading they set and what they would set next time.

3. Put the checks in the harness and the audit in the log. Every hard rule about what the agent cannot do becomes code the agent runs inside. Every action it took becomes a line someone can read afterward. Review shifts from every diff to sampled outcomes, the way big agent pull requests already forced it to. When a change needs eyes before it lands, the owner says so in the brief. That is a decision inside the turn, made once, and it is different from a standing queue everyone feeds.

4. Give every junior a boat. One whole problem a week, agent at their side, their name on the turn. The page at two in the morning goes to them. They present the retro. If you want to sharpen their eye on purpose, design the handicap for a week, then hand the agent back. The duty runs the other way too: a junior who is watching an agent decide owes asking for the whole problem instead of waiting to be handed one. The turns are what make them senior, and the turns are now cheap.

5. Review turns, not diffs. Once a week, seniors and juniors sit together with three questions per turn: what heading did you set, where did the boat end up, and what would you set differently. That hour builds more judgment than a month of approvals did, because it is about decisions and their results.

What Changes When Someone Owns the Turn

The agent runs at its own speed, because nothing is queued behind a person. Blame lands on a decision, so the team argues about headings instead of about who skimmed. Juniors get many times the decisions they used to get, because the typing time is gone, and the senior stock starts refilling from a bigger pipe than the old one. And the person who used to sit at the back of the boat with a stamp gets to do the job they were hired for.

Final Thoughts

Human in the loop was a comfortable answer to a real fear, and it answers the wrong question. Signing off on work you did not understand is older than software. Every manager who initialed a report they had not read stood at the back of the same boat, and the agent’s speed made the empty wheel visible in weeks instead of years. The model does the work now. The question is who owns the turn, and a stamp at the end of the run is no answer at all. Put a name on the heading before the agent starts, route the small turns to the people who need to become senior, and read outcomes and logs instead of diffs. Then let the agent run as fast as the harness allows, which is faster than the approval queue ever did.

If you want to work with people who set the heading before the run and answer for where the boat ends up, MasteryLab is built for that.

FAQ

What does human in the loop mean for AI agents?

Human in the loop means a person reviews or approves what an AI agent does before it takes effect, usually one pull request, ticket, or message at a time. In practice it puts the person with the least context at the end of the chain and asks them to catch what the model, the tests, and the task author missed. The better version is a human at the helm: a named owner who writes the task, sets what the agent must never touch, defines done, and answers for the result.

Why does human in the loop turn into a rubber stamp?

Because the loop trains the approver to read less. Every clean approval lowers the cost of skimming the next one, and watching a reliable system for a rare failure is a job people are bad at, as Lisanne Bainbridge showed in her 1983 paper “Ironies of Automation.” The approver also holds less information than anyone else in the chain. Put your most careful engineer in that seat and the seat still wins within a few weeks.

Who is accountable when an AI agent makes a mistake?

The person who set the task and decided what the agent was allowed to touch. Accountability only sticks to a decision someone made, and clicking approve on a summary is not a decision about the work. Name an owner before the run, put hard limits in code the agent runs inside, and log every action it takes. Then the postmortem names a decision instead of a click.

How do junior engineers build judgment when AI agents do the junior work?

By getting the decisions back while the typing stays with the agent. Juniors became seniors by deciding how to do a small job, being wrong, living with the consequence, and never making that mistake again. The agent removed the typing and most shops removed the decision with it. Give a junior an agent and a whole small problem every week, with their name on it and the consequences flowing back to them. They get more real decisions in a week than the old junior job allowed in a quarter.