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

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

लूप इंजिनीअरिंग म्हणजे 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 पर्यंत) आणि 2026-10-27 रोजी त्यावर सुमारे 11,600 stars दिसत होते. त्याखाली "Prompting थांबवा. Loop ची रचना करा. Score मिळवा." अशी ओळ आहे. July 2026 मध्ये त्याच्या README ने या बदलाचे सहा building blocks दिले: scheduling, worktrees, skills, plugins आणि connectors, sub-agents, तसेच conversation च्या बाहेर ठेवलेली durable memory. सध्याच्या README मध्ये ही यादी आता नाही (2026-10-27 रोजी तपासले), पण loop ची state अजूनही conversation च्या बाहेर असलेल्या file मध्ये ठेवली जाते.

या repository मध्ये Claude Code चे Anthropic मधील नेतृत्व करणाऱ्या Boris Cherny यांना त्यामागील inspirations पैकी एक म्हणून श्रेय दिले आहे. त्यांच्या विधानाचा मोठ्या प्रमाणावर उल्लेख झाला आहे:

मी आता Claude ला prompt देत नाही. Claude ला prompt देणारे loops माझ्याकडे चालू आहेत.

दुसरे repository, AI-Builder-Club/skills, 2026-10-27 रोजी जवळपास 1,300 stars वर आहे. त्यात दोन भूमिका थेट सांगितल्या आहेत: repository मध्ये agent ने tests चालवणे आणि deploys करणे सुरक्षित करणारा "codebase harness", आणि trigger वर सुरू होऊन काम करणारे workflow तयार करणारा "loop engineer". हा workflow agent ने काय शिकले ते 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 ठरते.

एजंटला जागे करणारा trigger

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

सर्वप्रथम एजंटसाठी स्वतंत्र user तयार करा. हा user boundary चा भाग आहे. त्यामुळे त्याच्या मालकीचे फक्त /srv/agent असावे:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

त्यानंतर 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 अपेक्षेपेक्षा अधिक महत्त्वाचे आहे. Type=oneshot service ची script exit होईपर्यंत ती सुरू होत असल्याचे मानले जाते. oneshot units साठी systemd start timeout default ने बंद ठेवते. त्यामुळे ही line नसल्यास input ची वाट पाहत अडकलेला agent unit ला activating state मध्ये कायम ठेवतो. त्यानंतरच्या प्रत्येक timer tick ला तो अजूनही running दिसतो आणि काहीही सुरू होत नाही. ही line दिल्यास systemd 30 minutes नंतर run terminate करते आणि त्याला failed म्हणून नोंदवते. Unit default Type=simple मध्ये बदलल्यास TimeoutStartSec run ला स्वतः लागू राहत नाही. त्याची कमाल मर्यादा RuntimeMaxSec= ठरवते. journalctl -u agent-loop.service -n 50 वापरून run तपासा.

Loop cron मधून चालवत असल्यास स्वतःचा overlap guard जोडा, कारण cron दुसरी प्रत सुरू करण्यास सहज तयार असतो:

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

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

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

तुमच्या 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 असलेली एक ओळ print करते. रन संपल्यावर git worktree remove /srv/agent/work/triage-01 worktree काढते, पण तो clean असल्यासच. Tree मध्ये untracked files किंवा modified tracked files असल्यास, किंवा त्यात submodules असल्यास, तुम्ही --force जोडल्याशिवाय git नकार देते. म्हणून खालील gate script फक्त रन हटवणाऱ्या path वर removal सक्तीने करते. Directory नाहीशी झालेल्या entries git worktree prune साफ करते. या टप्प्यावर parallel loops सुरक्षित होतात, कारण दोन branches वरील दोन directories मध्ये चालणारे दोन agents एकमेकांचे बदल 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 वर चालवा. तुम्ही कोणते tool चालवता यावरही code लिहिण्यापूर्वीच या सीमारेषेचा काही भाग ठरतो. त्यामुळे स्वतः किती isolation तयार करायचे हे ठरवण्यापूर्वी Cowork च्या managed sandbox ची तुमच्या स्वतःच्या machine वरील Claude Code शी तुलना कशी होते हे वाचणे उपयुक्त ठरेल.

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

