जब इंसानों को अभी भी कीबोर्ड के सामने बैठकर एजेंट्स को पंक्ति दर पंक्ति निर्देश देने की आवश्यकता होती है, तो मूल क्षमता प्रॉम्प्ट लिखने की होती है। आज, एजेंट्स एक लक्ष्य प्राप्त कर सकते हैं और फिर स्वयं कार्य कर सकते हैं, नई मूल क्षमता साइकिल इंजीनियरिंग है।

लेखक: CyrilXBT

लेख संकलन, स्रोत: ME News

जून 2026 में, एक हफ्ते के भीतर, तीन लोगों ने अलग-अलग रूप से एक ही निष्कर्ष पर पहुंचा।

OpenClaw के विकासक पीटर श्टाइनबर्गर ने जनता को सीधे प्रोग्रामिंग एजेंट्स को प्रॉम्प्ट लिखने के बजाय, उन चक्रीय प्रणालियों को डिज़ाइन करने के लिए कहा है जो स्वचालित रूप से एजेंट्स को निर्देश देती हैं।

लगभग उसी समय, Anthropic Claude Code के प्रमुख बोरिस चेर्नी ने भी कहा कि वे अब क्लॉड को सीधे प्रॉम्प्ट नहीं दे रहे हैं। अब, वे एक ऐसे चक्र चला रहे हैं जो क्लॉड को स्वचालित रूप से कॉल करते हैं और अगला कदम क्या होना चाहिए, यह निर्धारित करते हैं, और उनका वास्तविक काम इन चक्रों को लिखना और डिज़ाइन करना है।

कुछ दिनों बाद, गूगल इंजीनियर एडी ओसमैनी ने इस अभ्यास का एक व्यवस्थित सारांश प्रस्तुत किया और एक नाम दिया:

Loop Engineering, साइकिल इंजीनियरिंग।

उन्होंने इस कार्य शैली को अचानक नहीं बनाया, बल्कि एक ऐसे बदलाव का नाम दिया जो पहले से ही चुपचाप हो रहा था।

क्योंकि इससे पहले, निचले स्तर के उपकरण एक महत्वपूर्ण सीमा पार कर चुके थे: प्रोग्रामिंग एजेंट अब बिना किसी की देखरेख के वास्तविक कार्य पूरा करने लगे हैं; स्वचालित शेड्यूलिंग की लागत इतनी कम हो गई है कि एक कार्य को बार-बार समयबद्ध रूप से चलाना बर्बादी नहीं लगता; एकल एजेंट चलाने की लागत भी एक नए स्तर पर आ गई है—एक बार लंबे समय तक सोचने के बजाय, पांच बार प्रयास करना संभवतः कम लागतवाला हो सकता है।

यही कारण है कि यह रोडमैप मौजूद है।

जब इंसानों को अभी भी कीबोर्ड के सामने बैठकर एजेंट्स को पंक्ति दर पंक्ति निर्देश देने की आवश्यकता होती है, तो मूल क्षमता प्रॉम्प्ट लिखने की होती है। आज, एजेंट्स एक लक्ष्य प्राप्त कर सकते हैं और फिर स्वयं कार्य कर सकते हैं, नई मूल क्षमता साइकिल इंजीनियरिंग है।

नीचे एक पूर्ण 20-चरण पथ दिया गया है जो एक प्रॉम्प्ट ऑपरेटर से सिस्टम डिज़ाइनर तक जाता है। इस पथ में चरणों के बीच का क्रम अक्सर किसी भी अलग चरण से अधिक महत्वपूर्ण होता है, इसलिए इसे क्रम में आगे बढ़ाना आवश्यक है।

साइक्लिक इंजीनियरिंग एक ऐसी एकल क्षमता नहीं है जिसे आप "सीख लेते हैं" या "नहीं सीखते हैं"; यह एक स्तरबद्ध क्षमता स्टैक है। प्रत्येक स्तर, नीचे के आधार के मजबूत होने पर निर्भर करता है।

उदाहरण के लिए, वास्तविक स्टॉप कंडीशन को चरण 10 में स्थापित किए बिना, चरण 14 का ऑटोमेटेड स्केड्यूलर ट्रिगर बनाना केवल एक ऐसी प्रणाली प्राप्त करेगा जो बिना किसी की देखभाल के स्वयं पैसा बर्बाद कर सकती है। पहले यह कम से कम आपके स्क्रीन पर नजर रखने पर ही संसाधनों को बर्बाद करता था, अब यह स्वयं लगातार पैसा जला सकती है।

इसी तरह, यदि आप चरण 6 और चरण 7 के विश्वसनीय सत्यापन तंत्र को पूरा किए बिना चरण 11 की स्थायी स्मृति परत को लागू करते हैं, तो आप एक अत्यधिक ढीले, निरंतर गलत परिणामों को मंजूरी देने वाले "समीक्षक" द्वारा संकलित अनुभव को गंभीरता से संग्रहीत कर सकते हैं।

यह न केवल सिस्टम के विकास में मदद नहीं करेगा, बल्कि गलत अनुभव को जमा करेगा और मेमोरी लेयर को “अस्थायी रूप से अउपयोगी” से “सक्रिय रूप से हानिकारक” बना देगा।

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

असली पहला कदम किसी भी तकनीक से नहीं जुड़ा है।

आपको स्वीकार करना होगा कि वर्तमान कार्यप्रवाह में, दक्षता को सीमित करने वाले कारक अब अक्सर मॉडल क्षमता नहीं होते, बल्कि आप अभी भी चक्र में फंसे हुए हैं।

जब आप कंप्यूटर के सामने बैठकर मॉडल के उत्तर का इंतजार करते हैं, परिणाम पढ़ते हैं और फिर अगला निर्देश देते हैं, तो आप पूरी प्रणाली का सबसे धीमा घटक बन जाते हैं।

