लूप इंजिनीअरिंग म्हणजे काय? सोपी व्याख्या

लूप इंजिनीअरिंग म्हणजे काय

लूप इंजिनीअरिंग म्हणजे AI एजंट चालवतो त्या पुनरावृत्ती होणाऱ्या चक्राची रचना करण्याची पद्धत. या चक्राला कशामुळे जाग येते, त्याला कशावर काम करण्याची परवानगी आहे, त्याच्या आउटपुटची तपासणी कशी केली जाते आणि ते कशामुळे थांबते, हे त्यात ठरवले जाते. Prompt engineering द्वारे मॉडेलसाठी एक संदेश तयार केला जातो. Loop engineering द्वारे तुम्ही झोपेत असताना हजारो संदेश पाठवणारी प्रक्रिया तयार केली जाते. कामाचे एकक prompt वरून loop कडे सरकते.

थोडक्यात, तुम्ही सूचना लिहिणे थांबवून नियंत्रण प्रणाली लिहायला सुरुवात करता. एजंटला अजूनही चांगल्या सूचना आवश्यक असतात. परंतु त्या अशा चक्रातील एका घटकात रूपांतरित होतात, जे ठराविक वेळापत्रकानुसार चालते, तुमच्या code ची स्वतंत्र प्रत वापरते, test द्वारे स्वतःच्या परिणामाची खात्री करते आणि budget संपल्यावर थांबते.

2026 मध्ये हा शब्द का प्रचलित झाला

हे नाव सध्या सार्वजनिक वापरात स्थिर होत आहे. प्रथम दिसल्यानंतर दोन महिन्यांच्या आत GitHub repository cobusgreyling/loop-engineering ने 9,600 stars पार केले (July 2026 पर्यंत). त्यासोबत "Stop prompting. Design the loop. Get a score." ही ओळ वापरली आहे. यात या बदलाचे सहा building blocks दिले आहेत: scheduling, worktrees, skills, plugins and connectors, sub-agents आणि conversation च्या बाहेर ठेवली जाणारी durable memory.

यात Anthropic येथे Claude Code चे नेतृत्व करणाऱ्या Boris Cherny यांचे विधान उद्धृत केले आहे:

आता मी Claude ला prompt देत नाही. Claude ला prompt देणारे loops मी चालवत असतो.

दुसरे repository, AI-Builder-Club/skills, जवळपास 1,100 stars वर आहे (July 2026 पर्यंत). त्यात या दोन भूमिका थेट नमूद केल्या आहेत: repository मध्ये agent ने tests आणि deploys सुरक्षितपणे चालवता यावेत यासाठी तयार केलेले "codebase harness", आणि trigger वर जागे होणारे, काम करणारे आणि त्यांनी शिकलेली माहिती shared file मध्ये लिहिणारे workflows तयार करणारा "loop engineer", जेणेकरून पुढील loop ती माहिती वाचू शकेल.

ही पद्धत कोणत्याही repository ने शोधून काढलेली नाही. nightly build, continuous integration मधील linter किंवा ticket उघडणारा cron job चालवलेला कोणताही प्रशासक तिची रचना आधीपासून ओळखतो. नवीन बाब अशी आहे की loop मधील worker आता non-deterministic आहे. त्यामुळे त्याच्या सभोवतालच्या यंत्रणेला करावी लागणारी कामे बदलतात.

लूपचे चार भाग

प्रत्येक कार्यरत लूपमध्ये हे चार भाग असतात. यांपैकी एखादा भाग वगळणारा लूप तुम्हाला पहाटे 3 वाजता जागे करतो.

• ट्रिगर. रन सुरू करणारी घटना: टाइमर, webhook, नवीन pull request किंवा alert.
• सीमा. त्या रनदरम्यान agent ज्या files, credentials आणि network पर्यंत पोहोचू शकतो ते.
• पडताळणी. exit code असलेली तपासणी. तिच्यावरून रनचे output ठेवायचे की टाकून द्यायचे हे ठरते.
• बजेट. रन यशस्वी झाला किंवा नाही, तरी तो थांबवणारी token, वेळ आणि पैशांची मर्यादा.

हे चार भाग प्रश्नांच्या रूपात पुन्हा वाचा. तुम्ही सतत चालू ठेवणार असलेल्या कोणत्याही agent साठी ही design review ठरते.

Trigger: agent कशामुळे सुरू होतो

