Loop Engineering - एजेंट को prompt करने वाले सिस्टम को डिज़ाइन करना

• coding agent को हर turn पर सीधे prompt करने का तरीका खत्म करके, एजेंट की ओर से prompt करने वाले सिस्टम को डिज़ाइन करने वाले workflow की ओर बदलाव
• Loop ऐसा recursive goal है जिसमें उद्देश्य तय कर देने पर AI काम पूरा होने तक दोहराता रहता है, और यह लगभग पाँच components से बना होता है
• ये पाँच elements हैं Automations, Worktrees, Skills, Plugins·connectors, Sub-agents और Claude Code व Codex दोनों में अभी ये पाँचों मौजूद हैं
• छठा element memory है, जो एक markdown file या Linear board की तरह single conversation के बाहर state को store करता है, ताकि हर run में सब भूल जाने वाले model की कमी पूरी हो सके
• यह अभी शुरुआती चरण में है और token cost पर ध्यान देना ज़रूरी है; verification और understanding अब भी इंसान की ज़िम्मेदारी है (build the loop, stay the engineer)

---

Loop Engineering की परिभाषा और पृष्ठभूमि

• Loop engineering का मतलब है एजेंट को prompt करने वाले व्यक्ति की जगह खुद की बजाय सिस्टम को बैठाना, और उस काम को करने वाला सिस्टम स्वयं डिज़ाइन करना
  • loop वह recursive goal है जो उद्देश्य तय कर देने पर AI के पूरा करने तक बार-बार चलता है
  • यह coding agents के साथ काम करने का भविष्य हो सकता है, लेकिन अभी शुरुआती चरण में है और token cost पर सावधानी ज़रूरी है (token rich/poor होने के अनुसार उपयोग का पैटर्न बहुत बदलता है)
• उद्धरण
  • Peter Steinberger: "coding agent को अब prompt मत करो, बल्कि एजेंट को prompt करने वाला loop डिज़ाइन करो"
  • Boris Cherny (Anthropic में Claude Code के प्रमुख): "अब मैं Claude को prompt नहीं करता, बल्कि Claude को prompt करके क्या करना है यह तय करने वाला loop चलाता हूँ। मेरा काम loop लिखना है"
• पिछले लगभग 2 सालों में तरीका यह था कि अच्छा prompt और पर्याप्त context दिया जाए, और turn-by-turn बातचीत करते हुए एजेंट को सीधे tool की तरह पकड़े रखा जाए, लेकिन वह तरीका अब खत्म होने की ओर है
• अब ज़रूरत है एक छोटा सिस्टम बनाने की, जो काम ढूँढे और बाँटे, verify करे, पूरा हुआ काम दर्ज करे, और अगला काम तय करे, ताकि वही सिस्टम एजेंट को निर्देश दे
  • यह पहले लिखे गए agent harness engineering (एक agent के चलने का environment) और factory model (software बनाने वाला system) से भी ऊपर की परत है
  • timer पर चलने वाला, छोटे helpers बनाने वाला, और खुद को feed करने वाला harness
• अब यह tool का सवाल नहीं रह गया — 1 साल पहले loop चाहिए होता तो bash scripts खुद लिखकर और maintain करके काम चलाना पड़ता था, लेकिन अब ये components सीधे product के अंदर built-in हैं
  • Steinberger की सूची लगभग ठीक-ठीक Codex app से मेल खाती है और Claude Code से भी लगभग समान है, इसलिए किस tool को चुनना है इस पर बहस करने के बजाय ऐसा loop डिज़ाइन करना चाहिए जो दोनों पर चले

Loop के पाँच components और memory

• loop के लिए पाँच चीज़ें चाहिए, और उसके साथ state याद रखने की एक जगह
  • Automations — schedule के अनुसार trigger होकर खुद discovery और triage करते हैं
  • Worktrees — parallel काम कर रहे दो agents को आपस में टकराने से रोकते हैं
  • Skills — project knowledge को दर्ज रखते हैं, जिसे वरना agent अनुमान से भर देता
  • Plugins·connectors — agent को उन tools से जोड़ते हैं जिन्हें आप पहले से इस्तेमाल करते हैं
  • Sub-agents — एक agent idea बनाता है और दूसरा verify करता है
