لوپ انجینئرنگ (Loop engineering) اس وقت کافی مقبول ہو رہی ہے۔ کسی بھی تکنیکی فورم کو دیکھیں، آپ کو ایسی آوازیں ملیں گی جو بحث کر رہی ہیں کہ ہمیں AI ایجنٹس کے ساتھ چیٹ بوٹس جیسا سلوک کرنا بند کر دینا چاہیے جنہیں ہوشیار پرامپٹس (prompts) کے ذریعے تربیت دی جاتی ہے۔ اس کے بجائے، وہ کہتے ہیں کہ ہمیں لوپس ڈیزائن کرنے چاہئیں: خود مختار سائیکل جو ایجنٹ کو منصوبہ بندی کرنے، عمل درآمد کرنے، اپنے کام کی جانچ کرنے اور ہمارے سوتے ہوئے بھی بار بار اصلاح (iterate) کرنے کی اجازت دیں۔ یہ پیشکش پرکشش ہے۔ اگر لوپ کو بہتر طریقے سے بنایا جائے، تو ایجنٹ مسلسل انسانی نگرانی کے بغیر صحیح راستے پر رہتا ہے، اور راتوں رات خام مقصد کو مکمل آؤٹ پٹ میں بدل دیتا ہے۔

یہ وعدہ نظریاتی طور پر بہت خوبصورت لگتا ہے۔ عملی طور پر، زیادہ تر ایجنٹس پہلے ہی لوپ کرتے ہیں۔ وہ کوڈ تیار کرتے ہیں، کمپائلر کی غلطیوں یا ٹیسٹ کی ناکامیوں کا معائنہ کرتے ہیں، کوڈ کو درست کرتے ہیں، اور دوبارہ سیٹ (suite) چلاتے ہیں۔ یہ بنیادی فیڈ بیک سائیکل نئی نہیں ہے۔ جس چیز کا حامی اب مطالبہ کر رہے ہیں وہ کچھ زیادہ ہی پرجوش ہے: ایک آؤٹر لوپ (outer loop) جو صرف سنٹیکس کی غلطیوں کے بجائے پورے کام (task) کو کنٹرول کرے۔ اس آؤٹر لوپ کو بنانا ہی اصل مشکل ہے، کیونکہ سافٹ ویئر انجینئرنگ شاذ و نادر ہی طے شدہ قواعد والا ایک بند نظام (closed system) ہوتی ہے۔

لوپ ڈیزائن کا مسئلہ

پروڈکٹ کے اہداف الجھے ہوئے ہوتے ہیں۔ آپ شاذ و نادر ہی کام کے مکمل ہونے کی ایک مکمل تعریف کے ساتھ آغاز کرتے ہیں۔ اکثر، آپ اصل مقصد تب دریافت کرتے ہیں جب آپ تعمیر (build) کے عمل میں پوری طرح مصروف ہوتے ہیں۔ وائٹ بورڈ پر جو ضرورت سادہ معلوم ہوتی ہے، اس کے ایج کیسز (edge cases) نکلتے ہیں جو حل کی شکل کو مکمل طور پر بدل دیتے ہیں۔ جب آپ ایک ایجنٹ کو ایک سخت (rigid) لوپ کے اندر بند کرتے ہیں، تو وہ سختی ایک نقصان بن جاتی ہے۔ لوپ ایک ایسے ہدف پر ضرب لگاتا رہتا ہے جو شاید غلط ہو۔ اس سے بھی بدتر یہ کہ، ایک لچکدار لوپ کبھی کبھی مقصد کو خاموشی سے بدل کر ڈیڈ لاک (deadlock) کو حل کر دیتا ہے تاکہ وہ کسی بھی آؤٹ پٹ سے میل کھا سکے۔ دونوں میں سے کوئی بھی نتیجہ مفید نہیں ہے۔ ایک کمپیوٹ (compute) ضائع کرتا ہے؛ دوسرا اعتماد کے ساتھ کچرا (garbage) فراہم کرتا ہے۔

