لوپ انجینئرنگ کیا ہے؟ سادہ تعریف اور مثال

لوپ انجینئرنگ سے کیا مراد ہے

لوپ انجینئرنگ سے مراد اس دہرائے جانے والے چکر کو ڈیزائن کرنا ہے جس میں AI agent کام کرتا ہے: اسے کیا متحرک کرتا ہے، اسے کن چیزوں تک رسائی حاصل ہو سکتی ہے، اس کے output کی جانچ کیسے ہوتی ہے، اور اسے کون سی چیز روکتی ہے۔ Prompt engineering میں model کے لیے ایک message کی ساخت تیار کی جاتی ہے۔ Loop engineering اس process کی ساخت تیار کرتی ہے جو آپ کے سو جانے کے بعد ہزاروں messages بھیجتا ہے۔ کام کی بنیادی اکائی prompt سے بدل کر loop بن جاتی ہے۔

مختصر طور پر، آپ صرف instructions لکھنا چھوڑ کر control system لکھنا شروع کرتے ہیں۔ Agent کو اب بھی اچھی instructions درکار ہوتی ہیں، لیکن وہ ایک ایسے cycle کا جزو بن جاتی ہیں جو schedule کے مطابق چلتا ہے، آپ کے code کی isolated copy میں کام کرتا ہے، test کے ذریعے اپنے result کی تصدیق کرتا ہے، اور budget ختم ہونے پر رک جاتا ہے۔

یہ اصطلاح 2026 میں کیوں سامنے آئی

یہ نام اس وقت عوامی سطح پر رائج ہو رہا ہے۔ GitHub repository cobusgreyling/loop-engineering نے پہلی بار سامنے آنے کے دو ماہ کے اندر 9,600 stars حاصل کر لیے تھے (جولائی 2026 تک)۔ اس کے نعرے میں کہا گیا ہے: "بار بار prompt نہ دیں۔ loop design کریں۔ score حاصل کریں۔" یہ repository اس تبدیلی کو چھ بنیادی اجزا میں تقسیم کرتی ہے: scheduling، worktrees، skills، plugins اور connectors، sub-agents، اور conversation سے باہر محفوظ کی جانے والی مستقل memory۔

اس میں Boris Cherny کا حوالہ دیا گیا ہے، جو Anthropic میں Claude Code کی قیادت کرتے ہیں:

اب میں Claude کو prompt نہیں دیتا۔ میرے loops چل رہے ہیں جو Claude کو prompt کرتے ہیں۔

دوسری repository، AI-Builder-Club/skills، کے تقریباً 1,100 stars ہیں (جولائی 2026 تک)۔ یہ دونوں کردار براہِ راست بیان کرتی ہے: ایک "codebase harness" جو repository کو اس قابل بناتا ہے کہ agent اس میں محفوظ طریقے سے tests چلائے اور deploys کرے، اور ایک "loop engineer" جو ایسے workflows بناتا ہے جو کسی trigger پر فعال ہوں، کام کریں، اور اپنی سیکھی ہوئی معلومات ایک shared file میں لکھ دیں تاکہ اگلا loop اسے پڑھ سکے۔

ان میں سے کسی repository نے یہ طریقہ ایجاد نہیں کیا۔ جس شخص نے nightly build، continuous integration میں linter، یا ایسا cron job چلایا ہو جو ticket کھولتا ہے، وہ اس کی ساخت پہلے سے جانتا ہے۔ نیا پہلو یہ ہے کہ loop کے اندر کام کرنے والا worker اب non-deterministic ہے۔ اس کے باعث اردگرد کے machinery کو مختلف ذمہ داریاں انجام دینا پڑتی ہیں۔

لوپ کے چار حصے

ہر درست طور پر کام کرنے والے لوپ میں یہ چار حصے ہوتے ہیں۔ جو لوپ ان میں سے کسی ایک حصے کو چھوڑ دے، وہی آپ کو رات 3 بجے بیدار کرتا ہے۔

