लूप इंजीनियरिंग क्या है? आसान परिभाषा और अर्थ

लूप इंजीनियरिंग का अर्थ

लूप इंजीनियरिंग उस दोहराए जाने वाले चक्र को डिज़ाइन करने की प्रक्रिया है जिसे कोई AI agent चलाता है: उसे क्या सक्रिय करता है, वह किन चीज़ों को छू सकता है, उसके आउटपुट की जाँच कैसे होती है, और उसे कौन रोकता है। Prompt engineering किसी model के लिए एक संदेश का रूप तय करती है। लूप इंजीनियरिंग उस प्रक्रिया का रूप तय करती है जो आपके सोते समय हज़ारों संदेश भेजती है। काम की मूल इकाई prompt से बदलकर loop हो जाती है।

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

2026 में यह शब्द क्यों प्रचलित हुआ

यह नाम अभी सार्वजनिक रूप से स्थापित हो रहा है। पहली बार दिखाई देने के दो महीनों के भीतर GitHub repository cobusgreyling/loop-engineering को 9,600 से अधिक stars मिले (July 2026 तक)। इसके साथ यह पंक्ति दी गई है: "प्रॉम्प्ट देना बंद करें। लूप डिज़ाइन करें। स्कोर प्राप्त करें।" यह बदलाव को छह building blocks में समेटता है: scheduling, worktrees, skills, plugins और connectors, sub-agents, तथा conversation के बाहर रखा गया durable memory।

इसमें Anthropic में Claude Code का नेतृत्व करने वाले Boris Cherny का उद्धरण है:

अब मैं Claude को prompt नहीं देता। मेरे पास ऐसे loops चल रहे हैं जो Claude को prompt करते हैं।

दूसरी repository, AI-Builder-Club/skills, के पास लगभग 1,100 stars हैं (July 2026 तक)। इसमें दोनों भूमिकाओं का सीधे नाम दिया गया है: एक "codebase harness", जो किसी repository को agent के लिए tests चलाने और deploy करने हेतु सुरक्षित बनाता है; और एक "loop engineer", जो ऐसे workflows बनाता है जो किसी trigger पर सक्रिय होते हैं, काम करते हैं, और सीखी गई जानकारी को shared file में लिखते हैं ताकि अगला loop उसे पढ़ सके।

इनमें से किसी repository ने इस practice का आविष्कार नहीं किया। जिसने भी nightly build, continuous integration में linter, या ऐसा cron job चलाया है जो ticket खोलता है, वह इसका ढांचा पहले से जानता है। नया यह है कि loop के भीतर काम करने वाला worker अब non-deterministic है। इसलिए उसके आसपास की machinery को अलग तरीके से काम करना पड़ता है।

loop के चार भाग

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

• Trigger। वह घटना जो run शुरू करती है: timer, webhook, नया pull request या alert।
• Boundary। वे files, credentials और network जिन तक agent उस run के दौरान पहुंच सकता है।
• Verification। exit code वाला check, जो तय करता है कि run का output रखा जाए या हटा दिया जाए।
• Budget। token, समय और धन की वह सीमा, जो run को सफल होने या न होने की परवाह किए बिना समाप्त कर देती है।

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

Trigger: agent को क्या सक्रिय करता है

Timer सबसे सरल trigger है। Linux server पर इसके लिए systemd timer, cron से बेहतर है। यह logs लिखता है, आपकी शर्तों के अनुसार दोबारा प्रयास करता है, और अभी चल रही unit की दूसरी copy शुरू नहीं करता। यह अंतिम विशेषता agent loop में होने वाली सबसे सामान्य overlap समस्या को रोकती है: एक ही branch को दो runs द्वारा 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 दिखना चाहिए, जिसमें शेष समय घटता हुआ हो। खाली result का अर्थ है कि timer enabled नहीं है, क्योंकि enable को --now के बिना चलाने पर वह केवल अगले boot के लिए schedule होता है। TimeoutStartSec=1800 का महत्व अपेक्षा से अधिक है: input की प्रतीक्षा में अटकने वाला agent अन्यथा unit को हमेशा active रखेगा, और timer फिर कभी fire नहीं होगा। किसी run को journalctl -u agent-loop.service -n 50 से पढ़ें।

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

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

Lock पहले से held होने पर flock -n तुरंत status 1 के साथ exit करता है। इसलिए दूसरा run पहले run के साथ race करने के बजाय चुपचाप समाप्त हो जाता है। यही systemd service और timer setup box पर चलने वाले किसी भी लंबे समय तक चलने वाले job पर लागू होता है, चाहे वह agent हो या नहीं।

सीमा: हर रन को अपनी कॉपी दें

