क्लॉड फेबल 5 के साथ काम करना मुझे बार-बार एक पुराना सबक सिखाता है: नक्शा क्षेत्र नहीं है (the map is not the territory)।
नक्शा, यानी किए जाने वाले काम का प्रतिनिधित्व, मेरे प्रॉम्प्ट, कौशल और संदर्भ हैं – यह वह है जो मैं क्लॉड को देता हूं। क्षेत्र वह जगह है जहां काम होना चाहिए: कोडबेस, वास्तविक दुनिया और उसकी वास्तविक बाधाएं।

नक्शे और क्षेत्र के बीच के अंतर को मैं अज्ञात (unknowns) कहता हूं। जब क्लॉड किसी अज्ञात से टकराता है, तो उसे मेरी इच्छा के बारे में अपने सबसे अच्छे अनुमान के आधार पर निर्णय लेना होता है। जितना अधिक काम किया जा रहा है, उतने ही अधिक अज्ञात से क्लॉड टकरा सकता है।
फेबल पहला मॉडल है जहां मुझे लगता है कि काम की गुणवत्ता मेरी उसके अज्ञात को स्पष्ट करने की क्षमता से बाधित होती है।
महत्वपूर्ण बात यह है कि सिर्फ आगे की योजना बनाना हमेशा पर्याप्त नहीं होता। आप कार्यान्वयन में गहराई से अज्ञात पा सकते हैं, या आपके अज्ञात आपको बता सकते हैं कि आपको वास्तव में समस्या को पूरी तरह से अलग तरीके से हल करना चाहिए।
मैंने पाया है कि फेबल के साथ काम करना कार्यान्वयन से पहले, उसके दौरान और बाद में अपने अज्ञात की खोज करने की एक पुनरावृत्तीय प्रक्रिया है।
मैंने अज्ञात खोजने के लिए कुछ उदाहरण आर्टिफैक्ट यहां बनाए हैं, लेकिन कृपया वापस आकर यह समझ विकसित करें कि उनका उपयोग कब करना है।
अपने अज्ञात को जानना
आपके अज्ञात क्या हैं? जब मैं क्लॉड के पास किसी समस्या के साथ आता हूं, तो मैं इसे चार तरीकों से तोड़ता हूं:
- ज्ञात ज्ञात (Known Knowns): यह मूल रूप से वही है जो मेरे प्रॉम्प्ट में है। मैं एजेंट को क्या बताता हूं कि मैं क्या चाहता हूं?
- ज्ञात अज्ञात (Known Unknowns): मैंने अभी तक क्या नहीं समझा है, लेकिन मुझे पता है कि मैंने नहीं समझा है?
- अज्ञात ज्ञात (Unknown Knowns): ऐसा क्या है जो इतना स्पष्ट है कि मैं इसे कभी लिखूंगा नहीं, लेकिन देखने पर पहचान लूंगा?
- अज्ञात अज्ञात (Unknown Unknowns): मैंने किस बारे में बिल्कुल नहीं सोचा है? मैं किस ज्ञान से अवगत नहीं हूं? क्या मुझे पता है कि कोई चीज़ कितनी अच्छी हो सकती है?

सबसे अच्छे एजेंटिक कोडर वे होते हैं जिनके पास अपेक्षाकृत कम अज्ञात होते हैं। बोरिस या जैरेड को प्रॉम्प्ट करते देखकर, मुझे स्पष्ट है कि वे विस्तार से जानते हैं कि वे क्या चाहते हैं। वे कोडबेस और मॉडल व्यवहार दोनों के साथ गहराई से तालमेल में हैं।
लेकिन वे अज्ञात भी मानते हैं। कई मायनों में, अपने अज्ञात को कम करना और उनकी योजना बनाना, एजेंटिक कोडिंग का कौशल है। लेकिन सौभाग्य से, यह एक ऐसा कौशल है जिसे आप क्लॉड के साथ काम करके सुधार सकते हैं।
क्लॉड को आपकी मदद करने में मदद करें