Timer हा सर्वात सोपा trigger आहे. Linux server वर यासाठी systemd timer हा cron पेक्षा चांगला पर्याय आहे. तो logs नोंदवतो, तुमच्या नियमांनुसार पुन्हा प्रयत्न करतो आणि अजून चालू असलेल्या unit ची दुसरी copy सुरू करत नाही. या शेवटच्या गुणधर्मामुळे agent loop मधील सर्वात सामान्य overlap त्रुटी टळते: एकाच branch वर दोन runs बदल करणे.

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 दिसला पाहिजे. रिकामा परिणाम दिसल्यास timer enabled नाही. कारण enable हे --now शिवाय वापरल्यास ते केवळ पुढील boot साठी schedule केले जाते. TimeoutStartSec=1800 चे महत्त्व अपेक्षेपेक्षा जास्त आहे. Input ची वाट पाहताना agent अडकला, तर unit अन्यथा कायम active राहील आणि timer पुन्हा सुरू होणार नाही. 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 धरलेला असल्यास flock -n status 1 सह त्वरित exit होते. त्यामुळे दुसरा run पहिल्या run शी स्पर्धा न करता शांतपणे थांबतो. हीच systemd service आणि timer ची रचना server वरील कोणत्याही दीर्घकाळ चालणाऱ्या job ला लागू होते, agent असो किंवा नसो.

सीमा: प्रत्येक रनला स्वतःची प्रत द्या

तुमच्या working tree मध्ये बदल करणारा agent तुमचे commit न केलेले काम गमावू शकतो. Git worktrees ही समस्या कमी खर्चात सोडवतात: प्रत्येक रनला स्वतःची directory आणि स्वतःची branch मिळते. सर्व worktrees एकच 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 हटवते आणि git worktree prune directory नाहीशा झालेल्या entries साफ करते. या टप्प्यावर parallel loops सुरक्षित होतात, कारण दोन branches वरील दोन agents दोन वेगळ्या directories मध्ये काम करतात आणि एकमेकांचे बदल overwrite करू शकत नाहीत.

ही सीमा credentials साठीही महत्त्वाची आहे. unattended पद्धतीने चालणाऱ्या loop कडे दीर्घकाळ वैध असलेले tokens असतात. प्रत्येक रनमध्ये त्यापैकी एखादा token log, commit किंवा model context मध्ये उघड होण्याची शक्यता असते. token फक्त loop ज्या एकाच repository ला स्पर्श करते त्यापुरता मर्यादित ठेवा. शक्य असल्यास तो agent च्या स्वतःच्या shell ला दिसणाऱ्या environment पासून बाहेर ठेवा. Loop ला production access देण्यापूर्वी AI agents पासून secrets दूर कसे ठेवायचे ते वाचा. अधिक मजबूत अलगावासाठी, संपूर्ण 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 दुर्लक्षित होते आणि run जुन्या origin/main वर सुरू राहतो. -u शिवाय, variable name मधील टायपो रिकाम्या string मध्ये विस्तारतो. त्यानंतर cleanup स्पष्टपणे अयशस्वी न होता चुकीच्या path वर चालते.

if ! npm test block ही संपूर्ण संकल्पना आहे. तुम्ही आधीपासून विश्वास ठेवत असलेल्या check चा exit code — तुमचा test suite किंवा type checker — branch push करायची की नष्ट करायची, हे ठरवतो. गेट नसलेला लूप असे काम निर्माण करतो ज्याचे review करण्यासाठी कोणाकडेही वेळ नसतो. हे कोणतेही काम न करण्यापेक्षा वाईट आहे. गेट असलेला लूप असा branch तयार करतो, जो मानवी योगदानकर्त्याच्या branch ला पार करावा लागणारा समान निकष आधीच पार केलेला असतो.

प्रामाणिकपणे अयशस्वी होणारा गेट निवडा. रिकाम्या diff वरही पास होणारा test suite लूपला काहीही न करणे यशस्वी असल्याचे शिकवतो. कमकुवत tests असलेल्या repositories मध्ये कमकुवत loops तयार होतात. म्हणूनच trending repositories मध्ये "codebase agent-ready करा" हे "loop लिहा" याच्या आधी येते.

अंदाजपत्रक: रन कशामुळे थांबतो

