Fable Field Guide: Meine Unknowns finden

• Der Kern der Arbeit mit Claude Fable 5 besteht darin, die Lücke zwischen der Karte (map, Prompts·Skills·Kontext), die der Nutzer vorgibt, und dem Territorium (territory, Codebase·Realität·Constraints), in dem die Arbeit tatsächlich stattfindet — also die Unknowns — zu finden und zu verkleinern.
• Fable ist das erste Modell, bei dem die Arbeitsqualität davon abhängt, wie gut Nutzer Unknowns klar benennen können; je größer die Aufgabe, desto mehr Unknowns tauchen auf.
• Unknowns lassen sich in vier Kategorien einteilen: Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns. Unknowns zu reduzieren und sich darauf vorzubereiten, ist eine Kernkompetenz beim agentischen Coding.
• Unknowns werden vor, während und nach der Implementierung mit iterativen Techniken entdeckt: Blindspot Pass, Brainstorming, Interviews, Referenzen, Implementierungspläne, Implementation Notes, Quizze usw.
• Erklärungen, Brainstorming, Interviews, Prototypen und Referenzen sind Mittel, um Unknowns günstig zu entdecken, bevor Probleme teuer werden. Wichtig ist, das nächste Projekt damit zu beginnen, Claude um die Suche nach Unknowns zu bitten.

---

Karte, Territorium und Unknowns

• Die Karte ist die Darstellung der auszuführenden Arbeit: Prompts·Skills·Kontext, also das, was man Claude gibt. Das Territorium ist dort, wo die Arbeit tatsächlich passiert: Codebase·Realität·tatsächliche Constraints.
• Der Unterschied zwischen Karte und Territorium sind die Unknowns. Wenn Claude auf Unknowns stößt, muss es Entscheidungen auf Basis seiner besten Vermutung darüber treffen, was der Nutzer will.
• Fable ist das erste Modell, bei dem die Arbeitsqualität durch die Fähigkeit, Unknowns klarzumachen, zum Bottleneck wird.
• Vorausplanung allein reicht nicht aus; Unknowns werden tief in der Implementierung entdeckt oder zeigen, dass ein Problem sogar auf völlig andere Weise gelöst werden muss.
• Arbeit mit Fable ist ein iterativer Prozess, bei dem vor, während und nach der Implementierung Unknowns entdeckt werden.
• Einige Beispielmaterialien, die beim Finden von Unknowns helfen, später als Referenz nutzen.

Die eigenen Unknowns kennen (Knowing your unknowns)

• Das Problem in vier Kategorien zerlegen:
  • Known Knowns: Was im Prompt steht, was man dem Agenten sagt, dass man es will.
  • Known Unknowns: Dinge, die man noch nicht verstanden hat, aber von denen man weiß, dass man sie nicht verstanden hat.
  • Unknown Knowns: Dinge, die so selbstverständlich sind, dass man sie nicht aufschreibt, die man aber erkennt, wenn man sie sieht.
  • Unknown Unknowns: Dinge, die man gar nicht berücksichtigt hat; Wissen, dessen man sich nicht bewusst ist; das Unwissen darüber, wie gut etwas werden könnte.
• Hervorragende agentische Coder haben relativ wenige Unknowns und sind mit der Codebase und dem Modellverhalten tief synchronisiert (in-sync), sodass sie sehr genau wissen, was sie wollen.
• Unknowns zu reduzieren und sich darauf vorzubereiten, ist eine Fähigkeit, die sich durch die Arbeit mit Claude verbessern lässt.

Claude helfen, dir zu helfen (Help Claude help you)

• Bei Anweisungen ist Balance wichtig: Sind sie zu konkret, folgt Claude ihnen auch dann, wenn ein Richtungswechsel besser wäre; sind sie zu vage, trifft Claude Entscheidungen auf Basis von branchenüblichen Best Practices, die nicht zur Aufgabe passen.
• Wenn man Unknowns nicht berücksichtigt, scheitert man auf beiden Seiten: Man möchte, dass Claude die Richtung ändert, ohne zu wissen, wann ein Pfad blockiert ist und wann er frei wird.
• Claude beschleunigt das Entdecken von Unknowns, weil es Codebases und das Internet schnell durchsucht, über durchschnittliche Themen mehr weiß und schnell aus Fehlschlägen iteriert.
• Am wichtigsten ist es, Kontext zum Ausgangspunkt zu geben: den eigenen Stand im Denkprozess, Erfahrung mit dem Problem und der Codebase offenlegen und wie mit einem Denkpartner zusammenarbeiten.
• Ich habe früher darüber geschrieben, HTML in Claude zu verwenden; in den meisten Fällen sind HTML-Artefakte optimal für Visualisierung und Darstellung.

