Pairing versus leaving it running
Two working patterns with different economics. Most people use one when the other fits better.
There are two honest ways to work with an agent, and they are not points on a spectrum — they demand different preparation.
Human-in-the-loop
Human-in-the-loop is pairing: you watch the tool calls, redirect mid-turn, correct the plan, review as it goes. You are present.
Strong when: the task is ambiguous, the codebase is unfamiliar, the blast radius is large, or you are still learning what this agent does well. Also the only way to learn — the corrections you make are the data you later encode as standing instructions.
Costs: your full attention, in real time, at the agent's pace. That pace is uneven: bursts of output, then waiting. Sustained pairing is genuinely tiring and quality of supervision decays.
AFK
AFK is initiating and walking away: you write a spec, start the run, and review the result later. The unit of interaction is a pull request rather than a turn.
Strong when: the task is well specified, mechanical, or verifiable by automated checks. Migrations across many files, test backfill, a documented refactor, dependency upgrades with a green suite behind them.
Costs: everything moves to the spec. Ambiguity you would have resolved in one sentence while pairing becomes forty minutes of confidently wrong work. And you review a large diff cold.
Choosing
| Signal | Pair | AFK |
|---|---|---|
| Can you write the acceptance criteria in advance? | No | Yes |
| Will automated checks catch a wrong result? | No | Yes |
| Do you expect to change your mind mid-task? | Yes | No |
| Is the work repetitive across many files? | No | Yes |
| Is the blast radius contained? | Either | Required |
The pragmatic pattern: pair to produce the spec, then go AFK to execute it. One focused session with you present produces a document precise enough that the next session does not need you. That is exactly the spec-and-ticket structure of Module 06.
Watch out
The failure of AFK is almost never the model. It is a spec with an unstated assumption in it. When an unattended run comes back wrong, do not conclude the agent cannot do the task — go find the sentence you did not write.
Try it
Pick the most mechanical item on your task list. Write the spec until you believe a competent stranger could execute it with no questions. Run it AFK. Then, when you review, mark every mistake that traces to a missing sentence rather than a bad decision. That ratio is your spec-writing score.
Takeaways
- Pairing buys correction; AFK buys throughput. They need different inputs.
- Pair to write the spec, then run the spec unattended.
- Failed AFK runs are usually spec bugs, not model failures.
You paired on a task and had to redirect the agent four times. What should you do before the next similar task?
Look at the four redirections and ask which are general. Each one that would apply to any similar task belongs in a standing instruction file (Module 05); each one specific to this task belongs in the spec next time. That is how pairing converts into AFK-ready work.
A course by Pieter Zandbergen