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

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

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

थोडक्यात, तुम्ही instructions लिहिणे थांबवून control system लिहायला सुरुवात करता. Agent ला अजूनही चांगल्या instructions आवश्यक असतात. मात्र त्या schedule नुसार चालणाऱ्या cycle मधील एका component मध्ये रूपांतरित होतात. ही cycle तुमच्या code च्या isolated copy मध्ये काम करते, test द्वारे स्वतःच्या result ची खात्री करते आणि 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 आणि connectors, sub-agents, तसेच conversation च्या बाहेर ठेवली जाणारी durable memory.

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

I don't prompt Claude anymore. I have loops running that prompt Claude.

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

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

लूपचे चार भाग

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

• Trigger. रन सुरू करणारी घटना: timer, webhook, नवीन pull request किंवा alert.
• Boundary. त्या रनदरम्यान agent ला उपलब्ध असलेल्या files, credentials आणि network ची मर्यादा.
• Verification. exit code असलेली तपासणी. तिच्यावरून रनचे output ठेवायचे की टाकून द्यायचे हे ठरते.
• Budget. रन यशस्वी झाला किंवा नाही तरी तो थांबवणारी token, time आणि money ची मर्यादा.

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

ट्रिगर: agent कशामुळे सुरू होतो

Timer हा सर्वात सोपा trigger आहे. Linux server वर यासाठी systemd timer cron पेक्षा चांगला आहे. तो logs नोंदवतो, तुमच्या नियमांनुसार पुन्हा प्रयत्न करतो आणि अजून सुरू असलेल्या unit ची दुसरी प्रत सुरू करत नाही. या शेवटच्या वैशिष्ट्यामुळे agent loop मधील सर्वात सामान्य overlap bug टाळता येतो: एकाच 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 मध्ये उरलेला वेळ कमी होताना दिसला पाहिजे. Result रिकामा असल्यास 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 दुसरी प्रत सुरू करण्यास अजिबात थांबत नाही:

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

Lock धरलेला असल्यास flock -n status 1 सह त्वरित बाहेर पडतो. त्यामुळे दुसरा run पहिल्या run शी स्पर्धा न करता शांतपणे थांबतो. हीच systemd service आणि timer ची रचना server वरील कोणत्याही दीर्घकाळ चालणाऱ्या job ला लागू होते, agent असो वा नसो.

सीमा: प्रत्येक run साठी स्वतंत्र प्रत द्या

तुमच्या working tree मध्ये बदल करणारा agent तुमचे uncommitted काम गमावू शकतो. Git worktrees हा प्रश्न कमी खर्चात सोडवतात: प्रत्येक run ला स्वतःची 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 असलेली एक ओळ दाखवते. run संपल्यावर git worktree remove /srv/agent/work/triage-01 directory हटवते आणि git worktree prune ज्या directory नाहीशा झाल्या आहेत त्यांचे entries काढून टाकते. या टप्प्यावर parallel loops सुरक्षित होतात, कारण दोन directory मधील दोन branch वर काम करणारे दोन agents एकमेकांचे बदल overwrite करू शकत नाहीत.

ही सीमा credentials साठीही महत्त्वाची आहे. unattended पद्धतीने चालणाऱ्या loop कडे दीर्घकाळ वैध tokens असतात. प्रत्येक run मध्ये एखादा token log, commit किंवा model context मध्ये उघड होण्याची शक्यता असते. token ची scope loop ज्या एकाच repository ला स्पर्श करते तिथपर्यंत मर्यादित ठेवा. शक्य असल्यास agent च्या स्वतःच्या shell ला दिसणाऱ्या environment मधून token वेगळा ठेवा. loop ला production access देण्यापूर्वी AI agents पासून secrets कसे दूर ठेवायचे हे वाचा. अधिक मजबूत विभाजनासाठी संपूर्ण loop प्रत्येक run नंतर नष्ट करता येणाऱ्या disposable VM वर चालवा. तुम्ही कोणते tool वापरता यावरही, त्याची कोणतीही रचना करण्यापूर्वी, या सीमारेषेचा काही भाग ठरतो. त्यामुळे स्वतः किती isolation तयार करायचे हे ठरवण्यापूर्वी Cowork चा managed sandbox तुमच्या स्वतःच्या machine वरील Claude Code शी कसा तुलना करतो हे वाचणे उपयुक्त ठरेल.

पडताळणी: लूप सुरक्षित करणारा निर्णायक टप्पा

