Fable फ़ील्ड गाइड: अपने Unknowns कैसे खोजें

• Claude Fable 5 पर काम का मूल यह है कि उपयोगकर्ता द्वारा दिया गया मानचित्र (map, prompt·skill·context) और वह क्षेत्र (territory, codebase·reality·constraints) जहाँ काम वास्तव में होता है, इनके बीच की दूरी यानी unknowns को खोजकर कम किया जाए
• Fable पहला ऐसा मॉडल है जिसमें काम की गुणवत्ता unknowns को स्पष्ट करने की उपयोगकर्ता की क्षमता पर निर्भर करती है, और काम जितना बड़ा होता है, उतने अधिक unknowns सामने आते हैं
• unknowns को Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns इन 4 प्रकारों में बाँटा जा सकता है, और इन्हें कम करना व इनके लिए तैयारी करना agentic coding की मुख्य क्षमता है
• implementation से पहले, दौरान और बाद में blindspot pass, brainstorming, interview, references, implementation plan, implementation notes, quiz जैसी दोहरावदार तकनीकों से unknowns खोजे जाते हैं
• explanation, brainstorming, interview, prototype, reference जैसी चीजें समस्या के महँगी बनने से पहले सस्ते में unknowns खोजने के तरीके हैं, इसलिए अगला प्रोजेक्ट Claude से unknowns खोजने को कहकर शुरू करना महत्वपूर्ण है

---

मानचित्र और क्षेत्र, और unknowns

• मानचित्र उस काम का प्रतिनिधित्व है जिसे करना है, यानी prompt·skill·context — जो Claude को दिया जाता है; जबकि क्षेत्र वह जगह है जहाँ काम वास्तव में होता है: codebase·reality·actual constraints
• मानचित्र और क्षेत्र का अंतर ही unknowns है, और जब Claude unknowns से टकराता है, तो उसे उपयोगकर्ता की मंशा के बारे में अपनी सर्वश्रेष्ठ समझ के आधार पर निर्णय लेना पड़ता है
• Fable पहला ऐसा मॉडल है जहाँ काम की गुणवत्ता unknowns को स्पष्ट करने की क्षमता पर bottleneck हो जाती है
• केवल पहले से योजना बना लेना पर्याप्त नहीं है; unknowns implementation की गहराई में मिल सकते हैं, या यह भी बता सकते हैं कि समस्या को पूरी तरह किसी और तरीके से हल करना चाहिए
• Fable पर काम implementation से पहले, दौरान और बाद में unknowns खोजने की एक iterative प्रक्रिया है
• unknowns खोजने में मदद करने वाले कुछ उदाहरण संसाधन बाद में देखने लायक हैं

अपने unknowns को जानना

• समस्या को 4 हिस्सों में बाँटें
  • Known Knowns: जो prompt में है, जिसे आप agent से चाहते हैं और बता चुके हैं
  • Known Unknowns: जो अभी पता नहीं है, लेकिन यह पता है कि वह अभी पता नहीं है
  • Unknown Knowns: जो इतने स्वाभाविक हैं कि लिखे नहीं जाते, लेकिन सामने आने पर पहचान में आ जाते हैं
  • Unknown Unknowns: जिन पर बिल्कुल विचार नहीं किया गया, जिनके बारे में जागरूकता ही नहीं है, या यह भी नहीं पता कि चीज़ कितनी बेहतर हो सकती है
• बेहतरीन agentic coder के पास तुलनात्मक रूप से कम unknowns होते हैं, क्योंकि वे codebase और मॉडल के व्यवहार के साथ गहरे स्तर पर sync में होते हैं और विस्तार से जानते हैं कि उन्हें क्या चाहिए
• unknowns को कम करना और उनके लिए तैयार रहना Claude के साथ काम करते हुए सुधारी जा सकने वाली skill है

Claude को आपकी मदद करने दें

• निर्देशों में संतुलन ज़रूरी है; बहुत ज़्यादा specific होने पर Claude उस दिशा में बना रह सकता है जबकि pivot बेहतर हो, और बहुत vague होने पर वह काम के अनुरूप न होने वाली industry best practices के आधार पर चुनाव कर सकता है
• अगर unknowns को ध्यान में नहीं रखा गया, तो दोनों ही स्थितियों में विफलता हो सकती है, और आप Claude से दिशा बदलने की उम्मीद करेंगे बिना यह जाने कि रास्ता बंद है या खुला
• Claude codebase और इंटरनेट को तेज़ी से खोज सकता है, औसत विषयों के बारे में अधिक जानता है, और failure से जल्दी iterate करता है, इसलिए unknowns की खोज तेज़ होती है
• सबसे महत्वपूर्ण चीज़ है starting point का context देना — आप अभी सोच की किस स्थिति में हैं, समस्या और codebase के साथ आपका अनुभव क्या है, यह बताकर Claude के साथ thought partner की तरह सहयोग करना
• पहले Claude में HTML के उपयोग पर लिखा जा चुका है, और अधिकांश मामलों में HTML artifact visualization और expression के लिए सबसे उपयुक्त होता है