• छठी चीज़ memory है, जैसे markdown file या Linear board, जो single conversation के बाहर रहती है और क्या पूरा हुआ व आगे क्या करना है उसे संभालती है
  • यह बहुत साधारण लग सकता है, लेकिन यही वही तरकीब है जिस पर सभी long-running agents निर्भर करते हैं
  • model runs के बीच सब कुछ भूल जाता है, इसलिए memory context में नहीं बल्कि disk पर होनी चाहिए — agent भूल सकता है, repo नहीं
• दोनों products में अभी ये पाँचों capabilities मौजूद हैं, बस नाम थोड़े अलग हैं

Automations — loop की धड़कन

• Automations वही चीज़ है जो loop को एक बार चलने वाले run से निकालकर वास्तविक loop बनाती है
  • Codex app में यह Automations tab से बनाई जाती है, जहाँ project, चलाया जाने वाला prompt, frequency, और local checkout या background worktree चुन सकते हैं
  • जो runs कुछ खोज लेते हैं वे Triage inbox में जाते हैं, और जिन्हें कुछ नहीं मिलता वे खुद archive हो जाते हैं
  • OpenAI इसे internally रोज़ की issue triage, CI failures का summary, commit briefing लिखने, और पिछले हफ्ते जुड़े bugs की तलाश जैसे उबाऊ कामों में इस्तेमाल करता है
  • automation skill को call कर सकता है, इसलिए बहुत बड़ा instruction wall paste करने की बजाय $skill-name trigger करके repetitive काम maintainable बनाए जा सकते हैं
• Claude Code scheduling और hooks के ज़रिए उसी जगह पहुँचता है
  • /loop से तय interval पर prompt या command चलाया जा सकता है, cron jobs schedule की जा सकती हैं, और agent lifecycle के खास moments पर hooks से shell commands चलाई जा सकती हैं
  • अगर laptop बंद होने के बाद भी इसे चलते रहना है, तो पूरे flow को GitHub Actions में भेजा जा सकता है
• session के भीतर दूसरा primitive भी है, जो इस लेख के core के बहुत करीब है
  • /loop तय interval पर दोबारा चलता है
  • /goal तब तक चलता रहता है जब तक लिखी गई condition सचमुच true न हो जाए, और हर turn के बाद एक अलग छोटा model completion check करता है, ताकि code लिखने वाला agent खुद अपना judge न बन जाए
    • उदाहरण: "test/auth के सभी tests pass हों, lint clean हो" जैसी condition देकर आप सीट छोड़ सकते हैं
  • Codex भी इसी तरह /goal देता है, जो verifiable stopping condition पूरी होने तक turn लेते हुए चलता है, और pause·resume·clear को support करता है

Worktrees — ताकि parallel काम chaos न बने

• जैसे ही एक से ज़्यादा agents चलते हैं, files टकराने लगती हैं, और यही failure point है
  • दो agents का एक ही file पर लिखना वैसा ही सिरदर्द है जैसे दो engineers बिना बात किए एक ही line commit कर दें
  • git worktree इसका हल देता है — वही repo history share करते हुए हर branch के लिए अलग working directory, इसलिए एक agent के edits दूसरे checkout तक नहीं पहुँचते
• Codex में worktree support built-in है, इसलिए कई threads एक ही repo को साथ में छुएँ तो भी टकराव नहीं होता
• Claude Code git worktree, session को उसके अपने checkout में खोलने वाले --worktree flag, और subagent पर लगाए जाने वाले isolation: worktree setting से वही isolation देता है (हर helper को काम खत्म होने पर खुद साफ हो जाने वाला नया checkout मिलता है)
• worktree mechanical conflicts को हटा देता है, लेकिन सीमा अब भी आप ही हैं — वास्तव में कितने parallel runs संभाल सकते हैं, यह tool नहीं बल्कि आपकी review bandwidth तय करती है

Skills — ताकि हर बार project फिर से समझाना न पड़े

