प्रॉम्टिंग एजेंट्स से लूप इंजीनियरिंग तक

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

नीचे आप मेरे कुछ विचार (Claude की सहायता से लिखे गए) पढ़ सकते हैं, जो हमारे कुछ छात्रों, टेक्निकल फाउंडर्स, AI इंजीनियर्स और स्टार्टअप्स के साथ किए गए प्रयोगों, शोध और बातचीत से आए हैं।

आपको हमारा हालिया लाइव सेशन "स्वायत्त दीर्घकालिक कोडिंग एजेंट्स" भी इस सब के लिए एक अच्छा शुरुआती बिंदु लग सकता है।*

दावा कहाँ से आता है

"अब आपको कोडिंग एजेंट्स को प्रॉम्प्ट नहीं करना चाहिए। आपको ऐसे लूप्स डिज़ाइन करने चाहिए जो आपके एजेंट्स को प्रॉम्प्ट करें।"Peter Steinberger (

@steipete), 7 जून 2026। 2.2 मिलियन व्यूज़।

मूल ट्वीट

Boris Cherny, Claude Code के निर्माता, उसी बात को दूसरी तरफ से कहते हैं।

"मैं अब Claude को प्रॉम्प्ट नहीं करता। मेरे पास लूप्स चल रहे हैं। वे ही Claude को प्रॉम्प्ट कर रहे हैं और तय कर रहे हैं कि क्या करना है। मेरा काम लूप्स लिखना है।"Boris Cherny (

@bcherny).

मूल ट्वीट

मुद्दा यह नहीं है कि प्रॉम्प्ट इंजीनियरिंग खत्म हो गई है। लूप इंजीनियरिंग के साथ, काम एक स्तर ऊपर चला जाता है, कोड लिखने से लेकर वह सिस्टम लिखने तक जो कोड लिखता है। इस रास्ते पर सबसे आगे के डेवलपर्स ऐसे महीनों की रिपोर्ट करते हैं जहाँ उन्होंने बिना IDE खोले सैकड़ों PRs शिप किए, हर लाइन एजेंट द्वारा लिखी गई।

लूप वास्तव में क्या है

लूप एक छोटा प्रोग्राम है जो आप लिखते हैं और जो चार काम करता है:

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

आप लूप के अंदर बैठकर प्रॉम्प्ट टाइप करना बंद कर देते हैं; आप लूप लिखते हैं, और मॉडल एक सबरूटीन बन जाता है जिसे वह कॉल करता है।

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

"लूप" का मतलब कम से कम पाँच चीज़ें हैं

अधिकांश असहमति लोगों द्वारा एक ही शब्द का पाँच अलग-अलग विचारों के लिए उपयोग करने से है। यहाँ प्रगति है, सबसे पुराने से नवीनतम तक।

• ReAct (2022). मूल शोध पैटर्न: तर्क करें, कार्य करें, निरीक्षण करें, दोहराएँ।
• AutoGPT (2023). एक स्व-प्रॉम्प्टिंग लक्ष्य लूप, जो यह न जानने के लिए कुख्यात है कि कब रुकना है।
• ralph loop. पुनरावृत्तियों के बीच एक जानबूझकर संदर्भ रीसेट ताकि एजेंट अपने स्वयं के इतिहास में न डूबे।
• /loop और /goal. कैडेंस और पूर्णता की शर्तें एजेंट में निर्मित होती हैं, जो टर्न के बीच स्थिति ले जाती हैं।
• orchestration. एक लेखक कई एजेंटों को फैलाता है जो आपके GitHub, Slack और चैट को पढ़ते हैं, और तय करते हैं कि आगे क्या बनाना है।

वे भाग जिन्हें आप वास्तव में जोड़ते हैं

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

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

उन छह को इकट्ठा करें, और आपके पास लूप इंजीनियरिंग के लिए एक अच्छा शुरुआती बिंदु है। आप पहले सब कुछ हाथ से बनाते थे; अब अधिकांश अंतर्निहित सुविधाओं के रूप में शिप होते हैं, यही कारण है कि यह पैटर्न एक सीमांत तकनीक से सामान्य उपयोग में आ गया है।

