Interview Mode: Let Claude Code Ask the Questions First

Official Sources

Most developers start wrong. You fire up Claude Code, paste a prompt, and hit enter. Claude makes assumptions. Lots of them. By the time the code appears, you realize you wanted OAuth instead of sessions, or a third-party auth service instead of rolling your own.

Then you rework everything.

Spec-driven development flips this. Let Claude ask the questions first.

The Problem With One-Shot Prompts

When you ask Claude to "add authentication to my app," it has to guess. Is it a SPA? Mobile app? What's your auth strategy? JWT? Sessions? OAuth? Do you need multi-tenancy? Should you use a managed service like Clerk or WorkOS?

For the broader agentic coding map, read Claude Code Agent Teams, Subagents, and MCP: The 2026 Playbook and Why Skills Beat Prompts for Coding Agents in 2026; they connect this article to the surrounding tool and workflow decisions.

You didn't specify. Claude didn't ask. It shipped code based on assumptions that were cheap to change before being built, but expensive after.

This is the hidden cost of prompt-driven development: you're making critical architectural decisions implicitly, discovering them later during code review when fixing them means throwing away tokens and time.

Interview First, Spec Second, Code Last

The antidote: let Claude interview you.

This idea, shared by Tariq at Anthropic, is straightforward: instead of guessing what you want, Claude uses the Ask User Question tool to drill into requirements. Not obvious questions - deep ones.

One developer reported Claude asked 40+ questions before finalizing the spec. 40 questions they never would have answered upfront, but that made the spec bulletproof.

The workflow looks like this:

1. Provide a minimal prompt ("I'm building a Next.js marketing site for developers")
2. Let Claude interview you using Ask User Question tool - technical decisions, UI/UX concerns, trade-offs
3. Output a detailed spec (not code)
4. Start a new session to execute against that spec

This forces decisions to the surface when they're cheap to change.

How It Works in Practice

You create a skill that triggers the interview automatically. The prompt is simple:

"Read the spec.md and interview me using the Ask User Question tool about technical implementation, UI and UX concerns, trade-offs. Make sure questions aren't obvious. Be in-depth and continue until complete. Then write the spec to the file."

Claude asks. You answer. It synthesizes into a formal spec. No code yet.

This is not a replacement for Plan Mode (which you should still use). Think of interview mode as the precursor to planning - nail requirements first, then plan implementation.

Why This Actually Saves Time

Counterintuitive: slowing down speeds you up.

The longer you spend planning, the less time reworking. Because you're narrowing the solution space before Claude burns tokens generating code.

Instead of discovering buried assumptions during code review, you confront them when they're cheap to change. Instead of you guessing and Claude correcting, Claude asks clarifying questions instead of making assumptions.

This is a fundamental shift in how agentic AI works. Traditional prompt engineering demanded perfect instructions upfront. Spec-driven development lets AI help you discover what you actually want - because you probably don't know all the nuances before talking it through.

The Real Win

You get control back.

Most AI coding tools work top-down: you specify, they build. Here, it's bidirectional. Claude doesn't assume. It asks. You don't have to guess. You decide.

For large features, this changes everything. For a complex auth system, CMS integration, or multi-tenant setup, the difference between building once and building twice is hours of wasted effort.

Next time you have a large feature, try it. Don't cram everything into one prompt. Let Claude interview you. You'll be shocked how many requirements you didn't even know you had.

---

Further Reading

• Tariq's original insight: Search "spec-driven development Claude Code" on Twitter for the original thread
• In Claude Code: Try creating a skill that triggers interview mode - the Ask User Question tool is built in and designed for exactly this workflow

---

Frequently Asked Questions

What is interview mode in Claude Code?

Interview mode is a workflow where you let Claude Code ask you clarifying questions before writing any code. Instead of giving a one-shot prompt and letting Claude make assumptions, you use the Ask User Question tool to have Claude drill into requirements, technical decisions, and trade-offs. The output is a detailed spec, not code - code comes in a separate session after requirements are locked.

How do I enable interview mode in Claude Code?

Create a skill (markdown file in .claude/commands/) with a prompt like: "Read the spec.md and interview me using the Ask User Question tool about technical implementation, UI/UX concerns, and trade-offs. Continue until requirements are complete, then write the spec." When you invoke this skill, Claude switches into interview mode and asks questions instead of generating code.

Why is interview mode better than a detailed prompt?

You do not know all your requirements upfront. A detailed prompt forces you to guess. Interview mode surfaces decisions you did not know you needed to make - authentication strategy, error handling approach, edge cases, accessibility needs. Discovering these during a 5-minute interview is cheap. Discovering them after 500 lines of generated code is expensive.

How many questions should Claude ask in interview mode?

There is no fixed number. Some developers report Claude asking 40+ questions for complex features. The goal is comprehensiveness, not speed. A thorough interview covers technical architecture, UI/UX decisions, edge cases, constraints, and trade-offs. Stop when you feel confident the spec is complete enough to implement without ambiguity.

What is the difference between interview mode and plan mode?

Plan mode (Shift+Tab in Claude Code) outputs an implementation plan before writing code - which files to change, in what order. Interview mode comes before planning - it locks down requirements so the plan is based on complete information. Use interview mode first for complex features, then switch to plan mode for the implementation phase.

Does interview mode work for small tasks?

For simple, well-defined tasks - fixing a typo, adding a utility function, renaming a variable - interview mode is overkill. Use it for features with multiple moving parts: authentication systems, payment integrations, multi-step workflows, anything where architectural decisions matter. The rule of thumb: if you could imagine building it two different valid ways, interview first.

Can I skip questions during the interview?

Yes. If a question is not relevant or you want Claude to make its own decision, say so. "Use your best judgment" or "Not relevant to this feature" are valid answers. The interview should clarify what matters, not waste time on minutiae. Claude adapts based on your responses.

Where do I store the spec after the interview?

Most developers use a spec.md file in the project root or in a docs/ directory. The spec becomes the source of truth for the next session. When you start a new Claude Code session to implement, reference the spec: "Implement the feature described in spec.md." The separation between interview session and implementation session keeps context clean.

---

Watch the Video