मॉडल को निष्पादित, सत्यापित और पुनः प्रयास किया जा सकता है, और ये क्रियाएँ मानव द्वारा चरणबद्ध रूप से इसे कार्य पूरा करने के लिए निरीक्षण करने की तुलना में बहुत तेज़ होती हैं।

This step has no corresponding prompt; it is a cognitive decision.

जब तक आप इसे वास्तव में स्वीकार नहीं करते, तब तक सभी आगे के कदम अपने वास्तविक अर्थ—प्रणाली में सबसे बड़ी दक्षता की बाधा को हटाना—के बजाय अनावश्यक अतिरिक्त कार्य के रूप में दिखाई देंगे।

जब मॉडल का आउटपुट समस्या पैदा करता है, तो लोगों की सबसे प्राकृतिक प्रतिक्रिया अक्सर मूल प्रॉम्प्ट में एक नियम और जोड़ना होता है।

कुछ महीनों बाद, यह दृष्टिकोण नियमों की एक ऊँची दीवार बना देगा: सामग्री से भरपूर, एक-दूसरे के विरोधी, और इतनी लंबी कि मॉडल अपनी कार्य स्मृति में सभी आवश्यकताओं को एक साथ संभाल नहीं पाएगा।

अंततः, मॉडल अक्सर केवल हाल ही में आए या सबसे अधिक दिखाई देने वाली सामग्री के आधार पर पैटर्न मैच करते हैं और अनजाने में अन्य नियमों को नज़रअंदाज़ कर देते हैं।

Circularity engineering has completely transformed this approach.

जब कोई समस्या उत्पन्न होती है, तो आप केवल प्रॉम्प्ट में एक नया निर्देश जोड़ने के बजाय, सिस्टम में एक नया घटक जोड़ते हैं, जैसे:

• एक स्वतंत्र प्रमाणीकरण चरण जोड़ें;
• एक मेमोरी फ़ाइल जोड़ें;
• एक टाइमर ट्रिगर जोड़ें;
• एक संरचित समीक्षा चरण जोड़ें।

जैसे-जैसे बाहरी प्रणाली क्षमताएं बढ़ती जा रही हैं, प्रॉम्प्ट्स स्वयं लंबे नहीं, बल्कि छोटे होते जा रहे होने चाहिए।

किसी भी क्षेत्र का कार्य हो, चक्र के प्रत्येक चक्र को पाँच मूल क्रियाओं में विभाजित किया जा सकता है:

पहचान, हस्तांतरण, प्रमाणीकरण, स्थायीकरण, नियोजन।

खोज

Identify what the actual task that needs to be accomplished is.

हैंडऑफ

Assign the task to the model, agent, or tool responsible for execution.

प्रमाणीकरण

Check whether the results are correct based on real standards.

स्थायीकरण (Persistence)

इस रन के दौरान क्या हुआ, क्या सीखा गया, उसे रिकॉर्ड करें ताकि अगले रन में यह अनुभव खोया न जाए।

शेड्यूलिंग

Decide when this process should run again.

अधिकांश लोगों के वर्तमान कार्य प्रवाह में केवल पहले दो क्रियाएँ: कार्य पहचानना और कार्य हस्तांतरित करना शामिल हैं, और आमतौर पर ये चैट विंडो में हाथ से की जाती हैं।

अन्य तीन क्रियाएँ या तो मौजूद नहीं हैं या मनुष्य के अपने मस्तिष्क में छिपी हुई हैं।

साइक्लिक इंजीनियरिंग का केंद्र यह है कि इन पांच क्रियाओं को स्पष्ट रूप से दर्शाया जाए और संभवतः स्वचालित रूप से चलाया जाए।

शुरू करने से पहले, एक ऐसा कार्य चुनें जिसे आप पहले से ही दोहरा रहे हैं और जिसकी गुणवत्ता मानदंड को स्पष्ट रूप से वर्णित किया जा सकता है।

सबसे कठिन प्रश्नों का चयन न करें और न ही बिल्कुल अनुभवहीन नवीन कार्यों का चयन करें।

पहला उम्मीदवार कार्य तीन शर्तों को पूरा करना चाहिए:

1. आपको इसे बार-बार करना होगा;
2. इसमें लिखने योग्य स्पष्ट मानदंड हैं;
3. इसकी एक आसानी से पहचाने जा सकने वाली "पूर्ण स्थिति" है।

In other words, a colleague who sees the results should be able to quickly determine whether the task was completed correctly.

यह सीमा सतही रूप से दिखने से अधिक महत्वपूर्ण है।

अगर किसी कार्य के लिए स्पष्ट पूर्णता मानदंड नहीं हैं, तो वास्तविक प्रमाणीकरण चरण बनाया नहीं जा सकता। और एक ऐसा चक्र, जिसमें विश्वसनीय प्रमाणीकरण तंत्र नहीं है, वास्तविक चक्र नहीं है, बल्कि केवल एक अनुपस्थित निगरानी वाला अनुमान है।

यह वह सबसे आसान चरण है जिसे अधिकांश लोग छोड़ देते हैं, लेकिन यह बाद के सिस्टम के सही ढंग से काम करने का निर्णायक चरण है।

किसी एजेंट के लिए कोई निर्देश लिखने से पहले, स्पष्ट और प्राकृतिक भाषा में लिखें कि एक सही परिणाम कैसा होना चाहिए।

आपको वास्तविक, जांचने योग्य मानदंडों की आवश्यकता है, न कि "अच्छा लग रहा है" या "पेशेवर दिख रहा है" जैसे अस्पष्ट गुणवत्ता निर्णयों की।

निम्नलिखित टेम्पलेट का उपयोग कर सकते हैं:

कार्य नाम: [कार्य नाम]

