बोरिस चेर्नी अब क्लॉड को प्रॉम्प्ट नहीं करते।
यह कोई वायरल पैराफ्रेज़ नहीं है। यह उनका अपना, दर्ज किया गया बयान है: "मैं अब क्लॉड को प्रॉम्प्ट नहीं करता। मेरे पास लूप चल रहे हैं जो क्लॉड को प्रॉम्प्ट करते हैं और पता लगाते हैं कि क्या करना है। मेरा काम लूप लिखना है।" उन्होंने यह कई सार्वजनिक मंचों पर कहा है — एक सिकोइया टॉक, एक Acquired इंटरव्यू, Y Combinator की Startup School — और इसके पीछे का पैटर्न ही इस लेख का वास्तविक विषय है। कोई टिप्स नहीं। कोई फीचर लिस्ट नहीं। वह विशिष्ट तरीका जिससे Claude Code बनाने वाला व्यक्ति वास्तव में इसका उपयोग करता है, दिन-प्रतिदिन, दूसरे हाथ की व्याख्या के बजाय उसके अपने सार्वजनिक बयानों से पुष्टि किया गया।
यह संपूर्ण विश्लेषण है, जो चेर्नी के वास्तविक कथनों के साथ-साथ Anthropic के अपने प्रलेखित सर्वोत्तम अभ्यासों पर आधारित है, जो उस टूल के लिए है जिसे उसने खुद बनाया है।
Claude Code कभी प्रोडक्ट बनने वाला नहीं था
चेर्नी टूल का उपयोग कैसे करते हैं, यह समझना यह समझने से शुरू होता है कि यह कहाँ से आया, क्योंकि उत्पत्ति ही दर्शन को स्पष्ट करती है, और यह आज टूल का उपयोग करने वाले अधिकांश लोगों की कल्पना से कहीं अधिक दिलचस्प कहानी है।
Claude Code 2021 में एक AI सुरक्षा संरेखण अनुसंधान परियोजना के रूप में शुरू हुआ, न कि किसी प्रोडक्ट के रूप में। पहले एक मोटा-मोटा VS Code एक्सटेंशन, फिर clide नामक एक आंतरिक CLI टूल, जो कंपनी के बाहर किसी के सुनने से वर्षों पहले Anthropic के अंदर उपयोग किया जाता था। चेर्नी सितंबर 2024 में परियोजना से जुड़े और उसी साल दिसंबर में दो सप्ताह के स्प्रिंट में कोर को फिर से बनाया। फरवरी 2025 में सार्वजनिक लॉन्च चुपचाप हुआ, बिना किसी धूमधाम के, उत्साह से ज़्यादा उदासीनता के साथ मिला। फिर Claude 4 आया, और अपनाने की दर लगभग रातों-रात बढ़ गई।
टूल की वर्तमान स्थिति पर उनका अपना आकलन, सीधे कहा गया: "हम केवल 1% पूरा कर चुके हैं।"
यह फ्रेमिंग मायने रखती है कि आपको इसे कैसे इस्तेमाल करना चाहिए। चेर्नी किसी तयशुदा सही उपयोग पैटर्न वाले पूर्ण प्रोडक्ट का वर्णन नहीं कर रहे हैं। वे कुछ ऐसी चीज़ का वर्णन कर रहे हैं जिसे अभी भी सक्रिय रूप से फिर से बनाया जा रहा है, एक टीम द्वारा जो टूल का उपयोग करके टूल का निर्माण कर रही है। Claude Code को बार-बार खुद Claude Code का उपयोग करके फिर से लिखा गया है — यह आत्म-सुधार का एक लूप है जो "लूप इंजीनियरिंग" शब्द के सार्वजनिक रूप से उपयोग में आने से पहले से चला आ रहा है। यह एक पल के लिए रुकने लायक है, क्योंकि यह कुछ ऐसा समझाता है जो कई नए उपयोगकर्ताओं को भ्रमित करता है: इस टूल का उपयोग करने का "सही" तरीका लगातार क्यों बदलता दिखता है। यह असंगतता नहीं है। यह एक ऐसा टूल है जिसके निर्माता स्वयं अभी भी सक्रिय रूप से खोज रहे हैं कि यह वास्तव में क्या करने में सक्षम है, वास्तविक समय में, खुद टूल का उपयोग करके पता लगा रहे हैं।
कभी प्रोडक्ट बनने से पहले एक आंतरिक शोध उपकरण के रूप में बिताए गए वर्ष यह भी बताते हैं कि नीचे का इतना सारा दर्शन डेवलपर सॉफ्टवेयर के एक टुकड़े के लिए असामान्य रूप से मताधिकारी (opinionated) क्यों लगता है। अधिकांश टूल पहले दिन से ही प्रतिस्पर्धी ज़रूरतों वाले व्यापक बाहरी उपयोगकर्ता आधार को संतुष्ट करने के लिए फीचर जमा करते हैं। Claude Code ने पहले अपना दर्शन अर्जित किया, एक छोटी टीम के अंदर जो अपनी समस्याओं को हल कर रही थी, इससे पहले कि उसे किसी और के वर्कफ़्लो को संतुष्ट करना पड़ता। यही इतिहास बताता है कि चेर्नी के अपने उपयोग पैटर्न को विशेष रूप से समझना — न कि सामान्य "AI कोडिंग टूल" सलाह — वह समय लेने लायक है जो इसे वास्तव में आत्मसात करने में लगता है।
मुख्य बदलाव: प्रॉम्प्टिंग से लूप डिज़ाइन करने तक
Claude Code का उपयोग करने के बारे में चेर्नी ने सार्वजनिक रूप से जो सबसे महत्वपूर्ण बात कही है, वह उपरोक्त लूप वाला बयान है, और यह समझने लायक है कि व्यवहार में इसका वास्तव में क्या मतलब है, न कि केवल एक उद्धरण योग्य पंक्ति के रूप में।
प्रॉम्प्ट एक एकल निर्देश है, एक बार भेजा गया, एक बार उत्तर दिया गया। लूप एक सिस्टम है: यह क्लॉड को प्रॉम्प्ट करता है, जो वापस आया उसका मूल्यांकन करता है, तय करता है कि आगे क्या होगा, और दोहराता है, बिना किसी इंसान के हर चक्र के बीच में बैठे। चेर्नी का कहा गया काम का विवरण, "मेरा काम लूप लिखना है", का अर्थ है कि वे अपना समय उन सिस्टमों को डिज़ाइन करने में बिताते हैं जो प्रॉम्प्ट उत्पन्न और मूल्यांकन करते हैं, न कि खुद बारी-बारी से प्रॉम्प्ट टाइप करते हैं।
उनकी पुष्टि की गई दैनिक वर्कफ़्लो इसे सीधे दर्शाता है। लैपटॉप कीबोर्ड के बजाय फोन उनका प्राथमिक इंटरफ़ेस है। एक साथ पाँच से दस सक्रिय सत्र चल रहे हैं, जिनमें से प्रत्येक सब-एजेंट उत्पन्न करने में सक्षम है — कभी-कभी एक साथ कुछ सौ, कभी-कभी गहरे काम पर रातों-रात कुछ हज़ार। दर्जनों लूप पृष्ठभूमि में लगातार चल रहे हैं, पुल रिक्वेस्ट की देखभाल कर रहे हैं, निरंतर एकीकरण (continuous integration) को स्वस्थ रख रहे हैं, आवर्ती कार्यक्रम पर फीडबैक को क्लस्टर कर रहे हैं। ऐसी दिनचर्या जो उनका लैपटॉप बंद होने पर भी सर्वर-साइड बनी रहती हैं।
Claude Code का दैनिक उपयोग करने वाले किसी भी व्यक्ति के लिए व्यावहारिक निष्कर्ष: टूल जो कर सकता है उसकी सीमा किसी एक प्रॉम्प्ट के कितने अच्छे होने से तय नहीं होती। यह इस बात से तय होती है कि आप प्रॉम्प्टिंग, जाँच और पुनः प्रयास के दोहराए जाने वाले स्वचालित चक्रों के आसपास सिस्टम को कितनी अच्छी तरह डिज़ाइन करते हैं।
सिस्टम प्रॉम्प्ट में वास्तव में क्या बदला, और यह क्यों मायने रखता है
चेर्नी ने एक विशिष्ट, तकनीकी निर्णय के बारे में भी सीधे बात की है जो बताता है कि वे क्लॉड को निर्देश देने के बारे में कैसे सोचते हैं: "हमने अपने सबसे नए मॉडलों के लिए Claude Code सिस्टम प्रॉम्प्ट का ~80% हटा दिया — यही हमने सिस्टम प्रॉम्प्ट लिखने के बारे में सीखा है।"
यह कटौती विशेष रूप से Opus 4.8 पीढ़ी के साथ हुई, जिसमें सिस्टम प्रॉम्प्ट लगभग 15,000 वर्णों से घटाकर लगभग 4,500 कर दिया गया, और कोडिंग मूल्यांकनों पर कोई मापने योग्य नुकसान नहीं हुआ। इसके पीछे का सबक, Anthropic के अपने संदर्भ-इंजीनियरिंग मार्गदर्शन के अनुसार, यह है कि कठोर, विस्तृत नियम सूचियाँ आवश्यक होना बंद हो जाती हैं जब एक मॉडल वास्तविक निर्णय लेने के लिए पर्याप्त सक्षम होता है। नियम निर्णय-कॉल बन जाते हैं। टूल उपयोग के उदाहरणों को स्व-दस्तावेज़ीकरण के लिए डिज़ाइन किए गए इंटरफेस द्वारा बदल दिया जाता है। अग्रिम रूप से दिया जाने वाला विस्तृत संदर्भ प्रगतिशील प्रकटीकरण (progressive disclosure) द्वारा बदल दिया जाता है — जानकारी केवल तभी सामने आती है जब कोई विशिष्ट स्थिति वास्तव में उसे बुलाती है, न कि हर सत्र में डिफ़ॉल्ट रूप से लोड की जाती है।
एक बारीक बात जो ईमानदारी से शामिल करने लायक है, क्योंकि यह इस कहानी के सरल संस्करण को जटिल बनाती है: जब Opus 5 आया, स्वतंत्र डेवलपर परीक्षण में पाया गया कि इसका वास्तविक सिस्टम प्रॉम्प्ट Opus 4.8 की तुलना में लगभग 72% लंबा था। यह उपरोक्त सबक का विरोधाभास नहीं है, यह उसका गहरा संस्करण है। प्रॉम्प्ट कठोर निर्देश मात्रा में सिकुड़ा, फिर समृद्ध, अधिक विशिष्ट संदर्भों, काम किए गए उदाहरणों, परीक्षण सूट, मूल्यांकन रूब्रिक्स में फिर से बढ़ा — उस तरह का संदर्भ जिसका वास्तव में अधिक सक्षम मॉडल अच्छा उपयोग कर सकता है। निष्कर्ष यह नहीं है कि "छोटा हमेशा बेहतर होता है।" यह है कि निर्देश मात्रा को उस विशिष्ट मॉडल की वास्तविक ज़रूरतों का पालन करना चाहिए ताकि वह अच्छा निर्णय ले सके, न कि किसी भी दिशा में एक निश्चित लक्ष्य।
CLAUDE.md को Anthropic की अपनी टीमों की तरह लिखना
यह सीधे जुड़ता है कि आपको अपने प्रोजेक्ट-स्तरीय निर्देशों की संरचना कैसे करनी चाहिए, और Anthropic का अपना आधिकारिक दस्तावेज़ीकरण उपयोग करने के लिए मानसिक मॉडल के बारे में स्पष्ट है: क्लॉड को एक शानदार लेकिन बहुत नए कर्मचारी के रूप में सोचें, जिसे भूलने की बीमारी है, जिसे स्पष्ट निर्देशों की आवश्यकता है।
इस फ्रेमिंग के व्यावहारिक निहितार्थ। शानदार का मतलब है कि आपको सामान्य क्षमता को ज़्यादा समझाने की आवश्यकता नहीं है — वह पहले से मौजूद है। नया का मतलब है आपके विशिष्ट प्रोजेक्ट के इतिहास या परंपराओं के बारे में शून्य संचित ज्ञान। भूलने की बीमारी का मतलब है कि हर सत्र शुरू से शुरू होता है — CLAUDE.md ही एकमात्र चीज़ है जो सत्रों के बीच विश्वसनीय रूप से संदर्भ को आगे बढ़ाती है।
Anthropic का प्रलेखित मार्गदर्शन इस फ़ाइल को 200 पंक्तियों से कम रखने का लक्ष्य रखता है, कुछ सबसे अनुशासित टीमें 60 तक कम चलाती हैं। यह परीक्षण कि क्या कुछ फ़ाइल में होना चाहिए: क्या यह वास्तव में लगभग हर सत्र के लिए प्रासंगिक है, या केवल काम के एक संकीर्ण, परिस्थितिजन्य हिस्से के लिए? सार्वभौमिक चीज़ें — बिल्ड कमांड, गैर-परक्राम्य शैली नियम, परीक्षण अपेक्षाएँ, वास्तविक गार्डरेल — रूट फ़ाइल में होनी चाहिए। इससे संकीर्ण कुछ भी एक आयातित फ़ाइल में होना चाहिए, केवल तभी संदर्भ में लाया जाए जब सत्र का विशिष्ट कार्य वास्तव में उसे बुलाता है, टूल द्वारा सीधे समर्थित @path/to/file इम्पोर्ट सिंटैक्स का उपयोग करके।
उन निर्देशों के लिए जिन्हें वास्तव में छोड़ा नहीं जा सकता, Anthropic का अपना आंतरिक अभ्यास स्पष्ट ज़ोर चिह्नकों का उपयोग करता है — "IMPORTANT" या "YOU MUST" — विशेष रूप से उन कुछ नियमों के लिए आरक्षित जहाँ क्लॉड के उन्हें चूक जाने की लागत वास्तव में अधिक है। हर चीज़ को इस तरह चिह्नित करना उद्देश्य को पूरी तरह से विफल कर देता है, क्योंकि जिस क्षण इसे अन्धाधुंध रूप से लागू किया जाता है, यह एक संकेत के रूप में कार्य करना बंद कर देता है।
प्लान मोड: कार्य करने से पहले समझना
एक विशिष्ट व्यवहार पैटर्न जो आपके काम करने के तरीके में निर्मित होने लायक है: क्लॉड से कार्य करने से पहले योजना बनवाना, बजाय सीधे बदलावों में कूदने के।
यह केवल एक फीचर टॉगल नहीं है — यह एक वास्तविक बदलाव को दर्शाता है जिसे Anthropic की अपनी सामग्री वर्णित करती है: नए मॉडल पहले के मॉडलों की तरह भारी अग्रिम स्टीयरिंग की आवश्यकता के बिना सही ढंग से योजना बनाते हैं, इस हद तक कि कुछ टीमों ने रिपोर्ट किया है कि अब हर कार्य के लिए एक स्पष्ट प्लान मोड चरण को मजबूर करने की आवश्यकता नहीं है, क्योंकि मॉडल का अपना डिफ़ॉल्ट तर्क कार्य करने से पहले पहले से ही एक सुसंगत योजना उत्पन्न करता है। फिर भी, वास्तव में जटिल, बहु-फ़ाइल परिवर्तनों के लिए, पहले स्पष्ट रूप से योजना मांगना, और निष्पादन को मंजूरी देने से पहले उसकी समीक्षा करना, एक सार्थक रूप से उपयोगी जाँच बिंदु बना हुआ है, जो एक गलत समझी गई आवश्यकता को दर्जनों फ़ाइल संपादनों के माध्यम से फैलने से पहले पकड़ लेता है, बाद में नहीं।
सब-एजेंट और समानांतर कार्य
चेर्नी का पुष्टि किया गया वर्कफ़्लो — एक सत्र में सैकड़ों, कभी-कभी हज़ारों सब-एजेंट चलाना — एक संरचनात्मक क्षमता की ओर इशारा करता है जिसे समझना और जानबूझकर उपयोग करना लायक है, न कि संयोग से।
एक मुख्य एजेंट एक जटिल कार्य को छोटे टुकड़ों में विघटित कर सकता है और सब-एजेंटों को उन्हें स्वतंत्र रूप से निष्पादित करने के लिए तैनात कर सकता है — प्रत्येक अपने स्वयं के संदर्भ में काम कर रहा है, बजाय सभी के एक सतत वार्तालाप में स्थान के लिए प्रतिस्पर्धा करने के। यह एक साथ दो उद्देश्यों को पूरा करता है। यह उस काम को चलाने देता है जो एक संदर्भ विंडो को भर देगा, कई छोटे संदर्भों में। और यह एक वास्तविक सत्यापन परत जोड़ता है, क्योंकि एक सब-एजेंट दूसरे एजेंट के आउटपुट की समीक्षा कर रहा है — वह काम जाँच रहा है जो उसने स्वयं उत्पन्न नहीं किया — जो संरचनात्मक रूप से अधिक विश्वसनीय है बजाय एक एजेंट के अपने होमवर्क को उसी सांस में ग्रेड करने के जिसमें उसने इसे उत्पन्न किया।
विशेष रूप से समानांतर कार्य के लिए, git worktrees कई सत्रों को एक साथ अलग-अलग शाखाओं या निर्देशिकाओं पर काम करने देते हैं, बिना एक सत्र के चल रहे परिवर्तन दूसरे को बाधित किए। यह यांत्रिक बुनियादी ढांचा है जो कई समवर्ती लूप चलाने के पीछे है जैसा चेर्नी व्यक्तिगत रूप से करने का वर्णन करते हैं — एक एजेंट तेज़ी से काम कर रहा है, ऐसा नहीं, बल्कि कई एजेंट वास्तव में अलग-अलग काम के टुकड़ों पर एक साथ काम कर रहे हैं।
ग्रेप निर्णय: सरलता बनाम चतुराई में एक केस स्टडी
चेर्नी की अपनी टीम का एक विशिष्ट, अच्छी तरह से प्रलेखित तकनीकी निर्णय एक व्यापक दर्शन को दर्शाता है जिसे आत्मसात करने लायक है। Claude Code ने कोडबेस खोज के लिए वेक्टर खोज और एम्बेडिंग को हटाकर सादे grep और glob का उपयोग करना शुरू किया। परिणाम पर उनके अपने शब्द: "सब कुछ से बेहतर प्रदर्शन किया। काफी अंतर से।"
यह सबक इस एक विशिष्ट निर्णय से परे सामान्यीकृत होता है। अधिक परिष्कृत-लगने वाला समाधान — सिमेंटिक वेक्टर खोज — स्वचालित रूप से सरल समाधान, grep से बेहतर नहीं है, यदि सरल वास्तव में समस्या के लिए अच्छी तरह से मेल खाता है। कोडबेस में सटीक सिंटैक्स, सटीक फ़ंक्शन नाम, सटीक इम्पोर्ट पथ होते हैं — उस तरह का सटीक, शाब्दिक मिलान जिसमें grep उत्कृष्ट है और जिसे एक फजी सिमेंटिक मिलान वास्तव में कमजोर कर सकता है, प्रशंसनीय लेकिन गलत परिणाम सतह पर लाकर।
अपने स्वयं के वर्कफ़्लो को कॉन्फ़िगर करने के लिए व्यावहारिक निष्कर्ष: इस धारणा से अधिक जटिल-लगने वाले टूल या आर्किटेक्चर को डिफ़ॉल्ट न करें कि जटिलता क्षमता का संकेत देती है। पहले अपने वास्तविक उपयोग के मामले के खिलाफ सरल विकल्प का परीक्षण करें। अक्सर यह जीतता है, और जब यह नहीं जीतता, तब भी आपने पुष्टि कर ली है कि अधिक जटिल दृष्टिकोण अपना स्थान अर्जित करता है, न कि यह मान लिया कि वह अर्जित है।
किसी एजेंट को कभी अपने काम का मूल्यांकन न करने दें
Anthropic के अपने हार्नेस इंजीनियरिंग अभ्यास से एक अलग, पुष्टि किया गया सिद्धांत, जो सीधे प्रासंगिक है कि आपको अपने स्वयं के Claude Code वर्कफ़्लो में किसी भी सत्यापन चरण की संरचना कैसे करनी चाहिए: पीढ़ी और मूल्यांकन वास्तव में अलग-अलग भूमिकाओं में होना चाहिए, क्योंकि एक मॉडल जो अपने स्वयं के आउटपुट की उसी सांस में समीक्षा करता है जिसमें उसने इसे उत्पन्न किया, सकारात्मक पक्ष की ओर झुकता है, भले ही एक मानव समीक्षक तुरंत दोष देख सके।
व्यावहारिक रूप से, इसका मतलब है कि जो एजेंट कोड लिखता है, वह वही पास नहीं होना चाहिए जो यह तय करता है कि कोड शिप करने के लिए पर्याप्त अच्छा है या नहीं। एक अलग मूल्यांकन चरण — आदर्श रूप से किसी ऐसी चीज़ तक पहुँच के साथ जो उत्पन्न करने वाले एजेंट के पास नहीं थी, जैसे वास्तविक परीक्षण सूट आउटपुट या मूल आवश्यकताओं का दस्तावेज़ — वह पकड़ता है जो आत्म-मूल्यांकन चूक जाता है। यह वही सिद्धांत है जो उपरोक्त सब-एजेंट सत्यापन पैटर्न के पीछे है, जो एक सामान्य अनुशासन के रूप में लागू होता है न कि एक विशिष्ट फीचर के रूप में।
प्रयास और संदर्भ प्रबंधन
लंबे, अधिक मांग वाले सत्र चलाने वाले किसी भी व्यक्ति के लिए, यह समझना महत्वपूर्ण है कि प्रयास स्तर को सीधे कैसे संकेत दिया जाए। प्रॉम्प्ट में "ultrathink" शामिल करना उस विशिष्ट प्रतिक्रिया के लिए अधिकतम तर्क गहराई का संकेत देता है, बिना व्यापक सत्र सेटिंग्स बदले। सत्र-स्तरीय स्वचालित वर्कफ़्लो ऑर्केस्ट्रेशन के लिए, प्रयास स्तर को उच्चतम स्तर पर सेट करना गहरे तर्क को एक सत्र में स्वचालित कार्य विघटन के साथ जोड़ता है — हालाँकि इसके लिए एक ऐसे मॉडल की आवश्यकता होती है जो वास्तव में उस प्रयास स्तर का समर्थन करता हो; किसी दिए गए लाइनअप में हर मॉडल ऐसा नहीं करता।
संदर्भ प्रबंधन स्वयं लंबे सत्रों पर जानबूझकर ध्यान देने योग्य है। जैसे-जैसे एक सत्र लंबा चलता है, संचित संदर्भ वास्तव में अभी क्या मायने रखता है, इसके संकेत को कमजोर करना शुरू कर सकता है — वही समस्या जो फुलाए हुए CLAUDE.md फ़ाइलें पैदा करती हैं, बस एक फ़ाइल में स्थिर रूप से होने के बजाय एक ही वार्तालाप के भीतर गतिशील रूप से हो रही है। काम के वास्तव में नए चरण के लिए समय-समय पर एक नया सत्र शुरू करना, एक वार्तालाप को अनिश्चित काल तक बढ़ाने के बजाय, एक वास्तविक, व्यावहारिक अनुशासन है जो यह मानने के बजाय लागू करने लायक है कि अधिक संदर्भ हमेशा कड़ाई से बेहतर होता है।
एक काम किया हुआ उदाहरण: इसे एक वास्तविक कार्य पर लागू करना
उपरोक्त सभी को अमूर्त के बजाय ठोस बनाने के लिए, यहाँ बताया गया है कि ये सिद्धांत वास्तव में एक वास्तविक, सामान्य कार्य पर कैसे संयोजित होते हैं: एक मौजूदा कोडबेस में उचित जटिलता के साथ एक नई सुविधा जोड़ना — कुछ परस्पर जुड़ी फ़ाइलें, कुछ मौजूदा परीक्षण, एक गैर-तुच्छ लेकिन असामान्य नहीं बदलाव।
पहले से मौजूद CLAUDE.md के साथ शुरू करें — छोटा, सार्वभौमिक: बिल्ड और परीक्षण कमांड, गैर-परक्राम्य शैली नियम, कुछ भी परिस्थितिजनक इसे अव्यवस्थित नहीं कर रहा। इसका मतलब है कि सत्र वास्तविक, प्रासंगिक संदर्भ के साथ स्वचालित रूप से शुरू होता है, बिना आपको अपने प्रोजेक्ट की परंपराओं को शुरू से फिर से समझाने के।
एक एकल, लंबा, आशावादी प्रॉम्प्ट लिखने के बजाय जो पूरी सुविधा का विस्तृत विवरण देता है, लक्ष्य का वर्णन करें और मॉडल की अपनी योजना को विघटन संभालने दें — उपरोक्त सिस्टम प्रॉम्प्ट चर्चा से कम-मचान (reduced-scaffolding) दर्शन पर भरोसा करते हुए। इस आकार के कार्य के लिए, पहले स्पष्ट रूप से एक योजना मांगना अतिरिक्त कदम के लायक है, क्योंकि यहाँ पकड़ी गई एक गलत समझी गई आवश्यकता दो मिनट के सुधार की लागत देती है, बजाय बाद में कई फ़ाइलों में बदलावों को पूर्ववत करने के एक घंटे के।
एक बार योजना सही दिखती है, निष्पादन को आगे बढ़ने दें। यदि कार्य स्वाभाविक रूप से वास्तव में स्वतंत्र टुकड़ों में विभाजित होता है — एक डेटा मॉडल को अपडेट करना और अलग से उपयोगकर्ता इंटरफ़ेस को अपडेट करना जो उसे खाता है, उदाहरण के लिए — यह सब-एजेंट विघटन के लिए एक स्वाभाविक उम्मीदवार है, प्रत्येक टुकड़ा अपने स्वयं के संदर्भ में काम कर रहा है, बजाय सभी के एक सतत वार्तालाप को भीड़ने के।
परिणाम को पूर्ण मानने से पहले, कार्यान्वयन करने वाले एजेंट की अपनी स्व-रिपोर्ट पर भरोसा करने के बजाय एक अलग सत्यापन पास चलाएँ कि सब कुछ काम करता है। यह उतना ही सरल हो सकता है जितना एक नया सत्र, या केवल-पढ़ने के लिए पहुँच वाला एक सब-एजेंट, वास्तविक परीक्षण आउटपुट और मूल योजना के खिलाफ अंतर (diff) की जाँच करना — न कि केवल उसी संदर्भ से एक आत्मविश्वासपूर्ण "यह पूर्ण है" स्वीकार करना जिसने कोड लिखा।
ध्यान दें कि इस वॉकथ्रू में क्या अनुपस्थित है। कोई विदेशी टूलिंग नहीं। कोई असामान्य कॉन्फ़िगरेशन नहीं। केवल वास्तव में जटिल काम के लिए पहले-योजना का सामान्य अनुप्रयोग, वास्तव में स्वतंत्र टुकड़ों के लिए सब-एजेंट विघटन, और आत्म-मूल्यांकन के बजाय अलग सत्यापन — वही तीन सिद्धांत जो ऊपर हर चीज़ के माध्यम से चल रहे हैं, एक ठोस कार्य पर लागू होते हैं, अमूर्त रूप से वर्णित होने के बजाय।
इसे एक व्यक्ति से परे स्केल करना
ऊपर सब कुछ जानबूझकर Claude Code का उपयोग करने वाले एक व्यक्ति के लिए प्रथाओं का वर्णन करता है। चेर्नी का अपना पुष्टि किया गया वर्कफ़्लो — दैनिक सैकड़ों सब-एजेंट, रातों-रात हज़ारों — स्वयं पहले से ही स्केलिंग का एक रूप है: एक व्यक्ति वास्तव में बड़ी मात्रा में समानांतर, स्वचालित काम का निर्देशन कर रहा है। लेकिन वही सिद्धांत एक टीम तक विस्तारित होते हैं जो इन प्रथाओं को एक साथ अपनाती है, कुछ विशिष्ट विचारों के साथ जिन्हें सीधे नाम देने लायक है।
CLAUDE.md एक व्यक्तिगत पसंदीदा फ़ाइल नहीं रह जाती, जिस क्षण एक टीम में एक से अधिक लोग वास्तव में एक ही कोडबेस के खिलाफ Claude Code के साथ काम कर रहे होते हैं। इसमें परिवर्तनों को उसी समीक्षा अनुशासन के साथ व्यवहार करें जो आप टीम के वर्कफ़्लो को प्रभावित करने वाले किसी भी साझा कॉन्फ़िगरेशन पर लागू करेंगे। एक सहकर्मी जो एक निराशाजनक सत्र के बाद बिना समीक्षा के एक बार का "हॉटफिक्स" निर्देश जोड़ता है, ठीक वही तंत्र है जो फुलाए हुए, आत्म-विरोधाभासी फ़ाइलें उत्पन्न करता है जिनका वास्तव में विश्वसनीय रूप से पालन होना बंद हो जाता है। एक हल्का समीक्षा चरण — यहाँ तक कि केवल एक दूसरा व्यक्ति जो मर्ज से पहले अंतर पर नज़र डालता है — इसका एक सार्थक हिस्सा पकड़ लेता है, इससे पहले कि यह एक वास्तविक समस्या में जमा हो।
सत्यापन अनुशासन टीम स्तर पर एकल उपयोगकर्ता की तुलना में और भी अधिक मायने रखता है। जब एक व्यक्ति अपने एजेंट-सहायता प्राप्त काम को लिख और समीक्षा दोनों कर रहा होता है, तो कम से कम एक मौका होता है कि वे व्यक्तिगत रूप से कुछ पकड़ लेंगे जो एजेंट चूक गया। जब एक टीम एक साझा समीक्षा प्रक्रिया के माध्यम से बहने वाले Claude Code आउटपुट पर भरोसा कर रही है, तो पहले का अलग-मूल्यांकन सिद्धांत अब वैकल्पिक नहीं है — यह वास्तविक तंत्र है जो कोडबेस को एक एजेंट के आत्मविश्वासपूर्ण लेकिन गलत आत्म-मूल्यांकन को प्रोडक्शन तक पहुँचने से बचाता है, क्योंकि विकल्प यह भरोसा करना है कि कोई इंसान, एक व्यस्त टीम के वर्कफ़्लो में किसी बिंदु पर, संयोग से वह पकड़ लेगा जो एजेंट ने खुद फ्लैग नहीं किया।
समय-समय पर CLAUDE.md ऑडिट पर स्पष्ट स्वामित्व स्थापित करना भी लायक है — किसी भी साझा, संचित दस्तावेज़ के लिए अनुशंसित वही रखरखाव अनुशासन। स्पष्ट रूप से सौंपे गए मालिक के बिना, यह काम ठीक उसी कारण से दरारों से गिर जाता है क्योंकि यह किसी एक तत्काल कार्य को अवरुद्ध नहीं करता जिस तरह एक टूटा हुआ बिल्ड करता है, और छह महीने के बिना स्वामित्व वाले जोड़ ठीक उसी तरह की फुलाई हुई, विरोधाभासी फ़ाइल उत्पन्न करते हैं जिसे सार्वभौमिक-प्रयोज्यता सिद्धांत पहले स्थान पर रोकने के लिए मौजूद है।
लोग इन सिद्धांतों को कहाँ गलत लागू करते हैं
उपरोक्त विचारों की कुछ विशिष्ट गलत व्याख्याएँ बार-बार दिखाई देती हैं, जिन्हें सीधे नाम देने लायक है क्योंकि प्रत्येक के पास एक सरल, विशिष्ट सुधार है।
"प्रॉम्प्ट पर लूप" को कार्य को पूरी तरह से समझने को छोड़ने के लाइसेंस के रूप में मानना। चेर्नी का अपना बयान है कि उनका काम लूप लिखना है, यह नहीं कि उन्होंने यह सोचना बंद कर दिया कि उन लूपों को वास्तव में क्या करना चाहिए। एक अच्छा लूप डिज़ाइन करना — सफलता की एक अच्छी परिभाषा, एक अच्छी रोक स्थिति — फिर भी समस्या को उतनी ही स्पष्ट रूप से समझने की आवश्यकता होती है जितनी एक अच्छा एकल प्रॉम्प्ट लिखने की होती है। लूप बार-बार मैन्युअल टाइपिंग को बदलता है, शुरुआती सोच को नहीं।
सिस्टम प्रॉम्प्ट में कमी को "मॉडल को कम संदर्भ दें, हमेशा" के रूप में पढ़ना। इस लेख में पहले Opus 5 प्रति-उदाहरण विशेष रूप से इस गलत व्याख्या को सुधारने के लिए मौजूद है। वास्तविक सबक यह है कि निर्देश मात्रा को उससे मेल खाना चाहिए जो एक विशिष्ट मॉडल को वास्तव में अच्छा निर्णय लेने के लिए चाहिए — जिसका कभी-कभी अर्थ कम कठोर नियम-सूचीकरण होता है और कभी-कभी अधिक समृद्ध, विशिष्ट संदर्भ सामग्री। "नवीनतम मॉडलों को कम चाहिए" कहकर अन्धाधुंध रूप से संदर्भ काटना एक सूक्ष्म, मॉडल-विशिष्ट निष्कर्ष को एक सामान्य नियम के रूप में गलत लागू करता है।
आदत से बाहर सरल कार्यों को सब-एजेंटों में अधिक-विघटित करना। सब-एजेंट विघटन वास्तव में बड़े, वास्तव में स्वतंत्र काम के टुकड़ों पर अपनी जटिलता अर्जित करता है। एक छोटे, कसकर युग्मित परिवर्तन को पैटर्न का उपयोग करने के लिए कृत्रिम सब-एजेंट टुकड़ों में विभाजित करना समन्वय ओवरहेड जोड़ता है, बिना उस लाभ के जो बड़े कार्यों पर इसे उचित ठहराता है। इस लेख में पहले का काम किया हुआ उदाहरण जानबूझकर केवल वहीं सब-एजेंटों का उपयोग करता था जहाँ टुकड़े स्वाभाविक रूप से स्वतंत्र थे, न कि आकार की परवाह किए बिना हर कार्य के लिए एक डिफ़ॉल्ट के रूप में।
"नए मॉडलों को अब इसकी आवश्यकता नहीं है" धारणा पर सत्यापन छोड़ना। अलग-मूल्यांकन सिद्धांत कमजोर मॉडलों के लिए एक कामकाज नहीं है जो क्षमता में सुधार के रूप में अनावश्यक हो जाएगा। यह आत्म-मूल्यांकन के बारे में एक संरचनात्मक तथ्य है: एक मॉडल जो उसी संदर्भ में अपने काम की जाँच करता है जिसने इसे उत्पन्न किया, उसे हमेशा अपने स्वयं के अंधे धब्बों को पकड़ने में एक स्वतंत्र जाँच की तुलना में कठिन समय लगेगा, चाहे अंतर्निहित मॉडल कितना भी सक्षम क्यों न हो जाए। यह मानव समीक्षकों के लिए भी सच है, और यह सच होना बंद नहीं होता सिर्फ इसलिए कि समीक्षक अधिक स्मार्ट हो जाता है।
वास्तविक दैनिक आदतें जो अपनाने लायक हैं
उपरोक्त सभी को एक ठोस, व्यावहारिक दैनिक अभ्यास में खींचते हुए, यहाँ बताया गया है कि चेर्नी के प्रदर्शित दृष्टिकोण का वास्तव में पालन करना कैसा दिखता है।
हर कार्य को पहली कोशिश में सही करने के लिए एक एकल प्रॉम्प्ट के रूप में मानना बंद करें। इसके बजाय एक लूप डिज़ाइन करें: एक एजेंट जो कार्य का प्रयास करता है, यह जाँचने का एक तरीका कि प्रयास सफल हुआ या नहीं, और उस जाँच के आधार पर आगे क्या होता है इसका एक परिभाषित मार्ग — पास, पुनः प्रयास, या सीधे आपको बढ़ाना।
अपने CLAUDE.md को छोटा रखें और इसे एक सक्षम लेकिन संदर्भ-मुक्त नई भर्ती के लिए ऑनबोर्डिंग सामग्री के रूप में मानें, एक व्यापक मैनुअल के रूप में नहीं। रूट दस्तावेज़ को फुलाने के बजाय किसी भी परिस्थितिजन्य चीज़ को आयातित फ़ाइलों में ले जाएँ।
वास्तव में जटिल, बहु-फ़ाइल काम पर जानबूझकर प्लान मोड का उपयोग करें, और आदत से बाहर हर जगह एक अतिरिक्त कदम मजबूर करने के बजाय सरल, अच्छी तरह से दायरे वाले कार्यों पर मॉडल की अपनी डिफ़ॉल्ट योजना पर भरोसा करें।
एक पूरे जटिल कार्य को एक सतत वार्तालाप में रखने की कोशिश करने के बजाय बड़े कार्यों को अलग-अलग संदर्भों में काम करने वाले सब-एजेंटों में विघटित करें। एक एजेंट के आत्म-मूल्यांकन पर भरोसा करने के बजाय महत्वपूर्ण काम को सत्यापित करने के लिए एक अलग पास का उपयोग करें।
सबसे सरल टूल को डिफ़ॉल्ट करें जो आपकी विशिष्ट समस्या को स्पष्ट रूप से हल कर सकता है — जिस तरह grep ने इस सटीक उपयोग के मामले के लिए वेक्टर खोज को हराया — और केवल अधिक जटिलता तक पहुँचें जब सरल विकल्प का वास्तव में परीक्षण किया गया हो और कमी पाई गई हो।
वास्तव में स्वतंत्र काम के टुकड़ों के लिए git worktrees का उपयोग करके अपने वर्कफ़्लो में वास्तविक समानता बनाएँ, बजाय सब कुछ एक अनुक्रमिक सत्र के माध्यम से चलाने के क्योंकि यह काम करने का डिफ़ॉल्ट तरीका है।
यह वास्तव में कहाँ जा रहा है
चेर्नी का अपना "हम केवल 1% पूरा कर चुके हैं" फ्रेमिंग एक व्यावहारिक बयान के रूप में गंभीरता से लेने लायक है, न कि केवल एक विनम्र-लगने वाली पंक्ति के रूप में। ऊपर वर्णित विशिष्ट पैटर्न — एकल प्रॉम्प्टिंग पर लूप डिज़ाइन, मॉडल के अधिक सक्षम होने पर आक्रामक सिस्टम प्रॉम्प्ट कटौती, सब-एजेंट विघटन, अलग सत्यापन — एक निश्चित, अंतिम पद्धति नहीं हैं। वे एक टूल और अभ्यास की वर्तमान स्थिति हैं जिसे इसका अपना निर्माता अभी भी प्रारंभिक बताता है।
वास्तविक कौशल जो बनाने लायक है, वह आज के विशिष्ट कॉन्फ़िगरेशन को याद रखना नहीं है। यह अंतर्निहित सिद्धांतों को पर्याप्त रूप से समझना है ताकि टूल के बदलते रहने पर अनुकूलन करते रहें — उसी तरह जैसे चेर्नी की अपनी टीम ने Claude Code का उपयोग करके बार-बार Claude Code को फिर से बनाया, किसी एक संस्करण को पूर्ण मानने के बजाय लूप को परिष्कृत किया।
यही वास्तविक सूत्र है जो इस लेख में सब कुछ जोड़ता है। युक्तियों की एक स्थिर सूची नहीं, बल्कि एक काम करने वाला दर्शन: एकल निर्देश टाइप करने के बजाय सिस्टम डिज़ाइन करें, निर्देशों को दुबला रखें और मॉडल क्षमता को सुधारने के साथ अधिक काम करने दें, आत्म-मूल्यांकन पर भरोसा करने के बजाय स्वतंत्र रूप से सत्यापित करें, और सरलता को डिफ़ॉल्ट करें जब तक कि जटिलता वास्तव में खुद को आवश्यक साबित न करे। सीधे उस व्यक्ति से जिसने टूल बनाया, वह खुद इसका उपयोग कैसे करता है।
अधिक Claude Code विश्लेषणों के लिए @cyrilXBT को फॉलो करें, जो सत्यापित, रिकॉर्ड पर मौजूद सामग्री पर आधारित हैं।