हा भाग साध्या cron job पेक्षा लूप वेगळा ठरवतो. एजंटचे output हे प्रस्ताव असते. gate निर्णय घेतो.

#!/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 मधील typo रिकाम्या string मध्ये expand होतो आणि cleanup स्पष्टपणे अपयशी होण्याऐवजी चुकीच्या path वर चालतो.

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

प्रामाणिकपणे अपयशी होणारा gate निवडा. रिकाम्या diff वरही पास होणारा test suite लूपला काहीही न करणे यशस्वी असल्याचे शिकवतो. कमकुवत tests असलेल्या repositories मध्ये कमकुवत loops तयार होतात. म्हणूनच trending repositories मध्ये "write the loop" करण्यापूर्वी "make the codebase agent-ready" केले जाते. तुमचा suite regression प्रत्यक्ष पकडेल की फक्त संबंधित lines execute करेल, हे जाणून घ्यायचे असल्यास mutation testing हा त्याचे उत्तर देणारा check आहे. तसेच तुम्हाला diff वाचण्यास सांगण्याऐवजी पुन्हा चालवता येणारा evidence report परत देणारा एजंट हे उत्तर स्वतः पडताळता येईल अशा स्वरूपात देतो.

बजेट: रन कशामुळे थांबतो

अनंत काळ retry करणारा agent म्हणजे मर्यादा नसलेले बिल निर्माण करणारा 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 मिनिटांनी खर्च होतो.

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

ट्रेंडिंग repositories मध्ये नोंदवलेले नमुने

loop-engineering repository मध्ये production साठी सात नमुने दिले आहेत. ते जाहीरनाम्याप्रमाणे नव्हे, तर वापरता येणाऱ्या पर्यायांच्या यादीप्रमाणे वाचण्यासारखे आहेत. दररोजचे triage. Review comments वर लक्ष ठेवून त्यांना उत्तरे देणारा pull-request babysitter. अपयशी builds घेणारा continuous-integration sweeper. Dependency sweeper. Changelog चा मसुदा तयार करणारा घटक. Merge नंतरची cleanup प्रक्रिया. Issue triage.

या सर्वांमध्ये मर्यादित काम आणि स्पष्ट gate समान आहे. “अपयशी build दुरुस्त करा” यासाठी machine वाचू शकेल अशी pass condition असते. “Codebase सुधारा” यासाठी अशी condition नसते. त्यामुळे ते कधीही loop बनत नाही. ते schedule असलेला गोंधळ बनतो.

या सर्वांमध्ये लिखित नोंदही समान आहे. दोन्ही repositories state संभाषणाबाहेर काढून repository मधील files मध्ये ठेवतात: काय चालवले, काय आढळले आणि काय ठरवले. ही file loop ची memory असते. त्यामुळे दुसरा loop पहिल्या loop च्या कामावर पुढे काम करू शकतो; तेच काम पुन्हा शोधावे लागत नाही. नंतर agent चे audit करण्याची हीच पद्धत आहे, कारण run संपताच model चा context उपलब्ध राहत नाही. Live coordination हे स्वतंत्र channel आहे. दोन्ही sessions सुरू असताना एक Claude Code session त्याच box वरील दुसऱ्या session कडे काम सोपवू शकते. परंतु त्या exchange मधील कोणतीही माहिती दोन्हीपैकी कोणतेही session संपल्यानंतर टिकत नाही. त्यामुळे नंतर परत वाचता येणारा महत्त्वाचा भाग file हाच राहतो.

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

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

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

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

शब्दावलीशिवाय सुरुवात

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

FAQ

Loop engineering आणि prompt engineering वेगवेगळे आहेत का?

Prompt engineering एका संदेशाचे अनुकूलन करते: शब्दरचना, उदाहरणे आणि output format. Loop engineering त्या संदेशाभोवतीच्या cycle चे अनुकूलन करते: run सुरू करणारा trigger, run ज्या sandbox मध्ये चालतो तो sandbox, output स्वीकारायचा किंवा नाकारायचा हे ठरवणारी तपासणी आणि loop समाप्त करणारे budget. Loop मध्ये तरीही चांगला prompt आवश्यक असतो. मात्र दररोज tune करायची मुख्य गोष्ट prompt राहत नाही, कारण gate आणि trigger चा निकालावर अधिक परिणाम होतो.

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

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

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

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

Agent loop मुळे मोठे bill वाढत जाण्यापासून ते कसे थांबवायचे?

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

प्रथम कोणती कामे loop मध्ये रूपांतरित करणे उपयुक्त ठरेल?

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