Vor der Implementierung (Pre-implementation)

• Blind Spot Pass

  • Bei ungewohnten Aufgaben wie dem Schreiben von Features in einem neuen Bereich oder Design-Iterationen gibt es viele unknown unknowns: Man weiß möglicherweise nicht, welche Fragen man stellen soll, was gut ist, welche früheren Arbeiten es gab oder welche Fallen zu vermeiden sind.
  • Bitte Claude, unknown unknowns zu finden und zu erklären. Wichtig ist, die Begriffe „blindspot pass“ und „unknown unknowns“ genauso zu verwenden und Kontext dazu zu geben, wer man ist und was man weiß.
  • Beispiel-Prompts
    • „Ich arbeite daran, einen neuen Auth Provider hinzuzufügen, kenne das Auth-Modul in dieser Codebase aber überhaupt nicht. Mach einen blindspot pass, finde relevante unknown unknowns und hilf mir, besser zu prompten.“
    • „Ich weiß nicht, was color grading ist, muss dieses Video aber graden. Bring mir die unknown unknowns von color grading bei, damit ich besser prompten kann.“

• Brainstorming und Prototypen (Brainstorms and prototypes)

  • In Bereichen mit vielen unknown knowns, also vielen Kriterien, die man erkennt, wenn man sie sieht, aber schwer vorab definieren kann, sollte man mit Claude brainstormen und prototypisieren.
  • Es ist wertvoll, unknown knowns früh im Prototyping zu identifizieren und zu versprachlichen, statt erst während der Implementierung, weil kleine Änderungen an der Spezifikation die Code-Implementierung stark verändern können und frühere Änderungen schwer rückgängig zu machen sind.
    • Beispiel: Wenn man nur sehen möchte, wie ein Button in einem Frame wirkt, ohne Backend-Routen oder Frontend-State.
  • Visuelles Design ist ein Bereich, der schwer klar auszudrücken ist, bei dem man aber weiß, was man will, wenn man es sieht; bitte daher um mehrere Designansätze.
  • Fast jede Coding-Session mit einer Explorations- und Brainstorming-Phase zu beginnen, hilft, die Absicht festzulegen und den Scope zu definieren; das verhindert einen zu engen oder zu breiten Scope.
  • Beispiel-Prompts
    • „Ich möchte ein Dashboard für diese Daten, habe aber kein visuelles Gespür und weiß nicht, was möglich ist. Erstelle HTML-Seiten mit vier völlig unterschiedlichen Designrichtungen, damit ich darauf reagieren kann.“
    • „Erstelle eine einzelne HTML-Datei, die eine neue Editor-Toolbar mit Fake-Daten mockt, bevor wir sie verbinden. Ich möchte auf das Layout reagieren, bevor wir die echte App anfassen.“
    • „Das grobe Problem ist Nutzerabwanderung nach dem Onboarding. Durchsuche die Codebase und brainstorme 10 mögliche Interventionspunkte, von der günstigsten bis zur ambitioniertesten Maßnahme.“

• Interviews

  • Wenn nach ausreichend Brainstorming noch Unknowns übrig sind, bitte Claude um ein Interview zu Unknowns und Unklarheiten; gib Problemkontext, damit Claude Fragen anstoßen kann.
  • Beispiel-Prompts
    • „Stelle jeweils eine Frage zu unklaren Punkten und priorisiere Fragen, deren Antwort die Architektur verändern würde.“

• Referenzen (References)

  • Wenn man nicht detailliert beschreiben kann, was man will, ist die beste Antwort eine Referenz. Das können Diagramme, Dokumente oder Bilder sein, aber Source Code ist mit Abstand die beste Referenz.
  • Wenn es eine Library gibt, die auf eine bestimmte Weise implementiert ist, oder eine Designkomponente, die einem gefällt, kann man auch bei einer anderen Sprache auf den Ordner zeigen und Claude anweisen, dort nachzusehen.
  • Claude Design funktioniert genauso: Wenn man auf ein Modul einer Website zeigt, die man mag, liest Claude nicht nur den Screenshot, sondern den zugrunde liegenden Code und liefert reichhaltige Informationen zu Markup, Struktur und tatsächlicher Implementierung.
  • Beispiel-Prompts
    • „Diese Rust-Crate in vendor/rate-limiter implementiert genau das gewünschte Backoff-Verhalten. Lies sie und implementiere dieselbe Semantik in unserem TypeScript-API-Client neu.“