گہرا مسئلہ سپیسیفیکیشن کی لاگت (specification cost) ہے۔ اگر آپ چاہتے ہیں کہ لوپ بغیر نگرانی کے چلے، تو آپ کو ایسی سپیسیفیکیشن لکھنی ہوگی جو تقریباً ہر چیز کا پیش گوئی کرے۔ ایجنٹ کو اصل میں کیا تبدیل کرنا چاہیے؟ کون سا موجودہ رویہ مقدس ہے اور اسے برقرار رکھنا ضروری ہے؟ کن مخصوص حالات میں ایجنٹ کو بار بار اصلاح (iterating) کرنا بند کر دینی چاہیے؟ کون سے خطرات قابل قبول ہیں، اور کن ضمنی اثرات (side effects) کی وجہ سے فوری طور پر کام روک دینا چاہیے؟ اس دستاویز کو لکھنے میں ایجنٹ کے ساتھ بیٹھ کر اسے ریئل ٹائم میں کام سمجھانے سے بھی زیادہ وقت لگ سکتا ہے۔ آپ آٹومیشن کے بدلے میں ایک بھاری پیشگی ٹیکس ادا کر رہے ہیں جو صرف اس صورت میں فائدہ مند ہوتا ہے اگر تصدیق (verification) کا عمل کام کرنے کے مقابلے میں نمایاں طور پر سستا ہو۔

جہاں لوپس واقعی کارآمد ثابت ہوتے ہیں

اس کا مطلب یہ نہیں کہ لوپ انجینئرنگ بیکار ہے۔ اس کا مطلب یہ ہے کہ یہ ایک مخصوص ٹول ہے، کوئی عالمگیر حکمت عملی نہیں۔ لوپس اس وقت بہترین کام کرتے ہیں جب تصدیق کی لاگت بڑھتی جاتی ہے اور کامیابی کے معیار واضح ہوں۔ ایسی تین جگہیں ہیں جہاں یہ بات درست ثابت ہوتی ہے۔

معمول کے میکانکی کام۔ ان کاموں کے بارے میں سوچیں جو سینئر انجینئرز کو ریٹائر ہونے پر مجبور کر دیتے ہیں: مخصوص ترتیب میں ایپلی کیشنز شروع کرنا، ہر مرحلے کی تصدیق کے لیے ڈیپلائمنٹ UI پر کلک کرنا، ریلیز کے بعد معلوم ایرر اسٹرنگز کے لیے لاگز (logs) تلاش کرنا، یا یہ تصدیق کرنا کہ کنفیگریشن فائل تمام صحیح نوڈز پر لکھی گئی ہے۔ یہ اقدامات انسانوں کے لیے تھکا دینے والے ہیں لیکن تصدیق کے لیے معمولی ہیں۔ ایک لوپ اس عمل کی نگرانی کر سکتا ہے، ہر ری اسٹارٹ کے بعد ہیلتھ اینڈ پوائنٹس (health endpoints) کو چیک کر سکتا ہے اور دھوئیں (smoke) کے پہلے نشان پر رول بیک (roll back) کر سکتا ہے۔ انسان اب بھی رول آؤٹ پلان طے کرتا ہے۔ لوپ بس رات کے دو بجے ایک مشین کے صبر کے ساتھ اسے نافذ کرتا ہے۔

پیمائش کے قابل آپٹیمائزیشن اہداف۔ جب کامیابی ایک نمبر ہو، تو لوپس انتہائی مؤثر ثابت ہوتے ہیں۔ p99 لیٹنسی کو 150 ملی سیکنڈ سے کم کریں۔ میموری فٹ پرنٹ کو بیس فیصد کم کریں۔ ایک ہاٹ پاتھ (hot path) کو Python سے Rust میں منتقل کریں اور یقینی بنائیں کہ تمام موجودہ یونٹ ٹیسٹ اب بھی پاس ہو رہے ہیں۔ لوپ ایک تبدیلی پیدا کر سکتا ہے، اس کا بینچ مارک کر سکتا ہے، اس ورژن کو رکھ سکتا ہے جس نے نتائج بہتر کیے، اور باقی کو مسترد کر سکتا ہے۔ چونکہ تصدیق خودکار ہے اور سرچ اسپیس (search space) وسیع ہے، اس لیے دستی نظر ثانی (manual review) کی بڑھتی ہوئی لاگت لوپ کے بغیر اس کام کو ناقابل عمل بنا دے گی۔ ہدف مقرر ہے، راستہ نامعلوم ہے۔ یہی وہ بہترین مقام (sweet spot) ہے۔

