Make It Ask First: The 95%-Confidence Prompt

Most bad AI output isn't the model's fault. It started building before it understood you. You type a fast, underspecified prompt; the agent fills the gaps with its best guess; and you end up three files deep in code that solves the wrong problem. The fix isn't a better prompt — it's a different order of operations: make the agent ask before it acts.

Vague prompt in, vague output out

Coding agents are eager. Given a task like "add rate limiting to the API," Claude Code will pick an algorithm, a storage backend, and a set of routes to protect — all silently, all as assumptions. If those assumptions don't match what you had in mind, you don't find out until you're reviewing a diff you have to partially throw away. That's the expensive path: the agent burns tokens and time producing something, you burn time reading it, and then you both start over on the parts that were wrong.

The cheap path is to resolve the ambiguity in conversation, before a single line gets written. A clarifying question costs a few seconds to answer. A wrong implementation costs a review cycle, a revert, and a re-prompt — and if the agent runs semi-autonomously across multiple steps, a wrong assumption made early compounds through everything built on top of it.

Why questions-first works

Underspecification is the default state of any real request — "add rate limiting," "fix the flaky test," "make the dashboard faster" are all missing context: which routes, which environment, what "faster" needs to mean. Two ways exist to close that gap. You can try to add more context up front, but you rarely think of everything — that's why the request was underspecified in the first place. Or you can let the agent surface the specific gaps it's about to guess through, which are the exact places its knowledge runs out.

The second approach is more efficient because it's targeted. The agent isn't asking generic discovery questions; it's asking about the decision points it's about to hit. "Should the rate limit be per-user or per-IP?" is a question that only becomes obvious once you're staring at the implementation. Forcing the agent to ask it before implementing — rather than silently picking one — converts a guess into a decision you made on purpose.

The prompt pattern

One line does it:

Ask me questions until you're 95% confident you understand what I want, then proceed.

Say it once at the start of a task, or bake it into a project instructions file (CLAUDE.md) so it applies by default to every session. The specific number matters less than the mechanism — "95% confident" gives the agent a threshold it can reason about, rather than an open-ended invitation to ask one question and move on. Vague instructions like "ask me if anything's unclear" tend to get skipped; a concrete confidence bar is harder to wave away.

Two refinements sharpen it further:

• "What am I not thinking about? What would an expert consider?" — This pushes past the questions you'd have generated yourself, toward the class of edge case a domain expert would flag reflexively: auth boundaries, rollback behavior, concurrency. Add it as a follow-up once the agent has asked its first round of obvious questions.
• Scope the questions to the decision, not the whole codebase. If you only want alignment on architecture, say so — "ask me about design decisions, not implementation details" — so the back-and-forth stays short.

A concrete example

Compare two ways of kicking off the same task.

Without the pattern: "Add caching to the search endpoint." The agent picks in-memory caching, a 60-second TTL, and caches by raw query string — none of which you specified, all of which might be wrong for your traffic pattern.

With the pattern: "Add caching to the search endpoint. Ask me questions until you're 95% confident you understand what I want." The agent comes back with: Is this single-instance, or does it need to work across multiple servers (which rules out in-memory)? Should cache keys include the logged-in user, or is search public? What's an acceptable staleness window? Three questions, thirty seconds to answer, and the implementation that follows matches your actual constraints on the first pass.

Pitfalls

• Don't skip the follow-up. The first round of questions tends to be the obvious ones. "What am I not thinking about" is what surfaces the edge cases that would otherwise show up as a bug report next week.
• Don't let it ask forever. A 95% threshold is a target, not a stall tactic. If the agent is still asking after five or six questions on a small task, answer what's outstanding and tell it to proceed — over-clarifying a simple task wastes the time you were trying to save.
• Answer precisely. A vague answer to a precise question just relocates the ambiguity. If you don't know the answer yourself, say so — that's useful information too, and better resolved now than assumed silently later.

Power tricks

• Put it in your CLAUDE.md. Instead of repeating the line every session, add a rule like "for any non-trivial task, ask clarifying questions until 95% confident before writing code." It applies automatically across the whole project.
• Pair it with an explicit plan step. After the questions round, ask the agent to restate its understanding as a short plan before touching files — a second, cheap checkpoint before the expensive part starts.
• Use it for review, not just build. The same pattern works when asking an agent to review a PR or diagnose a bug: "ask me questions until you're confident you understand the failure" surfaces missing repro steps before it goes down the wrong path.

Resources

• Claude Code docs — Manage Claude's memory (CLAUDE.md)
• Anthropic — Be clear, direct, and detailed (prompt engineering)
• Claude Code docs — Common workflows