Prompting-Tipps für Fable 5: Zuerst die "unbekannten Unbekannten" finden

"Known Knowns" sind das, was im Prompt steht. "Known Unknowns" sind Fragen, von denen man weiß, dass man sie noch nicht beantwortet hat. "Unknown Knowns" beschreiben Wissen, das so selbstverständlich ist, dass man es nie aufschreiben würde, aber sofort erkennen würde, wenn man es sähe. Die kritische Kategorie laut Shihipar sind die "Unknown Unknowns", also das, was man überhaupt nicht bedacht hat.

Zu spezifisch ist genauso schlecht wie zu vage

Vorausplanung allein reiche daher nicht aus, so Shihipar. Unknowns könnten tief in der Implementierung auftauchen oder darauf hinweisen, dass das Problem grundsätzlich anders gelöst werden sollte. Die besten "Agentic Coder" hätten relativ wenige Unknowns, würden aber dennoch stets welche antizipieren.

Wer zu spezifisch sei, riskiere, dass Fable 5 Anweisungen stur befolge, selbst wenn ein Kurswechsel angebrachter wäre. Wer zu vage bleibe, erhalte Entscheidungen auf Basis von Industriestandards, die für die konkrete Aufgabe nicht passen.

"Wenn du deine Unknowns nicht berücksichtigst, scheiterst du auf beide Arten", schreibt Shihipar. Claude könne jedoch helfen, die eigenen Unknowns schneller zu entdecken, da es Codebasen und das Internet extrem schnell durchsuche und über die meisten Themen mehr wisse als der durchschnittliche Nutzer.

Entscheidend sei, Claude Kontext über den eigenen Ausgangspunkt zu geben: wo man im Denkprozess stehe, welche Erfahrung man mit dem Problem habe.

Vor der Implementierung: Blinde Flecken systematisch aufdecken

Shihipar beschreibt mehrere Techniken für die Phase vor der eigentlichen Umsetzung. Beim sogenannten "Blind Spot Pass" bittet man Claude, die eigenen unbekannten Unbekannten zu identifizieren. Das sei besonders nützlich, wenn man in einem unbekannten Teil der Codebasis arbeite.

Ein Beispielprompt: "Ich arbeite daran, einen neuen Auth-Provider hinzuzufügen, kenne aber nichts über die Auth-Module in dieser Codebasis. Kannst du einen Blindspot-Pass machen, um mir meine relevanten Unknown Unknowns zu zeigen und mir zu helfen, dich besser zu prompten?"

Für Bereiche mit vielen "Unknown Knowns", etwa visuelles Design, empfiehlt er Brainstorming und Prototyping. Statt sofort zu implementieren, lässt er Claude mehrere radikal unterschiedliche Designrichtungen als HTML-Artefakte erstellen, um darauf reagieren zu können. Fast jede Coding-Session beginne er mit einer Explorations- oder Brainstorming-Phase, um den Projektumfang bewusst zu definieren.

Weitere Techniken umfassen strukturierte Interviews, bei denen Claude den Nutzer Frage für Frage zu Ambiguitäten befragt, priorisiert nach Fragen, deren Antwort die Architektur verändern würde. Auch Referenzen spielen eine Rolle: Quellcode sei die beste Referenz, selbst wenn er in einer anderen Programmiersprache vorliege. Claude Design etwa lese den zugrundeliegenden Code einer Website, nicht nur den Screenshot.

Bevor die eigentliche Arbeit beginnt, lässt Shihipar Claude daher einen Implementierungsplan erstellen, der sich auf die am ehesten zu ändernden Teile konzentriert: Datenmodelle, Type Interfaces und alles Nutzerseitige. Mechanisches Refactoring werde ans Ende verbannt.

Während und nach der Implementierung: Dokumentieren und Verstehen

Auch während der Umsetzung lauern Unknowns. Shihipar bittet Claude, eine temporäre Datei namens "implementation-notes.md" zu führen, in der das Modell Abweichungen vom Plan dokumentiert. Bei unerwarteten Randfällen soll Claude die konservative Option wählen, die Abweichung protokollieren und weiterarbeiten.

Nach der Implementierung empfiehlt er zwei Techniken: Zum einen "Pitches und Explainer", also zusammenfassende Dokumente für Stakeholder, die Prototyp, Spezifikation und Implementierungsnotizen bündeln. Zum anderen "Quizzes": Claude erstellt einen HTML-Report über die vorgenommenen Änderungen mit Kontext und Intuition, gefolgt von einem Quiz. Shihipar mergt erst, wenn er das Quiz fehlerfrei besteht.

Praxistest: Ein Launch-Video komplett mit Claude Code

Wie die Techniken zusammenwirken, illustriert Shihipar am Beispiel des Launch-Videos für Fable, das er vollständig mit Claude Code bearbeitet hat. Videobearbeitung sei für ihn ein neues Gebiet gewesen.

Er begann mit dem, was er wusste: Claude könne Videos per Code bearbeiten und transkribieren. Ob die Genauigkeit ausreiche, war unklar, also ließ er sich erklären, wie Transkription mit Whisper funktioniere und ob sich Füllwörter und Pausen per ffmpeg präzise herausschneiden ließen. Für die zeitgesteuerte Einblendung von UI-Elementen erstellte er einen Prototyp mit Remotion.

Als das Ergebnis farblich flach wirkte, versuchte er zunächst, Claude verschiedene Color-Grading-Varianten erstellen zu lassen. Er merkte jedoch, dass er nicht wusste, was "gut" bei Color Grading überhaupt bedeutet. Statt blind Variationen zu bewerten, ließ er sich von Claude das Thema beibringen, um seine Unknowns zu entdecken.

Shihipars Fazit: Je leistungsfähiger die Modelle werden, desto mehr lasse sich mit dem richtigen Ansatz erreichen. Wenn eine langfristige Aufgabe schiefgehe, müsse man wahrscheinlich mehr Zeit in die Definition der eigenen Unknowns investieren oder einen Implementierungsplan erstellen, der Claude erlaubt, durch diese Unknowns hindurch zu improvisieren.

"Jeder Explainer, jedes Brainstorming, jedes Interview, jeder Prototyp und jede Referenz ist ein günstiger Weg herauszufinden, was man nicht wusste, bevor es teuer wird, es zu beheben", schreibt er. Seine Tipps hat er auch visuell auf einer Webseite aufbereitet.