Omakase is Japanese for "I'll leave it up to you." At a sushi counter you tell the chef the mood, the chef decides the courses, and nobody hands over a recipe. Nobody gets served something inedible either, because the chef makes decisions, says them out loud, and watches your face. That is the whole idea and in what follows is why I think it's the right way to work with agents now, the practices I use to put it into effect, and where I expect it to strain.
The Omakase principle. Agree on the outcome, the constraints, and what would count as evidence of success. Let the agent choose the implementation, make its consequential choices visible, and use concrete alternatives to resolve questions of taste. The person steers through judgment and feedback.
Why vibe coding needs a rule
Vibe coding had a good year and earned a bad reputation at the same time. Anyone can now describe a program and get one, which is the good part. The bad part is what "vibe" came to mean in practice: don't look, don't review, and end up with a stack of pull requests that each made sense on its own and together wrecked the architecture. David Heinemeier Hansson (also known as DHH) mentioned this in the Lex Fridman podcast when he described what was happening to Basecamp 5 in February: 37signals let designers ship agent-written features directly, and the result had to be cleaned up by hand.
The reflex response is to go back to specs, but I don't think that's right call now. If you read Anthropic's page on prompting Fable 5.1 next to OpenAI's guidance for GPT-6 Astra, neither is a doctrine. Both are lists of behaviours the new model shows and the sentence to add when you want a different one. But the same three themes turn up on both.
Scope: Anthropic's page tells the model not to fix, optimize or extend anything the task didn't mention, and OpenAI's tells Astra to size its testing to the change.
Assumptions: Anthropic's suggested prompt has the model make routine judgment calls itself, state the assumption in its summary, and check in only when different readings would lead to materially different work.
Questions: OpenAI notes that Astra asks for clarification more often than GPT-5.6 did, recommends a prompt that has it infer intent from context and bias toward action, and adds that when it does ask, it should first finish the work it's already authorized to do so the user is approving something concrete and reviewable.
Neither page says "define done" or "design the verification before you start". What they say is narrower: decide the small things yourself, say what you decided, and stop only for the things that would change the result.
Then there's DHH who has spent three months on a Linux release and says that for the last two of them agents wrote every line that shipped. Where the vendors are tightening the agent's scope, he is loosening the human's grip. He argues to be as vague as you can get away with and describe the problem, not the path and let something appear and then react to it. He says his own expertise was briefly a handicap because he kept prescribing implementations his way and the agents did better from a plain description of the problem.
Vibe coding goes wrong when the prompt is vague on both, the goal and the path. Heavy spec-driven work goes wrong when it's precise on both. The Omakase principle is for the remaining quadrant: precise about the result and the evidence, hands-off about the method.
Discovering the outcome together
Omakase asks the person to bring the outcome and the evidence of success. However, the whole point of vibe coding is that people often don't know what they want yet. Worse, designing verification is a technical job, and the person least able to do it is the one who came with a vague idea. So the outcome doesn't have to arrive finished and the person brings the problem and their judgment. The agent proposes an interpretation of what success means and a way to check it, alongside its implementation choices, and the person corrects both. In practice that means the first thing the agent writes is not code but a short menu, and the first line of the menu is "here's what I think you're trying to get." Agreeing on the outcome is a step in the work, not a precondition for starting it.
The practices I use to put it into effect
When a brief is fuzzy, the agent extracts the problem, the hard constraints that were actually stated, and any taste signals ("like Word but the 5% I use"). It asks when an answer would change what gets built or how it will be judged, and it doesn't ask about how to build it. In client work the clarifying question is sometimes the deliverable, because asking it is how the brief turns out to be wrong; a good chef asks about allergies and doesn't ask how to cut the fish.
The agent writes the menu. Before building, it lists what it thinks success means and the handful of consequential choices it's making: single-file Python because you said "quick," keyboard only, config in a file an agent can edit later, three opinionated defaults instead of a settings screen. You veto a line in two seconds or you don't, and a veto holds for the rest of the build. A visible menu doesn't guarantee the person can judge every technical consequence, but it makes the assumptions contestable, which is more than silence ever offered.
Taste gets tastings. At a real fork on look, feel, or naming, the agent produces three concrete variants and the person points. People are good at picking between a few things and bad at answering open questions, so three renders are more useful than a paragraph asking what aesthetic I prefer.
Done is followed by a simplify pass. After the work is finished and before anything is announced, the agent re-reads its output and asks whether it could be half the length. This is actually grounded in the observation by DHH when a human says "looks too complicated," and the model immediately agrees and halves it. Simplicity isn't a default. You have to ask, every time. The pass cuts abstractions used once, configuration nobody wanted, and defensive code against inputs that can't happen, which is also where Anthropic's scope warning lands in practice.
A second reader supplements the tests. Review is not evidence of success; tests, measurements, and looking at the thing are. But a different model, or a fresh context with no memory of the reasoning, reading the diff plus the files around it, catches what the author can't. A good combination is to use a model like Qwen as external reviewer.
The principle doesn't care which model you use
Nothing above is specific to Claude, or to agents. It works with Codex, with Astra, with an open-weight model on someone else's inference. It works, with some adjustment, with a human contractor, which since it's a principle and not a prompting trick. Good contractors have always written the menu; we called it "assumptions" and put it at the top of the estimate. The difference now is that the contractor is fast enough for the menu to be rewritten hourly and for tastings to cost minutes.
Omakase, the skill
Omakase is the skill I wrote to put this principle into practice which is - on a technical level - a folder with a description that tells the model when to reach for it and a body of instructions that arrives in context when it does. It triggers on the phrases people use when they don't know what they want ("build me a little thing that," "you decide," "make it simpler") and stays out of the way when a ticket or spec exists. The practices describes here above are its contents; the principle is the reason for them, and it lives in a references file one hop away, on the theory that a rule the model understands is the only kind it keeps.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.