ایک آئیکن کی رکاوٹ

اپنے اسکرین کا تصور کریں جب آپ کوڈنگ کے کسی مصروف مرحلے میں ہوں۔ ایک ٹرمینل ٹیب میں، Claude Code ایک React component کو ری فیکٹر (refactoring) کر رہا ہے۔ دوسرے میں، Codex ایک Python module کو دوبارہ لکھ رہا ہے۔ تیسرا ایجنٹ یونٹ ٹیسٹ (unit tests) تیار کر رہا ہے، چوتھا کسی API key کا انتظار کر رہا ہے، اور پانچواں ابھی ابھی بیک گراؤنڈ میں لینٹر (linter) کا کام مکمل کر چکا ہے۔ آپ کا مینو بار—یا جو بھی سسٹم ٹرے آپ استعمال کرتے ہیں—صرف ایک اسٹیٹس آئیکن کے لیے جگہ رکھتا ہے۔ ایک چھوٹا سا نقطہ یا لیبل پورے گروہ (swarm) کی نمائندگی کرنے والا ہوتا ہے۔ سوال یہ ہے کہ کون سا سیشن اس جگہ کا حقدار ہے۔

سست جواب یہ ہے کہ جو بھی سیشن آخری بار حرکت میں آیا ہو اسے دکھا دیا جائے۔ یہ منطقی لگتا ہے۔ کچھ ہوا ہے، اس لیے وہ سامنے آ جاتا ہے۔ یہ جبلت غلط ہے، اور یہ آپ کو مہنگا پڑ سکتی ہے۔ بیک گراؤنڈ میں فائل واچر (file watcher) کا ٹائم اسٹیمپ اپ ڈیٹ کرنا مدد کی پکار نہیں ہے۔ اس کے برعکس، ایک سیشن جس نے دس منٹ پہلے پرمیشن ایرر (permission error) کا سامنا کیا ہو، وہ نظر انداز ہو کر بیٹھا ہو سکتا ہے، اس انتظار میں کہ آپ "yes" ٹائپ کریں یا کوئی پاتھ (path) درست کریں۔ اگر آپ حالیہ ہونے (recency) کی بنیاد پر درجہ بندی کرتے ہیں، تو آپ اسی چیز کو چھپا دیتے ہیں جسے آپ کی توجہ کی ضرورت ہے۔ آپ کو 'ایکشن ایبلٹی' (actionability) یعنی اس قابلِ عمل ہونے کی بنیاد پر درجہ بندی کرنے کی ضرورت ہے۔

حالیہ ہونے (Recency) کی ناکامی کیوں ہوتی ہے

ڈویلپرز ٹائم اسٹیمپ کا سہارا اس لیے لیتے ہیں کیونکہ یہ آسان ہوتے ہیں۔ ہر سسٹم انہیں پیدا کرتا ہے، ہر ڈیٹا بیس انہیں انڈیکس کرتا ہے، اور ترتیب دینا (sorting) کوڈ کی صرف ایک لائن کا کام ہے۔ لیکن جیسے ہی آپ متعدد آزاد ورکرز کی نگرانی (orchestrating) شروع کرتے ہیں، آسانی کا فائدہ ختم ہو جاتا ہے۔

یہاں ناکامی کی ایک ٹھوس مثال دی گئی ہے۔ سیشن پانچ نے ابھی ایک لاگ لائن (log line) شامل کی ہے کیونکہ اس کے ڈیپینڈینسی واچر (dependency watcher) نے node_modules میں فائل کی تبدیلی کو محسوس کیا۔ اس کا ٹائم اسٹیمپ تازہ ہو کر 'ابھی' کا ہو گیا۔ تاہم، سیشن دو نے تین منٹ پہلے آپ سے ایک سوال پوچھا تھا: "کیا میں یہ پیکیج انسٹال کروں؟ (y/n)"۔ آپ نے جواب نہیں دیا۔ اگر آپ کا مینو بار تازہ ترین سیشن دکھاتا ہے، تو سیشن پانچ کو سبز چمک مل جائے گی اور سیشن دو فہرست میں کہیں غائب ہو جائے گا۔ کچھ بھی خراب نظر نہیں آتا۔ پھر بھی آپ کا ایک ایجنٹ آپ کے فیصلے کے انتظار میں رکا ہوا ہے جبکہ آپ ایک ایسے لینٹر (linter) کی نگرانی میں مصروف ہیں جسے آپ کی ضرورت نہیں ہے۔