डिफिनिशन ऑफ डन (Definition of Done, DoD):

• [विशिष्ट, जांचने योग्य मानदंड 1]
• [विशिष्ट, जांचने योग्य मानदंड 2]
• [विशिष्ट, जांचने योग्य मानदंड 3]

जब तक उपरोक्त में से कोई भी चीज़ नहीं शामिल है, तब तक यह कार्य पूरा नहीं माना जा सकता, भले ही अंतिम आउटपुट पूर्ण और सावधानी से संपादित लगे।

अगर आप वर्तमान चुनी गई कार्य के लिए इस टेम्पलेट को भरने में असमर्थ हैं, तो आपको चरण 4 पर वापस जाकर चक्र बनाने के लिए अधिक उपयुक्त कार्य चुनना चाहिए।

यह सभी साइक्लिक सिस्टम में सबसे महत्वपूर्ण आर्किटेक्चरल निर्णय है।

The role responsible for generating results must be separate from the role responsible for checking results.

कारण यह है कि जब मॉडल अपने उत्पादन के तुरंत बाद अपने आउटपुट की समीक्षा करता है, तो यह अक्सर अपने हाल ही में उत्पन्न उत्तर का समर्थन करने की प्रवृत्ति रखता है, बजाय इसमें मौजूद समस्याओं की आलोचनात्मक रूप से जांच करने के।

एक उचित चक्र में, कम से कम दो स्वतंत्र भूमिकाएँ होनी चाहिए:

बिल्डर

बिल्डर्स को एक निश्चित रचनात्मक स्वतंत्रता मिलती है और पहले संस्करण के परिणाम उत्पन्न करने की जिम्मेदारी होती है।

न्यायाधीश

रिव्यूअर बिल्डर के आउटपुट और चरण 5 में निर्धारित पूर्णता की परिभाषा प्राप्त करता है और इन मानदंडों के आधार पर परिणाम की योग्यता का आकलन करता है।

आदर्श रूप से, समीक्षकों को बिल्डर्स के लिए अप्राप्य स्वतंत्र साक्ष्य तक पहुंच भी होनी चाहिए, जैसे:

• टेस्ट सूट;
• Original data;
• रियल-टाइम डेटा;
• Authoritative database;
• Original task brief.

इस तरह, समीक्षक का निर्णय वास्तविक साक्ष्य पर आधारित होगा, और निर्माता के समान दृष्टिकोण से एक बार फिर व्यक्तिगत राय उत्पन्न नहीं होगी।

अगर समीक्षक केवल निर्माता के आउटपुट को देख सकता है, तो यह केवल यह निर्णय ले सकता है कि परिणाम "संगठित लगता है या नहीं"।

यह निर्धारित नहीं कर सकता कि परिणाम वास्तव में सही हैं या नहीं।

इसलिए, समीक्षक के पास एक वस्तुनिष्ठ आधार होना चाहिए, जिसे Ground Truth के रूप में जाना जाता है। उपयुक्त संदर्भ के अनुसार, इसे "आधारभूत तथ्य", "वास्तविक डेटा" या "अधिकृत आधार" के रूप में समझा जा सकता है।

विभिन्न कार्यों के लिए वस्तुनिष्ठ आधार भिन्न-भिन्न होते हैं।

प्रोग्रामिंग कार्य

The objective basis is the test suite and the output results after the code runs in reality.

कंटेंट उत्पादन कार्य

The objective basis is the original materials and content brief. Reviewers need to compare the original materials side by side with the generated draft.

अनुसंधान कार्य

The objective basis is the original documents, papers, datasets, or authoritative sources explicitly required for the task.

अगर आप यह स्पष्ट रूप से नहीं बता सकते कि समीक्षक को किस आधार पर जांचना है, तो आपके चक्र में अभी तक कोई वास्तविक प्रमाणीकरण तंत्र नहीं है, चाहे समीक्षक की भाषा कितनी भी आत्मविश्वास से भरी क्यों न हो।

निर्माता के आउटपुट और समीक्षक के निष्कर्ष दोनों को स्पष्ट रूप से परिभाषित संरचना का उपयोग करना चाहिए, केवल स्वतंत्र रूप से प्रवाहित प्राकृतिक भाषा नहीं।

अन्यथा, अगले मैनेजर के पास निर्णय और रूटिंग के लिए स्थिर, विश्वसनीय जानकारी नहीं होगी।

निर्माता निम्नलिखित आउटपुट फॉर्मेट का उपयोग कर सकते हैं:

बिल्डर आउटपुट:

• Final Deliverables;
• The level of confidence in the result;
• Known uncertainty.

समीक्षक निम्नलिखित आउटपुट फॉर्मेट का उपयोग कर सकते हैं:

रिव्यू निष्कर्ष:

• PASS: सफल;
• FAIL: विफल;
• NEEDS REVISION：需要修改；
• Identified specific issues;
• इस जांच के आधार पर निर्धारित वस्तुनिष्ठ मानदंड या मूल साक्ष्य।

ऑटोमेटेड स्केड्यूलिंग और ऑटोमेटेड रीट्राई के लिए पहले एक पूर्ण "बिल्डर—रिव्यूअर" प्रक्रिया को मैन्युअल रूप से खुद चलाएं।

रिव्यूअर द्वारा दिए गए निर्णय को ध्यान से पढ़ें, और खुद से पूछें:

• क्या आप इसके निष्कर्ष से सहमत हैं?
• क्या इसने कभी आपके लिए एक ऐसा परिणाम छोड़ दिया है जिसमें आप जानते हैं कि त्रुटि है?
• क्या इसने एक मूल रूप से योग्य परिणाम को गलती से अस्वीकार कर दिया?

