Do the part that is yours
Work kept landing back with the user when the assistant should have carried it.
The headline
Five changes this week. Each one is about work that was left with the user when it should have stayed with the assistant. A physical fix handed over when a software fix was in reach. Review notes the user had already written, ignored by the next revision. A slow check the user had to sit through, and notice for themselves. An estimate whose real cost only showed up when the deadline passed. And testing that only the user could finish.
Why these ones
It was the busiest week so far, with more than twice the usual number of conversations. Most of them were hands-on: small electronics on the bench, a display that would not come up, a design job, a new app built overnight by a team of agents, and an online application form.
On the bench, the same thing happened in three separate sessions. A display showed ghosting, and the assistant went after the wiring before it looked at the driver code. Two serial lines turned out to be crossed, and the user was told to swap them by hand. The answer came back to change the code, not the hardware. A monitor link dropped, and the user, who had already said it was a software problem, was asked to swap the cables back. The week before, a request to lower a voltage had been answered with a hardware trim, when the duty cycle was the control the assistant actually held.
The application form went through a test round. The user filled in the test copy and typed critical remarks straight into its fields. The next version still carried the questions they had marked as out of date. They had also asked for a specific way of testing it: agents playing different kinds of applicant, each reporting the first thing that stopped them, with a fixer agent clearing the way. A lighter round ran instead, and the form went out with no route at all for one whole kind of applicant.
Early in the week the user asked why every reply now ended with a long pause while claims were audited. The checking hook behind it had drifted to over a minute a reply at its worst. Its checker model was doing a large amount of hidden reasoning before writing a one-line verdict, and a timeout that failed open meant the slowest replies were not being checked at all. Switching that reasoning off brought it down to a few seconds, with the same verdicts.
And the overnight app build was estimated at about four and a half hours to everything, based on how fast the agents had been going. They kept that pace. But features kept being added as it ran, and the estimate was never re-quoted against the longer list. The next morning it was another four to five hours, and the following afternoon the user was still asking what was left.
What changed in the guide
Two new behavioural defaults went into chapter one, on the CLAUDE.md file.
The first is pull the lever you hold. When a fault can be fixed in something the assistant controls (code, configuration, a duty cycle, a pin mapping), that comes first. Asking the user to rewire, swap cables or trim a part is the last resort, and the assistant has to argue for it, because it costs the user real time, it cannot be checked from the assistant’s side, and it quietly hands them the work.
The second is the review lives in the artefact. Notes the user leaves inside the thing being reviewed (remarks typed into form fields, marked-up screenshots, document comments) are the specification for the next revision. Gather them first, and say which ones were acted on. And when the user names a method for the next round, the method is part of the ask; running something lighter is a scope cut that has to be said out loud.
One new failure mode went into chapter four, on hooks. A verification hook is paid for on every turn. Time it. Give the checker the cheapest setup that still catches a planted false claim. And treat a timeout that fails open as a coverage gap to log and count, because the replies it skips are exactly the ones most worth checking.
One went into chapter seven, on async work. A pace-based estimate holds only for a frozen task list. Quote an estimate together with the list it covers, and re-quote in the same reply whenever scope is added mid-run, so the cost of the new item lands when it is decided.
And one went into chapter eight, on multi-agent patterns, together with the pattern that fixes it. A user-facing flow tested by the agent that built it is barely tested. Run a persona loop instead. Each agent plays a different kind of real user and works through the live flow until something blocks them. A fixer agent clears that blocker, and the persona carries on from where it stopped. The loop ends when every persona reaches the end.
Housekeeping
Week ten rolled off the ten-week archive and is now a one-line summary in the updates index.
The cards
