Omakase ist Japanisch für „Ich überlasse es Ihnen.“ An der Sushi-Theke sagen Sie dem Koch, wonach Ihnen ist, der Koch entscheidet über die Gänge, und niemand reicht ein Rezept über den Tresen. Es bekommt aber auch niemand etwas Ungenießbares serviert, denn der Koch trifft Entscheidungen, spricht sie aus und beobachtet Ihr Gesicht. Das ist die ganze Idee. Im Folgenden erkläre ich, warum ich das derzeit für den richtigen Umgang mit Agenten halte, mit welchen Praktiken ich es umsetze und wo es meiner Erwartung nach an seine Grenzen stößt.
Das Omakase-Prinzip. Einigen Sie sich auf das Ergebnis, die Rahmenbedingungen und darauf, was als Beleg für den Erfolg gilt. Lassen Sie den Agenten die Umsetzung wählen, machen Sie seine folgenreichen Entscheidungen sichtbar und klären Sie Geschmacksfragen anhand konkreter Alternativen. Der Mensch steuert über sein Urteil und sein Feedback.
Warum Vibe Coding eine Regel braucht
Vibe Coding hatte ein gutes Jahr und hat sich gleichzeitig einen schlechten Ruf eingehandelt. Jeder kann heute ein Programm beschreiben und bekommt eines, das ist der gute Teil. Der schlechte Teil ist, was „Vibe“ in der Praxis bedeutete: nicht hinschauen, nicht reviewen und am Ende einen Stapel Pull Requests haben, von denen jeder für sich Sinn ergab und die zusammen die Architektur ruiniert haben. David Heinemeier Hansson (auch bekannt als DHH) hat das im Podcast von Lex Fridman erwähnt, als er beschrieb, was im Februar mit Basecamp 5 passiert ist: 37signals ließ Designer von Agenten geschriebene Features direkt ausliefern, und das Ergebnis musste von Hand aufgeräumt werden.
Der Reflex ist, zu Spezifikationen zurückzukehren, aber ich halte das im Moment nicht für den richtigen Weg. Wenn Sie die Seite von Anthropic zum Prompting von Fable 5.1 neben die Empfehlungen von OpenAI für GPT-6 Astra legen, ist keine von beiden eine Doktrin. Beide sind Listen von Verhaltensweisen, die das neue Modell zeigt, samt dem Satz, den man ergänzen sollte, wenn man ein anderes Verhalten will. Dieselben drei Themen tauchen aber in beiden auf.
Umfang: Anthropics Seite weist das Modell an, nichts zu reparieren, zu optimieren oder zu erweitern, was in der Aufgabe nicht vorkam, und OpenAI weist Astra an, den Testaufwand an die Größe der Änderung anzupassen.
Annahmen: Der von Anthropic vorgeschlagene Prompt lässt das Modell routinemäßige Ermessensentscheidungen selbst treffen, die jeweilige Annahme in seiner Zusammenfassung nennen und nur dann nachfragen, wenn unterschiedliche Lesarten zu wesentlich unterschiedlicher Arbeit führen würden.
Rückfragen: OpenAI merkt an, dass Astra häufiger um Klärung bittet als GPT-5.6, empfiehlt einen Prompt, der das Modell die Absicht aus dem Kontext ableiten und eher handeln lässt, und ergänzt: Wenn es doch fragt, soll es zuerst die Arbeit erledigen, für die es bereits freigegeben ist, damit der Nutzer etwas Konkretes und Überprüfbares absegnet.
Keine der beiden Seiten sagt „definiere, wann es fertig ist“ oder „entwirf die Verifikation, bevor du anfängst“. Was sie sagen, ist enger gefasst: Kleinigkeiten selbst entscheiden, sagen, was man entschieden hat, und nur bei Dingen anhalten, die das Ergebnis verändern würden.
Und dann ist da DHH, der drei Monate an einem Linux-Release gearbeitet hat und sagt, dass in den letzten zwei davon Agenten jede ausgelieferte Zeile geschrieben haben. Während die Anbieter den Spielraum des Agenten enger ziehen, lockert er den Griff des Menschen. Er plädiert dafür, so vage zu bleiben, wie man es sich leisten kann, das Problem zu beschreiben statt den Weg, etwas entstehen zu lassen und dann darauf zu reagieren. Seine eigene Expertise sei kurzzeitig ein Handicap gewesen, sagt er, weil er immer wieder Umsetzungen nach seiner Art vorgab, während die Agenten mit einer schlichten Problembeschreibung besser zurechtkamen.
Vibe Coding geht schief, wenn der Prompt bei beidem vage ist, beim Ziel und beim Weg. Schwergewichtige, spec-getriebene Arbeit geht schief, wenn sie bei beidem präzise ist. Das Omakase-Prinzip ist für den verbleibenden Quadranten gedacht: präzise beim Ergebnis und bei den Belegen, zurückhaltend bei der Methode.
Das Ergebnis gemeinsam herausfinden
Omakase verlangt vom Menschen, das Ergebnis und den Beleg für den Erfolg mitzubringen. Der ganze Witz von Vibe Coding ist aber, dass Leute oft noch gar nicht wissen, was sie wollen. Schlimmer noch: Verifikation zu entwerfen ist eine technische Aufgabe, und am wenigsten kann das ausgerechnet die Person, die mit einer vagen Idee gekommen ist. Das Ergebnis muss also nicht fertig ankommen. Der Mensch bringt das Problem und sein Urteilsvermögen mit. Der Agent schlägt eine Interpretation vor, was Erfolg bedeutet und wie man ihn überprüft, zusammen mit seinen Umsetzungsentscheidungen, und der Mensch korrigiert beides. In der Praxis heißt das: Das Erste, was der Agent schreibt, ist kein Code, sondern eine kurze Speisekarte, und deren erste Zeile lautet „Ich glaube, das wollen Sie erreichen.“ Die Einigung auf das Ergebnis ist ein Schritt in der Arbeit und keine Voraussetzung, um damit anzufangen.
Die Praktiken, mit denen ich es umsetze
Wenn ein Briefing unscharf ist, extrahiert der Agent das Problem, die harten Rahmenbedingungen, die tatsächlich genannt wurden, und alle Geschmackssignale („wie Word, aber nur die 5 %, die ich nutze“). Er fragt nach, wenn eine Antwort verändern würde, was gebaut wird oder wie es beurteilt wird, und er fragt nicht, wie es gebaut werden soll. In der Kundenarbeit ist die Rückfrage manchmal das eigentliche Ergebnis, weil sich erst durch sie zeigt, dass das Briefing falsch ist. Ein guter Koch fragt nach Allergien, aber nicht danach, wie er den Fisch schneiden soll.
Der Agent schreibt die Speisekarte. Bevor er baut, listet er auf, was Erfolg seiner Meinung nach bedeutet, und nennt die Handvoll folgenreicher Entscheidungen, die er trifft: Python in einer einzigen Datei, weil Sie „schnell“ gesagt haben, nur Tastaturbedienung, Konfiguration in einer Datei, die später ein Agent bearbeiten kann, drei bewusst gesetzte Voreinstellungen statt eines Einstellungsbildschirms. Sie legen in zwei Sekunden Ihr Veto gegen eine Zeile ein oder eben nicht, und ein Veto gilt für den Rest des Builds. Eine sichtbare Speisekarte garantiert nicht, dass die Person jede technische Konsequenz beurteilen kann, aber sie macht die Annahmen anfechtbar, und das ist mehr, als Schweigen je geboten hat.
Geschmack wird verkostet. An einer echten Weggabelung bei Optik, Anmutung oder Benennung erstellt der Agent drei konkrete Varianten, und die Person zeigt auf eine. Menschen können gut zwischen ein paar Dingen wählen und schlecht offene Fragen beantworten, deshalb nützen drei Renderings mehr als ein Absatz, der mich fragt, welche Ästhetik ich bevorzuge.
Auf das Fertig folgt ein Vereinfachungsdurchgang. Wenn die Arbeit erledigt ist und bevor irgendetwas verkündet wird, liest der Agent sein Ergebnis noch einmal und fragt sich, ob es nicht auch halb so lang ginge. Das geht auf eine Beobachtung von DHH zurück: Wenn ein Mensch sagt „sieht zu kompliziert aus“, stimmt das Modell sofort zu und halbiert den Umfang. Einfachheit ist kein Standardverhalten. Man muss jedes Mal danach fragen. Der Durchgang streicht Abstraktionen, die nur einmal verwendet werden, Konfiguration, die niemand wollte, und defensiven Code gegen Eingaben, die gar nicht vorkommen können. Genau dort greift in der Praxis auch Anthropics Warnung zum Umfang.
Ein zweiter Leser ergänzt die Tests. Ein Review ist kein Beleg für Erfolg; Tests, Messungen und das Ding selbst anzuschauen schon. Aber ein anderes Modell oder ein frischer Kontext ohne Erinnerung an die Überlegungen, der den Diff samt den umliegenden Dateien liest, findet, was der Autor selbst übersieht. Eine gute Kombination ist, ein Modell wie Qwen als externen Reviewer einzusetzen.
Dem Prinzip ist egal, welches Modell Sie verwenden
Nichts davon ist spezifisch für Claude oder für Agenten. Es funktioniert mit Codex, mit Astra, mit einem Open-Weight-Modell auf der Inferenz-Infrastruktur von jemand anderem. Mit etwas Anpassung funktioniert es auch mit einem menschlichen Auftragnehmer, eben weil es ein Prinzip ist und kein Prompting-Trick. Gute Auftragnehmer haben immer schon die Speisekarte geschrieben; wir nannten sie „Annahmen“ und stellten sie an den Anfang des Kostenvoranschlags. Der Unterschied ist, dass der Auftragnehmer heute schnell genug ist, um die Speisekarte stündlich neu zu schreiben, und eine Verkostung nur Minuten kostet.
Omakase als Skill
Omakase ist der Skill, den ich geschrieben habe, um dieses Prinzip in die Praxis umzusetzen. Technisch gesehen ist das ein Ordner mit einer Beschreibung, die dem Modell sagt, wann es darauf zurückgreifen soll, und einem Satz an Anweisungen, der in den Kontext geladen wird, wenn es das tut. Er springt auf die Formulierungen an, die Leute verwenden, wenn sie nicht wissen, was sie wollen („bau mir ein kleines Ding, das“, „entscheide du“, „mach es einfacher“), und hält sich heraus, wenn es ein Ticket oder eine Spezifikation gibt. Die oben beschriebenen Praktiken sind sein Inhalt; das Prinzip ist der Grund dafür und liegt in einer Referenzdatei, einen Schritt entfernt. Dahinter steht meine Annahme, dass sich ein Modell nur an Regeln hält, die es auch versteht.
Aus dem Englischen übersetzt: zum Originalbeitrag