"मैं अब क्लॉड में प्रॉम्प्ट टाइप नहीं कर रहा हूँ। यह वह लूप है जो चल रहा है, और यह लूप ही तय करता है कि आगे क्या करना है, क्लॉड को प्रॉम्प्ट करके। मेरा काम अब लूप लिखना हो गया है।"
ये शब्द बोरिस चेर्नी ने सार्वजनिक रूप से बोले थे, जो क्लॉड कोड (Claude Code) का नेतृत्व करते हैं (जैसा कि The New Stack और एड्डी ओसमानी के लेखों में दिखाया गया है)।
जहाँ हममें से कई लोग अभी भी सटीकता सुधारने के लिए प्रॉम्प्ट को रिफाइन कर रहे हैं, वहीं इस टूल को बनाने वाला व्यक्ति पहले ही "प्रॉम्प्टर" बनने से किनारा कर चुका है।
जब आप इसके बारे में सोचते हैं, जब तक "मानवीय चक्र"—स्क्रीन के सामने बैठना, AI प्रतिक्रिया का इंतज़ार करना, उसे जाँचना, और फिर से निर्देश देना—शामिल है, गति की सीमा आपके अपने हाथों की गति से तय होती है।
लूप इंजीनियरिंग (Loop Engineering) उस मानवीय चक्र को संरचना से हटाने का विचार है। बोरिस इसके प्रति पूरी तरह प्रतिबद्ध हैं; उनका कहना है कि उन्होंने नवंबर 2024 में अपना IDE डिलीट कर दिया और तब से इसे खोला भी नहीं। वे दावा करते हैं कि पिछले महीने क्लॉड कोड में उनके लगभग सभी योगदान क्लॉड कोड ने ही लिखे थे (रिपोर्ट के अनुसार 200 से अधिक PRs)।
टूल के निर्माता स्वयं कोड नहीं लिखते बल्कि "यह देखने" की तरफ बढ़ गए हैं कि "लूप सही ढंग से घूम रहा है या नहीं"। आज, मैं इसे सिर्फ एक भावना के रूप में नहीं, बल्कि तकनीकी विनिर्देश स्तर पर समझाऊंगा। मैं भी लूप की ओर शिफ्ट होने की प्रक्रिया में हूँ, और मैं महसूस कर सकता हूँ कि जितना अधिक मैं शिफ्ट होता हूँ, मेरे हाथ उतने ही स्वतंत्र होते जाते हैं।
https://note.com/nobel/n/n8192ec07d689
लूप इंजीनियरिंग का मतलब है भूमिकाओं में बदलाव
दूसरे शब्दों में, आपकी स्थिति बदल जाती है। पहले, मनुष्य एक आदान-प्रदान के बीच में बैठता था जहाँ मनुष्य निर्देश देता था, AI उत्तर देता था, और मनुष्य जाँचता और सुधारता था। लूप डिज़ाइन में, मनुष्य संचार तंत्र (लूप) को डिज़ाइन करने के लिए जिम्मेदार होते हैं, जबकि परिणामों का परीक्षण और सत्यापन AI की तरफ स्थानांतरित कर दिया जाता है। आप बस तब तक प्रतीक्षा करते हैं जब तक यह समाप्त न हो जाए और सूचना न मिल जाए।
गूगल के एड्डी ओसमानी ने लूप इंजीनियरिंग शीर्षक वाले लेख में भी यही लिखा, इसे "उस व्यक्ति को बदलना जो प्रॉम्प्ट टाइप करता है, एक ऐसे तंत्र से जो उनकी ओर से प्रॉम्प्ट टाइप करता है" के रूप में वर्णित किया। लाभ का बिंदु अच्छे प्रॉम्प्ट लिखने की क्षमता से हटकर इस बात पर आ गया है कि ऐसी प्रणाली कैसे डिज़ाइन की जाए जो AI को आपके लिए प्रॉम्प्ट लिखने दे। यही मूल है।
हालाँकि, एड्डी स्वयं चेतावनी देते हैं, "यह अभी भी शुरुआती चरणों में है, और मैं कुछ हद तक संशय में हूँ। टोकन लागतों के बारे में वास्तव में सावधान रहना होगा।" हम दूसरे भाग में इस नुकसान पर वापस आएंगे।
/loop के तकनीकी विनिर्देश
क्लॉड कोड में एक अंतर्निहित कौशल है जिसे /loop कहा जाता है (v2.1.72 से)। यह लूप इंजीनियरिंग का सबसे आसान प्रवेश बिंदु है। चूँकि ऑनलाइन स्पष्टीकरणों में अक्सर त्रुटियाँ मिली-जुली होती हैं, मैं आधिकारिक अनुसूचित निष्पादन दस्तावेज़ीकरण के आधार पर मुख्य बिंदुओं पर ध्यान केंद्रित करूंगा।
इसमें आप क्या पास करते हैं, उसके आधार पर व्यवहार बदलता है:
- दोनों अंतराल और प्रॉम्प्ट:
/loop 5m check if the deployment is finished and let me knowनिश्चित अंतराल पर चलेगा। - केवल प्रॉम्प्ट:
/loop check if the CI passed and respond to review comments। क्लॉड 1 मिनट से 1 घंटे के बीच स्वयं अंतराल तय करेगा (स्व-गति)। - कुछ नहीं पास किया
/loop: अंतर्निहित रखरखाव प्रॉम्प्ट (अधूरे काम को जारी रखना, PRs की देखभाल करना, हल्की सफाई) या आपके द्वारा रखा गयाloop.mdफ़ाइल चलेगा।
अंतराल को शुरू में 30m या अंत में every 2 hours की तरह रखा जा सकता है। इकाइयाँ s/m/h/d हैं। आप अन्य कमांड भी पास कर सकते हैं, जैसे /loop 20m /review-pr 1234, ताकि हर बार सहेजे गए कौशल चलें। इसे रोकने के लिए, प्रतीक्षा करते समय Esc दबाएँ (प्राकृतिक भाषा अनुरोधों के माध्यम से बनाए गए कार्य Esc से नहीं रुकते; आपको उन्हें हटाने के लिए कहना होगा)। स्व-गति मोड में, यदि क्लॉड निर्धारित करता है कि कार्य वास्तव में समाप्त हो गया है, तो यह अगली बार चलने का निर्धारण किए बिना समाप्त हो जाएगा।
स्व-गति मोड का एक सूक्ष्म लाभ है: यह स्वचालित रूप से समायोजित होता है, यदि बिल्ड लगभग समाप्त हो गया है तो थोड़ी देर प्रतीक्षा करता है और यदि कुछ नहीं हो रहा है तो अधिक देर प्रतीक्षा करता है। कभी-कभी "Monitor" नामक तंत्र का उपयोग पोलिंग के बजाय बैकग्राउंड आउटपुट को स्ट्रीम करने के लिए किया जाता है, जो अक्सर निश्चित अंतराल पर प्रॉम्प्ट फायर करने से सस्ता होता है।
मुझे स्रोत लेखों में पाई जाने वाली एक सामान्य गलतफहमी को सुधारने दें। कभी-कभी लिखा जाता है कि कार्य "निर्माण के 3 दिन बाद स्वचालित रूप से हटा दिए जाते हैं", लेकिन सटीक रूप से, आवर्ती कार्य निर्माण के 7 दिन बाद समाप्त हो जाते हैं (वे अंतिम बार चलते हैं और गायब हो जाते हैं)। साथ ही, /loop सत्र-स्कोप्ड है और जब आप एक नई बातचीत शुरू करते हैं तो गायब हो जाता है। यदि आप इसे बंद करते हैं, तो यदि यह समाप्त नहीं हुआ है तो आप --resume के साथ वापस आ सकते हैं।
तीन शेड्यूलिंग विधियाँ हैं, जिन्हें उपयोग के मामले के अनुसार चुना जाता है:
- क्लाउड (Routines): एंथ्रोपिक की तरफ चलता है। यह तब भी चलता है जब आपकी मशीन बंद हो। न्यूनतम अंतराल 1 घंटा है।
- डेस्कटॉप अनुसूचित कार्य: आपकी मशीन पर चलता है और स्थानीय फ़ाइलों को छू सकता है।
- /loop: केवल तब तक जब तक सत्र खुला है। न्यूनतम 1 मिनट, सत्र के दौरान पोलिंग के लिए सुविधाजनक।
श्रम का विभाजन है: स्थायी निवास के लिए मानवीय हस्तक्षेप के बिना Routines या GitHub Actions का उपयोग करें, और सत्र के दौरान निगरानी के लिए /loop का उपयोग करें।
लूप प्रभावी होने वाले मानक कार्य
आपकी दिनचर्या में वे कार्य जहाँ आप "जाँचें और थोड़ा ठीक करें" दोहराते हैं, आमतौर पर लूप के लिए उपयुक्त होते हैं। तीन सामान्य पैटर्न हैं:
- बग पेट्रोलिंग: नियमित अंतराल पर समस्याओं या परीक्षण विफलताओं का पता लगाएँ, कारण पढ़ें, ठीक करें, परीक्षण चलाएँ और PR बनाएँ।
- सतत समीक्षा: कोड परिवर्तनों की निगरानी करें और चिंता के क्षेत्रों को इंगित करते रहें। मनुष्य केवल यह तय करते हैं कि सुझाव स्वीकार करने हैं या नहीं।
- दस्तावेज़ सिंक: स्रोत परिवर्तनों का पता लगाएँ और README या विनिर्देशों को अद्यतन रखें।
इन तीनों में समानता यह है कि लक्ष्य का स्पष्ट रूप से न्याय किया जा सकता है, जैसे "परीक्षण पास होते हैं" या "PR बनाया गया है"। इसके विपरीत, अस्पष्ट मानदंड वाले कार्य लूप के लिए उपयुक्त नहीं हैं। यदि रुकने का बिंदु स्पष्ट नहीं है, तो यह चलता ही रहेगा और टोकन खर्च करता रहेगा। अपने पहले कार्य के लिए, एक ऐसा चुनना सुरक्षित है जिसमें सफलता या विफलता एक नज़र में स्पष्ट हो।
"स्टेट फ़ाइलों" से भागने और भूलने से बचाव
लूप के साथ दो डर हैं: एक ही विफलता को दोहराना और अंतहीन रूप से टोकन खर्च करना।
यहीं पर प्रोजेक्ट में एक एकल स्टेट फ़ाइल के साथ डिज़ाइन करना प्रभावी है। चाहे वह STATE.md हो या todo.md, AI हर लूप के दौरान वर्तमान लक्ष्य/पूर्ण की गई वस्तुएँ/अगले कदम/अटके हुए बिंदुओं को पढ़ता और लिखता है। भले ही सत्र कट जाए, AI यह नहीं भूलता कि "वह कहाँ है और किस लक्ष्य की ओर बढ़ रहा है"।
यह सिर्फ एक यादृच्छिक अभ्यास नहीं है; एंथ्रोपिक स्वयं लंबे समय तक चलने वाले एजेंटों के लिए प्रभावी हार्नेस (नवंबर 2024) में लगभग उसी निष्कर्ष पर पहुँचा। उनका कॉन्फ़िगरेशन दो भूमिकाओं का उपयोग करता है: वातावरण स्थापित करने के लिए एक इनिशियलाइज़र एजेंट और प्रति सत्र एक फ़ीचर पर आगे बढ़ने के लिए एक कोडिंग एजेंट। प्रगति को git commits और claude-progress.txt फ़ाइल के माध्यम से सत्रों के बीच स्थानांतरित किया जाता है। लंबे कार्यों के लिए, सारांशीकरण के माध्यम से संपीड़न अपर्याप्त है। नीति यह है कि एक संरचित फ़ाइल में एक बार लिखें और संदर्भ का पुनर्निर्माण करें।
अपने स्वयं के संचालन में, मैं साझा स्थिति के लिए एक केंद्र के रूप में tasks/state.md का उपयोग करता हूँ, जिसे विचार-मंथन पक्ष और कार्यान्वयन पक्ष दोनों कार्य करने से पहले पढ़ते हैं। यह पेपर के समान है: "संदर्भ पर भरोसा मत करो, फ़ाइल पर भरोसा करो।" यह सरल है, लेकिन इसके बिना, लूप दूसरे चक्र पर भटक जाता है।
राल्फ विधि और मेकर को चेकर से अलग करना
लूप का एक चरम संस्करण है जिसे "राल्फ" विधि कहा जाता है। जेफ्री हंटली द्वारा लोकप्रिय, मूल स्रोत सिर्फ एक सरल bash लूप है:
एक ही प्रॉम्प्ट को अंतहीन रूप से खिलाकर और योजना के साथ एक Markdown फ़ाइल को डिस्क पर साझा स्थिति के रूप में उपयोग करके, AI इसे हर बार पढ़ता है और स्वयं तय करता है कि "आगे क्या करना है"। यह लापरवाह लगता है, लेकिन चूँकि एक स्टेट फ़ाइल है, यह हर चक्कर के साथ आगे बढ़ता है। क्लॉड कोड में एक आधिकारिक ralph-loop प्लगइन भी है जो एक पूर्ति शर्त (completion promise) पूरी होने तक एक ही प्रॉम्प्ट को दोबारा सबमिट करता रहता है। एक बाधा यह है कि पूर्णता की घोषणा केवल तभी जारी की जानी चाहिए जब यह वास्तव में प्राप्त हो।
हालाँकि, यदि आप सब कुछ एक AI पर छोड़ देते हैं, तो वह अपने द्वारा लिखे गए कोड को "ठीक" कहेगा। यहीं पर AI जो बनाता है (मेकर) और AI जो निरीक्षण करता है (चेकर) को अलग करना प्रभावी है। अपने स्वयं के संचालन में, मैं कार्यान्वयन और सत्यापन को विभिन्न एजेंटों में अलग करता हूँ, और मैं सत्यापन पक्ष को कार्यान्वयन का इरादा नहीं देता—मैं केवल आवश्यकताएँ दिखाता हूँ और इसे स्वतंत्र रूप से मूल्यांकन करने देता हूँ। मैंने कठिन तरीके से सीखा कि एक ही सत्र में स्व-समीक्षाएँ अनिवार्य रूप से ढीली होती हैं।
"एक अलग दृष्टिकोण वाले केवल-समीक्षा एजेंट" को लूप में शामिल करना—इस बहु-स्तरीय जाँच को डिज़ाइन करना उन कार्यों में से एक है जो मनुष्यों को रखना चाहिए।
तीन चरणों में डिज़ाइन स्वायत्तता
एक बार में सब कुछ सौंपना दुर्घटनाओं का कारण बनेगा। भागीदारी के स्तर को परतों में अलग करना सुरक्षित है:
- L1 (मैनुअल): मनुष्य प्रॉम्प्ट टाइप करते हैं और प्रत्येक की जाँच करते हैं। पारंपरिक तरीका।
- L2 (अर्ध-स्वायत्त लूप): एक स्टेट फ़ाइल का पालन करें और
/loopके साथ कार्यों के एक विशिष्ट सेट को पूरा होने तक देखें। - L3 (निवासी): मानवीय हस्तक्षेप के बिना Routines या GitHub Actions के माध्यम से लगातार चलाएँ।
L2 से शुरू करना यथार्थवादी है। /loop के साथ एक कार्य को पूरा करने तक चलाएँ और व्यवहार का निरीक्षण करें। एक बार जब आप विश्वसनीयता की सीमा देख लें तो L3 पर जाएँ। पहली कुछ बार, मैंने एक साइड स्क्रीन पर लॉग देखा कि "उसने कहाँ गलत निर्णय लिया"।
नुकसान (पहले इन्हें जानें)
चूँकि मैंने केवल अच्छे पक्षों के बारे में लिखा है, यहाँ तीन बिंदु हैं जहाँ आप अटक सकते हैं:
- टोकन लागत: लूप चलने के साथ अधिक खपत करते हैं। एड्डी ने इस पर जोर दिया था; यदि आप अंतराल बहुत छोटा सेट करते हैं, तो यह रात भर में काफी खर्च कर सकता है। स्व-गति निश्चित अंतराल से बेहतर है क्योंकि यह जब चाहिए तब प्रतीक्षा करता है, जिससे बर्बादी कम होती है।
- अपरिवर्तनीय संचालन: अंतर्निहित रखरखाव प्रॉम्प्ट केवल उन अपरिवर्तनीय कार्यों को करता है जैसे पुश या डिलीट करना जो "पहले से ही बातचीत में अनुमत सीमा" के भीतर हैं। अपने स्वयं के प्रॉम्प्ट लिखते समय, विनाशकारी संचालन की सीमाएँ स्वयं परिभाषित करना सुरक्षित है।
- 7 दिनों में गायब: आवर्ती
/loopकार्य निर्माण के 7 दिन बाद समाप्त हो जाते हैं। यदि आप इसे अधिक समय तक चलाना चाहते हैं, तो Routines या डेस्कटॉप कार्यों पर जाएँ।
मध्यवर्ती उपयोगकर्ताओं के लिए नोट्स
/loopऔर/goalअलग हैं।/loopअंतराल पर चलता है। यदि आप एक शर्त पूरी होने तक हर बारी पर जारी रखना चाहते हैं, तो/goalका उपयोग करें। यदि आप चाहते हैं कि यह किसी घटना के घटित होते ही प्रतिक्रिया करे, तो Channels के माध्यम से push का उपयोग करें।loop.md(.claude/loop.mdया~/.claude/loop.md) रखने से आप एक खाली/loopके डिफ़ॉल्ट प्रॉम्प्ट को अपने स्वयं के साथ बदल सकते हैं। यह दिनचर्या के कार्यों को लिखने के लिए उपयोगी है जैसे "यदि रिलीज़ ब्रांच CI लाल है तो ठीक करें"।- प्रति सत्र 50 अनुसूचित कार्यों तक। आप
CronListके साथ सूची देख सकते हैं औरCronDeleteके साथ ID द्वारा हटा सकते हैं।
सारांश
पहले, मैंने स्क्रीन के सामने जो समय बिताया वह प्रगति की ऊपरी सीमा थी। अब, एक लूप जो मेरे सोते समय एक स्टेट फ़ाइल पढ़ता है, एक-एक करके फीचर आगे बढ़ाता है, और मेरी सुबह उस प्रगति की जाँच के साथ शुरू होती है।
सामग्री (प्रॉम्प्ट सटीकता) में सुधार करने से पहले, इसे चलाने के तरीके (लूपों का पृथक्करण, स्टेट प्रबंधन और सत्यापन) को डिज़ाइन करें। लाभ वहाँ स्थानांतरित हो गया है—यह बोरिस, एड्डी और एंथ्रोपिक के हार्नेस की कहानियों में सामान्य बिंदु है। मेरा मानना है कि यह कोई कठिन सिद्धांत नहीं है, बल्कि सरल डिज़ाइनों का एक स्थिर संचय है, जैसे लूप शुरू करने से पहले रुकने का समय तय करना।
X पर साझा नहीं की जा सकने वाली उपयोगी जानकारी LINE OpenChat में साझा की जा रही है। यदि आप Claude Code/Codex का उपयोग करने या X संचालन के लिए AI का उपयोग करने में रुचि रखते हैं, तो कृपया हमसे जुड़ें।
