When the AI coding assistant hands the work back, who on the team can take it?

I spent an evening reading the Claude Code changelog for 17 to 19 September, which is not a sentence I expected to write about my own free time. Five releases in three days. Inside them: a new key that interrupts the current turn and sends every queued message at once. A fix for a resumed background agent that had kept half of an interrupted batch of tool calls. And my favourite, from version 2.1.277 on 18 September: “Fixed messages typed while Claude is still working sometimes being ignored by the model.”

Read that last one slowly. A person watched something go wrong, typed, and the system did not hear them.

None of this is a scandal. It is ordinary engineering, published in public, and I would far rather use a tool whose makers file these than one that never mentions them. What caught me was the shape of the week. The cluster was not about making the agent cleverer. It was about the seam where a human tries to get back in.

The belief holding up the whole agentic coding market is that this seam is cheap. The agent works, and if it goes wrong an experienced engineer steps in and takes over. Every engineering leader I speak to believes some version of that. It is the most expensive wrong assumption in the category right now.

Why a senior engineer looks like the safety net for an agentic AI coding assistant

Give the belief its due, because it is not stupid. For thirty years it was simply true. Someone who knew the code was always one keystroke from the keyboard, because they had been at that keyboard yesterday. Handover was free, because there was no handover. The person reviewing a change had usually written its neighbour.

That is also the story the board hears. Risk is contained because a human is in the loop. The phrase does a lot of quiet work in a risk register.

Let me define the thing I keep pointing at. A harness is the software layer that runs an AI coding agent: it decides what the agent may touch, when it may act, and what a person sees while it works. An agentic AI coding assistant is one that plans its own steps and calls tools rather than just suggesting the next line, so the harness is the only place the intervention question can actually be answered.

The honest answer most harnesses give today is: we will let a person back in, eventually, and they will arrive somewhere slightly past where they were looking.

What a week of AI powered coding assistant fixes says about interrupting a run

Put that changelog cluster next to a second thing published inside the same week, and the picture sharpens.

On 17 September, The Anthropic Institute published a set of measurements about the pace of its own AI development, including how it supervises its internal agents. It reports roughly 30,000 agents doing research and engineering work on its most-used internal platform at any one time, and says every one of their actions passes through an automated checker before it runs. That checker is what they call an online monitor: a program that inspects each proposed action in the instant before it happens and can refuse it.

Two things about that number, in fairness to it. It is self-reported and unaudited. And it is not a failure rate, it is a refusal rate, which is a better thing to publish.

Now look at what happens to the ones that get blocked. The same page says: “Automated review happens before an agent takes action; humans review any blocked actions within one week.”

That is a sane, well-run process. It is also not takeover. It is archaeology. The person arrives long after the moment, reads a record, and forms an opinion about a world that has moved on. Fine for reviewing a refusal. Useless as preparation for the day someone has to grab the controls.

The 1995 driving study that still predicts the handover gap

The research on this is older than most of the people shipping agents.

In 1995, Mica Endsley and Esin Kiris published a study in Human Factors that automated a car navigation task using an expert system, an early kind of rule-based software that hands over an answer instead of helping a person work one out. They ran it at five levels of operator control, from fully manual at one end to fully automatic at the other, then made the system fail and watched what people did.

The finding has held up for thirty years. The performance drop after the failure was significantly worse under full automation than under the in-between levels, where the person still had some part to play. Situation awareness, meaning the live mental picture of what the system is doing and why, was lowest under full automation too. The field calls this the out-of-the-loop performance problem: the operator who was least involved while things were going well is the one least able to act when they stop.

Nothing about that mechanism cares whether the task is a car or a codebase.

The moment you most need to understand the system is the moment you have been least involved in it.

Pause is not a stop, and our own product says so in writing

I would rather show this in our own code than in someone else’s, because it is the part vendors do not usually publish.

In Cerevisor, our own local-first control plane for running agent workflows, pressing pause on a running workflow does not freeze the world. Model calls and tool executions that are already in flight are never cancelled. They finish. The run stops at the next checkpoint, which is the top of an agent’s turn, or the boundary between one group of agents and the next. So the state a person arrives at is, by design, a little further along than the state that made them reach for the button. That is the right engineering trade, because killing a call halfway through a write is how files get corrupted. It is also a delay nobody puts a number on.

Then there is the failure we shipped and had to fix. An agent can park a run by itself when it needs a person, and a person can park a run by pressing pause. Those used to be the same lock. If an agent had already parked the run to ask a question, a real human pause press landed on a lock that was already held and quietly did nothing. The person pressed stop, and the correct behaviour, by the system’s own rules, was to ignore them. Worse, when we first made the press visible, the interface announced it at the moment the agent had parked the run, so the record showed a person’s own action as having happened at a time they were not there.

The fix was to make a human press outrank everything: it takes the lock over, restamps it with a new identity so the agent’s later release cannot match it, and announces itself at the moment of the press. Worth stealing, if you build these things.

One more, because it is the most uncomfortable. We support Codex as one of the engines that can drive an agent, and it runs as a single uninterruptible job: once it starts, there is no way to stop it partway. So if someone pauses during one, we let it finish and then write a handover document into the project folder, holding the original task and the work that just completed, which a later re-run of that same agent reads as its starting context. It is genuinely useful. It is also worth saying out loud: the document that briefs the human on what happened was written by the thing they are taking over from, and it carries no independent account of the work. Anyone who wants to see how that path behaves before needing it can read the guide on continuing an interrupted run, which walks through what survives and what does not.

Rehearsed takeover beats every AI coding assistant benchmark

So here is the reframe I would offer instead of the safety-net story.

Takeover is not a fallback. It is a skill, it decays without use, and it is the capability an agent strategy quietly spends first. The question worth asking about any AI coding assistant tools decision is not which model wins which benchmark. Whether the best AI coding assistant this quarter turns out to be a hosted product or an open source AI coding assistant running on hardware the company owns, the number that decides how the bad afternoon goes is the same: how long between a person deciding to intervene and that person actually holding the controls, with enough of a picture to use them.

Nobody sells that number. It has to be measured, the way operations teams have rehearsed failover for decades.

1. Pick one real workflow, not a demo

   Something with actual consequences, running the way it runs on a normal day. A rehearsal on a toy task measures nothing worth knowing.

2. Have a named person press stop halfway through

   Start a stopwatch at the press. Stop it when the run has genuinely come to rest, not when the button changed colour. That gap is the first number.

3. Make that person explain the state out loud

   What has been changed, what is half done, what the agent was about to do next. Time how long the explanation takes to become confident. That is the second number, and it is the one that predicts the bad afternoon.

4. Finish the task by hand, then rotate the engineer next month

   No agent for the rest of that task. Run it monthly with a different person, because the skill decays individually, not as a team average.

The first run will be embarrassing. That is rather the point, and it is much better to be embarrassed on a Tuesday of one’s own choosing.