Die Interview-Methode: Wie AskUserQuestionTool meinen Claude Code Workflow verändert hat

TL;DR

Meine liebste Art, große Features mit Claude Code zu bauen: spec-basierte Entwicklung
Starte mit einer minimalen Spec, dann lass dich von Claude mit dem AskUserQuestionTool interviewen
Bei großen Features stellt Claude 40+ Fragen—am Ende hast du eine detaillierte Spec, die du wirklich besitzt
Führe die Spec in einer neuen Session mit frischem Kontext aus

Das Problem

Traditionelles Prompting ist rückwärts gedacht. Du schreibst einen Prompt, Claude rät deine Absicht, du korrigierst Missverständnisse, wiederhole. Du machst die schwere Arbeit herauszufinden, welchen Kontext Claude braucht.

Es geht besser.

Die Lösung: Lass dich von Claude interviewen

Dreh den Spieß um. Statt dass du Claude promptest, lass Claude dich interviewen.

Das AskUserQuestionTool ist ein eingebautes Claude Code Feature, das strukturierte Multiple-Choice-Fragen präsentiert. Claude fragt, du klickst. Schnell. Fokussiert. Keine Essays tippen.

So nutze ich es.

Der Workflow

Schritt 1: Starte mit einer minimalen Spec

Erstelle eine SPEC.md Datei mit deiner groben Idee. Sie darf chaotisch sein. Fünf Stichpunkte. Ein Absatz. Was auch immer du hast.

# Feature: User Dashboard

- Nutzungsmetriken anzeigen
- Export nach CSV
- Nach Datumsbereich filtern
- Vielleicht Charts?

Das war’s. Nicht überdenken.

Schritt 2: Starte das Interview-Prompt

Öffne Claude Code und nutze diesen Prompt:

read this @SPEC.md and interview me in detail using the
AskUserQuestionTool about literally anything: technical
implementation, UI & UX, concerns, tradeoffs, etc. but
make sure the questions are not obvious

be very in-depth and continue interviewing me continually
until it's complete, then write the spec to the file

Die Schlüsselteile:

“interview me in detail” — Claude geht in die Tiefe
“using the AskUserQuestionTool” — strukturiertes Q&A, kein Freitext-Chat
“not obvious” — überspringe die Basisfragen, grabe ins Schwierige
“continually until complete” — stoppe nicht nach 5 Fragen

Schritt 3: Beantworte 20-40+ Fragen

Claude beginnt zu fragen. Viel. Bei einem großen Feature erwarte 40+ Fragen zu:

Technische Implementierungsdetails
UI/UX-Entscheidungen
Edge Cases, an die du nicht gedacht hattest
Tradeoffs und Prioritäten
Integrationsfragen
Error Handling
Performance-Überlegungen

Jede Frage kommt mit Multiple-Choice-Optionen. Klicke die passende. Füge Kontext hinzu wenn nötig.

Schritt 4: Erhalte deine detaillierte Spec

Wenn Claude zufrieden ist, schreibt es die finale Spec in deine Datei. Du hast jetzt ein umfassendes Dokument, das jede Entscheidung festhält.

Schritt 5: Ausführen in einer frischen Session

Starte eine neue Claude Code Session. Der alte Interview-Kontext ist weg—das ist Absicht. Deine Spec ist jetzt die einzige Wahrheitsquelle.

implement @SPEC.md

Sauberer Kontext. Klare Anweisungen. Keine angesammelte Verwirrung.

Echte Beispielfragen

So sieht das AskUserQuestionTool in der Praxis aus. Das sind die Art von Fragen, die Claude mir bei einem kürzlichen Dashboard-Feature gestellt hat:

Technische Implementierung

Wie sollen die Metrikdaten abgerufen werden?

Echtzeit WebSocket-Updates

Polling alle 30 Sekunden

On-Demand wenn User aktualisiert

Andere

UX-Entscheidung

Was soll passieren, wenn der Export länger als 5 Sekunden dauert?

Fortschrittsbalken mit Prozentanzeige

Spinner mit “Generiere…” Text

Hintergrund-Export mit Benachrichtigung wenn fertig

Andere

Architektur-Tradeoff

Wo soll die Datumsfilter-Logik leben?

Client-seitig (schnellere UX, mehr Datentransfer)

