Loop engineering क्या है? आसान भाषा में समझें

Loop engineering का अर्थ

Loop engineering उस repeating cycle को design करने की प्रक्रिया है जिसमें AI agent चलता है: उसे क्या trigger करता है, वह किन चीजों को access कर सकता है, उसके output की जाँच कैसे होती है, और क्या चीज उसे रोकती है। Prompt engineering एक model के लिए एक message को तैयार करती है। Loop engineering उस process को तैयार करती है जो आपके सोते समय हजारों messages भेजती है। काम की इकाई prompt से हटकर loop पर आ जाती है।

संक्षेप में: आप निर्देश लिखना बंद कर देते हैं और एक control system लिखना शुरू करते हैं। Agent को अभी भी अच्छे निर्देशों की आवश्यकता होती है, लेकिन वे एक ऐसे cycle का हिस्सा बन जाते हैं जो एक schedule पर चलता है, आपके code की एक isolated copy में काम करता है, test के माध्यम से अपने परिणाम को सिद्ध करता है, और budget खत्म होने पर रुक जाता है।

यह शब्द 2026 में क्यों सामने आया

इसका नाम अभी सार्वजनिक रूप से तय किया जा रहा है। GitHub रिपॉजिटरी cobusgreyling/loop-engineering को पहली बार सामने आने के दो महीने के भीतर (जुलाई 2026 तक) 9,600 से अधिक स्टार्स मिले, जो "Stop prompting. Design the loop. Get a score." पंक्ति के अंतर्गत है। यह इस बदलाव को छह बिल्डिंग ब्लॉक्स में एकत्रित करता है: शेड्यूलिंग, वर्कट्रीज़, स्किल्स, प्लगइन्स और कनेक्टर्स, सब-एजेंट्स, और बातचीत से बाहर रखी गई ड्यूरेबल मेमोरी।

यह Boris Cherny को उद्धृत करता है, जो Anthropic में Claude Code का नेतृत्व करते हैं:

मैं अब Claude को प्रॉम्प्ट नहीं करता। मेरे पास ऐसे लूप चल रहे हैं जो Claude को प्रॉम्प्ट करते हैं।

एक दूसरी रिपॉजिटरी, AI-Builder-Club/skills, 1,100 स्टार्स के करीब है (जुलाई 2026 तक) और दो भूमिकाओं का सीधे नाम लेती है: एक "codebase harness" जो एक रिपॉजिटरी को एजेंट के लिए टेस्ट चलाने और डिप्लॉय करने हेतु सुरक्षित बनाती है, और एक "loop engineer" जो ऐसे वर्कफ़्लो बनाता है जो किसी ट्रिगर पर सक्रिय होते हैं, काम करते हैं, और जो सीखा उसे एक साझा फ़ाइल में लिखते हैं ताकि अगला लूप उसे पढ़ सके।

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

लूप के चार भाग

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

• Trigger. वह घटना जो रन (run) शुरू करती है: एक टाइमर, एक webhook, एक नया pull request, या एक alert।
• Boundary. वे files, credentials और network जिन तक agent उस रन के दौरान पहुँच सकता है।
• Verification. एक exit code के साथ की गई जाँच, जो यह तय करती है कि रन के आउटपुट को रखा जाए या हटा दिया जाए।
• Budget. token, समय और पैसे की वह सीमा जो रन के सफल होने या न होने पर भी उसे समाप्त कर देती है।

इन चारों को प्रश्नों के रूप में पढ़ें, और आपके पास किसी भी ऐसे agent के लिए डिज़ाइन रिव्यू तैयार है जिसे आप चलने के लिए छोड़ने वाले हैं।

Trigger: एजेंट को क्या सक्रिय करता है

एक timer सबसे सरल trigger है, और Linux सर्वर पर systemd timer इसके लिए cron से बेहतर है क्योंकि यह लॉग रखता है, आपकी शर्तों पर retry करता है, और यह किसी ऐसी unit की दूसरी copy शुरू नहीं करेगा जो पहले से चल रही हो। यह अंतिम विशेषता एजेंट लूप में सबसे आम overlap बग को दूर करती है: दो run का एक ही branch को edit करना।

Unit को /etc/systemd/system/agent-loop.service पर लिखें:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