• Trigger۔ وہ واقعہ جو run شروع کرتا ہے: timer، webhook، نیا pull request یا alert۔
• Boundary۔ وہ files، credentials اور network جن تک agent اس run کے دوران رسائی حاصل کر سکتا ہے۔
• Verification۔ exit code کے ساتھ ایک check، جو فیصلہ کرتا ہے کہ run کا output رکھا جائے یا discard کر دیا جائے۔
• Budget۔ tokens، وقت اور رقم کی حد، جو run کامیاب ہو یا نہ ہو، اسے ختم کر دیتی ہے۔

ان چاروں نکات کو سوالات کی صورت میں دوبارہ پڑھیں۔ اس طرح ہر اس agent کے لیے design review تیار ہو جاتا ہے جسے آپ مسلسل running حالت میں چھوڑنے والے ہیں۔

ایجنٹ کو کیا متحرک کرتا ہے

Timer سب سے سادہ trigger ہے۔ Linux server پر systemd timer اس کام کے لیے cron سے بہتر ہے، کیونکہ یہ logs لکھتا ہے، آپ کی مقررہ شرائط کے مطابق دوبارہ کوشش کرتا ہے، اور اس unit کی دوسری copy شروع نہیں کرتا جو پہلے ہی چل رہی ہو۔ آخری خصوصیت agent loops میں overlap کے عام ترین مسئلے کو ختم کرتی ہے: دو runs ایک ہی branch میں ترمیم کر رہے ہوں۔

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 بظاہر معمولی ہے، لیکن اس کی اہمیت زیادہ ہے: اگر agent input کا انتظار کرتے ہوئے hang ہو جائے تو یہ 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 موجود ہونے پر flock -n فوراً status 1 کے ساتھ exit کرتا ہے۔ اس طرح دوسرا run خاموشی سے ختم ہو جاتا ہے اور پہلے run کے ساتھ race نہیں کرتا۔ یہی systemd service اور timer setup اس machine پر کسی بھی long-running job، خواہ agent ہو یا نہ ہو، کے لیے لاگو ہوتا ہے۔

حد بندی: ہر رن کو اپنی الگ کاپی دیں

آپ کی 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 ان entries کو صاف کرتا ہے جن کی directory موجود نہیں رہی۔ اس مرحلے پر parallel loops محفوظ ہو جاتے ہیں، کیونکہ الگ directories میں الگ branches پر کام کرنے والے دو agents ایک دوسرے کی فائلیں overwrite نہیں کر سکتے۔

یہ boundary credentials سے بھی متعلق ہے۔ unattended طور پر چلنے والا loop طویل مدتی tokens اپنے پاس رکھتا ہے، اور ہر run میں یہ خطرہ ہوتا ہے کہ کوئی token log، commit یا model context میں افشا ہو جائے۔ token کو صرف اس repository تک محدود رکھیں جسے loop استعمال کرتا ہے۔ جہاں ممکن ہو، اسے اس environment سے باہر رکھیں جسے agent کا اپنا shell دیکھ سکتا ہے۔ loop کو production access دینے سے پہلے AI agents سے secrets کو باہر رکھنے کا طریقہ پڑھیں۔ مزید سخت isolation کے لیے پورے loop کو ایک ایسی disposable VM پر چلائیں جسے ہر run کے بعد تباہ کیا جا سکے۔ آپ کون سا tool چلاتے ہیں، یہ بھی شروع ہی میں boundary کا ایک حصہ طے کرتا ہے۔ اس لیے یہ فیصلہ کرنے سے پہلے کہ کتنی isolation خود بنانی ہے، Cowork کے managed sandbox کا اپنی machine پر Claude Code سے موازنہ پڑھنا مفید ہے۔

توثیق: وہ gate جو loop کو محفوظ بناتا ہے