यदि समीक्षक एक ऐसे परिणाम को मंजूरी दे देता है जिसे आप गलत जानते हैं, या एक ऐसे परिणाम को अस्वीकार कर देता है जिसमें वास्तव में कोई समस्या नहीं है, तो पहले वस्तुनिष्ठ आधार या मानक को सुधारें, फिर प्रणाली का निर्माण जारी रखें।

Automating an incorrect verification step only causes the system to produce erroneous results faster.

उपरोक्त पाँच चरणों को अधिक विशिष्ट बनाने के लिए, हम एक सामान्य कार्य का अवलोकन कर सकते हैं: एक मूल सामग्री को एक पूर्ण लेख में बदलना।

चरण 5: पूर्ण परिभाषा तैयार करें

इस कार्य को पूरा करने का मानदंड हो सकता है:

• प्रत्येक तथ्य, जो रूपरेखा में शामिल है, मूल स्रोत में स्पष्ट रूप से उल्लेखित है;
• ड्राफ्ट संक्षेप में सभी विशिष्ट आवश्यकताओं को पूरा करता है, जिसमें लंबाई, टोन और संरचना शामिल हैं;
• मूल तर्क को स्पष्ट रूप से बनाए रखा गया है, और इसे अनावश्यक भरपाई के साथ नहीं घटाया गया है।

चरण 6: बिल्डर ड्राफ्ट बनाता है

निर्माता मूल सामग्री और कंटेंट ब्रीफ प्राप्त करता है और एक प्रारंभिक ड्राफ्ट तैयार करता है।

इसके साथ ही, इसे लेखन प्रक्रिया के दौरान उत्पन्न अनिश्चितताओं को स्पष्ट रूप से सूचीबद्ध करना होगा, जैसे:

• क्या कोई संख्या वास्तव में मूल स्रोत में दिखाई देती है;
• क्या यह निष्कर्ष मूल पाठ में स्पष्ट रूप से व्यक्त किया गया है, या मॉडल द्वारा स्वयं निकाला गया है;
• क्या किसी तथ्य के लिए पर्याप्त स्रोत नहीं हैं?

चरण 7: समीक्षक मूल पाठ के साथ जांच करते हैं

Reviewers receive both the draft and the original materials, not just the draft.

इसे परिभाषा में निर्धारित तीन मानदंडों को अलग-अलग जांचना चाहिए और प्रत्येक मानदंड के लिए अलग से पास या फेल का निष्कर्ष देना चाहिए, न कि सभी आयामों को एक अस्पष्ट समग्र स्कोर में समेटना।

तीन अलग-अलग मानदंडों को एक समग्र निर्णय में मिलाना, यह छिपा देता है कि कौन सा आयाम समस्याग्रस्त है। यह उन अनेक चक्रों का सबसे सामान्य कारण है, जो धीरे-धीरे प्रतिक्रिया के मूल्य को खो देते हैं।

चरण 8: संरचित हस्तांतरण

रिव्यूअर का निष्कर्ष एक संरचित ऑब्जेक्ट होना चाहिए, न कि एक आरक्षित शब्दावली से भरा नैचुरल लैंग्वेज पैराग्राफ।

इसे तीन स्पष्ट पास या फेल परिणाम देने होंगे, और प्रत्येक फेल के लिए विशिष्ट कारण देना होगा।

चरण 9: समीक्षा तंत्र का हस्ताक्षरित सत्यापन

सिस्टम को स्वचालित रूप से चलाने से पहले, एक पूर्ण प्रक्रिया को मैनुअल रूप से निष्पादित करने से आपको पता चल सकता है कि समीक्षक अत्यधिक ढीले हैं या अत्यधिक कठोर हैं।

अत्यधिक ढीले समीक्षक, चूंकि लेख प्रवाहमय है, इसलिए उसमें गढ़े गए आंकड़ों को छूट दे सकते हैं।

अत्यधिक कठोर समीक्षक एक योग्य लेख को एक ऐसी व्यक्तिगत शैली की पसंद के कारण गलती से अस्वीकार कर सकते हैं, जो कभी ब्रीफिंग में शामिल नहीं की गई थी।

These two issues are very common during the first setup.

और 50 बार सिस्टम को बिना किसी व्यक्ति के चलाने के बाद उन्हें पाना, पहली बार मैनुअल टेस्टिंग के दौरान समस्याओं को हल करने की तुलना में बहुत अधिक महंगा होता है।

मैनेजर रिव्यूअर्स के निर्णय पढ़ता है और अगला कदम निर्धारित करता है।

स्टॉप कंडीशन को मैनेजर में भी मौजूद होना चाहिए, और इसे एक स्पष्ट, कठोर लॉजिक के रूप में लिखा जाना चाहिए, न कि एक ऐसी नरम निर्देश के रूप में जिसे मॉडल अपनी खुद की व्याख्या द्वारा बाहर निकाल सकता है।

उदाहरण के लिए:

Stop Condition:

• अधिकतम संशोधन गिनती: 3;
• जब तीसरी समीक्षा भी असफल रहती है, तो पूर्ण इतिहास मानवीय संसाधनों को सौंप दिया जाएगा, चौथा संशोधन शुरू नहीं किया जाएगा;
• गुणवत्ता मानक: प्रत्येक परिभाषा में निर्धारित बिंदु को PASS दिखाना आवश्यक है;
• बजट सीमा: यदि कार्य की लागत X से अधिक हो जाती है या चलने का समय Y से अधिक हो जाता है, तो वर्तमान स्थिति के आधार पर निर्भर किए बिना तुरंत रोक दिया जाना चाहिए।

एक बिना वास्तविक रोक शर्त के लूप एक प्रणाली नहीं, बल्कि जोखिम के प्रकट होने का इंतजार कर रहा एक दायित्व है।