آپریشنل پلے بکس۔ حادثاتی ردعمل (incident response) اور سپورٹ ٹکٹس اکثر ان پیٹرنز پر عمل کرتے ہیں جو انسان پہلے ہی سمجھ چکے ہوتے ہیں۔ پروڈکشن ایرر کی ایک مخصوص قسم کے لیے ہمیشہ کریڈنشل تبدیل کرنے اور کیش (cache) صاف کرنے کی ضرورت ہوتی ہے۔ سپورٹ کی درخواست کی ایک کیٹیگری کو ریفنڈ کے ذریعے حل کیا جا سکتا ہے جب تین مخصوص شرائط پوری ہو جائیں۔ ایک لوپ ان ٹرگرز پر نظر رکھ سکتا ہے اور پلے بک کو نافذ کر سکتا ہے، اور صرف اس وقت معاملہ آگے بڑھا سکتا ہے (escalating) جب پیٹرن ٹوٹ جائے۔ یہ فیصلہ نہیں کرتا کہ پلے بک درست ہے؛ یہ محض اس پیمانے اور رفتار پر تسلسل (consistency) کو نافذ کرتا ہے جس کا آن کال انجینئرز مقابلہ نہیں کر سکتے۔

ریگولیٹرز، نہ کہ ریفرنس سیٹرز

موجودہ گفتگو کے ایک بڑے حصے میں ایک اہم فرق نظر انداز کیا جا رہا ہے۔ Loops ریگولیٹرز ہیں۔ یہ ایک سسٹم کو پہلے سے طے شدہ ہدف کے مطابق رکھتے ہیں، بالکل اسی طرح جیسے ایک تھرموسٹیٹ کمرے کے درجہ حرارت کو 72 ڈگری پر برقرار رکھتا ہے۔ لیکن تھرموسٹیٹ خود 72 ڈگری کا انتخاب نہیں کرتا۔ کسی کو پہلے یہ فیصلہ کرنا پڑا کہ یہی صحیح درجہ حرارت ہے۔

سافٹ ویئر پر لاگو کرنے کا مطلب یہ ہے کہ ایک loop کے اندر موجود agent سارا دن bugs ٹھیک کر سکتا ہے، functions کو refactor کر سکتا ہے، یا parameters کو tune کر سکتا ہے۔ تاہم، یہ فیصلہ نہیں کر سکتا کہ کون سا feature اصل میں صارف کی مدد کرتا ہے یا اگلی release سے پہلے کسی bug کو ٹھیک کرنا فائدہ مند ہے یا نہیں۔ ان انتخاب کے لیے کاروباری سیاق و سباق، صارف کی مشکلات، اور اسٹریٹجک ترجیحات کے بارے میں judgment کی ضرورت ہوتی ہے۔ Agents عمل درآمد کرتے ہیں۔ Humans فیصلہ کرتے ہیں۔ ان دونوں کے درمیان فرق نہ کرنا ہی وہ وجہ ہے جس سے ٹیمیں ایسے خوبصورت اور optimized سسٹم بنا لیتی ہیں جو غلط مسئلے کو حل کر رہے ہوتے ہیں۔

Loop engineering مفید ہے، لیکن اس کا دائرہ محدود ہے۔ یہ آپ کو نظم و ضبط اور تیزی کے ساتھ مشین چلانے میں مدد دیتی ہے۔ یہ فیصلہ نہیں کرتی کہ کون سی مشین بنانی ہے، یہ کس کے لیے ہے، یا انسانی لحاظ سے کامیابی کیسی نظر آتی ہے۔ اس بارے میں فیصلہ کرنا کہ کون سا feature اہم ہے، کون سا خطرہ قابل قبول ہے، اور کب خود مقصد کو تبدیل کرنے کی ضرورت ہے، آپ کے اختیار میں ہے۔ ایسے کاموں کے لیے loops بنائیں جنہیں آپ خود بخود verify کرنے کے لیے کافی حد تک سمجھتے ہیں۔ باقی ہر چیز کا کنٹرول اپنے پاس رکھیں۔

یہ مضمون ان خیالات پر مبنی ہے جو اصل میں Isaac Hagoel نے “Loop Engineering Minus The Hype.” میں زیرِ بحث لائے تھے۔ مزید انجینئرنگ مباحثوں کے لیے، Telegram پر ہماری لرننگ کمیونٹی میں شامل ہوں۔