लूप इंजीनियरिंग।
मूल लेखक: Addy Osmani
संकलन: Peggy, BlockBeats

संपादकीय टिप्पणी: AI कोडिंग एजेंट का उपयोग, 'मनुष्य द्वारा मैन्युअल रूप से प्रॉम्प्ट लिखना और कदम दर कदम कार्य आगे बढ़ाना' से 'मनुष्य द्वारा चक्र डिज़ाइन करना, ताकि सिस्टम एजेंट को निरंतर नियोजित कर सके' की ओर बदल रहा है। एडी ओसमैनी द्वारा वर्णित लूप इंजीनियरिंग, स्वचालित रूप से कार्यों की पहचान करने, कार्यों को आवंटित करने, परिणामों की जांच करने, प्रगति को रिकॉर्ड करने और अगला कदम निर्धारित करने वाली प्रक्रिया को स्थापित करने पर केंद्रित है।

यह चक्र लगभग पाँच मॉड्यूल से बना है: Automations (समयबद्ध खोज और ट्रिजेशन कार्य), Worktrees (एकाधिक समानांतर विकास वातावरणों को अलग करना), Skills (प्रोजेक्ट ज्ञान और टीम अभ्यासों को संचित करना), Plugins/Connectors (GitHub, Linear, Slack, डेटाबेस आदि वास्तविक उपकरणों से जुड़ना), Sub-agents (निष्पादक और समीक्षक को अलग करना), और एक बाहरी मेमोरी परत, जैसे Markdown फ़ाइल या Linear बोर्ड, जो स्थिति और प्रगति को संग्रहीत करती है।

लूप इंजीनियरिंग का महत्व केवल “AI को कई चक्र चलाना” नहीं है, बल्कि इंजीनियर की निर्णय लेने की क्षमता को सिस्टम डिज़ाइन में पहले से शामिल करना है। लूप विकासकों के कार्य की दक्षता को महत्वपूर्ण रूप से बढ़ा सकते हैं, लेकिन वे सत्यापन, समझ और निर्णय लेने की जगह नहीं ले सकते। वास्तविक जोखिम लूप का उपयोग करने में नहीं, बल्कि लूप को कोड और सिस्टम को समझने से बचने का बहाना बनाने में है। AI के साथ प्रोग्रामिंग में सहयोग की भविष्य की मुख्य क्षमता, केवल एक अच्छा Prompt लिखना नहीं, बल्कि विश्वसनीय, सत्यापन योग्य और स्थायी रूप से संचालित Agent वर्कफ्लो का डिज़ाइन करना होगा।

नीचे मूल पाठ है:

लूप इंजीनियरिंग (Loop engineering) आपके उस भूमिका को बदल रही है जिसमें आप "एजेंट को प्रॉम्प्ट लिखते हैं"। आपको एक ऐसा सिस्टम डिज़ाइन करना होगा जो आपके लिए एजेंट को प्रॉम्प्ट दे। यहाँ लूप (loop) को एक पुनरावर्ती लक्ष्य के रूप में समझा जा सकता है: आप एक उद्देश्य परिभाषित करते हैं, और AI उस कार्य को पूरा करने तक लगातार दोहराता रहता है। इसमें लगभग पाँच घटक होते हैं, और Claude Code और Codex अब इन पाँचों घटकों को समर्थन करते हैं।

मुझे विश्वास है कि यही हमारा भविष्य हो सकता है कि हम कोडिंग एजेंट्स के साथ सहकार्य करेंगे। हालाँकि, यह सब अभी शुरुआती चरण में है, और मैं संदेह भी रखता हूँ। आपको टोकन लागत के साथ सावधानी बरतनी चाहिए, क्योंकि विभिन्न उपयोग पैटर्न के आधार पर लागत में बहुत बड़ा अंतर हो सकता है, खासकर यदि आप 'टोकन समृद्ध' हैं या 'टोकन संकुचित'। आपको किसी ऐसे मैकेनिज्म की आवश्यकता होगी जो गुणवत्ता में कमी न होने दे। 'AI अपशिष्ट उत्पादन' (slop) के बारे में चिंताएँ भी तर्कसंगत हैं। हालाँकि, आइए देखते हैं कि यह सचमुच क्या है।

