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

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

لوپ انجینئرنگ سے مراد اس تکراری چکر کو ڈیزائن کرنا ہے جس میں AI ایجنٹ کام کرتا ہے: اسے کیا فعال کرتا ہے، اسے کن چیزوں تک رسائی حاصل ہو سکتی ہے، اس کے آؤٹ پٹ کی جانچ کیسے ہوتی ہے، اور اسے کب روکا جاتا ہے۔ Prompt engineering ماڈل کے لیے ایک پیغام تیار کرتی ہے۔ Loop engineering اس عمل کو تشکیل دیتی ہے جو آپ کے سوئے ہوئے وقت میں ہزاروں پیغامات بھیجتا ہے۔ کام کی بنیادی اکائی prompt سے بدل کر loop بن جاتی ہے۔

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

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

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

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

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

دوسری repository، AI-Builder-Club/skills، کے تقریباً 1,100 stars ہیں (July 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 بجے جگا دیتا ہے۔

• ٹرگر۔ وہ واقعہ جو رَن شروع کرتا ہے: ٹائمر، webhook، نئی pull request یا alert۔
• حد۔ وہ files، credentials اور network جن تک agent اس رَن کے دوران رسائی حاصل کر سکتا ہے۔
• تصدیق۔ exit code کے ساتھ ایک جانچ، جو طے کرتی ہے کہ رَن کا output رکھا جائے یا رد کر دیا جائے۔
• بجٹ۔ tokens، وقت اور رقم کی وہ حد جو رَن کو ختم کر دیتی ہے، خواہ وہ کامیاب ہوا ہو یا نہیں۔

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

محرک: agent کو بیدار کرنے والی چیز

Timer سب سے سادہ محرک ہے۔ Linux server پر اس کام کے لیے systemd timer، cron سے بہتر ہے، کیونکہ یہ لاگ بناتا ہے، آپ کی مقررہ شرائط کے مطابق دوبارہ کوشش کرتا ہے، اور اس unit کی دوسری copy شروع نہیں کرتا جو پہلے ہی چل رہی ہو۔ یہ آخری خصوصیت agent loop میں ہونے والے سب سے عام overlap bug کو ختم کرتی ہے: دو 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 میں باقی وقت کی گنتی ہو۔ خالی نتیجے کا مطلب ہے کہ timer enabled نہیں ہے، کیونکہ enable کو --now کے بغیر استعمال کرنے سے یہ صرف اگلے boot کے لیے schedule ہوتا ہے۔ TimeoutStartSec=1800 کی اہمیت بظاہر زیادہ محسوس نہیں ہوتی، لیکن یہ ضروری ہے: اگر agent input کا انتظار کرتے ہوئے hang ہو جائے تو 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 کے ساتھ race نہیں کرتی۔ یہی systemd service اور timer setup server پر چلنے والے کسی بھی طویل دورانیے کے job پر لاگو ہوتا ہے، خواہ وہ agent ہو یا کچھ اور۔

حد بندی: ہر run کے لیے الگ copy دیں

آپ کی working tree میں ترمیم کرنے والا agent ایسا 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 محفوظ ہو جاتے ہیں، کیونکہ دو branches کی دو directories میں چلنے والے دو agents ایک دوسرے کی files overwrite نہیں کر سکتے۔

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

تصدیق: وہ گیٹ جو لوپ کو محفوظ بناتا ہے

یہ وہ حصہ ہے جو لوپ کو ایسی 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"

اس اسکرپٹ میں set -euo pipefail حقیقی کام کر رہا ہے۔ -e کے بغیر ناکام git fetch کو نظرانداز کر دیا جاتا ہے، اور رن پرانے origin/main کے خلاف جاری رہتا ہے۔ -u کے بغیر، متغیر کے نام میں ٹائپو خالی اسٹرنگ میں تبدیل ہو جاتا ہے، اور cleanup ناکامی کی واضح اطلاع دینے کے بجائے غلط path پر چلتا ہے۔

if ! npm test بلاک پورے تصور کا مرکز ہے۔ ایسے check کا exit code، جس پر آپ پہلے ہی اعتماد کرتے ہیں، یعنی اپنی test suite یا type checker کا exit code، یہ فیصلہ کرتا ہے کہ branch کو push کرنا ہے یا ختم کرنا ہے۔ بغیر گیٹ کے لوپ ایسا کام پیدا کرتا ہے جس کا جائزہ لینے کے لیے کسی کے پاس وقت نہیں ہوتا، اور یہ کوئی کام نہ ہونے سے بھی بدتر ہے۔ گیٹ والا لوپ ایسی branch پیدا کرتا ہے جو پہلے ہی وہی معیار پورا کر چکی ہوتی ہے جسے انسانی contributor کی branch کو پورا کرنا ضروری ہے۔

ایسا گیٹ منتخب کریں جو ایمانداری سے ناکام ہو۔ اگر test suite خالی diff پر بھی کامیاب ہو جاتی ہے، تو لوپ یہ سیکھتا ہے کہ کچھ نہ کرنا کامیابی ہے۔ کمزور tests والی repositories کمزور loops پیدا کرتی ہیں۔ اسی لیے مقبول repositories میں "codebase کو agent-ready بنائیں" کو "loop لکھیں" سے پہلے رکھا جاتا ہے۔

بجٹ: رَن کو کیا روکتا ہے

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

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

مقبولِ عام repositories میں مرتب کیے گئے نمونے

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

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

ان میں تحریری ریکارڈ بھی مشترک ہے۔ دونوں repositories حالت کو گفتگو سے نکال کر repository کی files میں محفوظ کرتی ہیں: کیا چلا، اسے کیا ملا، اور اس نے کیا فیصلہ کیا۔ یہ file loop کی یادداشت ہے، اور اسی کی وجہ سے دوسرا loop پہلے loop کے کام پر آگے بڑھ سکتا ہے، بجائے اس کے کہ اسے دوبارہ دریافت کرے۔ بعد میں agent کا audit کرنے کا طریقہ بھی یہی ہے، کیونکہ run ختم ہوتے ہی model کا context ختم ہو جاتا ہے۔

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

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

• کوئی گیٹ نہیں۔ آؤٹ پٹ جمع ہوتا رہتا ہے، کوئی اس کا جائزہ نہیں لیتا، اعتماد ختم ہو جاتا ہے، اور لوپ بند کر دیا جاتا ہے۔
• اوورلیپ۔ ایک ہی برانچ پر دو رنز، یا ایک ہی ورکنگ ٹری میں دو ایجنٹس، ایسے تنازعات پیدا کرتے ہیں جنہیں ایجنٹ بعد میں حل کرنے کی کوشش کرتا ہے۔
• خاموش انحراف۔ لوپ مسلسل کامیاب ہوتا رہتا ہے کیونکہ چیک اتنا کمزور ہے کہ ناکامی ظاہر نہیں ہوتی۔
• دائرۂ کار کی کوئی حد نہیں۔ مصروف repository میں ہر commit پر چلنے والا trigger ایک دن کے اندر اخراجات کا مسئلہ بن جاتا ہے۔

ہر مسئلے کا ایک ہی حل ہے: کام کو محدود کریں، چیک کو زیادہ دقیق بنائیں، اور رن کا لاگ درج کریں۔ اگر آپ pass condition کو ایک جملے میں بیان نہیں کر سکتے تو یہ کام خودکار بنانے کے لیے تیار نہیں ہے۔

اصطلاحات کے بغیر آغاز

آپ کو کسی 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 کو بہتر بناتی ہے: وہ trigger جو run شروع کرتا ہے، وہ sandbox جس میں run چلتا ہے، وہ check جو اس کے output کو قبول یا مسترد کرتا ہے، اور وہ budget جو run ختم کرتا ہے۔ 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، مشترکہ 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 بنانے سے کیسے روکوں؟

اسے تین جگہوں پر محدود کریں۔ systemd unit پر TimeoutStartSec مقرر کریں تاکہ hung run ختم کر دیا جائے۔ Script کے اندر retries کی حد مقرر کریں، بجائے اس کے کہ success تک 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 دوبارہ بنانا اس معیار پر پورا اترتے ہیں، کیونکہ test suite یا diff نتیجے کی تصدیق کر سکتا ہے۔ Refactoring یا design جیسے open-ended کام ابھی اس معیار پر پورے نہیں اترتے، کیونکہ gate کے پاس جانچنے کے لیے کچھ نہیں ہوتا۔ Gate کے بغیر loop review debt پیدا کرنے کا مہنگا طریقہ ہے۔