یہی وہ حصہ ہے جو loop کو صرف commands ٹائپ کرنے والے cron job سے الگ کرتا ہے۔ agent کا output ایک proposal ہوتا ہے۔ فیصلہ 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 ایک empty string میں expand ہو جاتا ہے، اور cleanup واضح failure کے بجائے غلط path کے خلاف چلتا ہے۔

if ! npm test block ہی پوری بنیاد ہے۔ کسی trusted check، test suite یا type checker، کا exit code فیصلہ کرتا ہے کہ branch push کی جائے یا ختم کر دی جائے۔ بغیر gate والا loop ایسا کام پیدا کرتا ہے جس کا review کرنے کے لیے کسی کے پاس وقت نہیں ہوتا، اور یہ کوئی کام نہ ہونے سے بھی بدتر ہے۔ gate والا loop ایسی branch بناتا ہے جو پہلے ہی وہی معیار پورا کر چکی ہوتی ہے جو انسانی contributor کی branch کو پورا کرنا ہوتا ہے۔ سبز gate یہ نہیں بتاتا کہ agent نے وہاں پہنچنے کے لیے کتنا code تبدیل کیا۔ اس لیے check کے ساتھ ایسی مستقل ہدایت شامل کرنا مفید ہے جیسے وہ rule جو agent کو کام کرنے والی کم سے کم تبدیلی اختیار کرنے پر مجبور کرتا ہے۔ اس سے diff اتنا چھوٹا رہتا ہے کہ اس کا review کم وقت میں ہو جاتا ہے۔

ایسا gate منتخب کریں جو ایمانداری سے fail ہو۔ اگر empty diff پر test suite پاس ہو جائے تو loop یہ سیکھتا ہے کہ کچھ نہ کرنا کامیابی ہے۔ کمزور tests والی repositories کمزور loops پیدا کرتی ہیں۔ اسی لیے مقبول repositories میں "loop لکھنے" سے پہلے "codebase کو agent-ready بنائیں" آتا ہے۔ اگر آپ جاننا چاہتے ہیں کہ آپ کی suite واقعی regression پکڑ سکتی ہے یا صرف lines execute کرتی ہے، تو mutation testing اس سوال کا جواب دینے والا check ہے۔ اور ایسا agent جو آپ سے diff پڑھنے کے بجائے دوبارہ چلائے جا سکنے والی evidence report واپس دے اس جواب کو ایسی چیز میں بدل دیتا ہے جس کی آپ خود تصدیق کر سکتے ہیں۔

بجٹ: run کو روکنے والی چیزیں

جو agent ہمیشہ retry کرتا رہے، اس کا bill بھی غیر محدود ہوتا ہے۔ ہر loop کے لیے wall-clock کی ایک آخری حد مقرر کریں اور اسے اوپر موجود TimeoutStartSec کے ذریعے نافذ کریں؛ اپنی script میں retry count رکھیں؛ اور provider account کے ذریعے spend cap نافذ کریں۔ پھر ہر run کی لاگت بھی log کریں، تاکہ invoice آنے سے پہلے معلوم ہو جائے کہ loop حد سے بڑھ رہا ہے۔ ہمیشہ فعال agent VPS کے لیے cost control accounting کے پہلو کا احاطہ کرتا ہے، جبکہ agent کے turns کے درمیان منتقل ہونے والے context کا انتظام فی run لاگت کے سب سے بڑے واحد عامل کی وضاحت کرتا ہے۔ اس کی وجہ یہ ہے کہ جو loop ہر 30 منٹ بعد اسی repository کو دوبارہ پڑھتا ہے، وہ اس کی لاگت بھی ہر 30 منٹ بعد ادا کرتا ہے۔

