कई AI एजेंट एक ही रेपो में छोड़ दिए, तो जो हुआ

AI एजेंट के साथ काम करते-करते लालच अपने-आप जाग जाता है। एक सेशन बग ठीक कर रहा हो, उतने में दूसरा रीफ़ैक्टरिंग करे, और तीसरा किसी इश्यू की पड़ताल - क्यों नहीं? मॉडल तो कई चलाए जा सकते हैं, तो प्रोडक्टिविटी भी उसी अनुपात में बढ़ेगी ही।

मैंने भी ऐसे ही शुरुआत की। और एक हफ़्ते में समझ गया। पैरलल एजेंटों का असली दुश्मन मॉडल की क़ाबिलियत नहीं, बल्कि वह वर्किंग डायरेक्टरी है जिसे वे साझा करते हैं।

HEAD एक ग्लोबल वेरिएबल है

कारण एक वाक्य में सिमट जाता है। एक git चेकआउट को कई सेशन साझा करें, तो "मौजूदा ब्रांच" नाम की स्टेट सबका ग्लोबल वेरिएबल बन जाती है।

दो इंसान एक ही कंप्यूटर पर एक साथ काम कर रहे हों - यह तस्वीर सोचते ही अजीब लगने लगती है, पर एजेंट चलाते समय यह ख़याल आया ही नहीं। हर टर्मिनल टैब में एक-एक सेशन चल रहा है, तो लगता है सब एक-दूसरे से अलग-थलग हैं। पर फ़ाइल सिस्टम एक है, और HEAD भी एक। जिस पल एक सेशन git checkout करता है, बाक़ी सारे सेशनों के पैरों तले की ज़मीन बदल जाती है।

उस हफ़्ते जो हादसे फटे, उनकी क़िस्में साफ़-साफ़ अलग थीं।

ब्रांच हाईजैक। सेशन A अपनी टॉपिक ब्रांच पर काम कर रहा था, इसी बीच सेशन B ने अपने काम के लिए ब्रांच बदल दी। A ने अनजाने में कमिट किया, और कमिट B की ब्रांच पर चढ़ गया। उल्टी दिशा में भी हुआ। A कमिट करने ही वाला था कि ब्रांच develop पर बदली हुई निकली, और प्रोटेक्टेड ब्रांच पर सीधे कमिट रोकने वाले हुक ने ब्लॉक कर दिया, तब जाकर हादसा टला। हुक न होता तो सीधा घुस जाता।

अनाथ कमिट। सेशन A की टॉपिक ब्रांच को सेशन B ने सफ़ाई के काम के दौरान डिलीट कर दिया। A के कमिट किसी भी ब्रांच के न रहकर अनाथ हो गए, और reflog खंगालकर कमिट हैश ढूँढा, फिर cherry-pick से वापस निकाला। बरामद हो गए, यही ग़नीमत है - reflog एक्सपायर हो गया होता या हैश न मिलता, तो पूरा का पूरा काम भाप बनकर उड़ जाता।

स्टेजिंग का दूषित होना। जिस पल सेशन A कमिट बना रहा था, उस पल सेशन B की स्टेज की हुई फ़ाइल-डिलीट भी स्टेजिंग एरिया में साथ चढ़ी हुई थी। वैसे का वैसा कमिट हो जाता तो A के कमिट में B का डिलीट घुलमिल जाता। diff पर नज़र दौड़ाते हुए एक अनजाना बदलाव दिखा, तब छाँटा गया - एजेंट ने कमिट से ठीक पहले diff न देखा होता तो पता ही नहीं चलता।

दोहरा इम्प्लीमेंटेशन। सबसे खोखली क़िस्म। दो सेशनों ने एक-दूसरे के वजूद से बेख़बर, एक ही फ़ीचर अलग-अलग बना डाला। दोनों ने मेहनत से बढ़िया बनाया था, और एक को पूरा का पूरा फेंकना पड़ा। पैरलल चलाकर जो समय बचाया था, वह ज्यों का त्यों लौटा दिया।

वेरिफ़िकेशन गेट पर भी एक-दूसरे के पैर कुचलते हैं

दिक्कत सिर्फ़ फ़ाइलों और ब्रांचों की नहीं थी। हमारे हार्नेस में एक गेट है, जो सेशन ख़त्म होने से पहले पूरे रेपो का स्टैटिक एनालिसिस और टेस्ट चलाता है, ताकि टूटी हालत में काम समेटा न जा सके। अकेले सेशन के लिए यह शानदार इंतज़ाम है।

पैरलल सेशनों में यही एक-दूसरे की टाँग खींचने वाला फंदा बन गया। सेशन A ने सिर्फ़ डॉक्यूमेंट छुए थे, पर सेशन B जिस फ़ाइल को उसी वक़्त ठीक कर रहा था, उसके कंपाइल एरर की वजह से A का गेट फ़ेल हो जाता है। A अपना टर्न "यह मेरा बदलाव नहीं है" साबित करने में फूँकता है, और बुरे दिन B के समेटने तक 30 मिनट इंतज़ार में गए। सबसे बुरी घटना यह रही कि एक सेशन ने गेट पास करने के लिए दूसरे सेशन का चालू काम वाला कोड ही ठीक कर डाला। गेट उल्टे दूसरे के काम में हाथ डलवाने वाला प्रलोभन बन गया।