Server-seitig (weniger Daten, langsamere Antwort)

Hybrid (Server filtert, Client verfeinert)

Andere

Edge Case

Wie soll das Dashboard User ohne Daten behandeln?

Leerer Zustand mit Onboarding-Hinweis

Beispieldaten-Vorschau

Weiterleitung zum Setup-Wizard

Andere

Prioritätsfrage

Für das MVP, priorisiere:

Feature-Vollständigkeit (alle Metriken, alle Exporte)

Polish (weniger Features, bessere UX)

Geschwindigkeit zum Ship (Minimum Viable, schnell iterieren)

Andere

Das sind keine Ja/Nein-Fragen. Sie erzwingen Entscheidungen.

Warum das funktioniert

Du durchdenkst Edge Cases. Die Fragen bringen Szenarien an die Oberfläche, die du sonst mitten in der Implementierung entdecken würdest. Oder schlimmer, in Produktion.

Entscheidungen werden dokumentiert. Jede Wahl wird festgehalten. Sechs Monate später weißt du, warum du WebSocket statt Polling gewählt hast.

Du fühlst Ownership. Du hast jede Entscheidung getroffen. Die Spec ist nicht Claudes Vermutung—es ist deine Produktvision, extrahiert und organisiert.

Saubere Kontexttrennung. Die Interview-Session akkumuliert Kontext. Die Ausführungs-Session startet frisch mit nur der Spec. Keine Verwirrung zwischen Exploration und Implementierung.

Es ist schneller als du denkst. Durch 40 Multiple-Choice-Fragen klicken dauert 10-15 Minuten. Eine so detaillierte Spec von Grund auf schreiben? Stunden.

Die Daten dahinter

Das ist nicht nur meine Meinung. Die Forschung bestätigt es.

MIT fand: Prompts zählen genauso viel wie Modelle. Eine Studie des MIT Sloan zeigte, dass 50% der KI-Leistungsverbesserung durch bessere Prompts kam—nicht durch Upgrade auf bessere Modelle. Wie du kommunizierst, macht den Unterschied.

Strukturierte Ansätze reduzieren Sicherheitslücken. Forschung, die “Vibe Coding” (Ad-hoc-Prompting) mit Spec-Driven Development verglich, fand 85% weniger Sicherheitslücken und 300% bessere Wartbarkeit mit dem Spec-First-Ansatz.

Unstrukturierte Sessions verschwenden Tokens. Eine PDCA-Framework-Studie fand, dass unstrukturierte Coding-Sessions 80% ihrer Tokens nach der Fertigmeldung verbrauchten—nur für Troubleshooting und Behebung von Missverständnissen. Planung im Voraus eliminiert diese Verschwendung.

Kontext degradiert bei langen Sessions. LLM-Generierung wird unzuverlässiger, je länger Sessions dauern. Die Trennung von Planung und Ausführung in separate Sessions—wie dieser Workflow es tut—verhindert Context-Window-Degradierung.

Du bist nicht allein

Mo Bitar nennt das “The Interrogation Method.” Sein Ansatz: lass Claude eine Frage pro Antwort stellen, zeichne das Q&A in einer Transkript-Datei auf, fahre fort bis es komplett ist. Ein 45-minütiges Interview für ein Notification-System generierte ~1.000 Zeilen Transkript. Die Spec produzierte funktionierenden Code beim ersten Versuch.

Seine Zusammenfassung: “The whole game is specification. You live and die by it.”

Andere nennen Variationen dieser Technik “Reverse Prompting” oder “Socratic Prompting.” Die Kernerkenntnis ist dieselbe: lass die KI dich interviewen statt umgekehrt. Es bringt Anforderungen an die Oberfläche, die du sonst übersehen würdest.

Probier es selbst

Nächstes Mal wenn du etwas Nicht-Triviales baust:

Erstelle eine minimale SPEC.md
Starte das Interview-Prompt
Beantworte alles was Claude fragt
Führe die Spec in einer neuen Session aus

Du wirst nie wieder zu traditionellem Prompting für große Features zurückkehren.

Das AskUserQuestionTool ist in Claude Code verfügbar. Wenn du es noch nicht nutzt, lässt du den besten Teil des Workflows auf dem Tisch liegen.