Step 3: Make the agent interview you

For work with meaningful choices, start with a design conversation. Ask the agent to inspect the project, interview you, name the decisions that would change the solution, and propose a plan. Approve the approach before the first edit.

Skipping this conversation does not remove the decisions. It hides them in the implementation, where they are harder to see and more expensive to change. This is the same reason teams use design reviews and RFCs: changing a paragraph is cheaper than rebuilding a system.

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

No edits during discovery. Use your agent’s plan mode if it has one, or say “do not edit until I approve the plan.”
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).
Approve a bounded plan. A plan for one feature gives the eventual diff a clear authority. A roadmap for everything does not.

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.

Try it with your agent

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.
A plan that only restates the request: it has not exposed a decision. The tell of a real one is that it contains a decision you had to make.