आपकी working tree को संपादित करने वाला agent आपके uncommitted work को खो सकता है। Git worktrees इस समस्या को कम लागत में हल करते हैं। हर रन को अपनी directory और अपना branch मिलता है, जबकि सभी एक ही object store साझा करते हैं।

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

git worktree list प्रत्येक tree के लिए उसके path, commit और branch वाली एक पंक्ति दिखाता है। रन समाप्त होने पर git worktree remove /srv/agent/work/triage-01 directory को delete करता है, और git worktree prune उन entries को साफ करता है जिनकी directory हट चुकी है। इस बिंदु पर parallel loops सुरक्षित हो जाते हैं, क्योंकि अलग-अलग directories में अलग-अलग branches पर चलने वाले दो agents एक-दूसरे के work को overwrite नहीं कर सकते।

यह सीमा credentials पर भी लागू होती है। unattended रूप से चलने वाला loop लंबे समय तक मान्य tokens रखता है। हर रन में token के log, commit या model context में leak होने का जोखिम रहता है। Token का scope केवल उस एक repository तक सीमित करें जिसे loop access करता है। जहाँ संभव हो, token को उस environment से बाहर रखें जिसे agent का अपना shell देख सकता है। Production access देने से पहले secrets को AI agents से बाहर रखने का तरीका पढ़ें। अधिक मजबूत अलगाव के लिए पूरा loop एक disposable VM पर चलाएँ जिसे हर रन के बाद नष्ट किया जा सके।

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

यही वह भाग है जो लूप को केवल टाइप करने वाले 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"

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

if ! npm test block ही पूरी अवधारणा है। जिस check पर आप पहले से भरोसा करते हैं, यानी आपकी test suite या आपका type checker, उसका exit code तय करता है कि branch को push करना है या नष्ट करना है। बिना गेट वाला लूप ऐसा काम तैयार करता है जिसकी समीक्षा करने का समय किसी के पास नहीं होता। यह कोई काम न होने से भी खराब है। गेट वाला लूप ऐसी branch तैयार करता है जो पहले ही उसी मानक पर खरी उतर चुकी होती है, जिस पर किसी human contributor की branch को उतरना होता है।

ऐसा गेट चुनें जो सही तरीके से विफल हो। जो test suite empty diff पर pass हो जाती है, वह लूप को सिखाती है कि कुछ न करना सफल है। कमजोर tests वाली repositories कमजोर loops तैयार करती हैं। इसी कारण trending repositories में "codebase को agent-ready बनाएं" को "loop लिखें" से पहले रखा जाता है।

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

ऐसा agent जो हमेशा retry करता रहता है, उसका बिल भी सीमित नहीं रहता। हर loop के लिए wall-clock की अधिकतम सीमा तय करें और उसे ऊपर दिए गए TimeoutStartSec से लागू करें। अपनी script में retry count रखें। Provider account के माध्यम से spend cap लागू करें। फिर हर run की लागत log करें, ताकि invoice आने से पहले ही आप loop की बढ़ती लागत देख सकें। हमेशा चालू agent VPS के लिए लागत नियंत्रण में accounting पक्ष शामिल है। एक turn से अगले turn तक agent द्वारा रखे गए context को प्रबंधित करना per-run cost को प्रभावित करने वाले सबसे बड़े उपाय को समझाता है। इसका कारण यह है कि जो loop हर 30 minutes में उसी repository को फिर से पढ़ता है, वह हर 30 minutes में उसकी लागत भी चुकाता है।

लागत के कारण loops आमतौर पर एक लंबे session से बेहतर होते हैं। ऐसा run जो नए सिरे से शुरू होता है, एक सीमित काम करता है और समाप्त हो जाता है, उसका context छोटा रहता है। आठ hours तक खुला रहने वाला session अपने history में पिछली हर गलती रखता है और हर turn पर पूरे transcript की लागत चुकाता है।

ट्रेंडिंग repositories में संहिताबद्ध पैटर्न

loop-engineering repository में production के सात पैटर्न सूचीबद्ध हैं। इन्हें घोषणापत्र के बजाय विकल्पों की सूची के रूप में पढ़ना उपयोगी है। दैनिक triage। ऐसा pull-request babysitter जो review comments की निगरानी करता है और उनका उत्तर देता है। ऐसा continuous-integration sweeper जो red builds को संभालता है। dependency sweeper। changelog drafter। merge के बाद की cleanup। Issue triage।

इन सभी में एक सीमित कार्य और स्पष्ट gate होता है। "विफल build ठीक करें" की ऐसी pass condition होती है जिसे मशीन पढ़ सकती है। "codebase में सुधार करें" की ऐसी condition नहीं होती। इसलिए यह कभी loop नहीं बनता। यह schedule वाली अव्यवस्था बन जाता है।

