Where Claude gets it wrong: your unknowns, not the model

Anthropic engineer Tarik Shihipar, who works on Claude Code, published an essay titled “A Field Guide to Fable: Finding Your Unknowns,” which garnered over a million views in a single day. This isn’t just another list of prompts, but a framework for thinking: why the agent doesn’t do what you wanted, and what to do about it before, during, and after the task. The main idea is that, given the quality of modern models, the outcome increasingly depends not on the models themselves, but on your ability to clarify your own unknowns. The map is not the territory. Your prompts, skills, and context are the map. The code base, real-world limitations, and edge cases—that’s the territory. The difference between them is what constitutes the unknowns. When Claude encounters an unknown, it guesses what you want. The larger the scope of work, the more of these guesses there are. Tarik breaks down all unknowns into four quadrants: Known knowns—what’s explicitly written in the prompt. Known unknowns—what you haven’t figured out yet, but you know you don’t know. Known unknowns—things so obvious that you didn’t bother writing them down, but you’d recognize them without a doubt. Unknown unknowns—things you haven’t even thought of at all. The last category is the most dangerous. The creators of Claude Code, whose prompts Tarik is monitoring, have relatively few unknowns: they have a deep understanding of both the codebase and the model’s behavior. But even they run into unknowns. The skill of agent-based coding is the skill of reducing them. ## Before implementation: a cheap way to find out what you didn’t know “Blindspot pass” is the most powerful technique for getting started in an unfamiliar field. Literal prompt: “Do a blindspot pass: help me identify my unknown unknowns on this topic.” Claude searches the codebase and the internet faster than you do and knows more about most topics—let it point out the pitfalls you haven’t even suspected. Brainstorming and prototyping work for “unknown knowns”—criteria that fall under “I’ll know it when I see it.” Discovering them during implementation is costly: a small change to a feature can lead to a radically different implementation, and it’s difficult for the agent to roll back. Tarik asks for several live design options for a single artifact, rather than a text description—reacting to a finished image is faster than visualizing a paragraph. Interviews are an underrated technique. After brainstorming, unknowns still remain. Tarik asks Claude to ask questions one at a time, starting with those where the answer changes the architecture. This is a low-cost way to shift the search for unknowns onto the model. References are more powerful than descriptions. The most powerful reference is source code. If there’s a library with the behavior you need, show the folder and tell them what to look for there. Claude will read the code under the hood rather than just look at a screenshot. The implementation plan should include priorities. Tarik suggests starting the plan with the decisions that are most likely to need changing: data models, type interfaces, and UX scenarios. Mechanical refactoring goes at the very bottom—you can trust the agent with that. ## During implementation: document deviations No matter how much you plan, unknown unknowns will crop up in the heat of the work. Tarik asks Claude Code to maintain a temporary file called implementation-notes.md: if the agent encounters an edge case, it chooses a conservative option, records it in the “Deviations” section, and continues. These notes are taken into account in the next attempt. ## After implementation: a quiz instead of reading the diff Reading a diff provides only a superficial understanding. A significant portion of the behavior depends on the code that’s already been written. Tarik first gets detailed context about the change from Claude, and then takes a quiz on that change. He merges only after passing the quiz without a single mistake. This transforms the review from a formality into a genuine self-assessment. The second step is a pitch to the team. The prototype, spec, and notes are compiled into a single document that can be shared on Slack. Reviewers start from the same unknowns you started with and can see that you’ve accounted for typical failure points. ## What I Take Away Interview mode is the most underrated technique. Before a developer writes any code, we walk through the problem, and asking questions one by one reveals things I hadn’t even considered. The prompt “start with questions where my answer changes the architecture” makes this even more effective. Brainstorming before coding has long been standard practice. Not a single line of code is written until we’ve agreed on what we’re doing. Tarik’s approach—asking for live prototypes you can point at, rather than just text—works better. I take on quizzes without hesitation. Reading a diff and understanding the changes are two different things. The idea of “merging only after a flawless quiz” turns code review from a formality into a genuine self-assessment. The better the models become, the more you can achieve with the right approach. If a big task returns the wrong result—most likely, it would have been worth spending more time identifying your unknowns. Every time you explore blind spots, brainstorm, conduct an interview, build a prototype, or review references—it’s an inexpensive way to discover what you didn’t know, while it’s still affordable to fix it. Source: ituzovlab.ru

Source: ituzovlab.ru