क्यों “जब परिणाम पर्याप्त अच्छा हो जाए तो रुक जाएँ” जैसे नरम निर्देश अविश्वसनीय होते हैं?

क्योंकि यह केवल एक सुझाव है।

जब मॉडल को कई बार लगातार संशोधित किया जाने के बाद भी स्वीकृत नहीं किया गया हो, तो कार्य को एक संतोषजनक अंत प्रदान करने के लिए, यह संभवतः अपने आप को यह विश्वास दिला लेता है कि "यह संस्करण मानक के काफी करीब है" और इस प्रकार अपनी निर्णय लेने की सीमा कम कर देता है।

In contrast, such issues do not arise with iterations mechanically checked by code or explicit rules that the manager cannot circumvent through reasoning.

अगर एक चक्र प्रत्येक बार शुरू होने पर शून्य से शुरू होता है, तो यह पिछले चलन से सीखा गया कुछ नहीं याद रखेगा।

इसलिए, एक सरल स्थायी परत की आवश्यकता है।

प्रत्येक वास्तविक नए अनुभव के लिए एक फ़ाइल बनाएं और फ़ाइल के शीर्ष पर एक वाक्य में सारांश दें:

• क्या सीखा;
• What was fixed;
• Why is this experience important?

मुख्य सिद्धांत यह है: केवल ऐसी नई जानकारी को ही रिकॉर्ड करें जो कहीं और सहेजी नहीं गई है।

Repeated memory is not knowledge, but noise.

लंबे समय तक स्थायी तंत्र को प्रभावी बनाए रखने के लिए, लिखते समय संयम बरतना आवश्यक है।

सभी चल रहे विवरणों को रिकॉर्ड करने की भावना समझना आसान है, लेकिन इससे केवल चरण 2 में उल्लिखित "बोझिल प्रॉम्प्ट" समस्या का पुनरुत्पादन होता है, केवल इस बार फूलने वाला तत्व प्रॉम्प्ट के बजाय स्मृति फोल्डर होता है।

वास्तविक रूप से दर्ज करने योग्य अनुभव वे हैं जो एक बार भूल जाने पर पुनः खोजने में बहुत समय लगता है, न कि किसी सामान्य सफल चलाने का सामान्य रिकॉर्ड।

केवल स्थायीकरण तंत्र बढ़ाने से अंततः अत्यधिक लंबे प्रॉम्प्ट्स के समान समस्याएँ उत्पन्न होंगी।

समय के साथ, सिस्टम दर्ज़नों फ़ाइलें जमा कर लेता है, जिनमें से कई केवल एक ही समस्या के हल्के अलग व्यक्तीकरण होते हैं।

इसलिए, मेमोरी फ़ाइलों को निर्धारित अंतराल पर व्यवस्थित किया जाना चाहिए। सप्ताह में एक बार करना आमतौर पर एक उचित आवृत्ति है।

संगठन प्रक्रिया में शामिल है:

• मौजूदा स्मृति की समीक्षा करें;
• दोहराए गए सामग्री को एकीकृत करें;
• कई समान अनुभवों को एक अधिक स्पष्ट सिद्धांत में संक्षिप्त करें;
• Delete content that has been proven incorrect or outdated.

लक्ष्य अधिक से अधिक फ़ाइलों को इकट्ठा करना नहीं, बल्कि कम संख्या में, अधिक सारगर्भित ज्ञान प्राप्त करना है।

बहुत से लोग इस चरण को पूरी तरह से छोड़ देते हैं, क्योंकि यह तुरंत कोई दृश्यमान नई क्षमता नहीं लाता, बल्कि भविष्य की समस्याओं को रोकने में मदद करता है।

लेकिन इसलिए कि इसमें तुरंत प्रतिक्रिया नहीं है, इसे स्पष्ट रूप से शेड्यूल में शामिल किया जाना चाहिए, और इंतजार नहीं किया जाना चाहिए कि कोई ऐसा समय आए जब किसी को पता चले कि स्मृति फोल्डर प्रबंधित करना मुश्किल हो गया है।

वास्तविकता में, ऐसी "बाद में जब समय मिले तो व्यवस्थित करूँगा" वाली कार्यों को अक्सर कभी नहीं किया जाता, जब तक कि प्रणाली का प्रदर्शन बहुत सारी विरोधी, अप्रचलित और आंशिक रूप से संबंधित स्मृतियों द्वारा संदर्भ खिड़की के लिए प्रतिस्पर्धा के कारण गिरने लगता।

प्रत्येक नए कार्य की शुरुआत में, चक्र पहले स्मृति फ़ाइल में एक वाक्य सारांश को स्कैन करे, जिससे यह निर्धारित हो सके कि कौन से अनुभव वर्तमान कार्य के संबंध में वास्तव में प्रासंगिक हैं, और केवल इन संबंधित सामग्री को ही लोड करे।

इसके अलावा, प्रणाली को स्पष्ट रूप से आवश्यकता है कि यदि मौजूदा स्मृति में वर्तमान कार्य के लिए कोई भी सामग्री उपलब्ध नहीं है, तो सीधे यह बताएं कि कोई उपयुक्त अनुभव उपलब्ध नहीं है।

न तो यह मानें कि क्योंकि एक स्मृति प्रणाली पहले से मौजूद है, इसलिए पुराने अनुभवों को एक पूरी तरह से अलग नए समस्या पर जबरन लागू किया जा सकता है।

अगला कदम यह तय करना है कि यह चक्र बिना मानवीय शुरुआत के कब स्वचालित रूप से चलेगा।

ट्रिगर तरीके में शामिल हो सकते हैं:

• क्रॉन टाइमर टास्क;
• File Change Listener;
• कैलेंडर-आधारित चक्रीय ट्रिगर;
• जब कोई बाहरी घटना या स्थिति बदलती है, तो यह ट्रिगर होता है।