एक ठोस लूप, PR बेबीसिटर

एक ठोस उदाहरण जो आप आज बना सकते हैं:

• ट्रिगर। हर 15 मिनट।
• दायरा। agent-watch लेबल वाले खुले PRs।
• कार्रवाई। अगर CI किसी निश्चित कारण से लाल है, तो एक फिक्स का प्रयास करें। अगर main चला गया है, तो एक बार रीबेस करें।
• बजट। प्रति PR एक फिक्स प्रयास, पाँच मिनट, दस फ़ाइलें बदली गईं।
• रुकने की शर्त। CI हरा, या बजट समाप्त, फिर रुकें और एक इंसान को पिंग करें।

आप टूटे हुए बिल्ड्स के बैकलॉग के बजाय मर्ज किए गए PRs पर लौटते हैं। वही आकार अधिकांश ऑप्स कार्य को कवर करता है:

• CI स्वास्थ्य। हर 30 मिनट, असफल रन खींचें और उन्हें हस्ताक्षर द्वारा क्लस्टर करें, ताकि एक मूल कारण वाले दस लाल PRs देखने के लिए एक चीज़ बन जाएँ।
• डिप्लॉय सत्यापन। पुश के बाद, अपने एंडपॉइंट्स को हिट करें, 200 और अपेक्षित सामग्री की पुष्टि करें, और उपयोगकर्ताओं से पहले रिग्रेशन को फ़्लैग करें।
• फीडबैक क्लस्टरिंग। हर 30 मिनट, अपने चैनलों से टिप्पणियाँ खींचें, उन्हें थीम में समूहित करें, और प्रत्येक क्लस्टर को उस फ़ाइल या डॉक से मैप करें जो इसका मालिक है।

/goal के साथ एक ठोस Claude Code लूप

बेबीसिटर एक लूप है जिसे आप स्वयं वायर करते हैं; यह भी देखने में मदद करता है कि एजेंट के अंदर कैसे शिप होता है। Claude Code में, सबसे छोटा पूर्ण लूप /goal है: आप इसे एक सत्यापन योग्य अंतिम स्थिति देते हैं, और यह तब तक टर्न लेता रहता है जब तक वह स्थिति सत्य न हो जाए।

यहाँ /goal का एक उदाहरण है जिसका उपयोग Claude Code में इन-सेशन कमांड के रूप में किया जाता है। आप सेशन लॉन्च करते हैं, फिर उसके अंदर लक्ष्य सेट करते हैं:

1$ claude  # Claude Code लॉन्च करें
2$ /goal tests in test/auth pass   # सेशन के अंदर लक्ष्य सेट करें

यह वही कार्य, जाँच, दोहराने का आकार है जो पहले था, जिसमें सत्यापनकर्ता अंतर्निहित है।

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

• शर्त सेट करें। /goal टाइप करें और एक जाँच योग्य अंतिम स्थिति, उदाहरण के लिए,/goal tests in test/auth pass। पहला टर्न तुरंत शुरू होता है।
• एजेंट एक टर्न काम करता है। यह संपादित करता है, टेस्ट चलाता है, और परिणामों को सेशन में सतह पर लाता है।
• एक मूल्यांकनकर्ता जाँचता है। एक तेज़ मॉडल ट्रांसक्रिप्ट पढ़ता है और तय करता है कि यह पूरा हुआ या नहीं, ताकि एजेंट अपने स्वयं के काम को ग्रेड न करे।
• लूप या समाप्त। पूरा नहीं हुआ का मतलब मार्गदर्शन के साथ एक और टर्न; पूरा हुआ का मतलब लक्ष्य स्वयं साफ हो जाता है और रन रुक जाता है।

स्थिति टर्न के पार ले जाती है, इसलिए यह जल्दी नहीं छोड़ता या बीच में किसी बाधा को नहीं छोड़ता। कुछ नियंत्रण इसे विश्वसनीय रखते हैं:

