एक-आयकॉनची मर्यादा

तुमच्या कोडिंगच्या व्यस्त सत्रादरम्यान तुमच्या स्क्रीनची कल्पना करा. एका टर्मिनल टॅबमध्ये, Claude Code एका React component मध्ये बदल (refactoring) करत आहे. दुसऱ्या टॅबमध्ये, Codex एक Python module पुन्हा लिहित आहे. तिसरा एजंट युनिट टेस्ट्स तयार करत आहे, चौथा API की ची वाट पाहत आहे, आणि पाचवा नुकताच बॅकग्राउंड लिन्टर पास पूर्ण केला आहे. तुमच्या मेनू बारमध्ये—किंवा तुम्ही जे सिस्टिम ट्रे वापरता त्यामध्ये—फक्त एकाच स्टेटस आयकॉनसाठी जागा आहे. एक छोटासा बिंदू किंवा लेबल संपूर्ण समूहाचे (swarm) प्रतिनिधित्व करणार आहे. प्रश्न असा आहे की कोणत्या सत्राला (session) ती जागा मिळेल.

सोपा किंवा आळशी उपाय म्हणजे जे सत्र शेवटचे हलले असेल ते दाखवणे. हे तर्कसंगत वाटते. काहीतरी घडले आहे, म्हणून ते वर येते. ही प्रवृत्ती चुकीची आहे आणि ती तुम्हाला महागात पडू शकते. बॅकग्राउंडमधील फाईल वॉचरने टाइमस्टॅम्प अपडेट करणे म्हणजे मदतीसाठी हाक मारणे नाही. दरम्यान, दहा मिनिटांपूर्वी 'परमिशन एरर' आलेले सत्र अदृश्य अवस्थेत असू शकते, जे तुम्ही "yes" टाइप करण्याची किंवा पाथ (path) दुरुस्त करण्याची वाट पाहत आहे. जर तुम्ही अलीकडील हालचालीनुसार (recency) क्रम लावला, तर तुम्हाला ज्या गोष्टीची सर्वात जास्त गरज आहे तीच गोष्ट तुम्ही लपवून ठेवता. तुम्हाला 'ॲक्शनॅबिलिटी'नुसार (actionability - कृती करण्यायोग्य असणे) क्रम लावणे आवश्यक आहे.

अलीकडील हालचालींवर आधारित पद्धत का अपयशी ठरते

डेव्हलपर्स टाइमस्टॅम्पचा वापर करतात कारण ते सोपे आहेत. प्रत्येक सिस्टम ते तयार करते, प्रत्येक डेटाबेस त्यांचे इंडेक्सिंग करतो आणि सॉर्टिंग करणे ही कोडची एक ओळ आहे. पण जेव्हा तुम्ही अनेक स्वतंत्र वर्कर्सचे व्यवस्थापन (orchestrating) करायला सुरुवात करता, तेव्हा हे 'सोपे' असणे निरुपयोगी ठरते.

येथे एक ठोस अपयशाचे उदाहरण दिले आहे. सत्र पाचने नुकतीच एक लॉग लाईन जोडली आहे कारण त्याच्या डिपेंडन्सी वॉचरने node_modules मध्ये फाईल बदलल्याचे पाहिले. त्याचा टाइमस्टॅम्प आताच्या वेळेनुसार अपडेट झाला. मात्र, सत्र दोनने तीन मिनिटांपूर्वी तुम्हाला एक प्रश्न विचारला होता: "मी हे पॅकेज इन्स्टॉल करू का? (y/n)". तुम्ही त्याचे उत्तर दिलेले नाही. जर तुमचा मेनू बार सर्वात नवीन सत्र दाखवत असेल, तर सत्र पाचला हिरवा प्रकाश (green glow) मिळेल आणि सत्र दोन यादीत अदृश्य होईल. काहीही बिघडल्यासारखे वाटणार नाही. तरीही, तुमचा एक एजंट तुमच्या निर्णयासाठी थांबलेला आहे, तर तुम्ही अशा लिन्टरवर लक्ष केंद्रित करण्यात व्यस्त आहात ज्याला तुमच्या मदतीची गरज नाही.

अलीकडील हालचाली (Recency) केवळ हालचाल मोजतात. तातडीसाठी (Urgency) अर्थ असणे आवश्यक आहे. जोपर्यंत एखादी फाईल लिहिणे तुमच्यासाठी एखादे कार्य निर्माण करत नाही, तोपर्यंत त्याला स्वतःचा कोणताही अर्थ नसतो. याउलट, एखादा प्रॉम्ट (prompt) ज्याची वाट पाहत आहे, तो पूर्णपणे 'ॲक्शनॅबिलिटी' आहे. बॅकग्राउंडमध्ये गोष्टी बदलताना पाहून तुम्ही कोड शिप करू शकत नाही. तुम्ही अडथळे (blockers) दूर करून कोड शिप करता. विचार करण्याच्या पद्धतीतील पहिला बदल साधा आहे: टाइमस्टॅम्पला केवळ 'टायब्रेकर' (tiebreaker) म्हणून वापरा, कधीही प्राथमिक सिग्नल म्हणून नाही.