और timer को /etc/systemd/system/agent-loop.timer पर:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers में एक NEXT column दिखना चाहिए जिसमें भविष्य का समय हो और एक LEFT column जो countdown दिखा रहा हो। खाली परिणाम का मतलब है कि timer enabled नहीं है, क्योंकि enable बिना --now के इसे केवल अगले boot के लिए schedule करता है। TimeoutStartSec=1800 जितना दिखता है उससे कहीं अधिक महत्वपूर्ण है: इनपुट की प्रतीक्षा में hang होने वाला एजेंट unit को हमेशा के लिए active रखेगा, और timer दोबारा कभी fire नहीं होगा। journalctl -u agent-loop.service -n 50 के साथ run को पढ़ें।

यदि आप इसके बजाय cron से लूप चलाते हैं, तो अपना स्वयं का overlap guard जोड़ें, क्योंकि cron खुशी-खुशी दूसरी copy शुरू कर देगा:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n lock होने पर status 1 के साथ तुरंत exit हो जाता है, इसलिए दूसरी run पहले वाली के साथ प्रतिस्पर्धा करने के बजाय चुपचाप समाप्त हो जाती है। यही systemd service and timer setup बॉक्स पर किसी भी long-running job पर लागू होता है, चाहे वह एजेंट हो या न हो।

सीमा: प्रत्येक रन को अपनी अलग कॉपी दें

जो एजेंट आपकी वर्किंग ट्री में बदलाव करता है, वह आपके अनकमिटेड (uncommitted) काम को मिटा सकता है। Git worktrees इस समस्या का सस्ता समाधान हैं: प्रत्येक रन को अपनी अलग डायरेक्टरी और अपनी अलग ब्रांच मिलती है, जबकि वे एक ही ऑब्जेक्ट स्टोर साझा करते हैं।

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list प्रत्येक ट्री के लिए उसके पाथ, कमिट और ब्रांच के साथ एक लाइन प्रिंट करता है। जब रन समाप्त हो जाता है, तो git worktree remove /srv/agent/work/triage-01 डायरेक्टरी को हटा देता है, और git worktree prune उन एंट्रीज़ को क्लियर कर देता है जिनकी डायरेक्टरी गायब हो गई है। इस बिंदु पर पैरेलल लूप सुरक्षित हो जाते हैं, क्योंकि दो अलग-अलग डायरेक्टरी में दो अलग-अलग ब्रांच पर काम कर रहे दो एजेंट एक-दूसरे के काम को ओवरराइट नहीं कर सकते।

यह सीमा क्रेडेंशियल्स के बारे में भी है। जो लूप बिना निगरानी के चलता है, उसमें लंबे समय तक चलने वाले टोकन होते हैं, और हर रन के दौरान इनके लॉग, कमिट या मॉडल कॉन्टेक्स्ट में लीक होने का खतरा रहता है। टोकन को केवल उसी रिपॉजिटरी तक सीमित रखें जिसे लूप एक्सेस करता है। जहाँ संभव हो, इसे एजेंट के अपने शेल एनवायरनमेंट से दूर रखें। लूप को प्रोडक्शन एक्सेस देने से पहले AI एजेंटों से सीक्रेट्स को सुरक्षित रखने का तरीका पढ़ें। अधिक सख्त सुरक्षा के लिए, पूरे लूप को एक डिस्पोजेबल VM पर रखें जिसे आप प्रत्येक रन के बाद नष्ट कर सकें। आप कौन सा टूल चुनते हैं, यह भी कोडिंग शुरू करने से पहले सीमा का एक हिस्सा तय करता है। इसलिए, यह तय करने से पहले कि आपको खुद कितनी आइसोलेशन बनाने की आवश्यकता है, Cowork का मैनेज्ड सैंडबॉक्स आपकी अपनी मशीन पर चलने वाले Claude Code से कैसे तुलना करता है यह पढ़ना उचित है।

सत्यापन: वह गेट जो लूप को सुरक्षित बनाता है

यह वह हिस्सा है जो एक लूप को केवल टाइप करने वाले cron job से अलग करता है। एजेंट का आउटपुट एक प्रस्ताव होता है। गेट निर्णय लेता है।

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail उस स्क्रिप्ट में वास्तविक काम कर रहा है। -e के बिना, एक विफल git fetch को अनदेखा कर दिया जाता है और रन एक पुराने origin/main के विरुद्ध जारी रहता है। -u के बिना, वेरिएबल नाम में एक टाइपो एक खाली स्ट्रिंग में बदल जाता है, और फिर क्लीनअप जोर से विफल होने के बजाय गलत पाथ पर चलता है।

