What it is
Before any code is written, intent should pass through a dialogue whose job is to compile messy human wishes into an executable specification. The right interaction is closer to a coaching or therapeutic conversation than a command line: the system does not rush to a solution but helps the human discover their own intent, asking why before how, separating goals from the implementations stakeholders propose, reflecting back its current understanding so misreadings surface early, asking for examples of good and bad outcomes, and naming the unknowns and contradictions it finds. The interviewer is skeptical by design — it refuses to start building until it can restate the goal cleanly in its own words, acting as a compiler from ambiguous intent to a specification, and it probes with questions like *what problem are we solving, who experiences it, what happens if we do nothing, what would make the solution unacceptable, what examples define success, what should not be changed, and what proof should the implementation produce.* What the dialogue emits is not a verbose transcript but a working artifact — a concise spec with acceptance criteria, user stories, scenarios, constraints, and open questions — small enough that the human can read it and reject or approve it. This guards against the common failure of treating the first prompt as the spec: the first prompt is an impulse, an input to the intent process, not the final instruction, and an agent that runs with it skips the step where intent is actually determined.
When to reach for it
- A request arrives as a one-line prompt and you are tempted to start building — route it through the interviewer first to turn the impulse into a spec.
- The work is high-stakes or expensive enough that building the wrong thing costs more than the dialogue.
- The goal is ambiguous, contested, or stated as a solution rather than a need.
- You want a durable, inspectable artifact (spec, acceptance criteria, open questions) that downstream agents and humans can both work from.
- An agent keeps producing plausible-but-wrong output because nobody pinned the success criteria before execution.
When NOT to
- The task is small, well-understood, and cheap to redo — a full interview is heavier than the work itself.
- The human genuinely wants exploration, not a spec — forcing premature precision kills the discovery the prototype is meant to provide.
- The interviewer becomes an interrogation that never terminates — if it cannot converge, the bottleneck is missing information, not more questions.
- Speed pressure makes a worse-but-shipped spec preferable to a perfect one that arrives too late.
Exemplars
- Harper Reed, "My LLM codegen workflow atm" (2025) — https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ — origin: the post that canonically describes having the LLM ask "one question at a time" to develop a thorough spec before implementation begins, producing a
spec.mdthe developer can hand off. - Gause & Weinberg, *Exploring Requirements: Quality Before Design* (1989) — https://geraldmweinberg.com/Site/Exploring_Requirements.html — classic antecedent: the foundational work on eliciting genuine needs rather than accepting surface statements; emphasizes helping people articulate what they cannot easily express without skilled questioning.
- Rob Fitzpatrick, *The Mom Test* (2013) — https://www.momtestbook.com/ — classic antecedent: practical discipline for extracting honest needs by asking about the customer's real life and problems rather than seeking validation of a proposed solution — directly parallels "ask why before how."
- Korn et al., "LLMREI: Automating Requirements Elicitation Interviews with LLMs" (arXiv:2507.02564) — https://arxiv.org/abs/2507.02564 — formalizes: empirical study finding LLM chatbots match human interviewer error rates and successfully extract requirements through context-sensitive iterative questioning across 33 simulated stakeholder interviews.