Pre-implementation

• Blind Spot Pass

  • नई domain की feature development या design iteration जैसे अपरिचित कामों में unknown unknowns बहुत होते हैं; हो सकता है आपको यह भी न पता हो कि कौन से प्रश्न पूछने हैं, क्या अच्छा माना जाता है, पहले क्या किया गया है, या किन pitfalls से बचना है
  • Claude से unknown unknowns खोजकर समझाने को कहें; "blindspot pass" और "unknown unknowns" जैसे शब्दों का वही रूप इस्तेमाल करें, और यह context देना महत्वपूर्ण है कि आप कौन हैं और क्या जानते हैं
  • उदाहरण prompt
    • "मैं एक नया auth provider जोड़ रहा हूँ, लेकिन इस codebase के auth module के बारे में कुछ नहीं जानता। blindspot pass करके संबंधित unknown unknowns पहचानो और मुझे बेहतर prompt करने में मदद करो"
    • "मुझे color grading क्या है यह नहीं पता, लेकिन मुझे इस वीडियो को grade करना है। मुझे बेहतर prompt करने लायक बनाने के लिए color grading के unknown unknowns समझाओ"

• Brainstorms and prototypes

  • जिन क्षेत्रों में unknown knowns बहुत हैं — यानी जिन्हें देखकर आप पहचान लेंगे, लेकिन पहले से define करना मुश्किल है — वहाँ Claude के साथ brainstorming और prototype करें
  • implementation के दौरान नहीं, बल्कि prototype के शुरुआती चरण में unknown knowns की पहचान और उन्हें भाषा देना क़ीमती होता है, क्योंकि spec में छोटे बदलाव code implementation को बहुत बदल सकते हैं और पहले किए गए बदलावों को वापस लेना कठिन हो सकता है
    • उदाहरण: जब आप backend route या frontend state के बिना सिर्फ़ frame में जोड़ा गया button कैसा दिखता है, यह देखना चाहते हों
  • visual design ऐसा क्षेत्र है जिसे साफ़ शब्दों में बयान करना कठिन होता है, लेकिन देखकर पता चल जाता है कि क्या चाहिए; इसलिए कई design approaches माँगें
  • लगभग हर coding session को exploration और brainstorming चरण से शुरू करें ताकि इरादे के साथ scope तय हो; इससे scope बहुत संकरा या बहुत बड़ा होने से बचता है
  • उदाहरण prompt
    • "मुझे इस data के लिए dashboard चाहिए, लेकिन मेरी visual sense अच्छी नहीं है और मुझे नहीं पता क्या संभव है। 4 पूरी तरह अलग design directions वाले HTML pages बनाओ ताकि मैं उन पर प्रतिक्रिया दे सकूँ"
    • "integration शुरू करने से पहले fake data के साथ नए editor toolbar का mockup एक single HTML file में बनाओ। मैं असली app को छुए बिना layout पर प्रतिक्रिया देना चाहता हूँ"
    • "मोटे तौर पर समस्या onboarding के बाद user churn है। codebase खोजकर सबसे सस्ते से लेकर सबसे ambitious तक intervention के 10 संभावित points brainstorm करो"

• Interviews

  • अगर पर्याप्त brainstorming के बाद भी unknowns बचे हैं, तो Claude से unknowns और ambiguity पर interview लेने को कहें, और ऐसा context दें कि वह प्रश्नों को अच्छी तरह guide कर सके
  • उदाहरण prompt
    • "एक बार में एक अस्पष्ट बिंदु के बारे में पूछो, और उन सवालों को प्राथमिकता दो जिनके जवाब architecture बदल सकते हैं"

• References

  • जब आप अपनी चाहत को विस्तार से बयान नहीं कर पाते, तो सबसे अच्छा उत्तर reference होता है; diagram, document, image सब काम आ सकते हैं, लेकिन source code सबसे बेहतरीन reference है
  • अगर कोई library किसी खास तरीके से implement की गई है या कोई design component पसंद है, तो Claude को उस folder की ओर इशारा करें और उसे ढूँढने को कहें, चाहे वह किसी दूसरी language में ही क्यों न हो
  • Claude Design में भी यही बात लागू होती है; अगर आप पसंदीदा website के किसी module की ओर इशारा करें, तो वह screenshot नहीं बल्कि underlying code पढ़कर markup, structure और actual implementation के बारे में समृद्ध जानकारी दे सकता है
  • उदाहरण prompt
    • "vendor/rate-limiter का यह Rust crate वही backoff behavior ठीक-ठीक implement करता है जो मुझे चाहिए। इसे पढ़ो और उसी semantics को हमारे TypeScript API client में फिर से implement करो"