لاگت ہی وہ وجہ ہے جس کی بنا پر loops عموماً ایک طویل session سے بہتر ہوتے ہیں۔ جو run نئے سرے سے شروع ہو، ایک محدود کام کرے اور ختم ہو جائے، وہ اپنا context مختصر رکھتا ہے۔ 8 گھنٹے تک کھلا رہنے والا session اپنی history میں پہلے کی ہر غلطی محفوظ رکھتا ہے اور ہر turn پر پوری transcript کی لاگت ادا کرتا ہے۔

رجحان رکھنے والی repositories میں درج patterns

loop-engineering repository میں production کے سات patterns درج ہیں۔ انہیں منشور کے بجائے ایک menu کے طور پر پڑھنا زیادہ مفید ہے۔ روزانہ triage۔ ایک pull-request babysitter جو review comments کی نگرانی کرتا ہے اور ان کا جواب دیتا ہے۔ ایک continuous-integration sweeper جو red builds کو سنبھالتا ہے۔ ایک dependency sweeper۔ changelog کا مسودہ تیار کرنا۔ merge کے بعد cleanup۔ issue triage۔

ان سب میں ایک محدود کام اور واضح gate مشترک ہے۔ "Fail ہونے والی build کو درست کریں" کی کامیابی کی شرط machine پڑھ سکتی ہے۔ "Codebase کو بہتر بنائیں" کی ایسی شرط نہیں ہے، اس لیے یہ کبھی loop نہیں بنتا۔ یہ schedule کے ساتھ ایک بے ترتیبی بن جاتا ہے۔

ان سب میں تحریری ریکارڈ بھی مشترک ہے۔ دونوں repositories state کو conversation سے نکال کر repository کی files میں محفوظ کرتی ہیں: کیا چلا، اسے کیا ملا، اور اس نے کیا فیصلہ کیا۔ یہ file loop کی memory ہے۔ اسی کی وجہ سے دوسرا loop پہلے loop کے کام پر آگے بڑھ سکتا ہے، بجائے اس کے کہ اسے دوبارہ تلاش کرے۔ یہ بعد میں agent کا audit کرنے کا طریقہ بھی ہے، کیونکہ run ختم ہوتے ہی model کا context ختم ہو جاتا ہے۔ Live coordination ایک الگ channel ہے، اور ایک ہی box پر ایک Claude Code session دوسرے کو کام دے سکتا ہے جبکہ دونوں ابھی چل رہے ہوں۔ لیکن اس exchange میں کوئی چیز دونوں sessions کے ختم ہونے کے بعد باقی نہیں رہتی، اس لیے بعد میں واپس پڑھنے کے لیے file ہی محفوظ حصہ رہتی ہے۔

لوپس کہاں ناکام ہوتے ہیں

ناکامیاں معمولی ہوتی ہیں اور مختلف ٹیموں میں بار بار دہرائی جاتی ہیں۔

• کوئی gate نہیں۔ Output جمع ہوتا رہتا ہے، کوئی اس کا جائزہ نہیں لیتا، اعتماد ختم ہو جاتا ہے، اور loop بند کر دیا جاتا ہے۔
• تداخل۔ ایک branch پر دو runs چلتے ہیں، یا ایک working tree میں دو agents کام کرتے ہیں، جس سے conflicts پیدا ہوتے ہیں اور agent پھر انہیں resolve کرنے کی کوشش کرتا ہے۔
• خاموش drift۔ Loop مسلسل کامیاب ہوتا رہتا ہے کیونکہ check اتنا کمزور ہے کہ failure پیدا نہیں کرتا۔
• غیر محدود scope۔ مصروف repository میں ہر commit پر فعال ہونے والا trigger ایک دن کے اندر اخراجات کا مسئلہ بن جاتا ہے۔

ہر صورت میں ایک ہی حل ہے: job کا دائرہ کم کریں، check کو زیادہ واضح اور سخت بنائیں، اور run کا log رکھیں۔ اگر آپ pass condition کو ایک جملے میں بیان نہیں کر سکتے تو job خودکار بنانے کے لیے تیار نہیں ہے۔