• जाँच को मापने योग्य बनाएँ। एक टेस्ट परिणाम, एक एग्ज़िट कोड, एक फ़ाइल गणना, या एक खाली कतार। npm test exits 0 एक लक्ष्य है; "इसे बेहतर बनाएँ" नहीं है।
• रन को सीमित करें। कुछ ऐसा जोड़ें जैसे "या 20 टर्न के बाद रुकें" ताकि एक अटका हुआ लूप टर्न जलाने के बजाय रुक जाए।
• इसे ऑटो मोड के साथ जोड़िए ताकि टर्न बिना ध्यान दिए चलें, और जल्दी छोड़ने के लिए /goal clear का उपयोग करें।

मूल्यांकनकर्ता चरण एक उपयोगी सूक्ष्मता छिपाता है: जाँचकर्ता को कोडर के समान मॉडल होने की आवश्यकता नहीं है। एक बार लूप में अलग-अलग भूमिकाएँ (योजनाकार, निष्पादक, मूल्यांकनकर्ता, विज़न समीक्षक) होने पर, प्रत्येक एक अलग मॉडल पर चल सकता है, और यह चुनना कि कौन सा मॉडल कौन सी भूमिका भरता है, एक आर्किटेक्चर निर्णय बन जाता है, न कि एक सर्वश्रेष्ठ कोडिंग एजेंट पर एकल दांव। कुछ मॉडल बेहतर योजना बनाते हैं, कुछ सस्ते में निष्पादित करते हैं, कुछ स्क्रीनशॉट का अधिक सटीक न्याय करते हैं, और एक अच्छा ऑर्केस्ट्रेटर आपको प्रति भूमिका उन्हें स्वैप करने देता है, बजाय एक विक्रेता के हर श्रेणी जीतने की प्रतीक्षा करने के।

यह API माइग्रेशन (हर कॉल साइट को तब तक ले जाएँ जब तक यह कंपाइल हो और टेस्ट पास हो), रीफैक्टर (एक फ़ाइल को तब तक विभाजित करें जब तक प्रत्येक मॉड्यूल बजट में हो), इश्यू बैकलॉग (एक लेबल वाली कतार को तब तक काम करें जब तक वह खाली न हो), और इवैल लूप्स (एक प्रॉम्प्ट को तब तक ट्यून करें जब तक स्कोर एक सीमा साफ न कर दे) के लिए अच्छा काम करता है। /loop एक समाप्ति रेखा के बिना काम के लिए समकक्ष है: पूर्णता की स्थिति के बजाय यह एक शेड्यूल पर फिर से प्रॉम्प्ट करता है, यही तरीका है जिससे PR बेबीसिटर जैसा लूप चलता रहता है।

कई लूप्स को बिना ध्यान दिए चलाना

एक एकल /goal लूप एक एजेंट है जो एक समाप्ति रेखा की ओर काम कर रहा है। कई बिना ध्यान दिए प्रक्रियाओं को चलाने से दांव बढ़ जाते हैं, क्योंकि एक लूप उतना ही भरोसेमंद है जितना कि अपने स्वयं के काम की जाँच करने की उसकी क्षमता। Cherny का सेटअप Opus को घंटों तक स्वायत्त रूप से चलाने के लिए पाँच चरणों में आता है:

1. परमिशन को ऑटो-अप्रूव करें ताकि एजेंट हर टूल कॉल पर पूछने के लिए न रुके।
2. डायनामिक वर्कफ़्लो का उपयोग करें (Ultracode को प्रॉम्प्ट में डालें) ताकि एक सीरियल थ्रेड के बजाय कई एजेंटों में फैल जाएँ।
3. /goal या /loop का उपयोग करें इसे चालू रखने के लिए। /goal एक पूर्णता शर्त सेट करता है, /loop एक शेड्यूल पर फिर से प्रॉम्प्ट करता है, और दोनों स्थिति ले जाते हैं, इसलिए यह जल्दी नहीं छोड़ता।
4. इसे क्लाउड में चलाएँ (डेस्कटॉप या मोबाइल ऐप) ताकि सेशन तब बचे जब आप लैपटॉप बंद करें।
5. इसे एंड-टू-एंड स्व-सत्यापन का एक तरीका दें। वेब के लिए Chrome में Claude, मोबाइल के लिए एक सिम्युलेटर MCP, और बैकएंड के लिए एक लाइव सर्वर। यह वह चरण है जो अन्य चार को सुरक्षित बनाता है।