लूप आणि फक्त commands टाइप करणाऱ्या cron job मधील फरक इथे स्पष्ट होतो. Agent चे output हे प्रस्ताव असते. गेट निर्णय घेतो.

#!/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 मध्ये विस्तारतो. त्यानंतर cleanup स्पष्टपणे अपयशी होण्याऐवजी चुकीच्या path वर चालते. शेवटच्या ओळीत मुद्दाम --force नाही. Run नंतर tree मध्ये untracked किंवा uncommitted files राहिल्यास git ते काढण्यास नकार देते. त्यानंतर -e push पूर्ण झाल्यावर error सह run थांबवते. त्यामुळे कोणीही commit न केलेले काम शांतपणे हटवले जात नाही.

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

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

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

अनंत काळ 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 साठी खर्च करतो.

Trending repositories मध्ये संहिताबद्ध केलेले patterns

loop-engineering repository मध्ये production साठी आठ patterns दिले आहेत (2026-10-27 पर्यंत). त्यांकडे manifesto म्हणून नव्हे, तर पर्यायांच्या menu म्हणून पाहणे उपयुक्त आहे. Daily triage. GitHub Action म्हणून चालणारा आणि state file न ठेवणारा thin loop. Review comments वर लक्ष ठेवून त्यांना उत्तरे देणारा pull-request babysitter. Red builds उचलणारा continuous-integration sweeper. Dependency sweeper. Changelog तयार करणारा drafter. Post-merge cleanup. Issue triage.

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

यांच्यात written record देखील समान आहे. दोन्ही repositories state conversation मधून बाहेर काढून repository मधील files मध्ये ठेवतात: काय चालले, काय आढळले आणि काय ठरवले. ती file loop ची memory असते. त्यामुळे दुसरा loop पहिल्या loop च्या कामावर पुढे काम करू शकतो; तेच काम पुन्हा शोधावे लागत नाही. नंतर agent चे audit करण्यासाठीही हीच पद्धत वापरता येते, कारण run संपताच model चा context नष्ट होतो. Live coordination हा स्वतंत्र channel आहे आणि एक Claude Code session त्याच box वरील दुसऱ्या session कडे काम सोपवू शकते; दोन्ही sessions अद्याप चालू असले तरी त्या देवाणघेवाणीपैकी काहीही दोन्ही sessions च्या पलीकडे टिकत नाही. त्यामुळे नंतर पुन्हा वाचता येणारा भाग म्हणून 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 एका message ला optimize करते: wording, examples आणि output format. Loop engineering त्या message भोवतीचा cycle optimize करते: run सुरू करणारा trigger, run ज्या sandbox मध्ये चालतो तो, output स्वीकारायचा किंवा नाकारायचा check आणि loop थांबवणारे budget. Loop मध्ये चांगला prompt तरीही आवश्यक असतो. मात्र रोजच्या tuning मध्ये prompt हा मुख्य घटक राहत नाही, कारण gate आणि trigger यांचा result वर अधिक परिणाम होतो.

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

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

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

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

Agent loop मुळे मोठे bill होणे कसे थांबवू?

तीन ठिकाणी मर्यादा घाला. वरच्या उदाहरणातील systemd unit सारख्या Type=oneshot systemd unit वर TimeoutStartSec सेट करा, म्हणजे अडकलेला run kill केला जाईल. Type=simple service वर याचा equivalent RuntimeMaxSec आहे. Script मध्ये retries ची कमाल संख्या ठरवा; success मिळेपर्यंत loop चालू ठेवू नका. API account वर hard spend limit सेट करा, कारण agent तर्क देऊन ओलांडू शकत नाही अशी हीच एकमेव मर्यादा आहे. प्रत्येक run चा cost नोंदवा. Cost दुप्पट होणारा loop म्हणजे सहसा scope नकळत वाढलेला loop असतो.

कोणती jobs प्रथम loop मध्ये रूपांतरित करावी?

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