क्लॉड को निर्देश देना एक नाजुक संतुलन है। यदि आप बहुत विशिष्ट हैं, तो क्लॉड आपके निर्देशों का पालन करेगा, भले ही कोई मोड़ अधिक उपयुक्त हो। यदि आप बहुत अस्पष्ट हैं, तो क्लॉड अक्सर उद्योग की सर्वोत्तम प्रथाओं के आधार पर विकल्प और धारणाएं बनाएगा जो आपके कार्य के लिए उपयुक्त नहीं हो सकते हैं।
जब आप अपने अज्ञात का हिसाब नहीं रखते, तो आप दोनों तरह से असफल होते हैं। आप नहीं जानते कि रास्ता कब बाधाओं से भरा होगा और आप नहीं जानते कि रास्ता कब साफ होगा, लेकिन फिर भी आप चाहते हैं कि क्लॉड मुड़े।
क्लॉड आपको आपके अज्ञात को तेजी से खोजने में मदद कर सकता है। यह आपके कोडबेस और इंटरनेट को बेहद तेज़ी से खोज सकता है और औसत विषय के बारे में आपसे अधिक जानता है। यह असफलता से भी तेजी से पुनरावृति कर सकता है।
इस प्रक्रिया का सबसे महत्वपूर्ण हिस्सा क्लॉड को आपके शुरुआती बिंदु के बारे में संदर्भ देना है। उदाहरण के लिए, उसे बताएं कि आप अपनी विचार प्रक्रिया में कहां हैं; समस्या और कोडबेस के साथ अपने अनुभव का खुलासा करें; और उसे एक विचार भागीदार की तरह आपके साथ काम करने दें।
मैंने पहले क्लॉड के साथ HTML का उपयोग करने के बारे में लिखा है, इनमें से लगभग सभी मामलों में, HTML आर्टिफैक्ट इसे देखने और प्रस्तुत करने का सबसे अच्छा तरीका है।
इस लेख में मैं उन कुछ पैटर्न का विवरण देता हूं जिनका उपयोग मैं इन अज्ञात को उजागर करने के लिए करता हूं। मैं हर बार हर तकनीक का उपयोग नहीं करता, लेकिन यह तकनीकों का एक उपयोगी संग्रह है।