इनमें लिखित रिकॉर्ड भी समान होता है। दोनों repositories state को conversation से बाहर निकालकर repository की files में रखते हैं: क्या चला, उसे क्या मिला और उसने क्या तय किया। वह file loop की memory होती है। इसी कारण दूसरा loop पहले loop के कार्य पर आगे बढ़ सकता है, उसे फिर से खोजने की आवश्यकता नहीं होती। यही तरीका agent का बाद में audit करने की सुविधा भी देता है, क्योंकि run समाप्त होते ही model का context समाप्त हो जाता है।

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

विफलताएँ साधारण होती हैं और अलग-अलग टीमों में बार-बार दोहराई जाती हैं।

• कोई गेट नहीं। आउटपुट जमा होता रहता है, कोई उसकी समीक्षा नहीं करता, भरोसा खत्म हो जाता है और लूप बंद कर दिया जाता है।
• ओवरलैप। एक ही branch पर दो runs चलते हैं या एक ही working tree में दो agents काम करते हैं। इससे conflicts बनते हैं, जिन्हें agent बाद में हल करने का प्रयास करता है।
• मौन विचलन। Check इतना कमजोर होता है कि विफल नहीं होता, इसलिए लूप लगातार पास होता रहता है।
• असीमित scope। व्यस्त repository में हर commit पर चलने वाला trigger एक दिन के भीतर खर्च की समस्या बन जाता है।

हर समस्या का एक ही समाधान है: job का दायरा घटाएँ, check को अधिक सटीक बनाएँ और run को log करें। यदि आप pass condition को एक वाक्य में स्पष्ट नहीं कर सकते, तो job को automate करने के लिए तैयार नहीं किया गया है।

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

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

FAQ

क्या loop engineering, prompt engineering से अलग है?

Prompt engineering एक message को optimize करता है: wording, examples और output format। Loop engineering उस message के आसपास के cycle को optimize करता है: run शुरू करने वाला trigger, वह sandbox जिसमें run चलता है, output को स्वीकार या अस्वीकार करने वाला check, और उसे समाप्त करने वाला budget। Loop के भीतर आपको अभी भी एक अच्छा prompt चाहिए। Prompt ऐसी चीज़ नहीं रहता जिसे आप हर दिन tune करते हैं, क्योंकि gate और trigger का result पर अधिक प्रभाव होता है।

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

नहीं। एक systemd timer, प्रत्येक run के लिए एक git worktree, test command पर समाप्त होने वाली shell script और provider account पर spend cap, definition के हर भाग को कवर करते हैं। Frameworks scheduling interfaces, shared memory formats और multi-agent routing जोड़ते हैं। ये तब उपयोगी होते हैं जब आप कई loops चलाते हैं। पहला loop बनाने के लिए ये अनिवार्य नहीं हैं।

Codebase harness क्या है?

यह उन सभी चीज़ों का समूह है जो किसी human के मौजूद न होने पर agent को repository में काम करने देती हैं: one-command setup, non-interactively चलने वाले और स्पष्ट रूप से fail होने वाले tests, एक linter, और किसी change को deploy या preview करने का तरीका। यह term loop engineering के समान 2026 wave of repositories से आया है। Practical test सरल है: यदि कोई नया human contributor एक command से clone से green tests तक नहीं पहुँच सकता, तो agent भी नहीं पहुँच सकता।

Agent loop को बड़ा bill बढ़ाने से कैसे रोकूँ?

इसे तीन स्थानों पर limit करें। systemd unit पर TimeoutStartSec set करें, ताकि hung run को kill किया जा सके। Script के भीतर retries की सीमा तय करें, success मिलने तक loop न चलाते रहें। API account पर hard spend limit set करें, क्योंकि यही एक ऐसी सीमा है जिसे agent बातचीत करके पार नहीं कर सकता। इसके बाद प्रत्येक run की cost log करें, क्योंकि जिस loop की cost दोगुनी हो जाती है, उसका scope आमतौर पर चुपचाप बढ़ गया होता है।

किन jobs को सबसे पहले loop में बदलना उपयोगी है?

ऐसी job चुनें जिसमें machine-readable pass condition और छोटा blast radius हो। Red build को ठीक करना, dependency update करना और changelog regenerate करना इसके योग्य हैं, क्योंकि test suite या diff result को प्रमाणित कर सकता है। Refactoring या design जैसे open-ended work अभी इसके योग्य नहीं हैं, क्योंकि gate के पास जाँचने के लिए कुछ नहीं होता। Gate के बिना loop review debt बनाने का महँगा तरीका है।