Anthropic developer shares prompting tips for Fable 5 that focus on finding your own blind spots first

Ad

Skip to content

Anthropic developer shares prompting tips for Fable 5 that focus on finding your own blind spots first


Matthias Bastian[View the LinkedIn Profile of Matthias Bastian](https://www.linkedin.com/in/matthias-bastian-128b71b1/ "View the LinkedIn Profile of Matthias Bastian")

Jul 4, 2026

Nano Banana Pro prompted by THE DECODER

Key Points

• According to Anthropic developer Thariq Shihipar, the quality of outputs from Claude's new Fable 5 model hinges on how effectively users can recognize their own knowledge gaps and blind spots before writing prompts.
• Shihipar suggests several techniques for uncovering these "unknowns," including targeted brainstorming, structured back-and-forth interviews with the AI, and maintaining detailed implementation notes during coding sessions.
• A central challenge in prompting, Shihipar notes, is finding the right level of specificity: instructions that are too detailed can lock the AI into flawed approaches, while prompts that are too open-ended tend to produce generic, unhelpful responses.

Ask about this article…Search

Topics

• Being too specific is just as bad as being too vague
• Before building, systematically uncover blind spots
• During and after implementation, document and understand
• A launch video edited entirely with Claude Code

Anyone who codes with AI agents knows the problem. The prompt is set, the plan seems clear, but the result isn't quite right. According to Anthropic developer Thariq Shihipar, with Claude's latest model, Fable 5, this is less and less a problem with the model itself and more a result of the user's own blind spots.

Shihipar says that Fable 5 is the first model where output quality is limited by the user's ability to clarify their "unknowns." "Known Knowns" are what's already in the prompt. "Known Unknowns" are questions you know you haven't figured out yet but are aware you haven't. "Unknown Knowns" describe knowledge so obvious you'd never write it down, but you'd recognize it if you saw it. The critical category, according to Shihipar, is "Unknown Unknowns," meaning things you haven't considered at all.

Being too specific is just as bad as being too vague

Planning ahead alone isn't enough, Shihipar says. Unknowns can surface deep in the implementation or signal that the problem should be solved in a completely different way. The best agentic coders have relatively few unknowns but still always expect them, he argues.

Ad

Too much specificity risks Fable 5 rigidly following instructions, even when a change of course would make more sense, according to Shihipar. Too much vagueness gets you decisions based on industry defaults that don't fit the specific task.

Ad

"When you don't account for your unknowns you fail both ways," Shihipar writes. But Claude can help you discover your own unknowns faster, he adds. It searches codebases and the internet at high speed and knows more about most topics than the average user. The key, according to Shihipar, is giving Claude context about your starting point, meaning where you are in your thinking and what experience you have with the problem.

Before building, systematically uncover blind spots

Shihipar describes several techniques for the phase before actual implementation. In what he calls a "blindspot pass," you ask Claude to identify your unknown unknowns. This works especially well when you're working in an unfamiliar part of the codebase, he says.

Ad

An example prompt he suggests: "I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better."

For areas with many "unknown knowns," like visual design, Shihipar recommends brainstorming and prototyping. Instead of jumping into implementation, he has Claude generate several radically different design directions as HTML artifacts so he can react to them. He starts almost every coding session with an exploration or brainstorming phase to consciously define the project scope.

Ad

Other techniques he describes include structured interviews, where Claude asks the user question by question about ambiguities, prioritizing questions whose answers would change the architecture. References also matter, Shihipar says. Source code is the best reference, even if it's written in a different programming language. Claude Design, for example, reads a website's underlying code, not just the screenshot.

Ad

Before the actual work begins, Shihipar has Claude create an implementation plan that focuses on the parts most likely to change, such as data models, type interfaces, and everything on the user side. Mechanical refactoring comes last.

During and after implementation, document and understand

Unknowns also lurk during implementation, Shihipar warns. He asks Claude Code to keep a temporary "implementation-notes.md" file where it tracks decisions it makes so they can learn from the next attempt. When unexpected edge cases come up, Claude should pick the conservative option, log the deviation, and keep working.

| Category | Meaning | | --- | --- | | Known Knowns | What is stated in the prompt—that is, the user’s explicitly stated knowledge. | | Known Unknowns | Questions that you know you haven’t answered yet. | | Unknown Knowns | Knowledge that is so obvious that you would never write it down, but would recognize it immediately if you saw it. | | Unknown Unknowns | Things you haven’t considered at all. |

After implementation, Shihipar recommends two techniques. First, "pitches and explainers," which are summary documents for stakeholders that bundle the prototype, specs, and implementation notes. Second, "quizzes," where Claude generates an HTML report detailing the changes made, with context and insights, followed by a quiz. Shihipar says he doesn't merge until he passes the quiz without any errors.

A launch video edited entirely with Claude Code

Shihipar shows how these techniques work together using the exampleof the launch video for Fable, which he edited entirely with Claude Code. Video editing was new territory for him, he says.

He started with what he knew. Claude can edit and transcribe videos using code. It was unclear whether the accuracy would be good enough, so he had someone explain how transcription works with Whisper and whether filler words and pauses could be precisely cut using ffmpeg. For the time-controlled fade-in of UI elements, he built a prototype with Remotion.

When the result looked flat in terms of color, he first tried having Claude generate various color-grading variations. But he realized that he didn't know what "good" looked like when it came to color grading. Instead of blindly evaluating variations, he had Claude teach him about the subject to uncover his unknowns.

The more powerful the models get, the more you can achieve with the right approach, Shihipar says. If a long-running task goes sideways, you likely need to invest more time defining your own unknowns or create an implementation plan that lets Claude improvise through them.

"Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix,"he writes. Shihipar also put togethera visual version of his tips on a website.

AI News Without the Hype – Curated by Humans

Subscribe to THE DECODER for ad-free reading, a weekly AI newsletter, our exclusive "AI Radar" frontier report six times a year, full archive access, and access to our comment section.

Subscribe now

Source:via X\|Companion Blog Page

BETA-TEST

×

Start new search

×\|

Send

wpDiscuz

Insert

BETA-TEST

×

Start new search

×\|

Send

wpDiscuz

Insert