अमर्यादित वेळा retry करणाऱ्या agent चे बिलही अमर्यादित असते. TimeoutStartSec द्वारे लागू केलेली wall-clock मर्यादा प्रत्येक loop साठी निश्चित करा; तुमच्या script मध्ये retry count ठेवा; आणि provider account द्वारे spend cap लागू करा. त्यानंतर प्रत्येक run साठी झालेला खर्च log करा. त्यामुळे invoice येण्यापूर्वीच loop च्या खर्चात होणारी वाढ दिसू शकते. सतत सुरू असलेल्या agent VPS साठी खर्च नियंत्रण मध्ये accounting बाजू स्पष्ट केली आहे. turn दरम्यान agent सोबत ठेवत असलेला context व्यवस्थापित करणे हे प्रत्येक run च्या खर्चावर परिणाम करणारे सर्वात मोठे नियंत्रण स्पष्ट करते. कारण दर 30 मिनिटांनी तीच repository पुन्हा वाचणाऱ्या loop साठी दर 30 मिनिटांनी त्याचा खर्च होतो.

खर्चामुळे loops सहसा एका दीर्घ session पेक्षा अधिक योग्य ठरतात. नवीन सुरुवात करून एक मर्यादित काम पूर्ण करणारा आणि बंद होणारा run आपला context लहान ठेवतो. 8 तास उघडा ठेवलेला session त्याच्या history मध्ये झालेल्या प्रत्येक आधीच्या चुकीला सोबत ठेवतो आणि प्रत्येक turn वेळी संपूर्ण transcript साठी शुल्क आकारले जाते.

प्रचलित repositories मध्ये नमूद केलेले नमुने

loop-engineering repository मध्ये उत्पादनातील सात नमुने दिले आहेत. त्यांना जाहीरनाम्याऐवजी पर्यायांच्या यादीप्रमाणे वाचणे अधिक उपयुक्त आहे. दररोजची छाननी. पुनरावलोकनाच्या टिप्पण्या पाहून त्यांना उत्तरे देणारा pull-request babysitter. अयशस्वी झालेल्या builds हाताळणारा continuous-integration sweeper. dependency sweeper. changelog चा मसुदा तयार करणारा घटक. merge नंतरची स्वच्छता. Issue triage.

या सर्वांमध्ये स्पष्ट प्रवेश-अट असलेले मर्यादित काम समान आहे. "अयशस्वी झालेला build दुरुस्त करा" यासाठी मशीन तपासू शकेल अशी यशाची अट असते. "codebase सुधारा" यासाठी अशी अट नसते. त्यामुळे ते कधीही loop बनत नाही. ते schedule असलेला गोंधळ बनते.

या सर्वांमध्ये लेखी नोंदही समान आहे. दोन्ही repositories स्थिती संभाषणाबाहेर काढून repository मधील files मध्ये नोंदवतात: काय चालवले, काय आढळले आणि काय ठरवले. ती file म्हणजे loop ची स्मृती आहे. त्यामुळे दुसरा loop पहिल्या loop च्या कामावर आधारित पुढे जाऊ शकतो आणि तेच काम पुन्हा शोधण्याची गरज पडत नाही. यामुळे नंतर agent चे audit करणेही शक्य होते, कारण run संपताच model चा context नष्ट होतो.

लूप कुठे अपयशी ठरतात

ही अपयशे कंटाळवाणी असतात आणि विविध टीममध्ये पुन्हा पुन्हा दिसतात.

• कोणताही गेट नाही. आउटपुट साचत जाते, कोणीही त्याचे पुनरावलोकन करत नाही, विश्वास कमी होतो आणि लूप बंद केला जातो.
• ओव्हरलॅप. एका branch वर दोन रन सुरू होतात किंवा एका working tree मध्ये दोन agents काम करतात. त्यामुळे conflicts निर्माण होतात आणि agent ते सोडवण्याचा प्रयत्न करतो.
• मूक विचलन. check अपयशी ठरण्याइतका कठोर नसल्यामुळे लूप सतत यशस्वी होत राहतो.
• अमर्यादित व्याप्ती. व्यस्त repository मधील प्रत्येक commit वर चालणारा trigger एका दिवसात खर्चाची समस्या निर्माण करतो.

प्रत्येक समस्येवर एकच उपाय आहे: कामाची व्याप्ती कमी करा, check अधिक कठोर करा आणि run चे लॉगिंग करा. pass condition एका वाक्यात स्पष्ट करता येत नसेल, तर ते काम स्वयंचलित करण्यासाठी तयार नाही.

शब्दसंग्रहाशिवाय सुरुवात

