जून 2026 में, एक ही सप्ताह के भीतर तीन लोग स्वतंत्र रूप से एक ही विचार पर पहुँचे।
पीटर स्टीनबर्गर, OpenClaw के निर्माता, ने सार्वजनिक रूप से कहा कि आपको कोडिंग एजेंटों को प्रॉम्प्ट करना बंद कर देना चाहिए और उन लूप्स को डिज़ाइन करना शुरू कर देना चाहिए जो उन्हें प्रॉम्प्ट करते हैं। लगभग उसी समय, बोरिस चेर्नी, जो Anthropic में Claude Code का नेतृत्व करते हैं, ने कहा कि वे अब Claude को सीधे प्रॉम्प्ट नहीं करते, बल्कि उनके पास लूप चल रहे हैं जो Claude को प्रॉम्प्ट करते हैं और पता लगाते हैं कि क्या करना है, और उनका वास्तविक काम लूप लिखना है। कुछ दिनों बाद, Google के इंजीनियर Addy Osmani ने इस शब्द को लिखा और इसे एक नाम दिया: लूप इंजीनियरिंग।
उनमें से किसी ने भी इस प्रथा को शून्य से आविष्कृत नहीं किया। उन्होंने उस चीज़ का नाम रखा जो पहले से हो रही थी, क्योंकि इसके अंतर्निहित उपकरण चुपचाप एक सीमा पार कर चुके थे। कोडिंग एजेंट इतने विश्वसनीय हो गए थे कि बिना निगरानी के एक वास्तविक कार्य पूरा कर सकें। शेड्यूलिंग इतनी सस्ती हो गई थी कि एक कार्य को बार-बार, एक टाइमर पर चलाना, अब बर्बादी जैसा नहीं लगता था। एक एजेंट रन की लागत इतनी गिर गई थी कि पाँच बार कुछ प्रयास करने की लागत एक बार ध्यान से सोचने से कम हो गई।
यही वह सीमा है जिसके कारण यह रोडमैप मौजूद है। प्रॉम्प्टिंग वह कौशल था जब एक मानव को कीबोर्ड पर बैठकर एक एजेंट को लाइन दर लाइन निर्देशित करना होता था। लूप इंजीनियरिंग अब वह कौशल है जब एजेंट को एक लक्ष्य दिया जा सकता है और चलने के लिए छोड़ा जा सकता है। यह एक से दूसरे तक का 20-चरणीय पूर्ण मार्ग है, क्रम में, क्योंकि क्रम किसी भी एकल चरण से अधिक मायने रखता है।
यहाँ बताया गया है कि क्रम विशेष रूप से क्यों मायने रखता है, चरणों से पहले ही। लूप इंजीनियरिंग एक एकल कौशल नहीं है जो आपके पास है या नहीं है। यह एक स्टैक है, जहाँ प्रत्येक परत उसके नीचे वाली परत के वास्तव में ठोस होने पर निर्भर करती है। चरण 14 में शेड्यूलिंग ट्रिगर बनाना, चरण 10 में एक वास्तविक स्टॉप कंडीशन होने से पहले, इसका सीधा सा मतलब है कि आपने एक ऐसी प्रणाली को स्वचालित कर दिया है जो अब बिना निगरानी के भी पैसा बर्बाद कर सकती है, न कि केवल तब जब आप देख रहे हों। चरण 11 में पर्सिस्टेंस बनाना, चरण 6 और 7 में वास्तविक सत्यापन से पहले, इसका मतलब है कि आप एक ऐसे जज से सीखे गए पाठों को ध्यान से रिकॉर्ड कर रहे हैं जो संभवतः खराब आउटपुट पर मुहर लगा रहा है, जो पर्सिस्टेंस लेयर को केवल बेकार नहीं बल्कि सक्रिय रूप से हानिकारक बनाता है। इस सूची में आगे बढ़ने का मतलब सिर्फ एक सुविधा को खोना नहीं है। इसका मतलब है कि रोमांचक दिखने वाले हिस्सों को एक ऐसी नींव पर बनाना जो वास्तव में उनका समर्थन नहीं कर सकती, और यह तभी पता चलता है जब पैमाने पर कुछ गलत हो चुका हो।
चरण एक: मानसिक बदलाव (चरण 1 से 4)
चरण 1: स्वीकार करें कि आप बाधा हैं, मॉडल नहीं
पहला वास्तविक कदम तकनीकी नहीं है। यह यह स्वीकार करना है कि आपके वर्तमान वर्कफ़्लो में सीमित कारक मॉडल की क्षमता नहीं है, बल्कि लूप में आपकी अपनी उपस्थिति है। हर बार जब आप बैठते हैं और प्रतिक्रिया की प्रतीक्षा करते हैं, उसे पढ़ते हैं, फिर अगला निर्देश टाइप करते हैं, तो आप सिस्टम का सबसे धीमा हिस्सा होते हैं, और वह भी बड़े अंतर से। मॉडल आपके द्वारा इसकी निगरानी करने की तुलना में कहीं अधिक तेज़ी से कार्य कर सकता है, सत्यापित कर सकता है और पुनः प्रयास कर सकता है।
इस चरण से कोई प्रॉम्प्ट संलग्न नहीं है। यह एक निर्णय है। जब तक आप वास्तव में इस पर विश्वास नहीं करते, तब तक प्रत्येक बाद का चरण आवश्यक कार्य के बजाय अनावश्यक ओवरहेड जैसा लगेगा, जो वास्तविक बाधा को दूर कर रहा है।
चरण 2: एक लंबे प्रॉम्प्ट को बेहतर सिस्टम समझने की गलती न करें
जब कुछ गलत होता है तो प्रवृत्ति उसी प्रॉम्प्ट में एक और निर्देश जोड़ने की होती है। महीनों में यह एक घना, आत्म-विरोधाभासी नियमों की दीवार पैदा करता है जिसे मॉडल अब एक साथ काम करने वाली मेमोरी में नहीं रख सकता, इसलिए वह सबसे ताज़ा लगने वाली चीज़ पर पैटर्न-मैच करता है और चुपचाप बाकी को छोड़ देता है।
लूप इंजीनियरिंग इस प्रवृत्ति को पूरी तरह से बदल देती है। एक प्रॉम्प्ट में एक और नियम जोड़ने के बजाय, आप सिस्टम में एक और घटक जोड़ते हैं। एक सत्यापन चरण। एक मेमोरी फ़ाइल। एक निर्धारित ट्रिगर। प्रॉम्प्ट स्वयं समय के साथ छोटा होना चाहिए क्योंकि उसके आस-पास का सिस्टम अधिक सक्षम हो जाता है, न कि इसके विपरीत।
चरण 3: हर कार्य को पाँच चालों के रूप में देखना सीखें
एक लूप का कोई भी एक मोड़, विशिष्ट डोमेन की परवाह किए बिना, पाँच चालों में विघटित होता है। डिस्कवरी, यह पता लगाना कि वास्तव में क्या होने की आवश्यकता है। हैंडऑफ़, कार्य को उस चीज़ को सौंपना जो इसे निष्पादित करेगी। सत्यापन, परिणाम को किसी वास्तविक चीज़ के विरुद्ध जाँचना। पर्सिस्टेंस, यह रिकॉर्ड करना कि क्या हुआ ताकि वह खो न जाए। शेड्यूलिंग, यह तय करना कि यह फिर कब चलेगा।
अधिकांश लोगों के वर्तमान वर्कफ़्लो में इनमें से केवल दो चालें स्पष्ट हैं, डिस्कवरी और हैंडऑफ़, मैन्युअल रूप से, एक चैट विंडो में की गईं। अन्य तीन या तो मौजूद नहीं हैं या व्यक्ति के अपने दिमाग में अदृश्य रूप से होती हैं। लूप इंजीनियरिंग सभी पाँच चालों को स्पष्ट और स्वचालित बनाने का अभ्यास है।
चरण 4: अपना पहला वास्तविक उम्मीदवार कार्य पहचानें
कुछ भी बनाने से पहले, एक ऐसा कार्य चुनें जिसे आप पहले से ही बार-बार करते हैं, जिसमें एक मानक हो जिसे आप पूछे जाने पर लिख सकते हैं। आपकी सबसे कठिन समस्या नहीं। पूरी तरह से नया कार्य नहीं। एक कार्य जिसकी पूर्णता की वास्तविक, पहचानने योग्य परिभाषा हो, कुछ ऐसा जिसे कोई सहकर्मी देख सके और तुरंत सहमत हो सके कि वह सही ढंग से पूरा हुआ या नहीं। यह बाधा दिखने से कहीं अधिक मायने रखती है। पूर्णता की स्पष्ट परिभाषा के बिना किसी कार्य के लिए चरण तीन, सत्यापन, का निर्माण नहीं किया जा सकता, और वास्तविक सत्यापन के बिना एक लूप लूप नहीं है, यह सिर्फ एक बिना निगरानी का अनुमान है।
चरण दो: पहला लूप बनाना (चरण 5 से 9)
चरण 5: कोई भी प्रॉम्प्ट लिखने से पहले पूर्णता की परिभाषा लिखें
यह वह चरण है जिसे अधिकांश लोग छोड़ देते हैं और यह वह है जो यह निर्धारित करता है कि इसके बाद सब कुछ काम करता है या नहीं। एजेंट के लिए एक भी निर्देश लिखने से पहले, सरल भाषा में लिखें कि एक सही परिणाम वास्तव में कैसा दिखता है। विशिष्ट, जाँचने योग्य मानदंड, गुणवत्ता की एक अस्पष्ट भावना नहीं।
[कार्य का नाम] के लिए पूर्णता की परिभाषा:
- [विशिष्ट, जाँचने योग्य मानदंड 1]
- [विशिष्ट, जाँचने योग्य मानदंड 2]
- [विशिष्ट, जाँचने योग्य मानदंड 3] यह कार्य तब तक पूरा नहीं हुआ है जब तक उपरोक्त में से कोई भी गायब है, भले ही आउटपुट पूर्ण या पॉलिश दिखाई दे।
यदि आप अपने चुने हुए कार्य के लिए इसे नहीं भर सकते हैं, तो चरण 4 पर वापस जाएँ और कोई दूसरा चुनें।
चरण 6: बिल्डर को जज से अलग करें
किसी भी लूप में सबसे महत्वपूर्ण एकल आर्किटेक्चरल निर्णय। काम पैदा करने वाली भूमिका और काम की जाँच करने वाली भूमिका को अलग किया जाना चाहिए, क्योंकि एक मॉडल जो उसी साँस में अपने स्वयं के आउटपुट की समीक्षा करता है जिसमें उसने इसे उत्पन्न किया, वह उस आउटपुट का बचाव करता है न कि वास्तविक रूप से उसकी जाँच करता है।
बिल्डर को रचनात्मक स्वतंत्रता मिलती है और वह पहला प्रयास करता है। जज को बिल्डर का आउटपुट और चरण 5 से पूर्णता की परिभाषा मिलती है, और इसके अलावा कुछ नहीं जिससे उसे बाहर निकालने की आवश्यकता हो। आदर्श रूप से जज के पास कुछ ऐसा भी हो जो बिल्डर के पास नहीं है, एक टेस्ट सूट, मूल स्रोत दस्तावेज़, लाइव डेटा, ताकि उसका फैसला वास्तविक सबूतों से आए, न कि उसी तरह से बनी दूसरी राय से जैसे पहली बनी थी।
चरण 7: जज को केवल एक राय नहीं, बल्कि ग्राउंड ट्रुथ दें
एक जज जो केवल बिल्डर का आउटपुट देखता है, वह आपको बता सकता है कि यह सुसंगत दिखता है या नहीं। वह आपको यह नहीं बता सकता कि यह वास्तव में सही है या नहीं। कोडिंग कार्यों के लिए, ग्राउंड ट्रुथ टेस्ट सूट और वास्तविक निष्पादन आउटपुट है। सामग्री कार्यों के लिए, यह मूल स्रोत सामग्री और ब्रीफ है, जो ड्राफ्ट के साथ-साथ है। अनुसंधान कार्यों के लिए, यह वास्तविक दस्तावेज़ हैं जिनका उपयोग किया जाना था।
यदि आप उस विशिष्ट ग्राउंड ट्रुथ का नाम नहीं बता सकते जिसके विरुद्ध आपका जज जाँच करेगा, तो आपके लूप में अभी तक वास्तविक सत्यापन नहीं है, चाहे जज की भाषा कितनी भी आत्मविश्वासी क्यों न लगे।
चरण 8: हैंडऑफ़ प्रॉम्प्ट लिखने से पहले हैंडऑफ़ फ़ॉर्मेट लिखें
बिल्डर के आउटपुट और जज के फैसले दोनों के लिए एक परिभाषित संरचना की आवश्यकता होती है, न कि स्वतंत्र रूप से बहने वाला गद्य, अन्यथा अगले चरण में मैनेजर के पास रूट करने के लिए कुछ भी विश्वसनीय नहीं होगा।
बिल्डर आउटपुट: डिलीवरेबल + आत्मविश्वास + ज्ञात अनिश्चितताएँ
जज का फैसला: पास / फेल / संशोधन की आवश्यकता + पाए गए विशिष्ट मुद्दे + यह किस ग्राउंड ट्रुथ के विरुद्ध जाँचा गया था
चरण 9: कुछ भी स्वचालित करने से पहले, इसे एक बार पूरी तरह से मैन्युअल रूप से चलाएँ
शेड्यूलिंग या स्वचालित पुनर्प्रयासों को जोड़ने से पहले, पूर्ण बिल्डर-फिर-जज अनुक्रम को स्वयं, हाथ से, एक बार चलाएँ। जज के फैसले को गंभीरता से पढ़ें। क्या आप इससे सहमत होते? यदि जज ने कुछ ऐसा पास किया जिसके बारे में आप जानते हैं कि वह गलत है, या कुछ ऐसा फेल किया जो वास्तव में ठीक था, तो आगे बढ़ने से पहले ग्राउंड ट्रुथ या मानदंडों को ठीक करें। एक टूटे हुए सत्यापन चरण को स्वचालित करने से केवल तेज़ी से टूटे हुए परिणाम मिलते हैं।
चरण 5 से 9 के माध्यम से एक कार्य उदाहरण
पिछले पाँच चरणों को ठोस बनाने के लिए, यहाँ बताया गया है कि वे एक वास्तविक, सामान्य कार्य पर कैसे काम करते हैं, एक कच्चे स्रोत दस्तावेज़ को सामग्री के एक तैयार टुकड़े में बदलना।
चरण 5 से पूर्णता की परिभाषा: ड्राफ्ट में प्रत्येक तथ्यात्मक दावा स्रोत दस्तावेज़ में वास्तव में मौजूद किसी चीज़ पर वापस जाता है। ड्राफ्ट ब्रीफ की प्रत्येक विशिष्ट आवश्यकता को पूरा करता है: लंबाई, लहज़ा, आवश्यक संरचना। मुख्य तर्क स्पष्ट रूप से जीवित रहता है, बिना फिलर द्वारा पतला हुए।
चरण 6 से बिल्डर, स्रोत और ब्रीफ प्राप्त करता है और एक ड्राफ्ट तैयार करता है, साथ ही इस बात का स्पष्ट विवरण देता है कि वह लिखते समय किस बारे में अनिश्चित था: एक संख्या जिसके बारे में उसे पूरी तरह से यकीन नहीं था कि वह स्रोत में है, एक दावा जिसे उसने स्पष्ट रूप से बताए जाने के बजाय अनुमान लगाया।
चरण 7 से जज, ड्राफ्ट और मूल स्रोत को साथ-साथ प्राप्त करता है, कभी भी केवल ड्राफ्ट नहीं, और पूर्णता-की-परिभाषा के प्रत्येक मानदंड की अलग-अलग जाँच करता है, प्रत्येक पर एक पास या फेल लौटाता है, न कि एक मिश्रित समग्र स्कोर। तीन अलग-अलग जाँचों को एक ही फैसले में समेटने से यह छिप जाता है कि वास्तव में कौन सा आयाम विफल हुआ, जो एक कार्यशील लूप के चुपचाप उपयोगी प्रतिक्रिया देना बंद करने का सबसे सामान्य तरीका है।
चरण 8 से हैंडऑफ़ फ़ॉर्मेट का मतलब है कि जज का फैसला एक संरचित वस्तु के रूप में आता है, न कि हेज किए गए गद्य के एक पैराग्राफ के रूप में; तीन स्पष्ट पास या फेल परिणाम जिनमें किसी भी विफलता से जुड़ा एक विशिष्ट कारण होता है।
चरण 9 के अनुसार, कुछ भी स्वचालित करने से पहले इसे एक बार हाथ से चलाना, उस मामले को पकड़ता है जहाँ आपका जज बहुत उदार है, पॉलिश लेखन शैली के कारण एक गढ़े हुए आँकड़े वाले ड्राफ्ट को पास कर रहा है, या बहुत सख्त है, एक शैलीगत प्राथमिकता के कारण ड्राफ्ट को फेल कर रहा है जो वास्तव में ब्रीफ में कभी थी ही नहीं। दोनों विफलता मोड पहले प्रयास में आम हैं, और दोनों को मैन्युअल रूप से एक बार पकड़ना कहीं अधिक सस्ता है, बजाय इसके कि लूप पचास बार बिना निगरानी के चलने के बाद इसका पता चले।
चरण तीन: लूप के लापता टुकड़े जोड़ना (चरण 10 से 14)
चरण 10: मैनेजर और उसकी स्टॉप कंडीशन बनाएँ
मैनेजर जज के फैसले को पढ़ता है और तय करता है कि आगे क्या होगा। यहीं पर लूप की स्टॉप कंडीशन भी रहती है, और इसे हार्ड लॉजिक के रूप में लिखा जाना चाहिए, न कि एक नरम निर्देश के रूप में जिसे मॉडल खुद को समझाकर पार कर सके।
स्टॉप कंडीशन:
अधिकतम संशोधन: 3. तीसरे असफल फैसले पर, पूरे इतिहास के साथ मामले को एक मानव के पास भेजें, चौथा चक्र शुरू न करें।
गुणवत्ता सीमा: पूर्णता की परिभाषा में प्रत्येक आइटम को PASS दिखाना चाहिए।
बजट सीमा: यदि यह कार्य [X] लागत या [Y] समय से अधिक हो जाता है, तो वर्तमान स्थिति की परवाह किए बिना तुरंत रुक जाएँ।
एक वास्तविक स्टॉप कंडीशन के बिना एक लूप एक सिस्टम नहीं है। यह एक देयता है जो उस दिन की प्रतीक्षा कर रही है जब कार्य वास्तव में अनसुलझा हो जाता है। यहाँ एक नरम निर्देश के विफल होने का विशिष्ट कारण समझने लायक है, न कि केवल स्वीकार करने लायक। एक प्रॉम्प्ट के अंदर "जब यह काफी अच्छा हो तो रुक जाओ" एक सुझाव है, और पर्याप्त दबाव में एक मॉडल, पहले से ही कई संशोधनों में विफल रहने के बाद, अक्सर खुद को यह विश्वास दिलाएगा कि वर्तमान प्रयास पास करने के लिए काफी करीब है, ठीक इसलिए क्योंकि वह कार्य का एक संतोषजनक समाधान तैयार करना चाहता है। एक हार्ड इटरेशन काउंटर जिसे यांत्रिक रूप से कोड द्वारा जाँचा जाता है, या एक स्पष्ट नियम द्वारा जिसके चारों ओर मैनेजर तर्क नहीं कर सकता, उस विफलता मोड में नहीं है।
चरण 11: पर्सिस्टेंस जोड़ें, ताकि लूप रनों के बीच याद रखे
एक लूप जो हर बार चलने पर शून्य से शुरू होता है, उसे पिछली बार सीखी गई बातों की कोई स्मृति नहीं होती। एक सरल पर्सिस्टेंस लेयर जोड़ें: प्रति वास्तविक नए पाठ के लिए एक फ़ाइल, जिसके शीर्ष पर एक-पंक्ति का सारांश हो, जो यह रिकॉर्ड करता हो कि क्या सीखा या सुधारा गया और यह क्यों मायने रखता है। महत्वपूर्ण रूप से, केवल वही रिकॉर्ड करें जो पहले से कहीं और कैप्चर नहीं किया गया है; डुप्लिकेट मेमोरी शोर है, ज्ञान नहीं।
अनुशासन जो इस चरण को लंबी अवधि में वास्तव में कारगर बनाता है, वह लिखने के समय संयम है। प्रवृत्ति एक सत्र में हुई हर चीज़ को लॉग करने की होती है, जो ठीक वही फूला हुआ ट्रांसक्रिप्ट समस्या पैदा करती है जिसके बारे में इस रोडमैप ने चरण 2 में चेतावनी दी थी, बस एक प्रॉम्प्ट के बजाय एक मेमोरी फ़ोल्डर में स्थानांतरित हो गई। लिखने लायक एक पाठ वह है जिसे भूल जाने पर फिर से खोजने में वास्तविक समय लगेगा, न कि नियमित कार्य का रिकॉर्ड जो बिल्कुल उम्मीद के मुताबिक सफल हुआ।
चरण 12: एक शेड्यूल पर समेकन पास जोड़ें
अकेले पर्सिस्टेंस अंततः वही समस्या पैदा करता है जो एक फूले हुए प्रॉम्प्ट की होती है: दर्जनों फ़ाइलें, जिनमें से कई एक ही चीज़ के थोड़े अलग संस्करण कहती हैं। एक आवर्ती शेड्यूल पर, साप्ताहिक उचित है, मेमोरी फ़ाइलों की समीक्षा करें, डुप्लिकेट को एकल, तेज पाठों में मर्ज करें, और जो कुछ भी बाद में गलत साबित हुआ है उसे हटा दें। लक्ष्य प्रत्येक में अधिक घनत्व वाली कम फ़ाइलें हैं, न कि लगातार बढ़ता हुआ ढेर।
यह वह चरण है जिसे अधिकांश लोग पूरी तरह से छोड़ देते हैं, क्योंकि यह अपने आप में कोई दृश्यमान नई क्षमता पैदा नहीं करता है; यह केवल भविष्य की समस्या को रोकता है। वह अदृश्यता ही वास्तव में कारण है कि इसे स्पष्ट रूप से शेड्यूल करने की आवश्यकता है, न कि जब भी किसी को पता चले कि मेमोरी फ़ोल्डर बोझिल हो गया है, तो ऐसा होने के लिए छोड़ दिया जाना चाहिए, जो व्यवहार में इसका मतलब है कि जब तक लूप का प्रदर्शन पहले से ही विरोधाभासी, अर्ध-प्रासंगिक पाठों के वजन के नीचे खराब होना शुरू नहीं हो जाता, तब तक ऐसा कभी नहीं होता जो एक ही संदर्भ विंडो के लिए प्रतिस्पर्धा कर रहे हों।
चरण 13: रिकॉल स्टेप जोड़ें
किसी भी नए रन की शुरुआत में, लूप को मेमोरी में एक-पंक्ति के सारांशों को स्कैन करने, यह पहचानने के लिए कहें कि कौन से पाठ वर्तमान कार्य के लिए वास्तव में प्रासंगिक हैं, और केवल उन्हें लोड करें। स्पष्ट रूप से निर्देश दें कि जब मेमोरी में कुछ भी लागू नहीं होता है तो वह यह कहे, न कि सिर्फ इसलिए कि मेमोरी मौजूद है, एक नई स्थिति पर एक अप्रासंगिक पिछले पाठ को जबरदस्ती फिट करे।
चरण 14: एक शेड्यूलिंग ट्रिगर जोड़ें
तय करें कि यह लूप आपके द्वारा इसे मैन्युअल रूप से शुरू किए बिना कब चलेगा। एक क्रॉन जॉब। एक फ़ाइल वॉचर। एक आवर्ती कैलेंडर-संचालित ट्रिगर। यह वह चरण है जो एक ऐसी प्रणाली को बदल देता है जिसे आप मांग पर चलाते हैं, एक ऐसी प्रणाली में जो आपके सोते समय चलती है, और यह आमतौर पर इस पूरी सूची में सबसे आसान चरण है, और वह है जिसे अधिकांश लोग बाकी सब कुछ बनाने के बाद भी कभी लागू करने की जहमत नहीं उठाते।
चरण चार: स्केलिंग और सख्त करना (चरण 15 से 18)
चरण 15: लूप पर भरोसा करने से पहले उसका स्ट्रेस टेस्ट करें
इस लूप पर किसी भी वास्तविक चीज़ के लिए भरोसा करने से पहले, जानबूझकर इसे चार विफलता मोड के विरुद्ध परीक्षण करें।
इसे कार्य का एक वास्तविक रूप से अनसुलझा संस्करण दें और पुष्टि करें कि मैनेजर वास्तव में हमेशा के लिए लूप करने के बजाय रुक जाता है, क्योंकि एक लूप जिसका केवल उन कार्यों पर परीक्षण किया गया है जिन्हें वह पूरा कर सकता है, उसने वास्तव में कभी प्रदर्शित नहीं किया है कि वह शालीनता से विफल होना जानता है।
जज को एक ऐसा आउटपुट खिलाएँ जिसके बारे में आप जानते हैं कि वह सूक्ष्म रूप से गलत है, कुछ ऐसा जो अच्छी तरह से पढ़ा जाता है लेकिन इसमें एक विशिष्ट तथ्यात्मक या तार्किक त्रुटि है जिसे आपने जानबूझकर लगाया है, और पुष्टि करें कि यह वास्तव में दोष को पकड़ता है न कि कुछ प्रशंसनीय लगने वाली चीज़ को पास करता है।
यदि बिल्डर और जज एक ही अंतर्निहित मॉडल साझा करते हैं, तो जज को वह गलती खिलाएँ जो वह मॉडल विशेष रूप से करता है और देखें कि क्या वह गलती को अनदेखा कर देता है, क्योंकि जज का बिल्डर के अंधे धब्बों को साझा करना चरण 6 से अलगाव के पूरे उद्देश्य को विफल कर देता है।
लूप के अपनी अधिकतम संशोधन सीमा तक चलने की सबसे खराब स्थिति की लागत की गणना करें, अपने सबसे महंगे मॉडल कॉल और सबसे लंबे उचित आउटपुट का उपयोग करके, और ईमानदारी से तय करें कि क्या वह संख्या, एक वास्तविक चालान पर दिखाई देने पर, आपको चिंतित करेगी।
किसी भी ऐसी चीज़ के साथ लूप पर भरोसा करने से पहले इन चार परीक्षणों को चलाने से विफलताओं का भारी बहुमत पकड़ में आ जाता है जो अन्यथा पहली बार किसी ग्राहक, बॉस या आपके अपने बैंक स्टेटमेंट के सामने दिखाई देते, बजाय एक नियंत्रित परीक्षण के जिसे आपने जानबूझकर चलाया।
चरण 16: कार्यों को हर बार एक ही मॉडल पर नहीं, बल्कि सही मॉडल पर रूट करें
एक बार जब लूप काम करता है, तो इसके हर हिस्से को अपने एकल पसंदीदा मॉडल पर चलाने की आदत का विरोध करें। बिल्डर भूमिका आमतौर पर आपके सबसे सक्षम मॉडल से लाभान्वित होती है, क्योंकि यह वास्तविक कठिन तर्क कर रहा है और यहाँ एक कमजोर मॉडल एक खराब पहला ड्राफ्ट तैयार करता है जिसे ठीक करने में अधिक संशोधन चक्र खर्च होते हैं, जितना कि इसे शुरू से अच्छी तरह से तैयार करने में खर्च होता।
जज भूमिका, एक विशिष्ट लिखित मानक के विरुद्ध जाँच करते हुए, अक्सर एक छोटे, सस्ते, तेज़ मॉडल पर उतनी ही विश्वसनीय रूप से प्रदर्शन करती है, क्योंकि उसे रचनात्मक होने के लिए नहीं कहा जा रहा है, केवल सुसंगत होने के लिए, और एक छोटा मॉडल जो एक अत्यधिक अच्छी तरह से निर्दिष्ट चेकलिस्ट के विरुद्ध जाँच कर रहा है, अक्सर लागत और विलंबता के एक अंश पर एक बड़े मॉडल से मेल खाता है।
मैनेजर, आपके पहले से लिखे नियमों के आधार पर रूटिंग करते हुए, लगभग कभी भी आपके सबसे महंगे मॉडल की आवश्यकता नहीं होती, क्योंकि उसका काम आपके द्वारा पहले से निर्दिष्ट तर्क को निष्पादित करना है, न कि खुले अंत वाला तर्क करना, और यह बिल्डर और जज के प्रदर्शन की परवाह किए बिना प्रति पुनरावृत्ति कम से कम एक बार चलता है, जो इसकी प्रति-कॉल लागत को इसकी कच्ची क्षमता से अधिक मायने रखता है।
यह स्तरीय दृष्टिकोण - निर्माण के लिए महंगा मॉडल, नियमित जाँच के लिए सस्ता और सुसंगत मॉडल, रूटिंग के लिए सस्ता मॉडल - आमतौर पर वह जगह है जहाँ से लूप में वास्तविक लागत बचत आती है। अधिकांश लोग मानते हैं कि लागत नियंत्रण का अर्थ है कम लूप या कम संशोधन। यह वास्तव में आपके द्वारा पहले से बनाए गए लूप के अंदर प्रत्येक विशिष्ट भूमिका की वास्तविक कठिनाई से मॉडल लागत का मिलान करने से आता है।
चरण 17: एक साथ पाँच नहीं, बल्कि दूसरे लूप तक विस्तार करें
पहला लूप काम करने के बाद प्रलोभन तुरंत कई और बनाने का होता है, पाँच अलग-अलग कार्यों को समानांतर में लेना क्योंकि आर्किटेक्चर अब तकनीकी रूप से इसका समर्थन करता है। आरामदायक महसूस होने से अधिक समय तक इसका विरोध करें। एक लूप को इतना विश्वसनीय रूप से चलाएँ कि आपने वास्तव में इसके आउटपुट की बारीकी से जाँच करना बंद कर दिया हो, जिसका अर्थ है कि यह वास्तविक समय की अवधि में लगातार आपके अपने मैन्युअल स्पॉट-चेक को पास करता है, न कि केवल एक एकल सफल डेमो रन जिसे सभी ने बारीकी से देखा। उसके बाद ही दूसरा लूप शुरू करें, एक अलग कार्य पर, आदर्श रूप से ऐसा जो पहले से पूरी तरह से अलग किसी चीज़ पर मैप हो, ताकि आप परीक्षण कर रहे हों कि क्या अंतर्निहित ढाँचा सामान्यीकृत होता है, न कि केवल उसी कार्य को और अधिक ट्यून कर रहे हों।
चरण 18: अपने आप को सभी चल रहे लूपों में एक साझा दृश्य दें
एक बार जब आपके पास एक से अधिक लूप चल रहे हों, तो सभी में लागत और स्टॉप-कंडीशन ट्रिगर का एक साझा दृश्य ट्रैक करें, न कि अलग-अलग प्रति-लूप। एक उचित प्रति-कार्य बजट वाला एक एकल लूप अपने आप में पूरी तरह से ठीक दिखता है। दस लूप जो प्रत्येक व्यक्तिगत रूप से बजट के भीतर हैं, फिर भी एक चिंताजनक कुल में जुड़ सकते हैं जिस पर तब तक किसी का ध्यान नहीं जाता जब तक कि कुल बिल नहीं आ जाता, ठीक इसलिए क्योंकि प्रत्येक व्यक्तिगत लूप की ट्रैकिंग अलग-थलग ठीक लग रही थी।
प्रत्येक स्टॉप-कंडीशन ट्रिगर को विशेष रूप से लॉग करें, न कि केवल सफल समापन को। एक लूप जो लगातार अपनी संशोधन सीमा तक पहुँच रहा है, जबकि अन्य शायद ही कभी पहुँचते हैं, आपको बता रहा है कि उसके जज का मानक गलत तरीके से कैलिब्रेट किया गया है, वास्तव में पास करने के लिए बहुत सख्त है, या पूरी तरह से गलत ग्राउंड ट्रुथ के विरुद्ध जाँच कर रहा है, न कि यह कि अंतर्निहित कार्य केवल कठिन है। वह पैटर्न अदृश्य है यदि आप केवल सफलताओं को ट्रैक कर रहे हैं और प्रत्येक वृद्धि को एक पृथक, सामान्य घटना के रूप में मान रहे हैं, न कि उस विशिष्ट लूप के डिज़ाइन के बारे में एक डेटा बिंदु के रूप में।
चरण पाँच: एक सिस्टम डिज़ाइनर बनना (चरण 19 और 20)
चरण 19: अपने आप को लिखे गए प्रॉम्प्ट से मापना बंद करें
बदलाव के वास्तव में होने का सबसे स्पष्ट संकेत यह है कि आप दिन-प्रतिदिन किस चीज़ पर ध्यान देते हैं, उसमें बदलाव आता है। एक प्रॉम्प्टर ट्रैक करता है कि उन्होंने कितने अच्छे प्रॉम्प्ट लिखे। एक सिस्टम डिज़ाइनर ट्रैक करता है कि कितने लूप चल रहे हैं, प्रत्येक कितना विश्वसनीय है, और उनका कितना अपना समय उन सिस्टमों द्वारा उन्हें वापस मिल गया है जिन्हें अब पर्यवेक्षण की आवश्यकता नहीं है। यदि आप अभी भी अपनी उत्पादकता को टाइप किए गए प्रॉम्प्ट में माप रहे हैं, तो चरण एक से मानसिक बदलाव अभी तक पूरी तरह से नहीं उतरा है, भले ही आपने तकनीकी रूप से कितने भी लूप बनाए हों।
चरण 20: किसी और को पाँच चालें सिखाएँ
अंतिम चरण वास्तव में अब आपके अपने सिस्टम के बारे में नहीं है। यह पुष्टि करना है कि आपने वास्तव में बदलाव को आंतरिक कर लिया है, इसे किसी और को शब्दजाल का सहारा लिए बिना समझाकर। डिस्कवरी, हैंडऑफ़, सत्यापन, पर्सिस्टेंस, शेड्यूलिंग। यदि आप किसी अन्य व्यक्ति को केवल उन पाँच चालों और उपरोक्त चरणों का उपयोग करके अपना पहला लूप बनाने में मार्गदर्शन कर सकते हैं, तो आपने वास्तविक परिवर्तन कर लिया है जिसका यह रोडमैप वर्णन करता है। अब आप लूप के अंदर बैठकर अगला निर्देश टाइप करने वाले व्यक्ति नहीं हैं। आप वह व्यक्ति हैं जिसने इसे डिज़ाइन किया है, बाहर खड़े होकर इसे चलते देख रहे हैं।
चार लागतें जो चरणों को छोड़ने पर चुपचाप बढ़ती हैं
एक चेतावनी के साथ समाप्त करना उचित है, क्योंकि इस रोडमैप में चरणों को छोड़ना जोर से विफल नहीं होता है; यह चुपचाप विफल होता है, ऐसे तरीकों से जो बहुत बाद में ही दिखाई देते हैं।
सत्यापन ऋण तब जमा होता है जब आप चरण 6 और 7 को छोड़ देते हैं, बिना किसी वास्तविक जज या वास्तविक ग्राउंड ट्रुथ के लूप बनाते हैं। लूप दिखता है जैसे यह काम कर रहा है क्योंकि आउटपुट ठीक दिखता है, ठीक उसी क्षण तक जब तक कोई गलती दर्जनों रनों में चुपचाप बढ़ नहीं जाती, इससे पहले कि किसी को पता चले।
समझ का क्षय तब शुरू होता है जब आप चरण 20 को छोड़ देते हैं, उन लूपों को चलाते हैं जिन्हें आपने एक बार बनाया था लेकिन यदि वे टूट गए तो उन्हें समझा या डीबग नहीं कर सकते, क्योंकि आपको कभी भी यह आंतरिक करने की आवश्यकता नहीं थी कि प्रत्येक टुकड़ा क्यों मौजूद था।
संज्ञानात्मक समर्पण तब होता है जब चरण 1 कभी वास्तव में नहीं उतरता है, जब आप आदत से बाहर हर आउटपुट की मैन्युअल रूप से दोबारा जाँच करते रहते हैं, सत्यापन प्रणाली के पहले से ही खुद को साबित करने के बाद भी, सिस्टम बनाने के पूरे उद्देश्य को विफल कर देते हैं।
टोकन ब्लोआउट वह है जो तब होता है जब आप चरण 10 को छोड़ देते हैं, बिना किसी वास्तविक स्टॉप कंडीशन के लूप चलाते हैं, वास्तविक लागत का पता तभी चलता है जब बिल आता है।
इनमें से प्रत्येक लागत टालने योग्य है, और प्रत्येक को उसी अनुशासन द्वारा टाला जाता है। चरणों को क्रम में बनाएँ। उन चरणों को न छोड़ें जो अप्रतिष्ठित लगते हैं। उबाऊ चरण - पूर्णता की परिभाषा, स्टॉप कंडीशन, ग्राउंड ट्रुथ - वास्तव में काम कर रहे हैं। दिलचस्प लगने वाले हिस्से - चतुर प्रॉम्प्ट, विस्तृत आर्किटेक्चर आरेख - इससे कहीं कम मायने रखते हैं कि क्या आपके द्वारा बनाया गया सिस्टम वास्तव में जानता है कि वह कब सही है, कब गलत है और कब रुकना है।
यह एक प्रॉम्प्टर और एक सिस्टम डिज़ाइनर के बीच पूरा अंतर है। चतुराई नहीं। उन हिस्सों के बारे में अनुशासन जो बनाने में उबाऊ हैं और छोड़ने में आसान हैं।
इस रोडमैप में प्रत्येक चरण के पीछे सटीक लूप टेम्पलेट्स और बिल्डर-जज-मैनेजर सेटअप के लिए @cyrilXBT को फॉलो करें।
