Question-First Prompting: Make Your Assistant Ask Before It Answers

When you ask a coding assistant for help, it’s tempting to dump a screenshot, paste a stack trace, and write: “What’s wrong?”

And you’ll often get an answer—confident, detailed, and occasionally… wrong.

The failure mode is predictable: you asked for a solution before you established the problem definition. The model fills the gaps with assumptions, and those assumptions become your “fix”.

The simplest way to stop this is a tiny change in how you prompt:

Force a clarification pass first.

I call this Question-First Prompting: require the assistant to ask the right questions (and wait) before proposing a plan or code.

This post gives you a reusable template and concrete examples you can copy into your workflow.

Why “question-first” works

Most assistant mistakes aren’t “bad code”—they’re bad premises.

Common missing premises:

• Your environment (runtime, OS, framework version)
• The exact desired behavior (“works” vs “works fast” vs “works safely”)
• Constraints (no new deps, backwards compatible, limited access)
• Context boundaries (what files exist, what you can change)

If the assistant guesses any of those, you’re already debugging a hallucinated world.

A question-first step forces two useful behaviors:

1. Uncertainty becomes explicit. Instead of guessing, the assistant surfaces what it needs.
2. Your problem becomes sharper. Half the time, answering the questions reveals the fix.

Think of it like a good senior engineer response: they don’t immediately ship a patch; they clarify the contract.

The core template (copy/paste)

Use this as the first message of a thread.

You are my coding assistant.

Before you propose any solution, do a clarification pass.

Rules:
- Ask 5–10 targeted questions to remove ambiguity.
- Group questions by category: Environment, Reproduction, Expected vs Actual, Constraints, and Data.
- Do NOT propose fixes yet.
- If any info is missing that would change the answer, ask about it.

After I answer, you will:
1) Summarize the problem in 3–5 bullet points.
2) Propose 2–3 solution paths with tradeoffs.
3) Recommend one path and provide the steps/code.

My issue:
<PASTE HERE>

Two details make this template stick:

• Categories prevent random questioning.
• “No fixes yet” prevents the premature solution.

Example 1: Debugging a flaky test

Your prompt

Before suggesting any fix, ask clarifying questions (no solutions yet).

Issue: Our Jest test sometimes fails in CI with "Timeout - Async callback was not invoked".
Locally it passes.
We recently introduced retries and parallelization.

Good questions you should get back

Environment

• What Node/Jest versions are you using locally vs CI?
• Are there differences in CPU count, timeouts, or test runner flags?

Reproduction

• Can you reproduce locally with --runInBand / --maxWorkers=50%?
• Does it correlate with a specific test file or suite order?

Expected vs Actual

• Which async operation is timing out (network, DB, timers, worker messages)?
• Are there logs right before the timeout?

Constraints

• Can you increase test timeouts, or must the suite stay under a budget?
• Can you add instrumentation in CI (extra logging) temporarily?

Data

• Share the failing test and the helper it depends on (especially setup/teardown).

Once you answer, the assistant can recommend realistic paths:

• Isolate global state leakage
• Remove hidden real-time dependencies
• Make timers deterministic
• Reduce parallel contention

But the point is: you don’t want that list until you know which world you’re in.

Example 2: “Why is my Docker image huge?”

If you ask “How do I reduce it?”, you’ll get 20 generic tips.

Instead:

Clarification pass first (no solutions yet).

Issue: Our Docker image went from 350MB to 1.2GB.
We didn’t change the app much.
We build on GitHub Actions and deploy to Kubernetes.

Targeted questions might include:

• What base image did you use before/now? (Alpine → Debian is a classic jump)
• Is the image multi-stage? If yes, are you copying the right build outputs only?
• Are you accidentally copying .git/, node_modules/, or build caches?
• Do you use npm ci or npm install in the image?
• Did you add browsers (Playwright/Puppeteer) or PDF tooling?
• Can you share Dockerfile and .dockerignore?

That last question (.dockerignore) is the hidden killer.

Example 3: “Help me design an API”

For design work, question-first prompts are even more important because the “right” answer depends on product choices.

Your prompt

Ask clarification questions first. Do not design yet.

Task: Design an API endpoint to create an invoice.
We have users, customers, line items, and taxes.

Categories that matter

• Domain rules: Can invoices be edited after sending? Are there credit notes?
• Idempotency: Will clients retry? Do you need idempotency keys?
• Validation: Do you reject unknown tax codes? Do you allow drafts?
• Security: Is it multi-tenant? What is the authorization model?
• Integrations: Does it connect to payment providers or accounting?

If you don’t answer those, you’ll get an endpoint that looks tidy but fails in production.

“Question-first” patterns you can reuse

Here are three patterns I reach for constantly.

1) The “minimal reproducible example” gate

Ask questions until you can express the issue as a minimal reproducible example.
Do not propose fixes until you can state the MRE.

This forces the assistant to shrink the problem, not expand it.

2) The “constraint lock”

Before solving, confirm these constraints:
- No new dependencies
- Must be backwards compatible
- Must pass existing tests
- Must keep p95 latency under 200ms

If any constraint is incompatible, say so and ask which one can move.

The best solution is often “change the constraint,” but you only get that if you name constraints explicitly.

3) The “data request with safe boundaries”

Ask for the minimum data needed.
If you request logs or code, specify exactly which sections and redact secrets.

This protects you from oversharing and makes the assistant’s job easier.

A practical way to use this day-to-day

You don’t need to do this for every question.

Use Question-First Prompting when:

• The problem is ambiguous (“it doesn’t work”)
• The cost of a wrong answer is high (production incidents, security, migrations)
• There are hidden constraints (compliance, dependencies, timelines)
• You’ve already tried 1–2 things and you’re now guessing

Skip it when:

• You want a quick snippet (regex, small utility)
• You already have a tight spec and complete context

The 30-second checklist

Before you hit “send”, add one sentence:

• “Ask clarifying questions first; no solutions yet.”

Then be ready to answer:

• Environment
• Repro steps
• Expected vs actual
• Constraints
• Data you can share

You’ll get fewer “magic fixes”… and far more answers you can actually ship.