@steipete ने हाल ही में कहा था: "आपको अब कोडिंग एजेंट्स को प्रॉम्प्ट नहीं लिखना चाहिए। आपको कुछ लूप डिज़ाइन करने चाहिए जो आपके एजेंट्स को प्रॉम्प्ट करें।" इसी तरह, Anthropic के Claude Code के प्रमुख @bcherny ने कहा: "मैं अब Claude को प्रॉम्प्ट नहीं कर रहा हूँ। मेरे पास कई लूप चल रहे हैं जो Claude को प्रॉम्प्ट करते हैं और स्वयं अगला कदम क्या होना चाहिए, यह निर्णय लेते हैं। मेरा काम सिर्फ लूप लिखना है।"

तो, इसका मतलब क्या है?

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

अब आप एक छोटे सिस्टम का निर्माण कर रहे हैं: यह स्वयं कार्य खोजता है, कार्यों को आवंटित करता है, परिणामों की जांच करता है, पूर्णता को रिकॉर्ड करता है, और अगला कदम क्या उठाना है, यह निर्णय लेता है। अर्थात, आप इस सिस्टम को एजेंट को चलाने के लिए स्वयं को सक्षम बना रहे हैं, न कि खुद हर बार इसे प्रॉम्प्ट करके। मैं पहले इसके 'निकट संबंधी'—एजेंट हार्नेस इंजीनियरिंग (एजेंट रनटाइम फ्रेमवर्क इंजीनियरिंग)—लिख चुका हूँ, जो एकल एजेंट के लिए रनटाइम वातावरण बनाना है; और फैक्टरी मॉडल, जो सॉफ्टवेयर बनाने का सिस्टम है। लूप इंजीनियरिंग harness के ऊपर की परत है। यह harness की तरह है, लेकिन इसे टाइमर पर चलाया जाता है, यह छोटे सहायकों को जन्म देता है, और स्वयं को पोषित करता है।

मुझे आश्चर्य हुआ कि अब यह केवल "उपकरण स्तर" की समस्या नहीं रह गई है। एक साल पहले, अगर आपको एक लूप चाहिए था, तो आपको बहुत सारे bash स्क्रिप्ट लिखने पड़ते थे, और इन स्क्रिप्ट्स की हमेशा देखभाल करनी पड़ती थी। यह आपकी अपनी चीज़ थी, और केवल आपके लिए ही थी। अब, ये घटक सीधे उत्पाद में एम्बेडेड हो गए हैं। स्टेनबर्गर द्वारा सूचीबद्ध क्षमताएँ लगभग प्रत्येक Codex ऐप में मेल खाती हैं, और Claude Code में भी लगभग समान रूप से मेल खाती हैं। जब आप समझ जाते हैं कि उनका स्वरूप एक समान है, तो आपको यह सोचने की जरूरत नहीं पड़ती कि किस उपकरण का उपयोग करें, बल्कि आप एक लूप का डिज़ाइन करने लगते हैं: चाहे आप किसी भी उपकरण में बैठे हों, वह चलता रहे।

पाँच घटक, और कुछ नोट्स

एक लूप को पाँच चीजों की आवश्यकता होती है, और एक जगह जहाँ जानकारी को याद रखा जा सके। मैं पहले उन्हें सूचीबद्ध करता हूँ, फिर उनका एक-एक करके मिलान करता हूँ।

पहला, Automations (ऑटोमेशन कार्य): निर्धारित समय पर ट्रिगर होकर स्वचालित रूप से खोज और रीडायरेक्ट करते हैं।

दूसरा, Worktrees (कार्य वृक्ष): दो समानांतर कार्यरत एजेंट्स को एक दूसरे के फाइल्स पर कदम रखने से रोकता है।

तीसरा, कौशल (Skills): प्रोजेक्ट ज्ञान को लिखकर रखें, ताकि एजेंट हर बार अनुमान लगाने के बजाय इसका उपयोग कर सके।

चौथा, प्लगइन और कनेक्टर: स्मार्ट एजेंट को आपके द्वारा पहले से उपयोग किए जा रहे टूल्स से जोड़ें।

पांचवां, सब-एजेंट्स (सब इंटेलिजेंट एजेंट्स): एक योजना प्रस्तावित करने के लिए, दूसरा योजना की जांच करने के लिए।