यह चरण एक ऐसी प्रणाली को बदल देगा जिसे आप केवल मैन्युअल रूप से शुरू कर सकते हैं, और इसे एक ऐसी प्रणाली में बदल देगा जो आपकी नींद के दौरान भी चलती रहेगी।

विचित्र बात यह है कि यह अक्सर सूची में सबसे आसान चरण होता है, लेकिन बहुत से लोग जो अन्य घटकों को पूरा कर चुके हैं, फिर भी इस चरण को लागू नहीं करते।

चार फ़ॉल्ट मोड्स के खिलाफ जांच करने के बाद ही किसी महत्वपूर्ण कार्य के लिए लूप का उपयोग करें।

परीक्षण 1: अपूर्ण कार्य

एक वास्तविक रूप से असाध्य कार्य संस्करण दें, ताकि प्रबंधक को अनंत लूप के बजाय रोकने की शर्तों के अनुसार बाहर निकलने की पुष्टि की जा सके।

अगर एक चक्र केवल उन कार्यों पर परीक्षण किया गया है जो सफलतापूर्वक पूरे किए जा सकते हैं, तो इसने कभी स्वयं को उपयुक्त विफलता की क्षमता रखने वाला साबित नहीं किया है।

परीक्षण 2: तर्कसंगत लगता है लेकिन वास्तव में गलत परिणाम

एक ऐसा आउटपुट प्रदान करें जिसमें आप जानते हैं कि सूक्ष्म त्रुटियाँ हैं।

यह परिणाम बहुत अच्छी तरह से पढ़ा जाना चाहिए, लेकिन इसमें एक ऐसी कृत्रिम रूप से डाली गई तथ्य या तर論क त्रुटि होनी चाहिए।

देखें कि समीक्षक समस्याएँ ढूंढ पाता है या केवल इसलिए कि सामग्री तर्कसंगत लगती है, उसे स्वीकार कर लेता है।

टेस्ट 3: बिल्डर्स और रिव्यूअर्स द्वारा मॉडल के अंधे क्षेत्रों को साझा किया जाता है

यदि निर्माता और समीक्षक एक ही नींव वाले मॉडल का उपयोग करते हैं, तो उन एक ऐसी त्रुटि को जानबूझकर शामिल किया जा सकता है जो इस मॉडल द्वारा अक्सर की जाती है, और देखा जा सकता है कि क्या समीक्षक इसे छोड़ देगा।

यदि समीक्षक और निर्माता के पास समान अंधबिंदु हैं, तो चरण 6 में डिज़ाइन किया गया भूमिका पृथक्करण अर्थहीन हो जाता है।

टेस्ट चार: सबसे खराब स्थिति में चलाने की लागत की गणना करें

सबसे अधिक संशोधनों के आधार पर, सबसे महंगे मॉडल कॉल और तर्कसंगत सीमा में सबसे लंबे आउटपुट का उपयोग करके, इस लूप की खराब स्थिति में कितनी लागत खर्च होगी, यह गणना करें।

और खुद से ईमानदारी से पूछें:

अगर यह डिजिटल संख्या वास्तविक बिल पर दिखाई दे, तो क्या आपको असहज महसूस होगा?

इन चार परीक्षणों को विश्वास चक्र द्वारा महत्वपूर्ण कार्यों को संभालने से पहले पूरा करने से अधिकांश संभावित समस्याओं का पहले से ही पता चल जाता है।

अन्यथा, ये समस्याएं संभवतः पहली बार ग्राहकों या प्रबंधकों के सामने आएंगी, या सीधे आपके बिल पर दिखाई देंगी, न कि आपके द्वारा स्वयं नियंत्रित परीक्षण में।

जब चक्र स्थिर रूप से चल रहा हो, तो सभी किरदारों को एक ही आपका पसंदीदा मॉडल न उपयोग करने दें।

अलग-अलग भूमिकाएँ चक्र में मॉडल क्षमताओं की अलग-अलग आवश्यकताएँ रखती हैं।

बिल्डर

बिल्डर्स को आमतौर पर सबसे शक्तिशाली मॉडल का उपयोग करना चाहिए।

क्योंकि यह मुख्य जटिल तर्क और सामग्री उत्पादन का कार्य करता है। यदि यहाँ कम क्षमता वाला मॉडल उपयोग किया जाता है, तो पहले संस्करण की गुणवत्ता कम हो जाएगी, और बाद में अधिक संशोधन चक्रों की आवश्यकता हो सकती है।

अंततः, निम्न गुणवत्ता वाले प्रारंभिक रूप को सुधारने में लगने वाली लागत, शुरू से ही अधिक मजबूत मॉडल का उपयोग करने की लागत से अधिक हो सकती है।

रिव्यूअर

रिव्यूअर को स्पष्ट मानदंडों के आधार पर जांच करने की जिम्मेदारी होती है, जिसके लिए आमतौर पर बहुत अधिक रचनात्मकता की आवश्यकता नहीं होती।

जब मानदंड पर्याप्त रूप से विशिष्ट होते हैं, तो एक छोटे, कम लागत वाले और तेज़ मॉडल भी समीक्षा कार्य को विश्वसनीयता से पूरा कर सकते हैं।

यदि एक छोटा मॉडल अत्यंत स्पष्ट जांच सूची के आधार पर काम करता है, तो इसकी स्थिरता बड़े मॉडल के करीब हो सकती है, लेकिन लागत और लेटेंसी दोनों काफी कम होती हैं।

मैनेजर

मैनेजर केवल पहले से लिखे गए नियमों के अनुसार रूटिंग करता है और लगभग कभी सबसे महंगे मॉडल का उपयोग नहीं करता।

इसका कार्य पहले से परिभाषित तर्क को निष्पादित करना है, खुली निष्कर्ष निकालना नहीं।

