A Field Guide to Fable: Finding Your Unknowns

Kernpunkte

1. Rahmenmetapher: die Karte ist nicht das Territorium. Die Karte = das, was man Claude gibt (Prompts, Skills, Kontext). Das Territorium = wo die Arbeit stattfindet (Codebase, reale Welt, Einschränkungen). Die Lücke zwischen beiden = die Unknowns. Bei einem Unknown entscheidet Claude anhand seiner besten Vermutung darüber, was man will → je größer die Arbeit, desto mehr Unknowns tauchen auf.
2. Das Fable-Plateau. "Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns" – der Engpass hat sich vom Modell zur menschlichen Klarheit verschoben. Vorausplanen allein reicht nicht: Unknowns tauchen mitten in der Implementierung auf oder zeigen, dass das Problem anders hätte gelöst werden müssen. → ein iterativer Prozess: die eigenen Unknowns vorher, während und nachher entdecken.
3. Die 4 Quadranten (Unknowns-Matrix). Known knowns = was im Prompt steht (was man explizit will); Known unknowns = was man noch nicht geklärt hat, sich aber dessen bewusst ist; Unknown knowns = "too obvious to write down, but I'd recognize it" (das "I'll know it when I see it"); Unknown unknowns = "the pothole you didn't know the road could have".
4. Die eigentliche Fähigkeit. "reducing and planning for your unknowns is THE skill of agentic coding". Die Besten (zitiert werden Boris, Jarred) haben wenige Unknowns (im Einklang sowohl mit der Codebase als auch mit dem Verhalten des Modells), gehen aber davon aus, dass einige verbleiben. Die gute Nachricht: Diese Fähigkeit verbessert sich durch die Arbeit mit Claude.
5. Claude zu instruieren ist eine heikle Balance. Zu präzise → Claude folgt den Anweisungen, selbst wenn ein Kurswechsel besser wäre. Zu vage → Claude füllt mit Branchen-Best-Practices auf, die nicht unbedingt zum Fall passen. Ohne Management der eigenen Unknowns scheitert man auf beiden Seiten. Abhilfe: Claude Kontext zum eigenen Ausgangspunkt geben (wo man in seinem Denken steht, welche Erfahrung man mit dem Problem hat) und es als Denkpartner behandeln. Claude durchsucht Codebase und Web sehr schnell und iteriert schneller als wir aus Fehlschlägen.
6. VORHER – Blindspot Pass. Beim Arbeiten in unbekanntem Terrain (unknown unknowns) Claude bitten, seine blinden Flecken zu finden und zu erklären. Die wörtlichen Begriffe "blindspot pass" und "unknown unknowns" verwenden, plus Kontext dazu, wer man ist. Z. B.: "I'm adding a new auth provider but I know nothing about the auth modules… do a blindspot pass"; "teach me to understand my unknown unknowns about color grading so I can prompt better".
7. VORHER – Brainstorms & Prototypen. für unknown knowns (Kriterien, die man nur durch Sehen definieren kann, z. B. visuelles Design). Sie früh verbalisieren, da ihre Entdeckung während der Implementierung teuer ist (eine kleine Spezifikationsänderung kann radikal anderen, schwer rückgängig zu machenden Code bedeuten). Fast jede Session mit einer Explorations-/Brainstorming-Phase beginnen, um den Umfang festzulegen (weder zu eng noch zu weit). Z. B.: "make me an HTML page with 4 wildly different design directions so I can react to them"; "mock the new toolbar in a single HTML file with fake data before you touch the real app"; "brainstorm 10 places we could intervene, cheapest to most ambitious".
8. VORHER – Interviews. Nach dem Brainstorming Claude bitten, uns zu den verbleibenden Unklarheiten zu befragen, eine Frage nach der anderen, mit Priorität auf "questions where my answer would change the architecture".
9. VORHER – Referenzen. Wenn man nicht beschreiben kann, was man will, ist die beste Referenz der Quellcode. Fable auf einen Ordner/eine Bibliothek verweisen (auch in einer anderen Sprache) und sagen, wonach dort gesucht werden soll. Claude Design funktioniert so: Auf das Modul einer Site verwiesen, liest es den zugrunde liegenden Code (Markup, Struktur, tatsächlichen Aufbau), nicht nur den Screenshot. Z. B.: "this Rust crate implements the exact backoff I want — reimplement the same semantics in our TypeScript client".
10. VORHER – Implementierungsplan. einen Plan anfordern, der von den Entscheidungen geleitet wird, die sich am wahrscheinlichsten ändern (Datenmodelle, Typ-Interfaces, UX-Abläufe), und der mechanisches Refactoring nach unten verlagert ("I trust you on that part"). Der Plan bringt zutage, was man tatsächlich anpassen muss.
11. WÄHREND – Implementation Notes. Wie viel auch geplant wird, unknown unknowns bleiben bestehen (der Agent stößt beim Coden auf einen Grenzfall). Claude Code eine temporäre implementation-notes.md führen lassen, die Entscheidungen protokolliert, "so we can learn from our next attempt". Z. B.: "if you hit an edge case that forces a deviation, pick the conservative option, log it under 'Deviations', and keep going".
12. DANACH – Pitches & Explainer. Shipping bedeutet, Zustimmung und Freigaben zu erhalten. Prototyp + Spezifikation + Notes in einem einzigen Dokument bündeln, das "lead[s] with the demo GIF" → beschleunigt das Verständnis (Reviewer gehen von denselben Unknowns aus wie man selbst) und die Freigaben (Experten wollen sehen, dass ihre Fehlerquellen abgedeckt wurden).
13. DANACH – Quizzes. Nach einer langen Session liefert das bloße Lesen der Diffs nur ein oberflächliches Verständnis (das Verhalten hängt von bestehenden Codepfaden ab). Claude um einen HTML-Report + ein Quiz zu den Änderungen bitten – "I only merge after I pass the quiz perfectly".
14. Beweis am Beispiel: das Fable-Launch-Video. , komplett mit Claude Code geschnitten in einem Fachgebiet, das Thariq nicht beherrschte – er geht von dem aus, was er weiß (Claude kann Video per Code bearbeiten/transkribieren), lässt sich Whisper/ffmpeg erklären, prototypt eine wortgenau getimte UI via Remotion und lässt sich dann von Claude Color Grading beibringen (ohne Vorstellung davon, was "gut" bedeutet), statt blind Varianten generieren zu lassen.
15. Schlusssatz. "every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix" → "start your next project by asking Claude to help you find your unknowns". Der Lernrückstand wird zur Karte für das nächste Mal ("what you learn becomes the map for next time").
16. Links. konvergiert mit dem Compounding Knowledge Lifecycle (das Gelernte kapitalisieren), Loop Engineering und der Notiz [[willison-fable-judgement-delegation-subagents-2026-07-03]] (gleicher zitierter Autor, Thariq, gleicher Moment zu Fable) – zwei komplementäre Facetten: Willison zum Fable urteilen lassen, Thariq zur Reduzierung der eigenen Unknowns, um es besser anzuleiten.