앤스로픽 개발자 타리크 시히파르(Thariq Shihipar)는 클로드의 최신 모델인 '파블 5(Fable 5)'의 성능을 극대화하려면 프롬프트를 작성하기 전에 사용자가 자신의 '모르는 것(맹점)'을 파악하는 것이 필수적이라고 강조합니다. 지나치게 구체적인 프롬프트는 AI의 유연성을 떨어뜨리고 반대로 너무 포괄적이면 뻔한 결과만 내뱉기 때문에, 코딩 에이전트와의 브레인스토밍이나 구조화된 인터뷰를 통해 사전에 맹점을 식별하고 프로젝트의 범위를 명확히 설정해야 합니다.
번역된 본문
제목: 앤스로픽 개발자, 스스로의 맹점을 먼저 찾는 데 초점을 맞춘 '파블 5(Fable 5)' 프롬프트 작성 팁 공유
AI 에이전트와 함께 코딩해 본 사람이라면 누구나 이 문제를 겪어봤을 것입니다. 프롬프트를 입력했고, 계획도 명확해 보였는데 결과물이 영 어딘가 부족한 경우입니다. 앤스로픽 개발자 타리크 시히파르(Thariq Shihipar)에 따르면, 클로드의 최신 모델인 '파블 5(Fable 5)'를 사용할 때 이러한 문제는 더 이상 모델 자체의 한계라기보다는 사용자 본인의 맹점(blind spots)에서 비롯되는 경우가 많습니다.
시히파르는 파블 5가 출시된 이래로 처음으로 '출력의 질이 사용자가 자신의 모르는 부분(unknowns)을 얼마나 잘 명확히 하는지'에 달려 있는 모델이라고 말합니다. 그는 지식의 네 가지 단계를 설명합니다. '아는 것(Known Knowns)'은 이미 프롬프트에 작성된 내용입니다. '아는 모르는 것(Known Unknowns)'은 아직 답을 찾지 못했지만, 그것을 모른다는 사실을 인지하고 있는 질문들입니다. '모르는 아는 것(Unknown Knowns)'은 너무 당연해서 글로 적어본 적은 없지만, 보자마자 알아볼 수 있는 지식을 뜻합니다. 그리고 가장 중요한 카테고리는 '모르는 모르는 것(Unknown Unknowns)'으로, 아예 고려조차 해보지 않은 사항들을 의미합니다.
지나친 구체화는 지나친 모호함만큼이나 위험하다
시히파르는 단순히 미리 계획하는 것만으로는 충분하지 않다고 말합니다. 모르는 부분은 구현 단계의 깊은 곳에서 발견될 수도 있고, 아니면 해당 문제를 완전히 다른 방식으로 풀어야 한다는 신호일 수도 있습니다. 그는 훌륭한 코딩 에이전트 사용자들은 모르는 부분이 상대적으로 적지만, 여전히 그런 변수들이 발생할 것을 항상 대비한다고 설명합니다. 지나치게 구체적인 지시는 상황 변화가 필요할 때도 모델이 기존 방식을 고집하게 만들 위험이 있습니다. 반대로 지나치게 모호하면 현재 작업과는 맞지 않는 업계의 기본값(일반적인 관행)에 따른 결과를 내뱉게 됩니다. 그는 "자신이 모르는 부분을 고려하지 않으면 두 가지 방향 모두에서 실패하게 된다"고 경고합니다. 하지만 클로드는 사용자가 미지의 영역을 더 빨리 발견하도록 도울 수 있다고 덧붙입니다. 코드베이스와 인터넷을 고속으로 검색할 수 있으며, 대부분의 주제에 대해 일반 사용자보다 더 많은 지식을 갖추고 있기 때문입니다. 핵심은 현재 생각의 진행 상황과 해당 문제에 대한 본인의 경험 수준 등 출발점에 대한 맥락을 클로드에게 제공하는 것입니다.
실제 구현에 앞서 체계적으로 맹점 찾아내기
시히파르는 본격적인 코딩에 들어가기 전 단계를 위한 몇 가지 기술을 소개합니다. 그가 이른바 '맹점 파악(blindspot pass)' 작업에서는 클로드에게 자신의 '모르는 모르는 것'을 찾아달라고 요청합니다. 그는 낯선 코드베이스에서 작업할 때 특히 효과가 좋다고 말합니다. 그가 제안하는 프롬프트 예시는 다음과 같습니다. "새로운 인증 제공자를 추가하려고 하는데, 이 코드베이스의 인증 모듈에 대해 아는 것이 없습니다. 나와 관련된 '모르는 모르는 것'을 찾아내고 내가 당신에게 더 나은 프롬프트를 줄 수 있도록 맹점 파앐 작업을 해줄래?"
시각 디자인과 같이 '모르는 아는 것'이 많은 분야의 경우, 그는 브레인스토밍과 프로토타이핑을 권장합니다. 바로 코드를 구현하는 대신, 반응을 살펴볼 수 있도록 HTML 형태로 급진적으로 다른 여러 디자인 방향을 생성해 달라고 요청합니다. 또한 코딩 세션을 시작할 때 거의 항상 탐색이나 브레인스토밍 단계를 거쳐 프로젝트의 범위를 의식적으로 정의합니다. 그가 설명하는 다른 기술로는 구조화된 인터뷰가 있습니다. 이는 클로드가 모호한 부분에 대해 사용자에게 하나씩 질문을 던지는 방식으로, 특히 답변에 따라 아키텍처가 바뀔 수 있는 중요한 질문들을 우선적으로 묻게 합니다. 더불어 그는 참조 자료(References) 역시 중요하다고 강조합니다. 소스 코드 자체도 훌륭한 참조가 될 수 있습니다.
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 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 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 DEC_D_Incontent-1 "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 DEC_D_Incontent-2 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 example of 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 together a 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