حالیہ ہونا حرکت کی پیمائش کرتا ہے۔ فوری ضرورت (Urgency) کے لیے معنی کی ضرورت ہوتی ہے۔ فائل لکھنے کا کوئی ذاتی مطلب نہیں ہے جب تک کہ وہ آپ کے لیے کوئی کام پیدا نہ کر دے۔ دوسری طرف، ایک انتظار کرنے والا پرامپٹ (prompt) خالصتاً قابلِ عمل (actionability) ہوتا ہے۔ آپ بیک گراؤنڈ میں چیزوں کو بدلتے ہوئے دیکھ کر کوڈ شیپ (ship) نہیں کر سکتے۔ آپ اسے رکاوٹوں (blockers) کو دور کر کے شیپ کرتے ہیں۔ سوچ میں پہلا بدلاؤ سادہ ہے: ٹائم اسٹیمپ کو صرف توازن برقرار رکھنے (tiebreaker) کے لیے استعمال کریں، کبھی بھی اسے بنیادی اشارہ نہ سمجھیں۔

پہلے درجہ بندی کریں، پھر ترتیب دیں

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

یہ آپ کو مجبور کرتا ہے کہ آپ اپنے ورک فلو (workflow) کے اندر "فوری" (urgent) کے اصل معنی بیان کریں۔ ایک ریٹ لمیٹڈ (rate-limited) سیشن فوری نہیں ہے؛ وہ سو رہا ہے۔ ایک کام کرنے والا سیشن مصروف ہے، لیکن اگر اسے کسی فیصلے کی ضرورت نہیں ہے، تو وہ سکون سے کمپیوٹنگ جاری رکھ سکتا ہے۔ ایک رکا ہوا (stalled) سیشن فوری ہے کیونکہ غلطیاں بگڑتی جاتی ہیں۔ ایک غیر جواب شدہ ہینڈ آف (handoff) فوری ہے کیونکہ اگلا قدم لفظی طور پر آپ کی ذمہ داری ہے اور ایجنٹ آپ کے عمل کرنے تک آگے نہیں بڑھ سکتا۔

درجہ بندی آپ کے مینو بار کو نیوز فیڈ سے ٹاسک لسٹ (task list) میں بدل دیتی ہے۔ اس کے بعد درجہ بندی کا مرحلہ میکانکی ہو جاتا ہے۔ آپ پہلے ہی فیصلہ کر چکے ہیں کہ ایک بلاک شدہ ورکر ایک مصروف ورکر سے زیادہ اہم ہے۔ آپ پہلے ہی فیصلہ کر چکے ہیں کہ ایک غیر دیکھی گئی سوال ایک دیکھے گئے سوال سے زیادہ اہم ہے۔ وقت کا تصور صرف اس وقت آتا ہے جب دو سیشنز ایک ہی ترجیحی سطح (priority level) پر مدد کے لیے پکار رہے ہوں۔ تب، اور صرف تب، پرانا سیشن جیت جاتا ہے۔ یہ 'پہلے آؤ، پہلے پاؤ' کی انصاف پسندی کے لیے ایک چھوٹی سی رعایت ہے، لیکن اسے کبھی بھی حالت (state) پر فوقیت نہیں ملنی چاہیے۔

ایک عملی ترجیحی پیمانہ (Priority Scale)

Agent Island v1.7.1 میں، ٹیم نے اسے پانچ نکاتی پیمانے میں باقاعدہ شکل دی ہے جسے کوئی بھی متعدد AI سیشنز چلانے والا استعمال کر سکتا ہے:

  • Unacknowledged needs-you: 4۔ سیشن نے آپ کو کچھ واپس بھیجا ہے اور آپ نے ابھی تک اسے دیکھا نہیں ہے۔ اگلا قدم آپ کی ذمہ داری ہے۔
  • Stalled: 3۔ سیشن کو کسی ایرر، پرمیشن کی ناکامی، یا کسی دوسری رکاوٹ کا سامنا کرنا پڑا۔ اسے آپ کی توجہ کی ضرورت ہے کیونکہ یہ خود سے ٹھیک نہیں ہو سکتا۔
  • Working: 2۔ سیشن فعال طور پر کمپیوٹنگ کر رہا ہے۔ یہ آپ کا انتظار نہیں کر رہا، اس لیے اسے آئیکن صرف اسی صورت میں ملتا ہے جب کوئی زیادہ فوری چیز موجود نہ ہو۔
  • Acknowledged needs-you: 1۔ آپ پرامپٹ یا سوال دیکھ چکے ہیں لیکن ابھی تک اس کا جواب نہیں دیا ہے۔ آپ آگاہ ہیں، اس لیے اس کی فوری ضرورت غیر دیکھی مداخلتوں سے ایک درجہ کم ہو جاتی ہے۔
  • Idle or rate limited: 0۔ سیشن محض پس منظر کا شور ہے۔ یہ اپنی باری کا انتظار کر رہا ہے یا بس کچھ نہیں کر رہا۔

یہ پیمانہ صارف کے عمل کے ساتھ بالکل مطابقت رکھتا ہے۔ جب آپ ہینڈ آف (handoff) مکمل کر لیتے ہیں، تو سیشن 'working' یا 'idle' پر آ جاتا ہے۔ جب ایک working سیشن میں ایرر آتا ہے، تو وہ 'stalled' پر چلا جاتا ہے۔ جب آپ پرامپٹ کو تسلیم کرنے کے لیے کلک کرتے ہیں لیکن ضرورت