तुम्हाला कोणत्याही फ्रेमवर्कची आवश्यकता नाही. नेहमी सुरू असलेला एक छोटा Linux server, योग्य वेळी अपयशी ठरणारा test suite असलेले एक git repository, एक systemd timer आणि त्यात if असलेली एक shell script मिळून पूर्ण प्रक्रिया तयार होते. बहुतेक लोकांनी याच पद्धतीने सुरुवात करावी, कारण साधन निवडण्यापेक्षा प्रत्यक्ष प्रक्रिया चालवून डिझाइनविषयक प्रश्नांची उत्तरे मिळतात. एक प्रक्रिया स्थिर झाल्यावर दुसरी प्रक्रिया चालवण्यासाठी प्रामुख्याने आणखी एक timer आणि दुसरे worktree आवश्यक असतात. मूलभूत सेटअपसाठी VPS वर coding AI agent कसा चालवायचा आणि तुमच्या नियंत्रणाखालील hardware वर agent स्वतः चालवायचा असल्यास सध्याचे self-hosted AI agent पर्याय पहा.

FAQ

लूप इंजिनिअरिंग आणि प्रॉम्प्ट इंजिनिअरिंग वेगवेगळे आहेत का?

प्रॉम्प्ट इंजिनिअरिंग एका संदेशाचे अनुकूलन करते: शब्दरचना, उदाहरणे आणि आउटपुटचे स्वरूप. लूप इंजिनिअरिंग त्या संदेशाभोवतीच्या चक्राचे अनुकूलन करते: रन सुरू करणारा ट्रिगर, रन ज्या sandbox मध्ये चालतो तो sandbox, त्याच्या आउटपुटला स्वीकारणारी किंवा नाकारणारी तपासणी आणि रन समाप्त करणारे बजेट. लूपच्या आत तुम्हाला अजूनही चांगला prompt आवश्यक असतो. दैनंदिन कामात prompt ही समायोजित करण्याची मुख्य गोष्ट राहत नाही, कारण gate आणि trigger यांचा निकालावर अधिक परिणाम होतो.

Agent loop तयार करण्यासाठी मला framework आवश्यक आहे का?

नाही. systemd timer, प्रत्येक रनसाठी एक git worktree, test command ने समाप्त होणारी shell script आणि provider account वरची spend cap या सर्व गोष्टी व्याख्येतील प्रत्येक भागासाठी पुरेशा आहेत. अनेक loops चालवल्यानंतर frameworks scheduling interfaces, shared memory formats आणि multi-agent routing जोडतात. पहिला loop तयार करण्यासाठी ती अनिवार्य सुरुवात नाहीत.

Codebase harness म्हणजे काय?

मानवी उपस्थितीशिवाय agent ला repository मध्ये काम करता यावे यासाठी आवश्यक असलेल्या गोष्टींचा हा संच आहे: एका command ने होणारे setup, non-interactive पद्धतीने चालणाऱ्या आणि स्पष्टपणे fail होणाऱ्या tests, linter आणि बदल deploy किंवा preview करण्याची पद्धत. हा शब्द loop engineering प्रमाणेच 2026 मधील repositories च्या प्रवाहातून आला आहे. व्यावहारिक चाचणी सोपी आहे: नवीन मानवी contributor ला एका command ने clone पासून green tests पर्यंत जाता येत नसेल, तर agent लाही ते करता येणार नाही.

Agent loop मुळे मोठे बिल होऊ नये यासाठी मी काय करू?

तीन ठिकाणी मर्यादा ठेवा. hung run बंद करण्यासाठी systemd unit वर TimeoutStartSec सेट करा. यश मिळेपर्यंत loop चालू ठेवण्याऐवजी script मध्ये retries ची कमाल संख्या ठरवा. API account वर hard spend limit सेट करा, कारण agent ज्या एकमेव मर्यादेपलीकडे बोलून जाऊ शकत नाही ती हीच आहे. त्यानंतर प्रत्येक रनचा खर्च log करा, कारण ज्या loop चा खर्च दुप्पट होतो त्याची scope सहसा नकळत वाढलेली असते.

कोणती कामे प्रथम loop मध्ये रूपांतरित करणे योग्य आहे?

Machine-readable pass condition आणि लहान blast radius असलेले काम निवडा. Red build दुरुस्त करणे, dependency अपडेट करणे आणि changelog पुन्हा तयार करणे ही कामे योग्य आहेत, कारण test suite किंवा diff निकाल सिद्ध करू शकतात. Refactoring किंवा design सारखी open-ended कामे अद्याप योग्य नाहीत, कारण gate तपासू शकेल असे काही नसते. Gate नसलेला loop review debt निर्माण करण्याचा महागडा मार्ग ठरतो.