Die längste Zeit in der Ära des agentischen Codings war das Modell der Engpass: Sie wussten, was Sie wollten, der Agent konnte es nicht zuverlässig liefern, und Prompting war die Kunst, einem System, das ständig patzte, Leistung abzuringen. Thariq Shihipar, Engineer in Anthropics Claude-Code-Team, argumentiert, dass sich der Engpass mit Fable, Anthropics Modell für lang laufende agentische Arbeit, eingesetzt über Claude Code, verschoben hat. Das Modell kann umsetzen. Was die Qualität der Arbeit jetzt begrenzt, ist Ihre Fähigkeit zu sagen, was Sie wollen, und genauer: Ihre Fähigkeit zu bemerken, was Sie nicht gesagt haben.
Shihipar beschreibt das als Karte und Gebiet. Die Karte ist alles, was Sie dem Agenten mitgeben: Prompts, Skills, Kontext. Das Gebiet ist der Ort, an dem die Arbeit passiert: die Codebasis, ihre Geschichte, ihre echten Einschränkungen. Die Lücke dazwischen besteht aus Unbekanntem, und jedes Mal, wenn der Agent darauf stößt, rät er für Sie. Je länger die Aufgabe, desto mehr Vermutungen sammeln sich an, und desto weiter entfernt sich das Ergebnis von dem, was Sie im Kopf hatten, aber nie aufgeschrieben haben.
Um diese Lücken zu sortieren, borgt er sich die alte Taxonomie mit vier Quadranten. Bekannte Bekannte stehen im Prompt. Bekannte Unbekannte sind die Fragen, die Sie noch nicht beantwortet haben, von denen Sie aber immerhin wissen. Unbekannte Bekannte sind die Dinge, die für Sie so selbstverständlich sind, dass Sie sie nie aufschreiben würden, obwohl Sie sie auf den ersten Blick wiedererkennen würden. Unbekannte Unbekannte sind die Dinge, die Sie gar nicht bedacht haben, einschließlich der Möglichkeit, dass Sie nicht wissen, wie gute Arbeit in diesem Gebiet aussieht.
Am nützlichsten ist, dass Shihipar daraus eine Sammlung praxistauglicher Prompts macht, und jeder davon führt denselben Handgriff aus: Er holt Information aus Ihrem Kopf oder legt offen, dass sie fehlt, und zwar bevor der Fehler passiert, nicht danach. Was jetzt folgt, ist meine Verpackung, nicht seine: zehn Prompts aus dem Leitfaden, leicht angepasst, nach Projektphase geordnet, und am Ende der, der für jede Phase gilt. Die Namen stammen von mir, die Handgriffe von ihm.
1. Der Blindspot-Check. Bevor Sie etwas Unvertrautes beginnen, fragen Sie direkt: „Mach einen Blindspot-Check. Was sind hier meine unbekannten Unbekannten? Bring mir genug bei, damit ich dich besser prompten kann.“ Die wesentliche Zutat ist das Eingeständnis, wo Sie stehen. Um Lücken, über die Sie hinwegtäuschen, kann das Modell nicht herumarbeiten, deshalb beginnt Shihipars eigenes Beispiel mit „Ich weiß nichts über die Auth-Module in dieser Codebasis.“
2. Die Optionsleiter. Bevor Sie entscheiden, was Sie bauen, fragen Sie nach dem Lösungsraum: „Hier ist mein grobes Problem. Sammle zehn Wege, es zu lösen, vom billigsten bis zum ehrgeizigsten. Ich sage dir, welche mich ansprechen.“ So legen Sie den Umfang bewusst fest. Wer das auslässt, landet bei Projekten, die zu eng sind, um etwas zu bewirken, oder zu breit, um je fertig zu werden.
3. Wegwerf-Prototypen. Wenn Sie es erkennen würden, sobald Sie es sehen, es aber nicht beschreiben können, lassen Sie sich drei oder vier Versionen zum Wegwerfen bauen: „Mach mir eine HTML-Seite mit vier völlig unterschiedlichen Designrichtungen, damit ich darauf reagieren kann.“ Auf Entwürfe zu reagieren ist besser, als aus dem Nichts zu beschreiben, und ein unbekanntes Bekanntes im Prototyp aufzudecken ist billig. Mitten in der Umsetzung, wenn kleine Änderungen an der Spezifikation große Code-Änderungen nach sich ziehen, ist es das nicht.
4. Das umgekehrte Interview. Sobald das Brainstorming durch ist, drehen Sie die Fragerichtung um: „Interviewe mich, eine Frage nach der anderen, zu allem, was unklar ist. Stell zuerst die Fragen, bei denen meine Antwort die Architektur verändern würde.“ Der Wert liegt im Zwang. Beim Antworten müssen Sie Annahmen aussprechen, die sonst unausgesprochen blieben, bis sie etwas kaputt machen.
5. Referenzen statt Beschreibung. Wenn es schon etwas gibt, das dem Gewünschten nahekommt, zeigen Sie darauf, statt es zu beschreiben. Shihipars Beispiel: „Dieses Rust-Crate implementiert genau das Backoff-Verhalten, das ich will. Lies es und implementiere dieselbe Semantik in unserem TypeScript-Client neu.“ Quellcode ist das dichteste Referenzformat, das es gibt, und er funktioniert über Sprachgrenzen hinweg.
6. Der Plan mit den veränderlichen Entscheidungen oben. Vor der Umsetzung verlangen Sie einen Plan, sortiert danach, wie wahrscheinlich sich etwas ändert: „Beginne mit den Entscheidungen, an denen ich am ehesten noch drehen werde: Datenmodelle, Typ-Interfaces, alles, was Benutzer sehen. Das mechanische Refactoring kommt ganz nach unten.“ Ihre Aufmerksamkeit beim Review ist begrenzt. Setzen Sie sie dort ein, wo Ihre Antwort das Ergebnis verändern würde.
7. Die Datei mit den Implementierungsnotizen. Keine noch so gute Planung beseitigt die Unbekannten, die erst unterwegs auftauchen. Also weisen Sie den Agenten an: „Führe eine Datei implementation-notes.md. Wenn du auf einen Randfall stößt, der eine Abweichung vom Plan erzwingt, nimm die konservative Option, trag sie unter Abweichungen ein und mach weiter.“ Jede autonome Entscheidung wird festgehalten, statt stillschweigend unterzugehen, und das Log wird zur Entscheidungsdokumentation für Ihren nächsten Versuch.
8. Das Buy-in-Artefakt. Ausliefern heißt Freigaben einholen, und Ihre Reviewer starten mit denselben Unbekannten wie Sie am Anfang. „Pack den Prototyp, die Spezifikation und die Implementierungsnotizen in ein einziges Dokument, das ich in Slack posten kann.“ Fachleute geben schneller frei, wenn sie sehen, dass Sie die Schwachstellen berücksichtigt haben, die sie selbst angesprochen hätten.
9. Das Quiz als Schranke. Nach einer langen Session hat der Agent oft mehr getan, als Sie mitbekommen haben, und Diffs lesen bringt nur begrenzt etwas, wenn das Verhalten von bestehenden Codepfaden abhängt. Also: „Gib mir einen Bericht über die Änderungen, mit Kontext und Intuition, und am Ende ein Quiz, das ich bestehen muss.“ Wenn Sie das Quiz nicht bestehen, verstehen Sie nicht, was Sie ausliefern, und Shihipar mergt nicht, bis er es versteht.
10. Bring es mir zuerst bei. Wenn Sie guten von schlechtem Output nicht unterscheiden können, ist es sinnlos, Optionen zu erzeugen. Schließen Sie die Lücke im Urteilsvermögen vorher: „Ich weiß nicht, was Color Grading ist. Bring mir genug bei, damit ich das beurteilen kann.“
Dieser letzte Prompt verdient besondere Aufmerksamkeit, denn er ist Shihipars eigenes durchgespieltes Beispiel. Das Launch-Video von Fable wurde komplett von Claude Code geschnitten, in einem Gebiet, in dem er Anfänger war. Sein erster Impuls beim flach wirkenden Material war der Standardzug: mehrere Color-Grading-Varianten erzeugen und eine auswählen. Dann bemerkte er den Fehler im Plan. Er hatte keine Ahnung, wie gutes Color Grading aussieht, also wäre jede Auswahl ein Münzwurf gewesen, der sich als Entscheidung verkleidet. Die Lösung war kein besserer Generierungs-Prompt. Er bat Claude, ihm das Gebiet beizubringen, bis er urteilen konnte, und wählte erst dann aus.
Das ist das Muster hinter allen zehn. Keiner dieser Prompts verlangt vom Modell, klüger zu sein. Jeder verlegt einen Fehler aus der Zeit nach der Arbeit, wo er teuer ist, in die Zeit davor, wo er eine Frage kostet. Die Prompts sind billig. Teuer wird es inzwischen, sie nicht zu stellen.
Aus dem Englischen übersetzt: zum Originalbeitrag