એક-આઇકનનો અવરોધ
તમારા ભારે કોડિંગ સત્ર દરમિયાનની તમારી સ્ક્રીનની કલ્પના કરો. એક ટર્મિનલ ટેબમાં, Claude Code એક React કમ્પોનન્ટનું રિફેક્ટરિંગ કરી રહ્યું છે. બીજામાં, Codex એક Python મોડ્યુલ ફરીથી લખી રહ્યું છે. ત્રીજું એજન્ટ યુનિટ ટેસ્ટ જનરેટ કરી રહ્યું છે, ચોથું એજન્ટ API કીની રાહ જોઈ રહ્યું છે, અને પાંચમું એજન્ટ હમણાં જ બેકગ્રાઉન્ડ લિન્ટર પાસ પૂરું કર્યું છે. તમારા મેનૂ બારમાં—અથવા તમે જે સિસ્ટમ ટ્રેનો ઉપયોગ કરતા હોવ તેમાં—માત્ર એક જ સ્ટેટસ આઇકન માટે જગ્યા છે. આખા સ્વોર્મ (swarm) નું પ્રતિનિધિત્વ કરવા માટે એક નાનકડો ટપકું અથવા લેબલ હોવું જોઈએ. પ્રશ્ન એ છે કે કયું સત્ર તે સ્થાન મેળવશે.
આળસુ જવાબ એ છે કે જે સત્ર છેલ્લે હલચલ કરી હોય તે બતાવવું. તે તર્કસંગત લાગે છે. કંઈક થયું છે, તેથી તે ઉપર આવે છે. પણ આ વૃત્તિ ખોટી છે, અને તે તમને મોંઘું પડશે. ટાઈમસ્ટેમ્પ અપડેટ કરતો બેકગ્રાઉન્ડ ફાઇલ વોચર મદદ માટેની પોકાર નથી. બીજી તરફ, દસ મિનિટ પહેલા પરમિશન એરર આવેલું સત્ર અદ્રશ્ય રીતે બેસી શકે છે, જે તમારી "yes" લખવાની અથવા પાથ સુધારવાની રાહ જોઈ રહ્યું છે. જો તમે તાજેતરના સમય (recency) મુજબ રેન્ક આપશો, તો તમે જે વસ્તુ પર ધ્યાન આપવાની સૌથી વધુ જરૂર છે તેને છુપાવી દેશો. તમારે એક્શનબિલિટી (actionability) મુજબ રેન્ક આપવાની જરૂર છે.
તાજગી (Recency) કેમ નિષ્ફળ જાય છે
ડેવલપર્સ ટાઈમસ્ટેમ્પનો ઉપયોગ એટલા માટે કરે છે કારણ કે તે સરળ છે. દરેક સિસ્ટમ તેને ઉત્પન્ન કરે છે, દરેક ડેટાબેઝ તેને ઇન્ડેક્સ કરે છે, અને સોર્ટિંગ એ કોડની એક જ લાઇન છે. પરંતુ જે ક્ષણે તમે અનેક સ્વતંત્ર વર્કર્સનું સંચાલન (orchestrating) કરવાનું શરૂ કરો છો, તે ક્ષણે સરળતા ઉપયોગી રહેતી નથી.
અહીં એક ચોક્કસ નિષ્ફળતાનું ઉદાહરણ છે. સત્ર પાંચે (Session five) હમણાં જ એક લોગ લાઇન ઉમેરી છે કારણ કે તેના ડિપેન્ડન્સી વોચરે node_modules માં ફાઇલ ફેરફાર નોંધ્યો છે. તેનું ટાઈમસ્ટેમ્પ રિફ્રેશ થઈને અત્યારનું થઈ ગયું છે. જોકે, સત્ર બેએ (Session two) ત્રણ મિનિટ પહેલા તમને એક પ્રશ્ન પૂછ્યો હતો: "શું મારે આ પેકેજ ઇન્સ્ટોલ કરવું જોઈએ? (y/n)". તમે હજુ જવાબ આપ્યો નથી. જો તમારો મેનૂ બાર સૌથી નવા સત્રને બતાવે છે, તો સત્ર પાંચને ગ્રીન ગ્લો મળશે અને સત્ર બે લિસ્ટમાં અદ્રશ્ય થઈ જશે. કંઈપણ તૂટેલું દેખાશે નહીં. છતાં તમારા એજન્ટોમાંથી એક તમારા નિર્ણય પર અટકી ગયો છે જ્યારે તમે એ લિન્ટરનું મોનિટરિંગ કરવામાં વ્યસ્ત છો જેને તમારી જરૂર નથી.
તાજગી (Recency) ગતિને માપે છે. તાકીદ (Urgency) ને અર્થની જરૂર છે. જ્યાં સુધી ફાઇલ રાઈટ તમારા માટે કોઈ કાર્ય ઊભું ન કરે ત્યાં સુધી તેનો કોઈ આંતરિક અર્થ નથી. બીજી બાજુ, વેઇટિંગ પ્રોમ્પ્ટ એ શુદ્ધ એક્શનબિલિટી છે. તમે બેકગ્રાઉન્ડમાં વસ્તુઓ બદલાતી જોઈને કોડ શિપ કરી શકતા નથી. તમે બ્લોકર્સ દૂર કરીને તેને શિપ કરો છો. વિચારવાની પદ્ધતિમાં પ્રથમ ફેરફાર સરળ છે: ટાઈમસ્ટેમ્પને માત્ર ટાઈ-બ્રેકર (tiebreaker) તરીકે ગણો, ક્યારેય પ્રાથમિક સિગ્નલ તરીકે નહીં.
પહેલા વર્ગીકરણ કરો, પછી સોર્ટ કરો
વધુ સારો અભિગમ એ બે-પગલાંનું ફિલ્ટર છે. પ્રથમ, દરેક સત્રને તે તમારી પાસેથી શું ઈચ્છે છે તેના આધારે લેબલ કરો. બીજું, તે લેબલ્સને રેન્ક આપો. માત્ર ત્યારે જ ઘડિયાળ જુઓ જ્યારે બે સત્રો સમાન લેબલ ધરાવતા હોય.
આ તમને તમારા વર્કફ્લોમાં "તાકીદનું" (urgent) ખરેખર શું છે તે વ્યાખ્યાયિત કરવા મજબૂર કરે છે. રેટ-લિમિટેડ (rate-limited) સત્ર તાકીદનું નથી; તે ઊંઘી રહ્યું છે. વર્કિંગ સત્ર વ્યસ્ત છે, પરંતુ જો તેને નિર્ણયની જરૂર નથી, તો તે શાંતિથી કમ્પ્યુટિંગ ચાલુ રાખી શકે છે. અટકેલું (stalled) સત્ર તાકીદનું છે કારણ કે એરર્સ વધતા જાય છે. વણઉત્તરિત હેન્ડઓફ (unanswered handoff) તાકીદનું છે કારણ કે આગલું સ્ટેપ ખરેખર તમારી જવાબદારી છે અને જ્યાં સુધી તમે પગલાં ન લો ત્યાં સુધી એજન્ટ આગળ વધી શકતો નથી.
વર્ગીકરણ તમારા મેનૂ બારને ન્યૂઝ ફીડમાંથી ટાસ્ક લિસ્ટમાં ફેરવી દે છે. ત્યારબાદ રેન્કિંગ સ્ટેપ મિકેનિકલ બની જાય છે. તમે પહેલેથી જ નક્કી કરી લીધું છે કે બ્લોક થયેલ વર્કર વ્યસ્ત વર્કર કરતા વધુ મહત્વનો છે. તમે પહેલેથી જ નક્કી કરી લીધું છે કે વણજોયેલો પ્રશ્ન જોયેલા પ્રશ્ન કરતા વધુ મહત્વનો છે. સમયનો ઉપયોગ ત્યારે જ થાય છે જ્યારે બે સત્રો સમાન પ્રાથમિકતા સ્તર પર મદદ માટે પોકાર કરતા હોય. ત્યારે જ, અને માત્ર ત્યારે જ, જૂનું સત્ર જીતે છે. તે 'પહેલા આવનારને પ્રથમ સેવા' (first-come, first-served) ની નિષ્પક્ષતા માટે એક નાની રાહત છે, પરંતુ તેણે ક્યારેય સ્ટેટ (state) ને ઓવરરાઈડ ન કરવું જોઈએ.
એક વ્યવહારુ પ્રાથમિકતા સ્કેલ
Agent Island v1.7.1 માં, ટીમે