Home/ Part III — Beginner Track: Learn to Communicate Like a Builder/6. Prompting Basics for Code (Without Prompt-Engineering Theater)/6.5 Use a "stop and confirm assumptions" step

6.5 Use a "stop and confirm assumptions" step

Overview and links for this section of the guide.

On this page

Why assumptions are the silent failure mode

Models fill gaps. They have to—because prompts are usually incomplete. The problem is that hidden assumptions become hidden requirements, and then they become bugs.

Common symptoms of unconfirmed assumptions:

  • “It built the wrong thing, but it seemed reasonable.”
  • “It changed files I didn’t want touched.”
  • “It picked libraries/frameworks I never asked for.”
  • “It handled errors differently than I expected.”
  • “It broke existing behavior because it assumed it wasn’t needed.”
The fix is procedural

Don’t rely on “better prompts” alone. Add a checkpoint: force assumptions into the open before code is produced.

What counts as an assumption?

An assumption is any unstated detail the model is choosing for you. Typical categories:

  • Environment assumptions: OS, runtime version, available tools.
  • Dependency assumptions: which libraries are allowed.
  • Interface assumptions: function signatures, CLI flags, HTTP routes.
  • Behavior assumptions: error messages, exit codes, edge case handling.
  • Data assumptions: input formats, schema fields, nullability.
  • Scope assumptions: what files/features are “in scope.”
Assumptions compound over time

In long conversations, the model may carry forward old assumptions even after the project changes. That’s why you need explicit re-anchoring.

A “stop and confirm assumptions” prompt

Use this when requirements are unclear or the change is risky:

Before you propose a plan or write any code:
1) List all assumptions you are making (environment, dependencies, inputs/outputs, edge cases, file scope).
2) List any questions you need answered to avoid guessing.
3) Stop and wait for my answers.

Do not write code yet.

Then answer the model’s questions and correct assumptions. Only after that do you proceed to “plan first” and implementation.

If you’re in a hurry, constrain instead of clarifying

If you don’t want to answer questions, you can impose constraints: “Assume X and Y. Do not assume anything else.”

How to respond (approve, correct, or defer)

When the model lists assumptions, respond explicitly:

  • Approve: “Yes, assume Python 3.11.”
  • Correct: “No, we must support Node 20, not Python.”
  • Defer: “We haven’t decided. Propose two options and tradeoffs.”

This turns the conversation into a spec negotiation rather than an implementation lottery.

Reset prompts when the conversation drifts

Over time, instructions conflict and context gets noisy. Use a reset prompt to re-anchor:

Reset: summarize the current agreed requirements and constraints in 10–15 bullets.
Then list any assumptions you are still making.
Stop and wait for confirmation before continuing.
This is not wasted time

A 30-second reset can save you hours of debugging the wrong implementation.

Common mistakes (and fixes)

Mistake: skipping the assumption step because “it’s a small change”

Fix: if the change touches interfaces, parsing, or security, assumptions matter even when the diff is small.

Mistake: responding vaguely (“sounds good”)

Fix: approve/correct assumptions explicitly so they become stable constraints.

Mistake: never resetting after many iterations

Fix: periodically re-summarize and re-confirm constraints, especially before refactors.

Where to go next