• skill वह तरीका है जिससे हर session में goldfish की तरह वही project context बार-बार समझाना बंद किया जा सके
  • दोनों tools एक जैसा format इस्तेमाल करते हैं — SKILL.md वाला folder, जिसमें instructions और metadata होते हैं, और optional scripts, references, assets भी हो सकते हैं
  • Codex में इन्हें $ या /skills से बुलाया जा सकता है, या अगर task skill description से मेल खाता हो तो यह खुद भी चल सकता है, इसलिए चालाक description से ज़्यादा संक्षिप्त और साधारण description बेहतर है
  • Claude Code भी यही तरीका अपनाता है
• skill वह जगह है जहाँ intent को recurring cost बनने से रोका जाता है
  • agent हर session को cold state से शुरू करता है और intent की कमी को आत्मविश्वास भरे अनुमान से भर देता है
  • skill उस intent को बाहर लिख देने का तरीका है — conventions, build steps, और "उस incident की वजह से हम यह ऐसे नहीं करते" जैसी बातें एक बार लिख दो, फिर agent हर run में उसे पढ़ लेता है
  • skill न हो तो loop हर cycle में पूरे project को शून्य से फिर derive करता है, skill हो तो वह जमा होता जाता है और compounding की तरह बढ़ता है
• skill authoring format है और plugin deployment method — कई repos में share करना हो या bundle बनाना हो तो उसे plugin की तरह package किया जाता है (Codex और Claude Code दोनों में यही)

Plugins·connectors — ताकि loop असली tools तक पहुँचे

• जो loop सिर्फ filesystem देख सकता है, वह छोटा loop है
  • MCP-आधारित connector agent को issue tracker पढ़ने, DB query करने, staging API call करने, और Slack message भेजने की क्षमता देते हैं
  • Codex और Claude Code दोनों MCP की बात करते हैं, इसलिए एक के लिए बना connector अक्सर दूसरे पर भी वैसे ही चलता है
  • plugin connector और skill को bundle करता है, ताकि सहकर्मी याददाश्त के भरोसे पूरा setup दोबारा बनाने के बजाय एक बार में install कर सकें
• यही अंतर है उस agent में जो सिर्फ कहता है "यहाँ एक fix है" और उस loop में जो PR खोलता है, Linear ticket link करता है, और CI green होते ही channel में ping भेजता है
  • connector की वजह से loop सिर्फ संभावना बताने के बजाय वास्तविक environment में action ले पाता है

Sub-agents — बनाने वाले और जाँचने वाले को अलग करना

• loop में सबसे उपयोगी structure निस्संदेह code लिखने वाले और उसकी जाँच करने वाले को अलग करना है
  • code लिखने वाला model अपने ही homework की grading करते समय बहुत उदार होता है
  • अलग instructions और कभी-कभी अलग model वाला दूसरा agent, पहली बार में सही लग जाने वाली बातों में भी खामियाँ पकड़ लेता है
• Codex subagent को सिर्फ request होने पर बनाता है, उन्हें parallel चलाता है, और फिर results को एक answer में जोड़ देता है
  • .codex/agents/ में TOML files के रूप में custom agents define किए जाते हैं (name·description·instructions, और optional model·reasoning effort)
  • उदाहरण: security reviewer के लिए high effort वाला strong model, explorer के लिए तेज़ read-only model
• Claude Code .claude/agents/ के subagents और काम बाँटने वाले agent teams से यही काम करता है
  • दोनों tools में आम बाँट यह है कि एक agent exploration करे, एक implementation करे, और एक spec के मुकाबले verification करे
• loop आपकी निगाह से बाहर भी चलता है, इसलिए विश्वसनीय verifier होना ज़रूरी है ताकि आप सीट छोड़ सकें
  • subagents अपने-अपने model और tool work चलाते हैं, इसलिए ज़्यादा tokens खर्च होते हैं; इन्हें वहीं इस्तेमाल करना चाहिए जहाँ second opinion की कीमत हो
  • Claude Code का /goal अंदर से यही करता है — एक नया model completion तय करता है, ताकि stopping condition पर भी maker-checker separation लागू रहे

एक loop कैसा दिखता है