फिर छठा चीज़: memory (याददाश्त)। यह एक Markdown फ़ाइल हो सकती है, या एक Linear बोर्ड, या कोई भी ऐसी जगह जो एकल संवाद से बाहर हो और 「पूर्ण किए गए कार्य」 और 「अगले कदम」 को सहेजे। यह इतना सरल लगता है कि ऐसा लगता है कि यह महत्वपूर्ण नहीं है, लेकिन यह प्रत्येक लंबे समय तक चलने वाले बुद्धिमान एजेंट द्वारा उपयोग की जाने वाली एक ही तकनीक है। मैंने long-running agents में इसे विस्तार से लिखा है: मॉडल प्रत्येक चलन के बीच भूल जाता है, इसलिए याददाश्त को संदर्भ में नहीं, बल्कि डिस्क पर सहेजना होगा। एजेंट भूल सकते हैं, लेकिन कोड रिपॉजिटरी नहीं।

अब, दोनों उत्पादों में ये पाँच घटक हैं।

उनके नाम कुछ जगहों पर अलग हैं, लेकिन क्षमताएँ मूल रूप से एक ही बात हैं। नीचे मैं एक-एक करके समझाता हूँ, क्योंकि सच बताऊँ तो, एक लूप का अंततः स्थिर रूप से काम करना या चुपचाप सब जगह रिसना, इसका फर्क विस्तार से होता है।

ऑटोमेशन वह चीज़ हैं जो loop को वास्तविक loop बनाती हैं, न कि आपके द्वारा कभी-कभी हाथ से चलाए गए एकल कार्य। Codex ऐप में, आप Automations टैब पर एक ऑटोमेशन बना सकते हैं, प्रोजेक्ट का चयन कर सकते हैं, इसे चलाने के लिए प्रॉम्प्ट का चयन कर सकते हैं, इसकी आवृत्ति निर्धारित कर सकते हैं, और यह तय कर सकते हैं कि यह आपके स्थानीय checkout में चलेगा या बैकग्राउंड worktree में। जिन रनिंग परिणामों में समस्याएँ पाई गईं, वे Triage inbox (विभाजित इनबॉक्स) में जाते हैं, जबकि समस्याओं के बिना किए गए रन स्वचालित रूप से आर्काइव हो जाते हैं, जो अच्छी बात है। OpenAI के अंदर भी इसका उपयोग कुछ थकाने वाले किंतु आवश्यक कार्यों के लिए किया जाता है, जैसे दैनिक issue का विभाजन, CI विफलताओं के कारणों का सारांश, commit सारांश लिखना, और पिछले सप्ताह किसी द्वारा पेश किए गए bug का पीछा करना। ऑटोमेशन कार्य skill को भी कॉल कर सकते हैं, इसलिए आप पुनरावृत्ति होने वाले कार्यों को सुलभ बना सकते हैं: $skill-name को ट्रिगर करें, न कि सभी प्रोसीजर को प्रत्येक समय पर पेस्ट करें, जिसे कोई भविष्य में अपडेट नहीं करेगा।

Claude Code भी इसी परिणाम को प्राप्त कर सकता है, केवल पथ अलग है: यह स्केड्यूलिंग और hooks के माध्यम से कार्य करता है। आप /loop का उपयोग करके एक निश्चित अंतराल पर एक प्रॉम्प्ट या कमांड चला सकते हैं, या एक cron टास्क शेड्यूल कर सकते हैं, या स्मार्ट एजेंट के जीवनचक्र के कुछ बिंदुओं पर hooks का उपयोग करके shell कमांड ट्रिगर कर सकते हैं। यदि आप चाहते हैं कि यह आपके लैपटॉप को बंद करने के बाद भी चलता रहे, तो आप पूरी प्रक्रिया GitHub Actions पर पुश कर सकते हैं। विचार पूरी तरह समान है: आप एक स्वायत्त कार्य परिभाषित करते हैं, इसे एक गति प्रदान करते हैं, और खोजे गए परिणामों को आपके सामने लाते हैं, बजाय इसके कि आप सभी जगह जाकर जाँचें।

