"Di fuor dorate son, sì ch'elli abbaglia; ma dentro tutte piombo" — "Gilded on the outside so they dazzle; but inside all lead" — Inferno, Canto XXIII

You ask the model to build a dashboard. Revenue over time. Simple request.

It runs the analysis. Gives you a chart. The line goes up and to the right. Looks plausible. You show it in the meeting.

Then someone asks why Q4 revenue is higher than the annual target. Why November shows twice as much as the actual cash received. Why the chart includes that big canceled order from September.

You go back and look closer. The foundation is missing. The model plotted order date, not revenue recognition date. It counted deferred revenue as current revenue. It didn’t understand your fiscal calendar runs July to June, not January to December. It may have mixed currencies without conversion.

This isn’t the model making up numbers. It’s filling in gaps in its context (dictionary, not AI-specific definition) you didn’t know existed.

You assume the model has the same understanding of the task as you do. It doesn’t.

When you work with colleagues, you get shared context for free. Through training, education, experience, or just interaction with you, they already understand implicitly what needs to happen.

The model was trained on the corpus of the internet. It may be biased away from this implicit understanding. You’re talking about your specific problem in your specific context. It’s talking about the statistically average problem across millions of examples. The model gives you an answer. The answer is well-written. The answer is wrong.


Here is an experiment to try: before you let the model build anything, make it tell you what it’s assuming.

The Clarification Protocol

Simple version

I need you to [YOUR TASK]

Before doing anything, follow this process:

  • IDENTIFY AMBIGUITIES: List all the underspecified parts of my request

  • STATE ASSUMPTIONS: For each ambiguity, tell me what assumption you would make by default

  • ASK QUESTIONS: Ask me clarifying questions about the most important decisions

  • 4. WAIT for my answers before starting

Format your response like:

  • Ambiguities I’ve identified:

    • [list them]

  • Assumptions I would make:

    • [list with reasoning]

  • Questions for you:

    • [prioritized questions]

Only proceed after I respond to your questions.

The Claude Code CLI Version

Before writing any code for the task below, run a multi-model divergence analysis to surface hidden assumptions.

TASK:

“”“

{TASK}

“”“

PROCESS — follow exactly:

1. Call the haiku task. Prompt: “You are a pragmatic developer. For this task, list: (a) every unspecified decision with likely default and dangerous alternative, (b) what could silently break — runs fine but wrong results, (c) the input/output contract gaps. No code. No solutions. Only gaps. Task: {TASK}”

2. Call the sonnet task. Prompt “You are a requirements engineer. For this task, list: (a) explicit vs implicit requirements with confidence levels, (b) every environment/dependency/format assumption, (c) unspecified decisions with downstream consequences if defaulted wrong, (d) integration surface assumptions. Do not resolve ambiguity — surface it. No code. Task: {TASK}”

3. Call the haiku task. Prompt: “You are a hostile code reviewer. For this task, list: (a) dangerous assumptions a helpful AI will silently make (scale, security, concurrency, encoding, timezone, idempotency), (b) the 3 worst-case scenarios if the developer guesses wrong on unspecified decisions, (c) questions you would block a PR for. Be adversarial and specific. No code. Task: {TASK}”

4. Compare all three outputs. Produce a divergence map:

✅ CONSENSUS — all three agree (safe defaults)

⚠️ PARTIAL — two agree, one differs (state the split)

🔴 DIVERGENCE — all differ or unique critical flags (must clarify)

5. From the 🔴 and ⚠️ items, write clarifying questions for me. Max 7. Phrase for a non-technical person. For each, explain why it matters and suggest the likely answer.

6. STOP. Show me the divergence map and questions. Wait for my answers before writing any code.

After I answer, implement with all ambiguities resolved. Mark any remaining assumptions with inline comments: # ASSUMPTION: [what] # ALTERNATIVE: [what else].

Minimal version (adapt to your task)

Before coding, simulate three reviewers of this task independently:

  • Pragmatic dev — list unspecified decisions and defaults

  • Requirements engineer — list implicit assumptions and alternatives

  • Hostile auditor — list dangerous silent defaults an AI would make

Diff them. Ask me only about the disagreements. Then code.

TASK: {TASK}