कार्यान्वयन से पहले
ब्लाइंड स्पॉट पास (Blind Spot Pass)
काम शुरू करते समय, सबसे उपयोगी चीजों में से एक है अपने ब्लाइंड स्पॉट को समझना। उदाहरण के लिए, यदि आप कोडबेस के किसी नए हिस्से में कोई सुविधा लिख रहे हैं या क्लॉड का उपयोग किसी अपरिचित काम, जैसे डिज़ाइन पर पुनरावृति, में मदद के लिए कर रहे हैं, तो आपके पास बहुत सारे अज्ञात अज्ञात (unknown unknowns) होने की संभावना है।
हो सकता है कि आप न जानते हों कि कौन से प्रश्न पूछने हैं, अच्छा कैसा दिखता है, क्या ऐतिहासिक काम किया गया है, या किन गड्ढों से बचना है।
ऐसा करने के लिए, आप क्लॉड से अपने अज्ञात अज्ञात को खोजने और उन्हें समझाने में मदद करने के लिए कह सकते हैं। मुझे शाब्दिक शब्दों "ब्लाइंड स्पॉट पास" और "अज्ञात अज्ञात" का उपयोग करना पसंद है। उसे यह संदर्भ देना कि आप कौन हैं और आप क्या जानते हैं, आमतौर पर महत्वपूर्ण होता है।
उदाहरण प्रॉम्प्ट:
- "मैं एक नया auth प्रदाता जोड़ने पर काम कर रहा हूं लेकिन मैं इस कोडबेस में auth मॉड्यूल के बारे में कुछ नहीं जानता। क्या आप मेरे प्रासंगिक अज्ञात अज्ञात को समझने और आपको बेहतर प्रॉम्प्ट करने में मेरी मदद करने के लिए एक ब्लाइंड स्पॉट पास कर सकते हैं?"
- "मैं नहीं जानता कि कलर ग्रेडिंग क्या है, लेकिन मुझे इस वीडियो को ग्रेड करने की जरूरत है। क्या आप मुझे कलर ग्रेडिंग के बारे में अपने अज्ञात अज्ञात को समझना सिखा सकते हैं, ताकि मैं बेहतर प्रॉम्प्ट कर सकूं?"
विचार-मंथन और प्रोटोटाइप
जब मैं बहुत सारे अज्ञात ज्ञात (unknown knowns) वाले क्षेत्र में काम कर रहा होता हूं, जिसमें ऐसे मानदंड शामिल होते हैं जिन्हें मैं केवल देखने पर ही परिभाषित कर पाता हूं, तो मैं क्लॉड से मेरे साथ विचार-मंथन और प्रोटोटाइप करने के लिए कहना पसंद करता हूं।
प्रोटोटाइपिंग के दौरान अज्ञात ज्ञात को जल्दी पहचानना और शब्दबद्ध करना बेहद मूल्यवान है, क्योंकि कार्यान्वयन के दौरान उन्हें ढूंढना (अपेक्षाकृत) महंगा हो सकता है। किसी सुविधा या स्पेक में छोटे बदलाव कोड में पूरी तरह से अलग कार्यान्वयन का कारण बन सकते हैं, और आपके एजेंट के लिए पिछले बदलावों को पूर्ववत करना अधिक कठिन हो सकता है।
उदाहरण के लिए, आप सिर्फ यह देखना चाह सकते हैं कि एक फ्रेम में जोड़ा गया बटन कैसा दिखता है, बिना बैकएंड रूट जोड़े या फ्रंटएंड में अतिरिक्त स्टेट बनाए रखे।
विज़ुअल डिज़ाइन मेरे लिए व्यक्त करना मुश्किल है, लेकिन मैं जानता हूं कि मैं क्या चाहता हूं जब मैं इसे देखता हूं। ऐसे मामलों में, मैं एक आर्टिफैक्ट के लिए कई डिज़ाइन दृष्टिकोण मांगता हूं।
मैं लगभग हर कोडिंग सत्र की शुरुआत एक अन्वेषण या विचार-मंथन चरण से भी करता हूं। इससे मुझे प्रोजेक्ट के दायरे को परिभाषित करने के इरादे से शुरू करने में मदद मिलती है। क्लॉड अक्सर ऐसे उच्च-मूल्य वाले दृष्टिकोण ढूंढ लेता है जो मैं चूक गया होता, और कभी-कभी पेड़ों के बीच जंगल को देखने से चूक जाता है। विचार-मंथन मुझे बहुत संकीर्ण या बहुत व्यापक दायरा तय करने से रोकता है।
उदाहरण प्रॉम्प्ट:
- "मैं इस डेटा के लिए एक डैशबोर्ड चाहता हूं, लेकिन मेरी कोई विज़ुअल रुचि नहीं है और मुझे नहीं पता कि क्या संभव है। मुझे 4 बिल्कुल अलग डिज़ाइन दिशाओं वाला एक HTML पेज बनाएं ताकि मैं उन पर प्रतिक्रिया दे सकूं।"
- "कुछ भी कनेक्ट करने से पहले, नकली डेटा के साथ नए एडिटर टूलबार का मॉकअप करने वाली एक एकल HTML फ़ाइल बनाएं। मैं वास्तविक ऐप को छूने से पहले लेआउट पर प्रतिक्रिया देना चाहता हूं।"
- "यह रही मेरी मोटी समस्या: ऑनबोर्डिंग के बाद उपयोगकर्ता चले जाते हैं। कोडबेस खोजें और 10 जगहों पर विचार-मंथन करें जहां हम हस्तक्षेप कर सकते हैं, सबसे सस्ते से लेकर सबसे महत्वाकांक्षी तक। मैं आपको बताऊंगा कि कौन से मेरे अनुकूल हैं।"
साक्षात्कार
एक बार जब मैं पर्याप्त विचार-मंथन कर लेता हूं, तो मेरे पास संभवतः अभी भी अज्ञात होते हैं।
इस मामले में, मैं क्लॉड से किसी भी अज्ञात या अस्पष्टता के बारे में मेरा साक्षात्कार करने के लिए कहता हूं। क्लॉड को आपका साक्षात्कार करने के लिए कहते समय, उसके प्रश्नों को निर्देशित करने के लिए उसे अपनी समस्या के बारे में संदर्भ देने का प्रयास करें। यहां कुछ उदाहरण दिए गए हैं।
उदाहरण प्रॉम्प्ट:
- "किसी भी अस्पष्ट चीज़ के बारे में एक बार में एक प्रश्न पूछकर मेरा साक्षात्कार करें, उन प्रश्नों को प्राथमिकता दें जहां मेरा उत्तर आर्किटेक्चर को बदल देगा।"
संदर्भ
कभी-कभी आप विस्तार से यह नहीं बता सकते कि आप क्या चाहते हैं। उदाहरण के लिए, हो सकता है कि आपके पास भाषा न हो या यह इतना जटिल हो कि इसमें आपको काफी समय लगे।
ऐसे में, सबसे अच्छा उत्तर एक संदर्भ है। जबकि आप आरेख, दस्तावेज़ या चित्र शामिल कर सकते हैं, सबसे अच्छा संदर्भ स्रोत कोड है।
यदि आपके पास कोई लाइब्रेरी है जो किसी चीज़ को एक निश्चित तरीके से लागू करती है या कोई डिज़ाइन घटक है जो आपको वास्तव में पसंद है, तो बस फेबल को फ़ोल्डर की ओर इंगित करें और उसे बताएं कि क्या देखना है, भले ही वह किसी भिन्न भाषा में हो।
इसी तरह क्लॉड डिज़ाइन भी काम करता है। आपको इसे एक फ़ाइल सौंपने की ज़रूरत नहीं है (हालांकि आप ऐसा भी कर सकते हैं)। आप इसे अपनी पसंद की वेबसाइट के किसी मॉड्यूल की ओर इंगित कर सकते हैं, और यह सिर्फ स्क्रीनशॉट नहीं, बल्कि अंतर्निहित कोड पढ़ता है। यह मार्कअप, संरचना और घटक के वास्तविक निर्माण के बारे में अधिक समृद्ध विवरण प्रदान करता है।
उदाहरण प्रॉम्प्ट:
- "vendor/rate-limiter में यह Rust crate ठीक उसी बैकऑफ़ व्यवहार को लागू करता है जो मैं चाहता हूं। इसे पढ़ें और हमारे TypeScript API क्लाइंट में उसी सिमैंटिक्स को फिर से लागू करें।"
कार्यान्वयन योजनाएं
जब मुझे लगता है कि मैं कार्यान्वयन के लिए तैयार हूं, तो मैं क्लॉड से एक कार्यान्वयन योजना तैयार करने के लिए कहता हूं जिसकी मैं समीक्षा कर सकूं, जो उन हिस्सों पर ध्यान केंद्रित करे जिनके बदलने की सबसे अधिक संभावना है, उदाहरण के लिए डेटा मॉडल, टाइप इंटरफ़ेस या UX प्रवाह की समीक्षा करना। यह क्लॉड को उन चीजों को सामने लाने की अनुमति देता है जिन्हें मुझे वास्तव में बदलने की आवश्यकता हो सकती है।
उदाहरण प्रॉम्प्ट:
- "HTML में एक कार्यान्वयन योजना लिखें, लेकिन उन निर्णयों से शुरू करें जिन्हें मेरे द्वारा बदलने की सबसे अधिक संभावना है: डेटा मॉडल में बदलाव, नए टाइप इंटरफ़ेस, और उपयोगकर्ता-सामना करने वाली कोई भी चीज़। यांत्रिक रीफ़ैक्टरिंग को नीचे दबा दें, मैं उस हिस्से के लिए आप पर भरोसा करता हूं।"
कार्यान्वयन के दौरान
कार्यान्वयन नोट्स
एक बार जब मैं अपनी योजना से संतुष्ट हो जाता हूं, तो मैं एक नया सत्र शुरू करता हूं और प्रॉम्प्ट में कोई भी आर्टिफैक्ट पास करता हूं। उदाहरण के लिए, मैं एक स्पेक फ़ाइल और एक प्रोटोटाइप पास कर सकता हूं और एक एजेंट से इसे लागू करने के लिए कह सकता हूं।
लेकिन सच्चाई यह है कि आप चाहे कितनी भी योजना बना लें, हमेशा अज्ञात अज्ञात छिपे रहते हैं। एजेंट अपने काम के दौरान पा सकता है कि कोड में मिले किसी एज केस के कारण उसे एक अलग रास्ता अपनाने की जरूरत है।
मैं क्लॉड कोड से एक अस्थायी 'implementation-notes.md' (या .html) फ़ाइल रखने के लिए कहता हूं जहां वह अपने द्वारा लिए गए निर्णयों का रिकॉर्ड रखता है, ताकि हम अपने अगले प्रयास से सीख सकें।
उदाहरण प्रॉम्प्ट:
- "एक implementation-notes.md फ़ाइल रखें। यदि आप किसी एज केस से टकराते हैं जो आपको योजना से विचलित होने के लिए मजबूर करता है, तो रूढ़िवादी विकल्प चुनें, इसे 'विचलन' के तहत लॉग करें, और आगे बढ़ते रहें।"
कार्यान्वयन के बाद
पिच और व्याख्याकार