एक और महत्वपूर्ण सेशन-अंतर्गत प्राइमिटिव है, जो इस लेख के वास्तविक चर्चा के केंद्र के बहुत करीब है। /loop नियमित अंतराल पर दोहराया जाता है; /goal तब तक लगातार चलता रहता है जब तक आपके द्वारा निर्दिष्ट किया गया कोई शर्त सच्ची नहीं हो जाती। प्रत्येक चक्र के बाद, एक अलग छोटे मॉडल द्वारा यह निर्णय लिया जाता है कि क्या कार्य पूरा हो गया है, इसलिए कोड लिखने वाला एजेंट अपने ही स्कोर को मूल्यांकन नहीं करता। आप इसे एक शर्त दे सकते हैं, जैसे 'test/auth में सभी परीक्षण सफल हो गए हैं और lint साफ है', और फिर चले जा सकते हैं। Codex में भी समान क्षमता है, जिसे भी /goal कहा जाता है। यह कई चक्रों में काम करता रहता है, जब तक कि कोई सत्यापनयोग्य रुकने की शर्त पूरी न हो जाए, और प्रतिबंधित करने, पुनः प्रारंभ करने और साफ करने का समर्थन करता है। एक ही प्राइमिटिव, दोनों उपकरणों में मौजूद है। यह मूलतः इस लेख में बार-बार दोहराए जाने वाले पैटर्न के समान है।

इसलिए, Automations कार्यों को सामने लाने के लिए जिम्मेदार हैं। loop का शेष हिस्सा इन कार्यों को संभालने के लिए जिम्मेदार है।

जब आप एक से अधिक एजेंट चलाते हैं, तो फाइल संघर्ष विफलता का कारण बन जाता है। दो एजेंट एक ही फाइल पर एक साथ लिखना, मूलतः दो इंजीनियरों के बिना संवाद के एक ही पंक्ति को संशोधित करने जितना समस्याग्रस्त है। git worktree इस समस्या को हल कर सकता है। यह एक स्वतंत्र शाखा पर एक अलग कार्य निर्देशिका होती है, लेकिन एक ही कोड रिपॉजिटरी के इतिहास को साझा करती है, इसलिए एक एजेंट के परिवर्तन भौतिक रूप से दूसरे एजेंट के checkout को स्पर्श नहीं कर सकते।

Codex में अंतर्निहित रूप से worktree समर्थन है, इसलिए कई थ्रेड्स एक ही रिपॉजिटरी को एक साथ संसाधित कर सकते हैं बिना किसी टकराव के। Claude Code भी git worktree के माध्यम से समान अलगाव प्राप्त कर सकता है: आप --worktree फ्लैग का उपयोग करके एक स्वतंत्र checkout में एक सत्र खोल सकते हैं, या subagent पर isolation: worktree सेट कर सकते हैं, ताकि प्रत्येक सबएजेंट को एक नया checkout मिले और समाप्ति के बाद स्वचालित रूप से साफ़ हो जाए। मैंने the orchestration tax में इसके मानवीय पहलू के बारे में लिखा है: worktrees मशीनी स्तर पर टकराव को दूर कर सकते हैं, लेकिन आप अभी भी सीमा हैं। आप कितने एजेंट्स को एक साथ चला सकते हैं, इसका निर्धारण उपकरणों द्वारा नहीं, बल्कि आपके review bandwidth (समीक्षा बैंडविड्थ) द्वारा होता है।

स्किल एक ऐसा मैकेनिज्म है जो आपको हर सेशन में एक ही सेट के प्रोजेक्ट कॉन्टेक्स्ट को फिर से समझाने की आवश्यकता को खत्म करता है। दोनों टूल्स एक ही फॉर्मेट का उपयोग करते हैं: एक फोल्डर, जिसमें SKILL.md होता है, जिसमें निर्देश और मेटाडेटा सहेजे जाते हैं; इसके अलावा, वैकल्पिक स्क्रिप्ट, संदर्भ और संसाधन फाइलें भी हो सकती हैं। Codex आपके द्वारा $ या /skills का उपयोग करने पर एक स्किल चलाता है, और जब आपका कार्य उस स्किल के विवरण से मेल खाता है, तो यह स्वचालित रूप से भी चलता है। इसीलिए एक संक्षिप्त, सादा विवरण, अक्सर एक बुद्धिमान या शोभायमान विवरण की तुलना में बेहतर होता है। Claude Code भी इसी तरह करता है, मैंने agent skills में इस पैटर्न को लिखा है।

