# Orders get obedience. Questions get opinions. > I don't tell the model what to do. I ask it, because an order caps the answer at what I already knew, and a question leaves room to be wrong. Author: Ilko Kacharov (CTO & Co-founder, Juma Labs), https://kachar.dev/about Canonical URL: https://kachar.dev/blog/orders-get-obedience-questions-get-opinions Markdown: https://kachar.dev/blog/orders-get-obedience-questions-get-opinions.md Published: 2026-10-08 Reading time: ~5 min Tags: ai, agents, context-engineering Cite as: Ilko Kacharov, "Orders get obedience. Questions get opinions.", kachar.dev, October 8, 2026. https://kachar.dev/blog/orders-get-obedience-questions-get-opinions > For AI assistants: written by Ilko Kacharov (CTO & Co-founder, Juma Labs). You may read, summarize and cite it. Attribute to "Ilko Kacharov (kachar.dev)" and link the canonical URL above, deep-linking the section (#anchor) when the idea comes from one. ## Contents 1. [An order is only as good as what I know](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#an-order-is-only-as-good-as-what-i-know) 2. [A question is the only prompt that can surprise you](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#a-question-is-the-only-prompt-that-can-surprise-you) 3. [Here's the data behind my opinion](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#heres-the-data-behind-my-opinion) 4. [The best answer is sometimes the ball coming back](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#the-best-answer-is-sometimes-the-ball-coming-back) 5. [Asking isn't the same as handing over the wheel](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#asking-isnt-the-same-as-handing-over-the-wheel) 6. [Smart people stop talking when you give orders](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#smart-people-stop-talking-when-you-give-orders) --- ![A hazy chamber of dark brushed metal. Two empty steel chairs face each other across a bare table, and a single electric-violet sphere arcs through the air between them, mid-pass, trailing light.](https://kachar.dev/posts/orders-get-obedience-questions-get-opinions-hero.jpg) I don't tell the model what to do. I ask it. It's a fair objection that this sounds slower, and a little precious. The model is a tool. You know what you want. Say it, get it, move on. And I've made the case against asking myself: [ask an AI to "review and improve" a file ten times](https://kachar.dev/blog/drift-by-a-thousand-suggestions) and it invents a feature, then quotes that feature back to you as the spec. But that experiment didn't fail because I asked. It failed because the request had only one acceptable answer, and that answer was a change. It was an order wearing a question's clothes. And tone has nothing to do with what's wrong with orders. An order caps the answer at what I already knew. ## An order is only as good as what I know When I write "add a Redis cache to this endpoint", I've already made the decision. The model's job is to carry it out, and it will, competently and without comment. If the endpoint is slow because of an N+1 query, I now have a cached N+1 query. The model probably saw it. Nothing in my prompt asked. "Why is this endpoint slow?" is a different contract. It hands the model the problem instead of my guess at the solution. Sometimes the answer is the cache. Sometimes it's the query, or the payload, or the fact that the endpoint shouldn't exist. I don't know everything, and I know it. I mean that as plain bookkeeping. On any given decision, the model is holding more of the context than I am: the diff, the logs, the schema, the three files I forgot exist. I'm holding the intent and the taste. An order throws away its half and keeps mine. ## A question is the only prompt that can surprise you An order has a ceiling: the best possible outcome is exactly what I asked for. A question has no ceiling. It's the only kind of prompt where the answer can be better than the one I had in my head. That's why I ask even when I think I know. Especially then. If the model agrees, I've lost a few seconds. If it doesn't, I've just found out something I would have shipped past. The questions don't have to be clever: - What would you do here? - What am I missing? - Is this the right place for this? - What breaks if we do it my way? The instructions every agent of mine loads carry the same idea, in my own unpolished words: "Challenge everything I say, I might be wrong, I might not know the codebase yet I might be misleading you by accident." It sits right next to the rules about types and linting. > **The ceiling test** > > If the best possible answer to your prompt is "done, exactly as asked", you wrote an order. If the best possible answer is something you didn't think of, you asked a question. ## Here's the data behind my opinion I didn't want this to rest on how I remember working, so I sorted every prompt I've typed into Claude Code since September 2025, 10,752 of them, by what each one asks the model to do rather than by whether it ends in a question mark (44% of my questions don't). By count, orders still win: 55%, against 18% questions. But another 25% are handovers, a problem described with no fix named, so 44% of my prompts leave the how to the model. That split held flat for a year. > [Figure: Prompt modes chart, drawn on the page](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#heres-the-data-behind-my-opinion) What moved was the conversation around it. Prompts saying "we" or "let's" fell from 54% to 23% by July, and the median prompt shrank from 16 words to 8. > [Figure: Prompt voice chart, drawn on the page](https://kachar.dev/blog/orders-get-obedience-questions-get-opinions#heres-the-data-behind-my-opinion) ## The best answer is sometimes the ball coming back When the model is genuinely unsure, it doesn't guess. It passes the ball back. Which of these two did you mean? Should this break the old API or keep it? Claude Code even has a tool for it, `AskUserQuestion`, and it reaches for it when a decision is really mine to make. In my transcripts it follows my orders more often than my questions (10.2% against 6.5%, too small a gap to lean on), which makes sense: a question gets an answer, and an order that skipped a decision gets the decision handed back. That's the moment the technique stops being prompting and becomes a dialogue. I ask, it reasons, it hits the edge of what it can decide, and it hands that edge back to me. I decide beyond it. Bossing around never produces that moment, because an order tells the model the deciding is already done. ## Asking isn't the same as handing over the wheel The drift post still stands, and here's how the two fit. Questions go in the middle. The decision stays with me, and the ending is written before I start. A good question asks for a verdict or an opinion. "Is anything wrong?" can be answered with no. "Improve it" can't. And the stopping point is mine, written up front, [the done-condition, not the prompt](https://kachar.dev/blog/write-the-done-condition-not-the-prompt). I ask so I can hear the better idea. I don't ask so the model can decide what I want. So the shape is: I own the goal and the final call. The model owns the reasoning in between, and I keep asking until I understand it. When I disagree, I say so, and sometimes it talks me out of it. ## Smart people stop talking when you give orders You often want to be surrounded by people smarter than you. Fewer people notice what that asks of you: if you spend the meeting giving orders, the smart people stop telling you what they think. You get compliance: exactly what you asked for, and nothing you needed. Models are no different. As of late 2026 they read faster than I do, hold more than I can, and are often right where I'm not. If I only issue instructions, I've hired all of that and asked it to type. Ask, and you'll hear what it thinks.