• सबको जोड़ने पर एक single thread छोटे control panel में बदल जाता है; बार-बार इस्तेमाल होने वाला एक common pattern यह है
  • automation हर सुबह repo में चलता है, और उसका prompt triage skill को call करके कल के CI failures, open issues, और हाल की commits पढ़ता है और result को markdown file या Linear board में दर्ज करता है
  • जिन items पर काम करना सार्थक हो, उनमें हर item के लिए isolated worktree खुलता है, जहाँ sub-agent fix draft करता है, और दूसरा sub-agent उस draft को project skill और existing tests के सामने review करता है
  • connector loop को PR खोलने और ticket update करने देता है, और जो चीज़ें loop handle नहीं कर पाता वे triage inbox में चली जाती हैं
  • state file पूरी व्यवस्था की रीढ़ है — क्या कोशिश की गई, क्या pass हुआ, क्या अभी खुला है, यह सब वही याद रखती है, ताकि अगली सुबह का run आज जहाँ रुका था वहीं से जारी हो
• मुख्य बात यह है that इनमें से किसी step को हर बार prompt नहीं किया गया, बल्कि एक बार डिज़ाइन किया गया — Codex हो या Claude Code, components एक जैसे हैं इसलिए loop भी वही है

loop अब भी क्या नहीं कर सकता

• loop काम का रूप बदलता है, इंसान को हटाता नहीं; बल्कि loop जितना बेहतर होता है, तीन समस्याएँ उतनी तेज़ हो जाती हैं
• verification अब भी आपकी ज़िम्मेदारी है
  • unattended चलने वाला loop unattended गलती भी कर सकता है
  • verifier sub-agent को maker से अलग रखने का मकसद loop के "पूरा हो गया" को अर्थ देना है, लेकिन तब भी "done" proof नहीं, एक claim है
• understanding को छोड़ दिया जाए तो वह सड़ने लगती है
  • loop जितनी तेज़ी से ऐसा code ship करता है जिसे आपने खुद नहीं लिखा, उतना ही gap बढ़ता है उस चीज़ के बीच जो मौजूद है और जिसे आप सच में समझते हैं
  • यही comprehension debt है; अगर loop ने जो बनाया उसे आप पढ़ते नहीं, तो smooth loop उस gap को और तेज़ी से बढ़ाता है
• आरामदायक posture ही जोखिम भरा posture है
  • जब loop खुद चलने लगता है, तब अपनी राय बनाना बंद करके जो लौटकर आता है उसे वैसा का वैसा स्वीकार कर लेना आसान हो जाता है (cognitive surrender)
  • अगर सोच-विचार के साथ किया जाए तो loop design इलाज है, और अगर सोच से बचने के लिए किया जाए तो accelerant — एक ही action, बिल्कुल उलटा result

loop बनाओ, लेकिन engineer बने रहो

• यह काम के विकसित होने के तरीके की एक झलक लग सकता है, लेकिन अगर आप code को खुद review नहीं करते या सिर्फ automated loop पर निर्भर रहते हैं, तो product quality गिर सकती है और आप और गहरे गड्ढे में फँसते जा सकते हैं
• loop सेट करना ज़रूरी है, लेकिन agent को सीधे prompt करना भी अब भी प्रभावी है; असली बात सही संतुलन ढूँढने की है
• loop अलग-अलग लोगों के लिए बिल्कुल उलटे नतीजे देता है — एक ही loop बनाने वाले दो लोगों में से एक गहरी समझ वाले काम को तेज़ करता है, दूसरा उसी का उपयोग काम को समझने से बचने के लिए करता है
  • loop यह फर्क नहीं जानता, लेकिन आप जानते हैं
• यही वजह है कि loop design, prompt engineering से आसान नहीं बल्कि और कठिन है — Cherny की बात यह नहीं कि काम आसान हो गया, बल्कि यह कि leverage point बदल गया है
• निष्कर्ष: loop बनाइए, लेकिन ऐसे जैसे आप सिर्फ start button दबाने वाले नहीं, बल्कि engineer बने रहने वाले व्यक्ति हैं

[shakespeares]

सत्यापन अभी भी आपकी अपनी ज़िम्मेदारी है

समझ को यूँ ही छोड़ दें, तो वह सड़ जाती है

आरामदायक मुद्रा ही ख़तरनाक मुद्रा है

=> आख़िरकार, ख़ुद सीधे जाँच करना और दोहराए जाने वाले काम को कम से कम करने के लिए prompting की ज़रूरत होती है.