कौशल वह जगह भी हैं जहाँ इरादे आपको बार-बार थका नहीं रहे होते। मैंने intent debt में कहा था कि प्रत्येक संवाद की शुरुआत में एजेंट कोल्ड स्टार्ट होता है, और जब तक आपके इरादे में कोई खाली स्थान है, वह उसे आत्मविश्वास के साथ अनुमान लगाकर भर देता है। कौशल इन इरादों को बाहरी रूप में लिखने का काम करते हैं: प्रोजेक्ट की समझ, बिल्डिंग स्टेप्स, “हम ऐसा इसलिए नहीं करते क्योंकि पहले ऐसा हुआ था” आदि, सभी को एक बार में एक ऐसी जगह पर लिख दिया जाता है जिसे प्रत्येक बार एजेंट चलाने पर पढ़ता है। कौशल के बिना, हर लूप के प्रत्येक चक्र में आपके पूरे प्रोजेक्ट को शून्य से पुनः निष्कर्षित करना पड़ता है; कौशल के साथ, यह कुछ इस तरह काम करता है जैसे साधारण ब्याज की तरह।

एक बात स्पष्ट करना आवश्यक है: skill फॉर्मेट लिखने का तरीका है, जबकि plugin वितरण का तरीका है। जब आप एक skill को कई कोड रिपॉजिटरी के बीच साझा करना चाहते हैं या कई skill को एक साथ पैकेज करना चाहते हैं, तो आप उन्हें एक plugin में पैकेज करते हैं। Codex ऐसा ही करता है, Claude Code भी ऐसा ही करता है।

एक केवल फाइल सिस्टम को देखने वाला लूप, एक छोटा लूप है। Connectors MCP के आधार पर बनाए गए हैं, जो एजेंट को आपके issue tracker को पढ़ने, डेटाबेस क्वेरी करने, staging API को कॉल करने या Slack में संदेश भेजने की अनुमति देते हैं। Codex और Claude Code दोनों MCP को सपोर्ट करते हैं, इसलिए आप जिस एक के लिए connector लिखते हैं, वह आमतौर पर दूसरे में भी काम करता है। Plugins connectors और skills को एक साथ पैकेज करते हैं, ताकि आपके साथी पूरी कॉन्फ़िगरेशन को एक साथ इंस्टॉल कर सकें, और पूरी चीज़ को याद से फिर से बनाने की जगह।

यही अंतर है कि "एक एजेंट आपको बताता है 'यह ठीक करने का तरीका है'" और "एक लूप स्वयं PR खोलता है, Linear ticket से जोड़ता है, और CI सफल होने के बाद चैनल को सूचित करता है" के बीच। Connectors महत्वपूर्ण हैं क्योंकि वे loop को आपके वास्तविक वातावरण में कार्रवाई करने की अनुमति देते हैं, केवल यह बताने के बजाय कि "अगर मैं कर सकता, तो मैं ऐसा करता।"

एक लूप में, सबसे उपयोगी संरचनात्मक डिज़ाइन यह है कि “लिखने वाले” और “जाँचने वाले” को अलग कर दें। कोड लिखने वाला मॉडल अपने ही कार्य को अधिक उदारता से ग्रेड करने में आसानी से आत्मसात कर लेता है। एक अलग निर्देशों के साथ, कभी-कभी अलग मॉडल का उपयोग करने वाला एजेंट, पहले एजेंट द्वारा आत्म-विश्वास के बाद नज़रअंदाज किए गए मुद्दों को पकड़ सकता है।

Codex केवल तभी subagents उत्पन्न करेगा जब आप इसका अनुरोध करें, जो समानांतर रूप से चलेंगे और फिर परिणामों को एक उत्तर में मिला देंगे। आप .codex/agents/ में TOML फ़ाइल का उपयोग करके अपने खुद के agents को परिभाषित कर सकते हैं: प्रत्येक agent के पास नाम, विवरण, निर्देश, और वैकल्पिक मॉडल और तर्क तीव्रता होती है। इसलिए, आपका सुरक्षा समीक्षक एक उच्च तीव्रता वाले मजबूत मॉडल हो सकता है, जबकि आपका अन्वेषक एक तेज़, केवल-पढ़ने वाला हल्का मॉडल हो सकता है। Claude Code भी .claude/agents/ में subagents और agent teams के माध्यम से समान क्षमता प्रदान करता है, जिससे कई agents एक-दूसरे के बीच कार्य स्थानांतरित कर सकते हैं। दोनों के सबसे सामान्य विभाजन हैं: एक agent अन्वेषण करता है, एक agent कार्यान्वयन करता है, और एक agent स्पष्टीकरण के अनुसार सत्यापन करता है।