• Implementation Plans

  • जब implementation के लिए तैयार हों, तो review के लिए ऐसा implementation plan माँगें जो सबसे अधिक बदल सकने वाले हिस्सों (data model, type interfaces, UX flow) पर केंद्रित हो, ताकि जिन जगहों पर संशोधन चाहिए वे सतह पर आ सकें
  • उदाहरण prompt
    • "HTML में implementation plan लिखो, लेकिन वे निर्णय सबसे ऊपर रखो जिनमें मैं सबसे अधिक बदलाव कर सकता हूँ (data model changes, नए type interfaces, user-facing elements), और mechanical refactoring को सबसे नीचे रखो"

During implementation

• Implementation notes

  • जब आप plan से संतुष्ट हों, तो एक नया session बनाकर spec file, prototype जैसे artifacts prompt में दें और agent से implementation करने को कहें
  • चाहे आप कितनी भी planning कर लें, unknown unknowns हमेशा छिपे रहते हैं, और काम के दौरान मिले edge cases के कारण agent को अलग रास्ता अपनाना पड़ सकता है
  • Claude Code से कहें कि वह एक अस्थायी implementation-notes.md(या .html) file में लिए गए निर्णय दर्ज करे, ताकि अगली कोशिश में उनसे सीखा जा सके
  • उदाहरण prompt
    • "implementation-notes.md file maintain करो। अगर ऐसा edge case मिले जो plan से अलग जाने पर मजबूर करे, तो conservative choice लो, उसे 'Deviations' में लिखो, और फिर आगे बढ़ो"

Post implementation

• Pitches and explainers

  • कुछ भी ship करने में सबसे महत्वपूर्ण बातों में से एक है सहमति और approval हासिल करना, और final document में pitch तथा explainer artifacts बनाना इसमें मदद करता है
    • जब reviewer भी आपकी तरह unknowns से शुरू कर रहा हो, तो यह समझ को तेज़ करता है
    • जब कोई expert यह देखना चाहता हो कि आपने unknowns और आम failure points पर विचार किया है या नहीं, तो यह approval को तेज़ करता है
  • उदाहरण prompt
    • "prototype, spec और implementation notes को मिलाकर एक single document बनाओ जिसे Slack पर डालकर सहमति ली जा सके। demo GIF को सबसे आगे रखो"

• Quizzes

  • लंबे work session के बाद Claude आपकी अपेक्षा से अधिक काम कर चुका हो सकता है, और सिर्फ़ code diff देखकर मौजूदा code paths पर निर्भर behavior की समझ सतही रह सकती है
  • context देने के बाद Claude से बदलावों पर quiz बनाने को कहें ताकि समझ की पुष्टि हो सके, और quiz पूरी तरह pass करने के बाद ही merge करें
  • उदाहरण prompt
    • "मैं इस change में हुई हर चीज़ समझना चाहता हूँ। context, intuition, क्या किया गया, इन सबको शामिल करते हुए एक HTML report बनाओ और नीचे ऐसा quiz जोड़ो जिसे pass करना अनिवार्य हो"

Fable launch के उदाहरण से यह सब कैसे जुड़ता है

• Fable launch video पूरी तरह Claude Code से edit की गई थी, जबकि यह एक नया क्षेत्र था और विशेषज्ञता का विषय भी नहीं था
• जो पता था, वहीं से शुरुआत हुई: यह ज्ञात था कि Claude code के जरिए video editing और transcription कर सकता है, लेकिन accuracy को लेकर भरोसा नहीं था; इसलिए Whisper-style transcription के सिद्धांत और यह कि ffmpeg से ums और लंबे silence को सटीक रूप से काटा जा सकता है या नहीं, इसकी व्याख्या माँगी गई
• एक ऐसा UI चाहिए था जिसमें बोले गए शब्द और timing मेल खाएँ, लेकिन यह संभव होगा या नहीं, इस पर भरोसा नहीं था; इसलिए Remotion और transcription के साथ prototype video बनाकर जाँच की गई
• वीडियो थोड़ा muted इसलिए दिख रहा था क्योंकि color grading की कमी थी; यह पता था, लेकिन color grading क्या है यह नहीं पता था, इसलिए variations चुनने के बजाय color grading सिखाने को कहा गया ताकि unknowns सामने आएँ

मानचित्र और क्षेत्र को मिलाना

• जैसे-जैसे model बेहतर होते जाते हैं, सही approach के साथ और ज़्यादा हासिल किया जा सकता है; और अगर कोई long-term task गलत दिशा में लौटता है, तो आमतौर पर unknowns को define करने या ऐसे implementation plan पर अधिक समय देने की ज़रूरत होती है जिस पर Claude तुरंत काम चला सके
• हर explanation, brainstorming, interview, prototype और reference समस्या के महँगी बनने से पहले सस्ते में unknowns खोजने का साधन है
• अगला प्रोजेक्ट Claude से unknowns खोजने को कहकर शुरू करना ही मुख्य बात है