प्रथम वर्गीकरण करा, नंतर क्रम लावा

एक उत्तम दृष्टिकोन म्हणजे दोन-टप्प्यांची फिल्टरिंग प्रक्रिया. पहिले, प्रत्येक सत्र तुम्हाला काय हवे आहे यावर आधारित लेबल करा. दुसरे, त्या लेबल्सना क्रम लावा. केवळ दोन सत्रे एकाच लेबलची असतील तरच वेळेकडे लक्ष द्या.

यामुळे तुम्हाला तुमच्या वर्कफ्लोमध्ये "तातडीचे" (urgent) म्हणजे नक्की काय, हे परिभाषित करण्यास भाग पाडले जाते. रेट-लिमिटेड (rate-limited) सत्र तातडीचे नसते; ते झोपलेले असते. कार्यरत सत्र व्यस्त असते, पण जर त्याला निर्णयाची गरज नसेल, तर ते शांतपणे काम चालू ठेवू शकते. थांबलेले (stalled) सत्र तातडीचे असते कारण एरर्समुळे काम बिघडू शकते. न हाताळलेले हँडऑफ (unanswered handoff) तातडीचे असते कारण पुढचे पाऊल उचलण्याची जबाबदारी तुमची आहे आणि तुम्ही कृती करेपर्यंत एजंट पुढे जाऊ शकत नाही.

वर्गीकरणामुळे तुमचा मेनू बार 'न्यूज फीड' वरून 'टास्क लिस्ट' मध्ये बदलतो. त्यानंतर रँकिंगची प्रक्रिया यांत्रिक होते. तुम्ही आधीच ठरवले आहे की अडकलेला (blocked) वर्कर व्यस्त वर्करपेक्षा महत्त्वाचा आहे. तुम्ही आधीच ठरवले आहे की न पाहिलेला प्रश्न पाहिलेल्या प्रश्नापेक्षा महत्त्वाचा आहे. जेव्हा दोन सत्रे एकाच प्रायोरिटी लेव्हलवर मदतीसाठी हाक मारतात, तेव्हाच वेळेचा विचार केला जातो. तेव्हाच आणि तेव्हाच, जुने सत्र जिंकते. हे 'प्रथम येणाऱ्यास प्राधान्य' या न्यायासाठी एक लहानशी मदत आहे, परंतु त्याने सत्राच्या स्थितीला (state) कधीही डावलू नये.

एक व्यावहारिक प्रायोरिटी स्केल

Agent Island v1.7.1 मध्ये, टीमने याला पाच-मुद्द्यांच्या स्केलमध्ये औपचारिक रूप दिले आहे, जे अनेक AI सत्रे चालवणारे कोणीही वापरू शकते:

  • Unacknowledged needs-you: 4. सत्राने तुम्हाला काहीतरी परत दिले आहे आणि तुम्ही ते अजून पाहिलेले नाही. पुढची हालचाल करण्याची जबाबदारी तुमची आहे.
  • Stalled: 3. सत्रामध्ये एरर, परमिशन फेल्युअर किंवा इतर कोणताही अडथळा आला आहे. त्याला तुमच्या लक्ष देण्याची गरज आहे कारण ते स्वतःहून दुरुस्त होऊ शकत नाही.
  • Working: 2. सत्र सक्रियपणे गणना (computing) करत आहे. ते तुमच्यासाठी थांबलेले नाही, त्यामुळे जर काही अधिक तातडीचे नसेल तरच त्याला आयकॉन मिळेल.
  • Acknowledged needs-you: 1. तुम्ही प्रॉम्ट किंवा प्रश्न आधीच पाहिला आहे परंतु अद्याप उत्तर दिलेले नाही. तुम्हाला याची जाणीव आहे, त्यामुळे तातडीचे प्रमाण न पाहिलेल्या व्यत्ययापेक्षा एक पायरी खाली येते.
  • Idle or rate limited: 0. सत्र केवळ पार्श्वभूमीतील आवाजासारखे (ambient noise) आहे. ते आपल्या पाळीची वाट पाहत आहे किंवा काहीही करत नाहीये.

हे स्केल वापरकर्त्याच्या कृतीशी सुसंगत आहे. जेव्हा तुम्ही एखादे हँडऑफ पूर्ण करता, तेव्हा सत्र 'working' किंवा 'idle' मध्ये येते. जेव्हा एखादे 'working' सत्र एरर देते, तेव्हा ते थेट 'stalled' मध्ये जाते. जेव्हा तुम्ही प्रॉम्ट स्वीकारण्यासाठी क्लिक करता पण तुम्हाला