इसके अलावा, निर्माता और समीक्षक के प्रदर्शन के आधार पर निर्भर किए बिना, प्रत्येक इटरेशन में प्रबंधक कम से कम एक बार चलता है, इसलिए इसकी एकल कॉल लागत विशेष रूप से महत्वपूर्ण है।

उचित स्तरीकृत कॉन्फ़िगरेशन सामान्यतः होता है:

• Strong model is responsible for building;
• सस्ते और स्थिर मॉडल नियमित समीक्षाओं के लिए जिम्मेदार हैं;
• कम लागत वाले मॉडल या नियम-आधारित प्रोग्राम रूटिंग और प्रबंधन के लिए जिम्मेदार होते हैं।

सही मॉडल भूमिका मेल आमतौर पर साइक्लिक सिस्टम में वास्तविक रूप से महत्वपूर्ण लागत बचत लाता है।

बहुत से लोग मानते हैं कि लागत नियंत्रित करने का अर्थ है चक्रों या संशोधनों की संख्या कम करना। वास्तव में, अधिक प्रभावी तरीका यह है कि मॉडल की लागत को चक्र में प्रत्येक भूमिका की वास्तविक कठिनाई के साथ मेल खाने दिया जाए।

पहला चक्र सफल होने के बाद, लोग आसानी से एक साथ कई चक्र बनाने की कोशिश करने लगते हैं और पांच अलग-अलग कार्यों को समानांतर रूप से संभालते हैं।

हालांकि वर्तमान आर्किटेक्चर इस विस्तार को समर्थन कर सकता है, लेकिन इस इच्छा को संयमित रखना चाहिए।

आपको पहले चक्र को पर्याप्त समय तक स्थिर रूप से चलने देना चाहिए, जब तक कि आपको इसके प्रत्येक आउटपुट की गहन जांच करने की आवश्यकता नहीं रह जाती।

यह किसी ऐसे प्रदर्शन की बात नहीं है जो एक बार सभी लोगों द्वारा गंभीरता से देखे जाने पर सफल हो गया, बल्कि यह इस बात की बात है कि यह वास्तविक संचालन के बाद भी मानव द्वारा यादृच्छिक जांच के माध्यम से लगातार सफल होता रहता है।

केवल इस अवस्था को प्राप्त करने के बाद ही दूसरा चक्र बनाना शुरू करना चाहिए।

दूसरा चक्र एक ऐसा कार्य संभालना चाहिए जो पहले चक्र से स्पष्ट रूप से भिन्न हो।

इससे ही यह सत्यापित होता है कि नींव की संरचना वास्तविक रूप से सार्वभौमिक है, और केवल एक ही कार्य के लिए बार-बार सूक्ष्म समायोजन का परिणाम नहीं है।

जब आप एक साथ कई चक्र चलाते हैं, तो प्रत्येक चक्र को अलग-अलग देखने के बजाय, सभी चक्रों की लागत और रोकने की शर्तों के ट्रिगर होने का एकीकृत मॉनिटरिंग दृश्य स्थापित करना आवश्यक है।

अकेले देखने पर, एक चक्रीय कार्य बजट पूरी तरह से तर्कसंगत हो सकता है।

लेकिन यदि दस चक्र प्रत्येक अपने बजट के भीतर कार्य करते हैं, तो उनकी कुल लागत अभी भी एक आश्चर्यजनक स्तर तक पहुँच सकती है।

चूंकि प्रत्येक चक्र का स्वतंत्र डेटा सामान्य दिखता है, इस जोखिम का पता अक्सर सामूहिक बिल आने तक नहीं चलता।

सफलतापूर्वक पूर्ण किए गए कार्यों के अलावा, प्रत्येक रोकने की शर्त के ट्रिगर होने को विशेष रूप से रिकॉर्ड किया जाना चाहिए।

अगर कोई चक्र अक्सर अधिकतम संशोधन सीमा को स्पर्श करता है, जबकि अन्य चक्र इस स्थिति में कम आते हैं, तो यह संकेत हो सकता है कि "यह कार्य विशेष रूप से कठिन है" नहीं, बल्कि:

• रिव्यू मानदंडों की व्यवस्था अनुचित है;
• समीक्षक बहुत कठोर हैं, जिससे कोई भी परिणाम स्वीकार नहीं हो पाता;
• सिस्टम ने गलत वस्तुनिष्ठ आधार की जांच की;
• The definition itself has issues.

अगर केवल सफल परिणामों का पीछा किया जाए और प्रत्येक मानव अपग्रेड को एक दूसरे से स्वतंत्र घटनाओं के रूप में मान लिया जाए, तो इस डिजाइन स्तरीय पैटर्न का पता नहीं चलेगा।

सोच के परिवर्तन के वास्तविक रूप से पूरा हो जाने का सबसे स्पष्ट मानदंड यह है कि आपके दैनिक ध्यान केंद्रित सूचकांक बदल गए हैं।

प्रॉम्प्ट ऑपरेटर का ध्यान है:

• आज कितने प्रभावी प्रॉम्प्ट्स लिखे गए;
• कौन सा प्रॉम्प्ट सबसे अच्छा काम करता है;
• How to write prompts more cleverly.

सिस्टम डिजाइनर दिलचस्पी रखते हैं:

• वर्तमान में कितने साइकिल चल रहे हैं;
• प्रत्येक चक्र की विश्वसनीयता क्या है;
• सिस्टम ने खुद के लिए कितना समय रिलीज़ किया;
• कौन से कार्य अब मानवीय निगरानी की आवश्यकता नहीं करते।

अगर आप अभी भी अपनी उत्पादकता को इनपुट किए गए प्रॉम्प्ट्स की संख्या से माप रहे हैं, तो चाहे तकनीकी रूप से कितने भी चक्र स्थापित किए गए हों, पहले कदम में मांगी गई सोच का परिवर्तन अभी तक पूरी तरह से पूरा नहीं हुआ है।