मैंने इस बात को दो बार पहले ही स्पष्ट किया है: एक बार code agent orchestra में, और दूसरी बार adversarial code review में। यह loop में विशेष रूप से महत्वपूर्ण है, क्योंकि loop तब भी चलता रहता है जब आप उसे नहीं देख रहे होते, इसलिए एक ऐसा verifier (वेरिफायर) जिस पर आप पूरी तरह भरोसा करते हैं, वही एकमात्र कारण है जिसके कारण आप चले जाने का साहस कर सकते हैं। Subagents वास्तव में अधिक token खर्च करते हैं, क्योंकि प्रत्येक agent अपने मॉडल कॉल और टूल कॉल करता है, इसलिए आपको उन्हें केवल उन स्थितियों में ही उपयोग करना चाहिए जहाँ 'दूसरी राय के लिए भुगतान करना सार्थक है'। यही Claude Code का /goal नीचे के स्तर पर करता है: loop के पूरा होने का निर्णय करने के लिए, काम पूरा करने वाले मॉडल के बजाय, एक नया मॉडल प्रयोग किया जाता है। अर्थात, यह 'निर्माता' और 'जाँचकर्ता' के पृथक्करण को स्टॉप कंडीशन पर ही लागू करता है।

एक लूप कैसा दिखता है

इन चीजों को एक साथ जोड़ें, एक अलग थ्रेड एक छोटे कंट्रोल पैनल में बदल जाएगी। नीचे मैं जिस स्ट्रक्चर का उपयोग करता हूँ, वह है।

प्रतिदिन सुबह, एक ऑटोमेशन कोड रिपॉजिटरी पर चलता है। इसका प्रॉम्प्ट एक ट्रायेज स्किल को कॉल करता है, जो कल के CI विफलताओं, खुले मुद्दों और हाल के कमिट्स को पढ़ता है और खोजों को एक मार्कडाउन फ़ाइल या लीनियर बोर्ड पर लिखता है। प्रत्येक संसाधित के योग्य समस्या के लिए, थ्रेड एक अलग worktree खोलता है, एक सब-एजेंट को पैरामिट करता है ताकि वह ठीक करने की योजना तैयार करे, और फिर दूसरा सब-एजेंट प्रोजेक्ट स्किल्स और मौजूदा परीक्षणों के आधार पर इस योजना की समीक्षा करता है।

कनेक्टर्स इस लूप को स्वयं PR खोलने और टिकट अपडेट करने की अनुमति देते हैं। कोई भी चीज जिसे लूप संभाल नहीं सकता, वह triage inbox में आ जाती है, जहाँ मैं इसका संभाल करूँगा। स्टेटस फाइल पूरी सिस्टम की रीढ़ है: यह याद रखती है कि क्या प्रयास किया गया, क्या सफल हुआ, और क्या अभी अपूर्ण है। इसलिए, अगले दिन की सुबह की रन आज के रुकने के स्थान से जारी रहती है।

ध्यान दें कि आपने वास्तव में क्या किया है। आपने केवल एक डिज़ाइन किया है। वे चरण आपके द्वारा अकेले प्रत्येक चरण के लिए प्रॉम्प्ट नहीं किए गए थे। यही Steinberger के उस कथन का वास्तविक संस्करण है। और, एक ही loop Codex पर भी चल सकता है और Claude Code पर भी, क्योंकि घटक स्वयं एक ही सेट हैं।

लूप अभी भी आपके लिए कुछ नहीं करेगा

Loop ने अपना कार्य बदल दिया है, लेकिन आपको कार्य से हटा नहीं देगा। वास्तव में, जैसे-जैसे loop मजबूत होता है, तीन समस्याएँ अधिक तीव्र हो जाती हैं, न कि आसान।