if ! npm test ब्लॉक ही पूरा विचार है। जिस चेक पर आप पहले से भरोसा करते हैं, उसका एग्जिट कोड—चाहे वह आपकी टेस्ट सुइट हो या टाइप चेकर—यह तय करता है कि ब्रांच को पुश किया जाए या नष्ट। बिना गेट वाला लूप ऐसा काम पैदा करता है जिसकी समीक्षा करने का समय किसी के पास नहीं है, जो कि काम न होने से भी बदतर है। गेट वाला लूप एक ऐसी ब्रांच बनाता है जो उसी मानक को पार कर चुकी है जिसे एक मानव योगदानकर्ता की ब्रांच को पार करना होता है। एक ग्रीन गेट इस बारे में कुछ नहीं कहता कि एजेंट ने वहां तक पहुँचने के लिए कितना कोड बदला है, इसलिए चेक को वह नियम जो एजेंट को सबसे छोटा काम करने वाला बदलाव लेने के लिए प्रेरित करता है जैसे स्थायी निर्देश के साथ जोड़ना उचित है, जो डिफ को इतना छोटा रखता है कि उसकी समीक्षा करना आसान बना रहे।

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

बजट: रन को क्या रोकता है

जो एजेंट हमेशा retry करता रहता है, उसका बिल असीमित हो सकता है। हर लूप के लिए एक समय सीमा (wall-clock ceiling) तय करें, जिसे ऊपर दिए गए TimeoutStartSec द्वारा लागू किया जाए; अपनी स्क्रिप्ट के भीतर एक retry count रखें; और provider account के माध्यम से खर्च की एक सीमा (spend cap) निर्धारित करें। इसके बाद हर रन की लागत को log करें, ताकि invoice आने से पहले ही आप लूप में होने वाली वृद्धि को देख सकें। हमेशा चालू रहने वाले एजेंट VPS के लिए लागत नियंत्रण अकाउंटिंग पक्ष को कवर करता है, और एजेंट द्वारा टर्न के बीच ले जाए जाने वाले कॉन्टेक्स्ट का प्रबंधन प्रति-रन लागत को नियंत्रित करने का सबसे बड़ा जरिया है, क्योंकि जो लूप हर 30 मिनट में एक ही रिपॉजिटरी को दोबारा पढ़ता है, वह हर बार उसके लिए भुगतान करता है।

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

Trending repositories द्वारा कोडिफाई किए गए पैटर्न

loop-engineering रिपॉजिटरी सात प्रोडक्शन पैटर्न सूचीबद्ध करती है, और इन्हें एक घोषणापत्र के बजाय एक मेनू के रूप में पढ़ना सार्थक है। दैनिक ट्राइएज (triage)। एक पुल-रिक्वेस्ट बेबीसिटर जो रिव्यू कमेंट्स पर नज़र रखता है और उनका उत्तर देता है। एक कंटीन्यूअस-इंटीग्रेशन स्वीपर जो विफल (red) बिल्ड्स को उठाता है। एक डिपेंडेंसी स्वीपर। एक चेंजलॉग ड्राफ्टर। पोस्ट-मर्ज क्लीनअप। इश्यू ट्राइएज।

इनमें जो समानता है, वह है एक स्पष्ट गेट (gate) के साथ एक सीमित कार्य। "विफल बिल्ड को ठीक करें" में एक पास कंडीशन होती है जिसे मशीन पढ़ सकती है। "कोडबेस में सुधार करें" में ऐसी कोई कंडीशन नहीं होती, इसलिए यह कभी भी लूप नहीं बन पाता। यह एक शेड्यूल के साथ अव्यवस्था बन जाता है।

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

लूप कहाँ विफल होते हैं

ये विफलताएँ नीरस होती हैं और विभिन्न टीमों में बार-बार दोहराई जाती हैं।

