The Handoff Interview: Six Prompts and a Written Rule for Splitting Work in a Pairing Session

A pairing session usually stalls for one reason before any tool gets involved: nobody wrote down who owns the next step. The fix that survives review is a twenty-minute handoff interview that ends in a single written routing rule, not a benchmark number. A rule can be audited, argued with, and edited; a benchmark only records that one side was faster on a task nobody has described precisely. Everything below is an illustrative exercise, and the code is unexecuted scaffolding rather than a tested tool.

Why the conversation drifts

Most teams treat model-versus-human routing as a judgement call made out loud, which means it disappears when the call ends. The pair agrees informally, the patch lands, and no one can reconstruct why that step went to a model instead of to a script on a server. When the same task type returns two weeks later, the conversation restarts from zero with slightly different assumptions. A written rule costs one session and removes that repeated negotiation.

Three alternatives that were considered and set aside

Before the interview format was chosen, three cheaper options were examined and rejected for specific reasons rather than taste.

The common failure is that all three produce an answer without producing evidence. The interview format is slower to start and faster to defend, which matters more once a decision is questioned during review.

The six prompts, in three rounds

The exercise runs best with two people: one who owns the task and one who will review it. Each round produces short written answers, and no round may be skipped because the answer feels obvious. The full set fits on one screen.

1. Round one, scope. Prompt one asks the pair to name the single reversible unit of work, meaning the smallest change that can be undone without touching anything else. Prompt two asks for the blast radius as a file count and a service count, because a number forces precision where an adjective does not.
2. Round two, failure. Prompt three asks how the failure would become visible in an existing test, and a missing answer ends the exercise for that task. Prompt four asks whether the inputs are pinned, so both sides would receive identical context on a rerun.
3. Round three, ownership. Prompt five asks which part of the work requires judgement that cannot be expressed as a test. Prompt six asks who signs the change, which is a name and not a role.

The rule, with precedence made explicit

The value of the artefact comes from ordered precedence, since unordered criteria let a later signal quietly override an earlier one. The router below is illustrative scaffolding that has not been executed against a real session log.

# Illustrative only. Not executed against any production session data.
from dataclasses import dataclass, field


@dataclass
class Handoff:
    reversible: bool
    blast_radius_files: int
    inputs_pinned: bool
    failure_visible_in_test: bool
    needs_human_judgement: bool
    answers: dict[str, str] = field(default_factory=dict)


def route(h: Handoff) -> str:
    # Earlier rules win; later rules never override an earlier refusal.
    if h.needs_human_judgement:
        return "human"
    if not h.inputs_pinned:
        return "human"
    if not h.failure_visible_in_test:
        return "human"
    if not h.reversible and h.blast_radius_files > 1:
        return "human"
    if h.blast_radius_files <= 1:
        return "model-draft"
    return "server-run"


def explain(h: Handoff) -> str:
    decision = route(h)
    reasons = []
    if h.needs_human_judgement:
        reasons.append("judgement cannot be expressed as a test")
    if not h.inputs_pinned:
        reasons.append("inputs unpinned, rerun would not be comparable")
    if not h.failure_visible_in_test:
        reasons.append("failure has no visible test surface")
    return f"{decision}: {', '.join(reasons) or 'scope bounded and reversible'}"

The ordering carries the argument. A judgement call blocks delegation before any tool question is asked, and unpinned inputs block a rerun regardless of how small the change looks. Irreversible multi-file work stays with the human because no rerun recovers it, and everything else falls through to drafting or to a scripted run.

Where free access and a free server enter the rule

The two outsourced branches above need somewhere to run, and that is the only place the tooling matters. MonkeyCode is described by its operators as an open-source project that provides free model access and a free server option, and the outreach brief for this round quotes a free allowance of ten million tokens. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Those availability claims are operator-supplied and were not independently verified while drafting, so the token allowance, any model names, and any server specifications should be confirmed on the project's own listing before capacity is planned around them. The useful reading is narrow: free model access lowers the cost of the model-draft branch, and the free server option lowers the cost of the server-run branch while the rule is being trialled. Neither changes the rule, and neither justifies skipping the interview, because a free rerun still cannot recover an irreversible change.

Validating the rule without a benchmark

Validation here means checking whether the rule reproduces the decisions the pair would defend in review. The method is a replay, and it is described as a plan rather than a result because no replay has been run for this article.

1. Take the last twenty completed tasks from one repository and write down the routing decision each one actually received.
2. Replay those twenty decisions through the router by filling in the Handoff fields from memory of the task, marking any field that cannot be reconstructed with confidence.
3. Log every disagreement between the historical decision and the router output in a single file, with one line of explanation per entry.
4. Edit the rule only when a disagreement traces back to a missing prompt, and reject edits that merely restore a preferred outcome.

A disagreement rate near zero is suspicious rather than reassuring, because it usually means the fields were filled in to match the known answer. Marking reconstruction confidence during step two is the cheapest defence against that bias.

Boundaries and stop rules

The exercise is worth stopping when three consecutive disagreements trace to the same prompt, since that points at a question that is too vague to answer consistently. It is also worth stopping when a task touches production data or credentials, because routing those to any hosted branch needs a separate review path that a pairing rule cannot supply.

Teams that already have a written change-management policy should not adopt this router as a second, competing authority. The same applies to anyone who needs measured throughput numbers before adopting a workflow, because this exercise produces a decision record rather than a performance claim.

The one-page output

The deliverable is a single page with six prompt answers, the routing decision, and the reviewer's name attached to it. That page is small enough to paste into a pull request and specific enough that a later reader can challenge one field instead of the whole session. Teams that want to trial the drafting branch without a procurement step can use MonkeyCode's free model access to run the exercise on low-risk tasks, while keeping the written rule in the repository as the part that outlives any particular tool.