जाँच अपने-आप में ग़लत नहीं है। जाँच का दायरा "पूरा रेपो" होना - यही उस पल ग़लत हो गया, जिस पल रेपो किसी एक का नहीं रहा।

तीन रक्षा-पंक्तियाँ

हादसे क़िस्म-वार झेलने के बाद रक्षा की तीन परतें खड़ी कीं।

1. worktree आइसोलेशन को डिफ़ॉल्ट बनाओ। git worktree से हर सेशन को अपनी स्वतंत्र वर्किंग डायरेक्टरी दे दो, तो HEAD साझा वेरिएबल नहीं रहता। ब्रांच हाईजैक, अनाथ कमिट, स्टेजिंग का दूषित होना - जड़ से मिट जाते हैं। ऊपर की चार क़िस्मों में से तीन इस एक चाल से ख़त्म। पर यह मुफ़्त नहीं है। मोनोरेपो हो तो हर worktree में डिपेंडेंसी इंस्टॉल और कोड जनरेशन दोबारा करना पड़ता है, और git-crypt जैसे worktree से न पटने वाले टूल इस्तेमाल करने वाले रेपो में इसे थोपना मुश्किल है। हमारा भी एक रेपो इसी अड़चन की वजह से साझा चेकआउट पर टिका है, और इसीलिए बाक़ी दो रक्षा-पंक्तियाँ ज़रूरी हैं।
2. कमिट से ठीक पहले ब्रांच दोबारा जाँचो। सेशन काम शुरू करते समय दर्ज कर लेता है कि "मैं इस ब्रांच पर काम कर रहा हूँ", और कमिट से ठीक पहले मौजूदा HEAD से मिलान करता है। अलग निकले तो कमिट रोककर पहले हालात समझो। नियम हास्यास्पद हद तक सरल है, पर ब्रांच हाईजैक के सारे हादसे इसी से निकले थे कि "कमिट करते पल का HEAD वह HEAD नहीं था जो मैं समझ रहा था"। इंसान होता तो प्रॉम्प्ट में ब्रांच का नाम दिखता और भाँप लेता, पर एजेंट को साफ़-साफ़ न कहो तो वह जाँचता नहीं।
3. वेरिफ़िकेशन गेट को अपने बदलावों तक सीमित करो। सेशन के समापन गेट के जाँचने का दायरा पूरे रेपो से घटाकर उन्हीं फ़ाइलों तक ले आओ जिन्हें उस सेशन ने सचमुच बदला है। दूसरे के WIP से मेरा समापन अटकने की नौबत भी मिट जाती है, और गेट पास करने के लिए दूसरे के कोड में हाथ डालने का प्रलोभन भी। पूरे रेपो की सेहत तो CI वैसे भी कमिट हो चुकी हालत पर दोबारा देखता है। सेशन गेट तक को पूरा रेपो देखने की ज़रूरत नहीं थी।

इनके ऊपर एक ऑपरेशनल नियम और चढ़ाया। सेशन चलाने से पहले खुली हुई ब्रांचों और PR पर नज़र दौड़ाकर देखता हूँ कि कोई दायरा आपस में टकरा तो नहीं रहा। दोहरा इम्प्लीमेंटेशन git के रोके रुकने वाली समस्या नहीं, बल्कि काम बाँटने की समस्या है, इसलिए इसे टूल से नहीं, आदत से ही रोका जा सकता था।

कन्करेंसी की समस्या सिर्फ़ डेटाबेस में नहीं थी

समेटकर देखा तो तस्वीर जानी-पहचानी है। साझा संसाधन, बिना लॉक की समानांतर पहुँच, रेस कंडीशन, और आइसोलेशन लेवल। जो समस्या हमने डेटाबेस और मल्टीथ्रेडेड कोड में दशकों से सीखी है, ठीक वही वर्किंग डायरेक्टरी के ऊपर दोबारा खेली गई।

एक एजेंट के साथ काम करते समय यह समस्या वजूद में ही नहीं होती। इंसान और एजेंट बारी-बारी काम करें, तब भी इंसान अनकहे तौर पर तालमेल बिठाने वाले की भूमिका निभाता है। समस्या उस पल शुरू होती है जब एजेंट कई हो जाते हैं और इंसान तालमेल छोड़ देता है। उस बिंदु से वर्किंग डायरेक्टरी एक ऐसा साझा संसाधन है जिसे कन्करेंसी कंट्रोल चाहिए, और आइसोलेशन के बिना चलाओ तो, जैसा डेटाबेस के साथ हुआ था, डेटा जाना तय है।

यह पैरलल एजेंट छोड़ देने की बात नहीं है। आज भी रोज़ कई सेशन चलाता हूँ। बदला बस एक है। अब उन्हें एक ही कमरे में ठूँसता नहीं हूँ।