Step 3: Make the agent interview you

For anything non-trivial, the cheapest quality gate happens before the first edit: a design conversation where the agent interviews you, names the genuine forks, and gets a plan approved. Skipping it doesn’t skip the decisions. It just moves them into the diff, where they’re expensive to find.

You’ve met this before. RFCs and design reviews: decisions on paper, argued before they’re implemented, because a paragraph is cheaper to change than a system. The agent twist is that the document becomes a conversation, and the reviewer being interviewed is you.

Where this comes from: reviewing months of session logs, the pattern in the human’s interventions was consistent: they were surgical corrections at forks the agent had driven through without asking. The failure isn’t wrong answers; it’s unnamed questions (AF-15). Putting the fork-naming before the work is the structural fix.

What good looks like

Plan mode first. Claude Code has a literal plan mode (the agent reads and asks but can’t edit). Elsewhere: “don’t touch files until I approve a plan” does the same job.
Open questions, one at a time. Interview-style beats a wall of multiple-choice the agent grades itself. You’ll say things the agent wouldn’t have offered as options.
Forks named with a recommendation. The agent states each genuine fork, the plausible readings, and which it would pick and why, then waits. Especially for trigger conditions and state transitions, where an inferred condition is the classic silent wrong turn (AF-14).
The plan is the approval unit. You approve a plan, not a vibe. Scope it to one feature; a plan covering everything approves nothing.

Try it

TRY IT The unnamed fork

you

Add re-crawl logic: when a bookmark changes, re-enqueue it for indexing.

agent

Looking at the store. There are two different things that can "change": the bookmark row itself (URL, tags, notes: your edits) and the fetched page metadata (title, description: the web's drift).

Pick the agent's next move, then see where it leads:

AMetadata change is the natural trigger. Implementing: re-enqueue whenever freshly fetched page metadata differs from what's stored.

you

This is re-crawling half the store every night. Page descriptions drift constantly. I meant when I edit the bookmark's URL.

agent

Reverting the trigger and re-gating on bookmark edits. One wasted nightly run, one revert.

the baseline

A gating condition inferred from surrounding code, implemented without surfacing the fork. The reading was plausible: that's exactly why it shipped, and exactly why it was wrong quietly instead of loudly. AF-14

BThat's a fork I shouldn't pick silently. Reading (1): the bookmark row changes. You edited it. Reading (2): the fetched page changed. Web drift. (1) re-crawls on your edits; (2) re-crawls on the internet's churn, which could be most of the store nightly. Which did you mean?

you

(1). And actually, narrower: URL edits only. Retagging shouldn't trigger a crawl.

agent

Gating on URL change only, then. Spec in one line: re-enqueue iff bookmarks.url differs after an edit. Tags and notes never trigger.

correct

The exact condition restated with its alternative readings, and the human picked. Note what the interview surfaced: the real spec ("URL only, not tags") was narrower than either reading. Inference would never have produced it. AF-14 · AF-15

CI'll implement both triggers behind a config flag (re_crawl_mode: metadata | bookmark), defaulting to metadata. Covers either intent.

you

Why is there a config flag? Which one is running? …and why did everything re-crawl last night?

agent

The default is metadata mode, which re-crawls on page drift. You'd want the flag flipped. And the flag, tests, and docs now all exist for a mode nobody asked for.

plausible but wrong

Implementing both is the fork dodged, not answered: doubled surface area, and the wrong default still shipped. A configuration option is not a decision. AF-14 · AF-15

Do it by hand

Next non-trivial task, open with:

“Enter plan mode. Interview me about this, one open question at a time, until you can state the goal, the non-goals, and the forks. Then propose the plan and wait.”

And when an agent presents you options mid-work, notice it: that’s the pattern working. Answer the fork; don’t wave it through.

Or paste this into Claude

Before writing any code for this task, enter plan mode (if you have no
plan mode: make no edits yet). Interview me (one open question at a
time, no multiple-choice) until you can state: the goal in one
sentence, the non-goals, the constraint most likely to bite, and the
two or three genuine forks with your recommendation for each. Where a
trigger or gating condition is involved, restate the exact condition
and the plausible alternative readings, and make me pick. Then present
the plan and wait for approval before touching anything.

Watch out

The interview that answers itself: multiple-choice questions where the agent picks a default if you hesitate are forks driven through with extra steps. Insist on open questions.
Plan-mode theater: a plan restating the request isn’t a plan. The tell of a real one is that it contains a decision you had to make.