• Implementierungspläne (Implementation Plans)

  • Wenn man bereit für die Implementierung ist, sollte man einen Implementierungsplan zur Prüfung anfordern, der sich auf die am wahrscheinlichsten zu ändernden Teile konzentriert (Datenmodell, Typ-Interfaces, UX-Flows), um Punkte sichtbar zu machen, die angepasst werden müssen.
  • Beispiel-Prompts
    • „Schreibe den Implementierungsplan in HTML, stelle die Entscheidungen nach oben, die ich am ehesten anfassen werde (Änderungen am Datenmodell, neue Typ-Interfaces, nutzerseitige Elemente), und verschiebe mechanische Refactorings ganz nach unten.“

Während der Implementierung (During implementation)

• Implementation Notes

  • Wenn man mit dem Plan zufrieden ist, erstellt man eine neue Session, übergibt Artefakte wie Spezifikationsdateien und Prototypen im Prompt und bittet den Agenten um die Implementierung.
  • Egal wie viel man plant: unknown unknowns lauern immer. Edge Cases, die der Agent während der Arbeit entdeckt, können ein anderes Vorgehen erforderlich machen.
  • Lass Claude Code Entscheidungen in einer temporären Datei implementation-notes.md (oder .html) festhalten, damit der nächste Versuch daraus lernt.
  • Beispiel-Prompts
    • „Pflege eine Datei implementation-notes.md. Wenn du auf einen Edge Case triffst, der dich vom Plan abweichen lässt, triff eine konservative Entscheidung, dokumentiere sie unter ‚Deviations‘ und fahre fort.“

Nach der Implementierung (Post implementation)

• Pitches und Erklärmaterialien (Pitches and explainers)

  • Einer der wichtigsten Teile beim Veröffentlichen von etwas ist, Zustimmung und Freigabe zu erhalten. Dafür hilft es, Pitch- und Erklär-Artefakte in die abschließende Dokumentation aufzunehmen.
    • Wenn Reviewer bei denselben Unknowns starten wie du, beschleunigt das das Verständnis.
    • Wenn Experten prüfen wollen, ob Unknowns und häufige Fehlerpunkte berücksichtigt wurden, beschleunigt das die Freigabe.
  • Beispiel-Prompts
    • „Fasse Prototyp, Spezifikation und Implementation Notes zu einem einzelnen Dokument zusammen, das ich in Slack posten kann, um Zustimmung zu bekommen. Stelle das Demo-GIF nach vorne.“

• Quizze (Quizzes)

  • Nach einer langen Arbeitssession hat Claude möglicherweise mehr geschafft als erwartet; ein Code-Diff allein vermittelt nur oberflächlich, welches Verhalten von bestehenden Codepfaden abhängt.
  • Gib Kontext und bitte Claude, ein Quiz zu den Änderungen zu erstellen, um dein Verständnis zu prüfen. Merge erst, wenn du das Quiz vollständig bestanden hast.
  • Beispiel-Prompts
    • „Ich möchte alles verstehen, was in dieser Änderung passiert ist. Erstelle einen HTML-Report mit Kontext, Intuition und den durchgeführten Arbeiten und hänge unten ein Quiz an, das ich bestehen muss.“

Wie das beim Fable-Launch zusammenkommt (How this comes together)

• Das Fable-Launch-Video wurde vollständig mit Claude Code geschnitten; es war ein neuer Bereich und nicht mein Fachgebiet.
• Ausgehend von dem, was ich wusste: Ich wusste, dass Claude Videoschnitt und Transkription per Code kann, war mir bei der Genauigkeit aber unsicher. Daher bat ich um eine Erklärung der Whisper-artigen Transkriptionsprinzipien und darum, ob sich ums und lange Pausen mit ffmpeg exakt herausschneiden lassen.
• Ich wollte eine UI, bei der gesprochene Wörter und Timing zusammenpassen, war aber unsicher, ob das möglich ist. Also ließ ich mit Remotion und Transkription ein Prototyp-Video erstellen und validieren.
• Ich wusste, dass das Video etwas muted wirkte, weil Color Grading fehlte, wusste aber nicht, was das genau ist. Statt Varianten auszusortieren, bat ich darum, mir Color Grading beizubringen, um Unknowns zu entdecken.

Karte und Territorium abgleichen (Matching the Map and Territory)

• Je besser Modelle werden, desto mehr lässt sich mit dem richtigen Ansatz erreichen. Wenn eine langfristige Aufgabe falsch zurückkommt, muss man meist mehr Zeit in die Definition von Unknowns oder in einen Implementierungsplan investieren, der Claude spontanes Reagieren erlaubt.
• Alle Erklärungen, Brainstormings, Interviews, Prototypen und Referenzen sind Mittel, um Unknowns günstig zu entdecken, bevor Probleme teuer werden.
• Entscheidend ist, das nächste Projekt damit zu beginnen, Claude um die Suche nach Unknowns zu bitten.