कुछ शिप करने का सबसे महत्वपूर्ण हिस्सा स्वीकृति और अनुमोदन प्राप्त करना है। अंतिम दस्तावेज़ में पिच और व्याख्याकार आर्टिफैक्ट बनाने से मदद मिलती है:
- समीक्षकों की समझ को गति देने में जब वे आपके समान अज्ञात के साथ शुरुआत करते हैं
- अनुमोदन में तेजी लाने में जब विशेषज्ञ देखना चाहते हैं कि आपने उन अज्ञात और सामान्य विफलता बिंदुओं का हिसाब रखा है जिनकी उन्होंने अपेक्षा की होगी
उदाहरण प्रॉम्प्ट:
- "प्रोटोटाइप, स्पेक और कार्यान्वयन नोट्स को एक एकल दस्तावेज़ में पैकेज करें जिसे मैं स्वीकृति प्राप्त करने के लिए Slack में डाल सकूं। डेमो GIF से शुरुआत करें।"
प्रश्नोत्तरी
एक लंबे कार्य सत्र के बाद, क्लॉड ने मेरी समझ से कहीं अधिक काम पूरा कर लिया होता है। कोड डिफ़ पढ़ने से मुझे केवल एक हल्की समझ मिलती है कि क्या हुआ, क्योंकि अधिकांश व्यवहार मौजूदा कोड पथों पर निर्भर करेगा।
क्लॉड से मुझे बहुत सारा संदर्भ देने के बाद बदलाव के बारे में प्रश्नोत्तरी करने के लिए कहने से मुझे यह समझने में मदद मिलती है कि क्या हुआ। मैं तभी मर्ज करता हूं जब मैं प्रश्नोत्तरी को पूरी तरह से पास कर लेता हूं।
उदाहरण प्रॉम्प्ट:
- "मैं यह सुनिश्चित करना चाहता हूं कि मैं इस बदलाव में हुई हर चीज को समझता हूं। मुझे बदलावों पर एक HTML रिपोर्ट दें जिसे मैं संदर्भ, अंतर्ज्ञान, क्या किया गया, आदि के साथ पढ़ और समझ सकूं, और नीचे बदलावों पर एक प्रश्नोत्तरी हो जिसे मुझे पास करना होगा।"
यह सब एक साथ कैसे आता है: फेबल लॉन्च करना
फेबल के लिए लॉन्च वीडियो पूरी तरह से क्लॉड कोड द्वारा संपादित किया गया था। यह मेरे लिए एक नया डोमेन था और मैं किसी भी तरह से विशेषज्ञ नहीं हूं।
इसलिए मैंने उस चीज़ से शुरुआत की जो मुझे पता थी। मुझे पता था कि क्लॉड वीडियो संपादित करने और उन्हें ट्रांसक्राइब करने के लिए कोड का उपयोग कर सकता है, लेकिन मुझे यकीन नहीं था कि यह पर्याप्त सटीक होगा। फिर मैंने क्लॉड से यह समझाने के लिए कहा कि व्हिस्पर जैसी ट्रांसक्रिप्शन कैसे काम करती है, और क्या मैं ffmpeg का उपयोग करके सटीक रूप से 'उम' या लंबे विराम जैसी चीजों को काट पाऊंगा।
मैं चाहता था कि क्लॉड एक ऐसा UI बनाए जो मेरे द्वारा बोले जा रहे शब्दों के साथ समयबद्ध हो, लेकिन यह सुनिश्चित नहीं था कि यह कर पाएगा, इसलिए मैंने क्लॉड से यह देखने के लिए Remotion और एक ट्रांसक्रिप्शन का उपयोग करके एक प्रोटोटाइप वीडियो बनाने के लिए कहा कि क्या यह काम करेगा।
अंत में, वीडियो स्वयं थोड़ा म्यूट दिखता था, जो मुझे पता था कि कलर ग्रेडिंग का परिणाम था, लेकिन मैं वास्तव में नहीं जानता था कि कलर ग्रेडिंग क्या थी। मेरा पहला प्रयास क्लॉड से चुनने के लिए कुछ विविधताएं करवाना था, लेकिन मुझे एहसास हुआ कि मैं नहीं जानता था कि कलर ग्रेडिंग के मामले में "अच्छा" कैसा दिखता है। इसलिए इसके बजाय, मैंने क्लॉड से मुझे कलर ग्रेडिंग के बारे में सिखाने के लिए कहा ताकि मैं अपने अज्ञात की खोज कर सकूं।
आप इस पर अधिक गहन स्पष्टीकरण यहां** देख सकते हैं।
नक्शा और क्षेत्र का मिलान
मॉडल जितने बेहतर होते जाएंगे, आप सही दृष्टिकोण के साथ उतना ही अधिक हासिल कर सकते हैं। जब कोई लंबी अवधि का कार्य गलत वापस आता है, तो संभावना है कि आपको अपने अज्ञात को परिभाषित करने या एक कार्यान्वयन योजना बनाने में अधिक समय बिताने की आवश्यकता है जो क्लॉड को उनके माध्यम से सुधार करने की अनुमति देती है।
हर व्याख्याकार, विचार-मंथन, साक्षात्कार, प्रोटोटाइप और संदर्भ एक सस्ता तरीका है यह पता लगाने का कि आप क्या नहीं जानते थे, इससे पहले कि इसे ठीक करना महंगा हो जाए।
इसलिए अपना अगला प्रोजेक्ट क्लॉड से अपने अज्ञात खोजने में मदद मांगकर शुरू करें।