الفاظ کی اصطلاحات جانے بغیر آغاز

آپ کو کسی framework کی ضرورت نہیں۔ ایک چھوٹا، ہمیشہ فعال Linux server، ایک git repository جس کی test suite ناکامی کی صورت میں ناکام ہو، ایک systemd timer، اور ایک shell script جس میں if موجود ہو، مکمل loop بنا دیتے ہیں۔ زیادہ تر لوگوں کے لیے واقعی یہی بہترین آغاز ہے، کیونکہ design سے متعلق سوالات کسی tool کا انتخاب کرنے کے بجائے اسے چلا کر حل ہوتے ہیں۔ ایک loop مستحکم ہو جائے تو دوسرا loop چلانا عموماً ایک اور 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، وہ sandbox جس میں run ہوتا ہے، وہ check جو output قبول یا مسترد کرتا ہے، اور وہ budget جو loop ختم کرتا ہے۔ Loop کے اندر اچھے prompt کی پھر بھی ضرورت ہوتی ہے۔ روزمرہ tuning میں prompt بنیادی عنصر نہیں رہتا، کیونکہ gate اور trigger نتیجے پر زیادہ اثر ڈالتے ہیں۔

کیا agent loop بنانے کے لیے framework ضروری ہے؟

نہیں۔ ایک systemd timer، ہر run کے لیے ایک git worktree، ایسا shell script جو test command پر ختم ہو، اور provider account پر spend cap، تعریف کے ہر حصے کو پورا کرتے ہیں۔ Frameworks scheduling interfaces، shared memory formats اور multi-agent routing شامل کرتے ہیں، جو کئی loops چلانے کے بعد مفید ہوتے ہیں۔ پہلے loop کے لیے یہ لازمی شرط نہیں ہیں۔

codebase harness کیا ہوتا ہے؟

یہ ان تمام چیزوں کا مجموعہ ہے جو کسی agent کو انسانی موجودگی کے بغیر repository میں کام کرنے دیتی ہیں: one-command setup، ایسے tests جو non-interactively چلیں اور واضح failure دیں، ایک linter، اور change کو deploy یا preview کرنے کا طریقہ۔ یہ اصطلاح loop engineering کے ساتھ 2026 میں repositories کی اسی لہر سے سامنے آئی۔ عملی معیار سادہ ہے: اگر نیا انسانی contributor ایک command سے clone سے green tests تک نہیں پہنچ سکتا تو agent بھی نہیں پہنچ سکتا۔

agent loop کو بڑا bill بنانے سے کیسے روکوں؟

اس پر تین مقامات پر cap لگائیں۔ systemd unit پر TimeoutStartSec مقرر کریں تاکہ معطل run ختم ہو جائے۔ Retries کو script کے اندر محدود کریں، بجائے اس کے کہ کامیابی تک loop جاری رہے۔ API account پر hard spend limit مقرر کریں، کیونکہ یہی وہ واحد حد ہے جسے agent باتوں سے عبور نہیں کر سکتا۔ پھر ہر run کی cost log کریں، کیونکہ جس loop کی cost دوگنی ہو رہی ہو، عموماً اس کا scope خاموشی سے بڑھ چکا ہوتا ہے۔

کن jobs کو پہلے loop میں تبدیل کرنا مفید ہے؟

ایسی job منتخب کریں جس کی pass condition machine-readable ہو اور blast radius محدود ہو۔ Red build درست کرنا، dependency update کرنا اور changelog دوبارہ generate کرنا اس معیار پر پورا اترتے ہیں، کیونکہ test suite یا diff نتیجے کا ثبوت دے سکتا ہے۔ Refactoring یا design جیسے open-ended کام ابھی موزوں نہیں، کیونکہ gate کے پاس جانچنے کے لیے کچھ نہیں ہوتا۔ Gate کے بغیر loop review debt پیدا کرنے کا ایک مہنگا طریقہ ہے۔