अंतिम कदम अब पूरी तरह से आपके अपने सिस्टम के बारे में नहीं है।

यह आपकी इस विधि को वास्तव में समझने की पुष्टि करने के लिए उपयोग किया जाता है।

आपको एक अन्य व्यक्ति को पाँच बुनियादी क्रियाओं को जटिल शब्दावली के बिना समझाना होगा:

पहचान, हस्तांतरण, प्रमाणीकरण, स्थायीकरण, नियोजन।

अगर आप केवल इन पाँच क्रियाओं और पिछले चरणों का उपयोग करके किसी और को उसकी पहली चक्रीय प्रक्रिया बनाने में सक्षम होते हैं, तो आपने इस मार्गदर्शिका में वर्णित वास्तविक परिवर्तन पूरा कर लिया है।

तुम अब उस व्यक्ति नहीं हो जो चक्र के अंदर रहकर लगातार अगला आदेश दे रहा हो।

आप चक्र के बाहर खड़े हो गए हैं, जो प्रणाली का डिज़ाइन करते हैं और इसे स्वयं चलते हुए देखते हैं।

चरणों को छोड़ने के बाद धीरे-धीरे जमा होने वाली चार लागतें

लेख के अंत में, एक चेतावनी देना आवश्यक है।

इस रोडमैप के चरणों को छोड़ना अक्सर तुरंत सिस्टम क्रैश का कारण नहीं बनता।

इसकी विफलता आमतौर पर शांति से होती है, और लंबे समय तक अदृश्य रहती है, जब तक कि समस्या काफी गंभीर हो जाए।

जब आप चरण 6 और चरण 7 को छोड़ देते हैं, और वास्तविक स्वतंत्र समीक्षक नहीं बनाते हैं और विश्वसनीय वस्तुनिष्ठ आधार प्रदान नहीं करते हैं, तो ऋण की पुष्टि जमा होने लगती है।

चक्र अभी भी सामान्य रूप से काम कर रहा प्रतीत होता है, क्योंकि उत्पादित परिणाम "अच्छे दिखते हैं"।

जब तक किसी गलती का दहलीज दर्ज़ करने वाले द्वारा दर्ज़ किए गए दर्ज़ के दौरान दहलीज़ नहीं हो जाता, तब तक आपको एहसास नहीं होता कि सिस्टम शुरू से ही परिणाम की सही पुष्टि नहीं कर रहा था।

जब आप 20वें कदम को छोड़ देते हैं, तो समझ में गिरावट आ सकती है।

आप अभी भी अपने द्वारा पहले बनाए गए चक्र को चला रहे हैं, लेकिन अब आप प्रत्येक घटक के मौजूद होने का कारण स्पष्ट रूप से समझा नहीं पा रहे हैं, और प्रणाली की खराबी के समय प्रभावी ढंग से डीबग नहीं कर पा रहे हैं।

कारण यह है कि आपने कभी इस आर्किटेक्चर के पीछे की तर्कशक्ति को वास्तविक रूप से अंतर्निहित नहीं किया है।

अगर पहला कदम कभी पूरा नहीं हुआ, तो ज्ञानात्मक शरणागति होती है।

हालांकि सत्यापन प्रणाली लंबे समय तक चलने के बाद अपनी विश्वसनीयता साबित कर चुकी है, आप आदत के कारण हर आउटपुट की अभी भी हाथ से जांच करते हैं।

यह व्यवहार सावधानी भरा लगता है, लेकिन वास्तव में प्रणाली बनाने के पूरे उद्देश्य को रद्द कर देता है।

अगर आप 10वें चरण को छोड़ देते हैं और लूप के लिए कोई वास्तविक रोकने की शर्त नहीं बनाते हैं, तो टोकन की खपत और कॉल लागत अनियंत्रित हो सकती है।

आप अक्सर तब तक समस्या का एहसास नहीं करते जब तक कि सिस्टम बिल्कुल बेकाबू न हो जाए, बल्कि अंतिम बिल आने तक पता नहीं चलता कि चक्र ने कई अनावश्यक कॉल किए हैं।

ऊपर उल्लिखित सभी लागतों से बचा जा सकता है।

उनसे बचने का तरीका, हमेशा एक ही अनुशासन है:

क्रम में बनाएं, जो कदम अच्छे नहीं लगते उन्हें छोड़ें नहीं।

जो सबसे उबाऊ होते हैं, वे ही अक्सर सचमुच काम करते हैं:

• Clear completion definition;
• Reliable stop conditions;
• Verifiable objective evidence;
• Independent review mechanism.

इसके विपरीत, जो भाग अधिक आकर्षक लगते हैं—चतुर टिप्स, जटिल सिस्टम आर्किटेक्चर डायग्राम—वे लोगों के अनुमान के विपरीत बहुत कम महत्वपूर्ण होते हैं।

सिस्टम की वास्तविक गुणवत्ता तभी निर्धारित होती है, जब आपके द्वारा बनाया गया सिस्टम जानता हो:

• कब आप सही होते हैं;
• कब अपने आप में गलत होते हैं;
• कब रुकना अनिवार्य है।

This is the entire difference between a prompt operator and a system designer.

अंतर इस बात में नहीं है कि कौन अधिक बुद्धिमान है, या कौन अधिक शानदार प्रॉम्प्ट लिख सकता है।

असली अंतर यह है कि क्या आपके पास पर्याप्त अनुशासन है, जिससे आप उन थकाने वाले, छोड़ दिए जाने वाले, लेकिन प्रणाली की विश्वसनीयता निर्धारित करने वाले हिस्सों को गंभीरता से बना सकें।