पूरा अनुक्रम:

1claude --permission-mode auto                          # 1 · कोई अनुमोदन प्रॉम्प्ट नहीं
2ultracode  orchestrate sub-agents to ship the feature  # 2 · फैलाएँ
3/goal all tests pass and the demo loads clean          # 3 · चालू रखें
4→ cloud / desktop app                                  # 4 · लैपटॉप बंद करें
5→ chrome ext · sim MCP · live server                   # 5 · स्व-सत्यापन करें, फिर रुकें

crabfleet: एक उत्पाद के रूप में ऑर्केस्ट्रेशन

ऑर्केस्ट्रेशन एक ठोस टूल के साथ चित्रित करना आसान है। Peter Steinberger का crabfleet, एक OpenClaw प्रोजेक्ट जिसे "एजेंट रन के लिए मिशन कंट्रोल" के रूप में विज्ञापित किया गया है, एक लूप है जिसे एक उत्पाद के रूप में पैकेज किया गया है, और इसका आकार ऊपर की हर चीज़ पर मैप होता है।

• एक बोर्ड पर कार्ड के रूप में काम। कार्य एक प्रॉम्प्ट, GitHub इश्यू, या PR से बने कार्ड के रूप में दर्ज किए जाते हैं, फिर todo, running, human review और done के माध्यम से चलते हैं। वह बोर्ड लूप की कतार और इसका रुकने और रिपोर्ट करने का चरण है, जो दिखाई देता है।
• टिकाऊ रन, फायर-एंड-फॉरगेट नहीं। प्रत्येक रन हार्टबीट के साथ एक ट्रैक किया गया प्रयास है, इसलिए यह चलता रहता है जब आप दूसरी ओर देखते हैं और बंद लैपटॉप से बच जाता है। आप तभी संभालते हैं जब रनटाइम विज्ञापित करता है कि यह हैंडऑफ़ का समर्थन करता है।
• एजेंट जो एजेंटों को जन्म देते हैं। एक रन चाइल्ड सेशन शुरू कर सकता है, संदेश भेज सकता है, ट्रांसक्रिप्ट पढ़ सकता है, और सैंडबॉक्स के अंदर से अपना स्वयं का सारांश अपडेट कर सकता है: ऑन-डिस्क मेमोरी और फैन-आउट एक ही स्थान पर, एक लेखक और कई एजेंट।

यह डिस्पोजेबल क्लाउड सैंडबॉक्स पर ब्राउज़र-आधारित टर्मिनलों के साथ चलता है, जो एक बिना ध्यान दिए रन से दूर जाने को सुरक्षित बनाता है। मुद्दा विशिष्ट टूल नहीं है, बल्कि यह है कि लूप बुनियादी ढाँचे में कठोर हो गया है: एक कतार, टिकाऊ निष्पादन, फैन-आउट और एक मानव-समीक्षा गेट अब ऐसी चीज़ें हैं जिन्हें आप हर बार हाथ से स्क्रिप्ट करने के बजाय कॉन्फ़िगर करते हैं।

अब लागत कहाँ जाती है

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

उससे वह बदल जाता है जो अनुकूलन के लायक है:

