In a post on X, Thariq argues that working with Claude Fable 5 keeps reinforcing an old software lesson: “the map is not the territory.” In his account, the map is the prompt, context and skills handed to the model, while the territory is the codebase, the real-world constraints and the task itself.
Thariq says the gap between those two things is where “unknowns” live. When Claude runs into one, he says, it has to make a guess about intent. As work gets larger, he suggests, the challenge becomes less about writing more instructions and more about identifying what still needs to be clarified. The post later appeared on the Claude blog, according to a follow-up on his account.
He breaks ambiguity into four categories: “known knowns,” “known unknowns,” “unknown knowns” and “unknown unknowns.” In the thread, he argues that stronger agentic coding tends to come from having fewer of those gaps, while still planning for the ones that remain.
A workflow for surfacing unknowns
Thariq’s post recommends several ways to draw out those gaps before implementation begins.
For unfamiliar areas, he suggests a “blind spot pass” aimed at finding “unknown unknowns.” That can include asking Claude to explain what needs to be learned, what questions matter and what pitfalls are likely to appear.
For design-heavy or scope-heavy work, he recommends brainstorming and prototyping first. In the examples he shares, that means asking for several design directions, mocking up a toolbar in HTML, or listing possible intervention points for a problem like onboarding churn before touching production code.
He also describes using interviews when the shape of the task is still unclear, asking Claude to question him one point at a time and prioritizing the questions that would change architecture.
When a more concrete reference exists, he points Claude to source code rather than relying only on descriptions or screenshots. The post mentions a Rust crate as a reference for matching backoff behavior, and notes that Claude Design can inspect underlying code directly.
Planning, then logging deviations
Once the shape of the work is clearer, Thariq says he asks for an implementation plan that leads with parts most likely to change, such as data models, type interfaces and user-facing flows.
He also recommends keeping an “implementation-notes.md” file during the build itself. In his version of the process, that file tracks deviations from the plan, especially when edge cases force a conservative choice.
After implementation, he suggests packaging the outcome into pitch or explainer materials for reviewers, then asking Claude to quiz him on the change. In the thread, he writes that he only merges after passing the quiz.
How he says it played out on Fable
Thariq uses the launch video for Fable as an example. He says the project started from what he already knew: Claude could help with video editing and transcription, but he was unsure how accurate it would be.
From there, he reports asking Claude to explain how transcription systems work and whether it could reliably cut pauses and filler words with ffmpeg. He then says he asked for a prototype video using Remotion and transcription before moving further.
When the finished video looked muted, he says he realized he did not actually know what “good” color grading looked like. Instead of asking for random visual variations, he says he asked Claude to teach him about color grading so he could identify his own unknowns.
The post’s closing argument is straightforward: long-horizon work tends to go wrong when the unknowns are not surfaced early enough. Thariq’s answer is a repeated cycle of explaining, brainstorming, interviewing, prototyping and documenting until the map and the territory line up more closely.
Source: X