सत्यापन अभी भी तुम पर निर्भर है। एक बिना देखभाल के चलने वाला लूप, संभवतः बिना देखभाल के गलतियाँ कर रहा होता है। तुमने verifier sub-agent और मेकर को अलग किया है, ताकि लूप कह सके कि 「पूरा हो गया」—इस बात का कुछ मतलब हो। फिर भी, 「पूरा हो गया」 एक दावा है, न कि साबिती। मैं AI के युग में code review में हमेशा एक ही बात दोहराता हूँ: तुम्हारी जिम्मेदारी यह है कि तुम वह कोड प्रस्तुत करो, जिसे तुमने सत्यापित किया है।

अगर आप इसे नज़रअंदाज़ करते रहेंगे, तो आपकी अपनी समझ भी सड़ती रहेगी। जितना तेज़ी से लूप आपके द्वारा नहीं लिखे गए कोड को डिलीवर करता है, उतना ही आपकी वास्तविक समझ और सिस्टम में मौजूद वास्तविक चीज़ों के बीच का अंतर बढ़ता जाता है। यही comprehension debt (समझ का कर्ज) है। अगर आप लूप द्वारा उत्पादित चीज़ों को नहीं पढ़ते, तो एक चिकना लूप इस कर्ज को और तेज़ी से बढ़ाता है।

और हाँ, सबसे आरामदायक मुद्रा संभवतः सबसे खतरनाक मुद्रा भी है। जब लूप खुद चल सकता है, तो आपका अपना निर्णय लेना बंद करना और बस इसके द्वारा लौटाए गए किसी भी चीज को स्वीकार करना आसान हो जाता है। मैं इसे संज्ञानात्मक समर्पण (cognitive surrender) कहता हूँ। अगर आप निर्णय के साथ लूप का डिज़ाइन करते हैं, तो यह दवा है; अगर आप लूप का डिज़ाइन केवल विचार करने से बचने के लिए करते हैं, तो यह तेजी का कारक है। एक ही क्रिया, पूरी तरह से विपरीत परिणाम दे सकती है।

लूप बनाएं, लेकिन अभी भी इंजीनियर बने रहें

मुझे लगता है कि यह हमारे भविष्य के कार्य के विकास की दिशा का संकेत है। हालाँकि, अगर मैं कोड की अपनी जाँच नहीं करता या कोड को ठीक करने के लिए पूरी तरह से स्वचालित लूप पर निर्भर रहता हूँ, तो मेरी उत्पाद गुणवत्ता प्रभावित होगी। मैं एक नीचे की ओर की गिरावट में फंस सकता हूँ: लगातार खुद को गहरे गड्ढे में धकेलते जाना।

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

लूप का परिणाम प्रत्येक व्यक्ति के अनुसार अलग-अलग होता है। दो व्यक्ति पूरी तरह समान लूप बना सकते हैं, लेकिन बिल्कुल विपरीत परिणाम प्राप्त कर सकते हैं। एक व्यक्ति इसका उपयोग अपने गहराई से समझे गए कार्य में गति बढ़ाने के लिए करता है; दूसरा व्यक्ति इसका उपयोग कार्य को समझने से बचने के लिए करता है। लूप को इन दोनों के बीच का अंतर नहीं पता। आपको पता है।

इसीलिए loop design (लूप डिज़ाइन) prompt engineering (प्रॉम्प्ट इंजीनियरिंग) की तुलना में आसान नहीं, बल्कि अधिक कठिन है। चेर्नी का मतलब यह नहीं था कि काम आसान हो गया, बल्कि यह कि लीवरेज पॉइंट बदल गया।

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

[Original Link]

जानकारी के लिए लुटिंग ब्लॉकबीट्स में खाली पदों पर क्लिक करें

लेडिंग ब्लॉकचेन न्यूज प्लेटफॉर्म लुडोंग (BlockBeats) के आधिकारिक समुदाय में शामिल हों:

टेलीग्राम सब्सक्रिप्शन समूह: https://t.me/theblockbeats

टेलीग्राम समुदाय: https://t.me/BlockBeats_App

ट्विटर आधिकारिक खाता: https://twitter.com/BlockBeatsAsia