• पुनरावृत्तियाँ बजट लाइन हैं, टोकन नहीं। एक सस्ता मॉडल जो दोगुनी बार लूप करता है, सस्ता नहीं है, इसलिए प्रति पूर्ण कार्य लागत ट्रैक करें, प्रति कॉल लागत नहीं।
• एक कमज़ोर सत्यापनकर्ता सबसे महँगा बग है जिसे आप शिप कर सकते हैं। अगर "हो गया" तय करने वाली जाँच ढीली है, तो लूप या तो टूटे हुए काम पर जल्दी रुक जाता है या उस काम पर पीसता रहता है जो पहले से ठीक था, और दोनों पूरी पुनरावृत्तियाँ बर्बाद करते हैं। किसी और चीज़ से पहले इसे कस लें।
• तेज़ी से असफल होना लागत नियंत्रण है। लगातार असफलताओं पर कोई सीमा न रखने वाला लूप अंततः सफल नहीं होता; यह अंततः खाता खाली कर देता है, इसलिए रुकने की शर्त बिल को उतना ही सुरक्षित रखती है जितना कोडबेस को।

आप पहले प्रॉम्प्ट को ट्यून करते थे; अब आप लूप को ट्यून करते हैं, क्योंकि वहीं लागत जमा होती है।

कब लूप न करें

लूप तब भुगतान करते हैं जब कोई कार्य दोहराया जाता है, और एक मशीन बता सकती है कि कब यह हो गया है। उसके बाहर, एक लूप केवल उथल-पुथल को स्वचालित करता है। इन मामलों में इसे छोड़ें:

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

क्या गलत हो सकता है

एक लूप जो आपके सोते समय चलता है, वह भी आपके सोते समय गलतियाँ करता है, और विफलता के तरीके पूर्वानुमेय हैं।

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

इनमें से कोई भी लूप के खिलाफ तर्क नहीं है; यही कारण है कि लूप डिज़ाइन करने वाला इंजीनियर अधिक मायने रखता है, कम नहीं।

अपना खुद का कैसे बनाएँ

1. एक दोहराने योग्य कार्य चुनें। PRs की देखभाल, CI को ठीक करना, डिप्लॉय सत्यापित करना: नियमित काम से शुरू करें।
2. इसे कसकर दायर करें। "बिलिंग वेबहुक वैलिडेशन ठीक करें, केवल app/api/billing और lib/billing को छुएँ," "बग ठीक करें" से बेहतर है। एक ढीला लूप भटकता है।
3. इसे एक बजट और एक रुकने की शर्त दें। अधिकतम प्रयास, अधिकतम रनटाइम, अधिकतम फ़ाइलें, अधिकतम खर्च, अधिकतम लगातार असफलताएँ। बिना ध्यान दिए चलने वाला लूप बिना ध्यान दिए गलतियाँ भी करता है।
4. एक स्वतंत्र सत्यापनकर्ता जोड़ें। एक अलग उप-एजेंट काम को ग्रेड करता है, क्योंकि कोड लिखने वाला एजेंट यह तय करने का सबसे खराब न्यायाधीश है कि काम हुआ या नहीं।
5. इसे एक कैडेंस पर चलाएँ। /loop एक अंतराल के लिए, cron एक शेड्यूल के लिए, लाइफसाइकिल बिंदुओं पर हुक, या GitHub Actions ताकि यह बंद लैपटॉप से बचे।
6. मेमोरी को डिस्क पर रखें। मॉडल रनों के बीच भूल जाता है, इसलिए स्थिति मार्कडाउन या बोर्ड में रहती है, कॉन्टेक्स्ट विंडो में नहीं।

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

अगर आपको कोई त्रुटियाँ या ऐसी चीज़ें दिखती हैं जिनमें और स्पष्टीकरण की आवश्यकता है, तो संपर्क करने में संकोच न करें।

अन्य उपयोगी संदर्भ

• Addy Osmani (@addyosmani), AI-सहायता प्राप्त कोडिंग लूप्स पर
• Matt Van Horn (@mvanhorn), "WTF एक लूप है?"
• Peter Steinberger (@steipete), लूप्स डिज़ाइन करने पर
• Boris Cherny (@bcherny), एजेंट्स को स्वायत्त रूप से चलाने पर