• कोई गेट (gate) न होना। आउटपुट जमा होता रहता है, कोई इसकी समीक्षा नहीं करता, विश्वास खत्म हो जाता है और लूप को बंद कर दिया जाता है।
• ओवरलैप (overlap)। एक ही branch पर दो रन, या एक ही working tree में दो agents, जिससे ऐसे conflicts पैदा होते हैं जिन्हें agent सुलझाने की कोशिश करता है।
• साइलेंट ड्रिफ्ट (silent drift)। लूप पास होता रहता है क्योंकि चेक इतना कमजोर है कि वह विफल नहीं हो पाता।
• असीमित दायरा (unbounded scope)। एक busy repository में हर commit पर चलने वाला ट्रिगर एक दिन के भीतर खर्च की समस्या बन जाता है।

हर समस्या का एक ही समाधान है: जॉब को छोटा करें, चेक को सटीक बनाएँ और रन को लॉग करें। यदि आप पास होने की शर्त को एक वाक्य में नहीं समझा सकते, तो वह जॉब ऑटोमेशन के लिए तैयार नहीं है।

बिना किसी शब्दावली के शुरुआत करना

आपको किसी framework की आवश्यकता नहीं है। एक छोटा always-on Linux सर्वर, एक git repository जिसका test suite विफल होने पर विफल हो जाता है, एक systemd timer और एक shell script जिसमें if हो, एक पूर्ण loop बनाते हैं। वास्तव में अधिकांश लोगों को यहीं से शुरुआत करनी चाहिए, क्योंकि design संबंधी प्रश्नों के उत्तर किसी tool को चुनने के बजाय उसे चलाने से मिलते हैं। एक बार जब एक loop स्थिर हो जाए, तो दूसरा loop चलाना मुख्य रूप से एक और timer और एक और worktree का मामला है। base setup के लिए VPS पर coding AI agent कैसे चलाएं देखें, और यदि आप चाहते हैं कि agent आपके द्वारा नियंत्रित hardware पर चले तो वर्तमान self-hosted AI agent विकल्प देखें।

FAQ

क्या loop engineering और prompt engineering अलग हैं?

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

क्या मुझे agent loop बनाने के लिए किसी फ्रेमवर्क की आवश्यकता है?

नहीं। एक systemd timer, प्रति रन एक git worktree, एक शेल स्क्रिप्ट जो एक टेस्ट कमांड पर समाप्त होती है, और प्रोवाइडर अकाउंट पर खर्च की सीमा (spend cap) परिभाषा के हर हिस्से को कवर करती है। फ्रेमवर्क शेड्यूलिंग इंटरफेस, साझा मेमोरी फॉर्मेट और मल्टी-एजेंट रूटिंग जोड़ते हैं, जो तब उपयोगी होते हैं जब आप कई लूप चलाते हैं। वे पहले लूप के लिए प्रवेश शुल्क नहीं हैं।

codebase harness क्या है?

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

मैं agent loop को बड़ा बिल बनाने से कैसे रोकूँ?

इसे तीन जगहों पर सीमित करें। systemd unit पर TimeoutStartSec सेट करें ताकि एक फंसा हुआ रन समाप्त हो जाए। सफलता तक लूप चलाने के बजाय स्क्रिप्ट के अंदर ही retries को सीमित करें। API अकाउंट पर एक सख्त खर्च सीमा सेट करें, क्योंकि यह एकमात्र ऐसी सीमा है जिसे एजेंट अपनी बातों से पार नहीं कर सकता। फिर प्रति-रन लागत को लॉग करें, क्योंकि जिस लूप की लागत दोगुनी हो जाती है, वह आमतौर पर ऐसा लूप होता है जिसका दायरा चुपचाप बढ़ गया है।

किन कार्यों को सबसे पहले लूप में बदलना सार्थक है?

ऐसा कार्य चुनें जिसमें मशीन-पठनीय पास स्थिति (pass condition) हो और जिसका प्रभाव क्षेत्र (blast radius) छोटा हो। एक red build को ठीक करना, dependency अपडेट करना और changelog को पुनर्जीवित करना, ये सभी इसके लिए उपयुक्त हैं, क्योंकि एक टेस्ट सूट या diff परिणाम को साबित कर सकता है। refactoring या डिज़ाइन जैसा खुला कार्य अभी इसके लिए उपयुक्त नहीं है, क्योंकि गेट के पास जाँचने के लिए कुछ नहीं होता है, और बिना गेट वाला लूप review debt उत्पन्न करने का एक महंगा तरीका है।