Anthropic’s Fable 5 is arriving with a familiar promise: better outputs, cleaner reasoning, fewer dead ends. But the most interesting part of the recent prompting advice around the model is not about clever phrasing or hidden magic words. It is about operator discipline.
According to Anthropic developer Thariq Shihipar, the limiting factor is often not whether the model can follow instructions. It is whether the person writing the prompt has already identified the gaps in their own understanding. In that framing, prompting becomes less like asking a system for help and more like a preflight check: define the task, inventory the unknowns, and decide what must be resolved before generation begins.
That sounds abstract until you compare it with how teams actually ship AI features. Product and engineering groups often spend time tuning prompts after a feature is already in motion, then interpret every weak answer as a model issue. Shihipar’s advice shifts some of that burden back to the human side of the interface. If the prompt author cannot distinguish between what is known, what is unknown, and what is merely assumed, the model inherits ambiguity that no amount of parameter tweaking will fully clean up.
What changed: self-awareness is now part of prompt quality
The new idea here is not that prompts matter. That is settled. The shift is that prompt quality now depends on the author’s ability to expose their own blind spots before they write.
That matters because the failure mode is often upstream of generation. A team may believe it is asking for a coding plan, a data extraction flow, or a customer support response. In practice, the request may hide unanswered questions about edge cases, constraints, evaluation criteria, or failure handling. The model then produces something coherent against an incomplete specification, and the team mistakes coherence for correctness.
Shihipar’s framing makes that risk explicit: the operator is not just selecting wording, but performing risk management. The better the pre-prompt diagnosis, the less likely the model is to optimize for the wrong objective, take a flawed assumption as ground truth, or overcommit to an underdefined path.
Known Knowns and Known Unknowns: a usable taxonomy
The most useful part of this guidance is the distinction between Known Knowns and Known Unknowns.
- Known Knowns are the facts, requirements, constraints, and decisions you can already state clearly. In a product context, that might include target users, supported platforms, latency limits, or the exact schema you need the output to follow.
- Known Unknowns are the questions you know exist but have not resolved yet. These are the gaps that can be named even if they cannot yet be answered. Examples include the best ranking heuristic, acceptable fallback behavior, or how strict a compliance rule should be in practice.
The important third category is the one Shihipar is really warning about: Unknown Unknowns. These are the assumptions you have not noticed you are making. They are dangerous precisely because they do not show up in the prompt as questions. Instead, they appear later as awkward outputs, brittle workflows, or costly rework.
This taxonomy is operational, not philosophical. If a requirement can be written down, it belongs in the Known Knowns. If it can be framed as an open question, it belongs in the Known Unknowns and should be surfaced before prompting. If it only appears after the model fails, it was probably an Unknown Unknown and should be captured for the next iteration.
That gives teams a concrete way to design prompts and tests. A prompt that starts from Known Knowns can be tighter and more reproducible. A prompt that still depends on Known Unknowns should be treated as provisional, with explicit branching logic or clarification steps. And if a task still feels fuzzy after that review, the right move may be to stop and investigate rather than generate immediately.
How to surface the blind spots before you build
Shihipar’s suggested techniques are notable because they are simple and implementation-friendly. They also map well onto existing engineering habits.
1. Targeted brainstorming
Start by listing the task and then forcing a separation between facts, assumptions, and open questions.
A practical version looks like this:
- What do we know for certain?
- What are we assuming because we have not checked?
- What could break this approach in production?
- Which parts of the task depend on policy, domain expertise, or user behavior we have not validated?
This kind of brainstorming is useful because it converts vague unease into a structured inventory. If the team cannot articulate the assumptions, the prompt is likely premature.
2. Structured back-and-forth interviews with the AI
Instead of writing a fully formed prompt immediately, use the model as an interviewer. Ask it to question the plan, challenge unstated assumptions, or propose failure modes. The point is not to outsource judgment. It is to expose what the author missed.
For example, a team building an AI workflow can ask:
- What information is missing for this task to be specified well?
- Which edge cases are most likely to produce misleading output?
- What assumptions in this plan are fragile or contradictory?
- If this approach fails, where is the failure likely to appear first?
This is especially useful when the prompt must support a production workflow. If the AI can identify ambiguities before the feature ships, the team can decide whether to narrow scope, collect more data, or add validation steps.
3. Detailed implementation notes
Shihipar also points to careful note-taking during coding or implementation sessions. That may sound mundane, but it matters because prompt quality degrades when decisions are made informally and then forgotten.
Implementation notes should capture:
- Why a particular output format was chosen
- What constraints were enforced and why
- Which assumptions were accepted without proof
- Which fallback behaviors were chosen for the first version
- Where the prompt had to be tightened or relaxed during testing
These notes become a record of how the system actually works, not how the team remembers it working. That distinction is important when prompt libraries, evals, or handoffs are involved.
From prompt to production: what teams need to change
If this surface-first approach is going to matter in real deployments, it cannot live only in a prompt author’s head. It has to become part of the tooling and process around the model.
The most obvious change is to add a pre-prompt checklist to product and engineering workflows. Before a prompt is approved, teams should confirm that they have:
- Written the task in terms of Known Knowns
- Enumerated Known Unknowns explicitly
- Identified at least the most likely Unknown Unknowns through review or challenge
- Defined success criteria and failure modes
- Decided whether the prompt is safe to ship as-is or should remain in experimentation
That checklist can sit inside a PRD, a design doc, or a prompt template. The point is to make the discovery step visible and repeatable.
For engineering teams, the next step is to connect that checklist to QA and CI. A prompt library should not just store the final prompt text. It should preserve the assumptions that shaped it, the unresolved questions it depends on, and the tests that verify those assumptions still hold. If an upstream dependency changes, that metadata should tell reviewers which prompts may need revision.
This also has implications for rollout. A prompt that depends on unresolved unknowns should probably not go straight into a broad production release. It may need gated deployment, narrower user exposure, or a review loop that captures errors quickly. That is not because the model is inherently unsafe. It is because under-specified prompts behave like under-specified software: they may work in the happy path and fail quietly elsewhere.
Tooling will likely need to evolve in the same direction. Prompt editors, model orchestration layers, and internal agent frameworks could all benefit from fields that capture assumptions, open questions, evaluation notes, and versioned decision logs. In other words, the artifact around the prompt may matter almost as much as the prompt itself.
Why this matters now
The timing is what makes Shihipar’s advice more than a style preference. As model capability rises, teams are tempted to assume that stronger models will compensate for weaker process. That works only up to a point. Better models can fill gaps, but they cannot reliably infer product intent that was never specified, policy constraints that were never documented, or deployment risks that were never named.
For developers, that means the center of gravity is moving. The craft is no longer just in writing prompts that sound precise. It is in building a repeatable habit of making uncertainty explicit before the model is invoked.
For product teams, the implication is sharper: prompt engineering is becoming part of release engineering. Teams that treat unknowns as a first-class input will likely ship with fewer surprises, better evaluations, and less rework. Teams that keep treating prompting as a last-mile tuning exercise may continue to chase marginal gains while leaving the real risk in the room: their own blind spots.
