डेवलपर्स अब ओवरराइट (overwritten) स्टेट फाइलों या छिपे हुए फाइल टकरावों (file clashes) के डर के बिना एक साथ कई कोडिंग-एजेंट सत्र (sessions) शुरू कर सकते हैं। एक एडवाइजरी "शेयर-नथिंग" (share-nothing) पैटर्न प्रत्येक एजेंट के वर्कस्पेस को अलग करता है और संभावित संघर्षों (conflicts) के बारे में चेतावनी देता है। यह दृष्टिकोण हार्ड लॉक्स (hard locks) के स्थान पर एक लाइटवेट रजिस्ट्री (lightweight registry) का उपयोग करता है जो काम ओवरलैप होने से पहले ही उसे फ्लैग कर देती है, जिससे सत्र क्रैश होने पर भी पाइपलाइन चलती रहती है।
पैरेलल एजेंट क्यों समस्या पैदा करते हैं
एक ही रिपॉजिटरी में एक से अधिक ऑटोमेटेड कोडिंग असिस्टेंट चलाने से कोड जनरेशन, टेस्टिंग या रिफैक्टरिंग की गति बढ़ जाती है। व्यवहार में, तुरंत दो समस्याएं सामने आती हैं।
- स्टेट करप्शन (State corruption) – दो एजेंट एक ही स्टेट फाइल में लिखते हैं; बाद में होने वाला राइट (write) पहले वाले को ओवरराइट कर देता है, जिससे प्रगति मिट जाती है।
- फाइल कोलिजन (File collision) – दो एजेंट एक-दूसरे से अनभिज्ञ होकर एक ही सोर्स फाइल को एडिट करते हैं। संघर्ष बाद में दिखाई देता है, जब एक 'diff' अलग-अलग बदलावों को दर्शाता है।
ये दोनों समस्याएं डेवलपर का समय बर्बाद करती हैं और ऐसे बग्स पैदा कर सकती हैं जिन्हें ट्रैक करना कठिन होता है।
"शेयर नथिंग" (share nothing) नियम
मूल विचार सरल है: प्रत्येक एजेंट को डिस्क पर अपना निजी स्क्रैचपैड (scratchpad) मिलता है और वह केवल उसी सत्र से संबंधित फाइलों में लिखता है। प्रति ब्रांच केवल एक जानबूझकर साझा की गई फाइल की अनुमति है, और यह "लास्ट-राइटर-विन्स" (last-writer-wins) नियम का पालन करती है—जो भी एजेंट अंत में लिखता है, वही अंतिम सामग्री निर्धारित करता है।
एक प्रेजेंस लेयर (presence layer) प्रत्येक सक्रिय सत्र को ट्रैक करती है:
- ब्रांच का नाम
- जिन फाइलों को छुआ जा रहा है उनकी सूची
- अंतिम गतिविधि का टाइमस्टैम्प
जब एक नया सत्र शुरू होता है, तो यह रजिस्ट्री से परामर्श करता है। यदि कोई अन्य सत्र पहले से ही उन्हीं फाइलों में से किसी को संभाल रहा है, तो डेवलपर को काम शुरू होने से पहले ही चेतावनी मिल जाती है।
एडवाइजरी बनाम ब्लॉकिंग लॉक्स (Advisory vs. blocking locks)
पारंपरिक लॉक फाइलें एक बंद सड़क (dead-end road) की तरह काम करती हैं: एक बार लॉक लेने के बाद, कोई भी अन्य प्रक्रिया लॉक रिलीज होने तक प्रतीक्षा करती है। यदि स्वामित्व वाला सत्र क्रैश हो जाता है, तो लॉक अनिश्चित काल तक बना रह सकता है, जिससे पुराने (stale) लॉक फाइलों को मैन्युअल रूप से खोजने के लिए मजबूर होना पड़ता है।
एडवाइजरी मॉडल अधिक सौम्य है। यह संभावित संघर्ष का पता चलने पर चेतावनी जारी करता है लेकिन नए सत्र को नहीं रोकता है। यदि रजिस्ट्री प्रविष्टि (entry) पुरानी है—यानी जिस प्रक्रिया ने इसे बनाया था वह अब मौजूद नहीं है—तो सिस्टम केवल चेतावनी देता है, जिससे डेवलपर को आगे बढ़ने का निर्णय लेने की स्वतंत्रता मिलती है।
इस पैटर्न को कैसे लागू करें
- राइटर के आधार पर स्टेट को विभाजित करें – प्रत्येक एजेंट को अस्थायी फाइलों और स्टेट के लिए अपना स्वयं का डायरेक्टरी दें। साझा फाइलों को वास्तव में वैश्विक डेटा के लिए आरक्षित रखें और वहां केवल "लास्ट-राइटर-विन्स" नियम लागू करें।
- लॉन्च के समय जागरूकता डालें – एजेंट शुरू होने से पहले, प्रेजेंस रजिस्ट्री को पढ़ें और अनुरोधित फ़ाइल सूची की तुलना मौजूदा प्रविष्टियों से करें। यदि ओवरलैप मिलता है तो प्रक्रिया को रोक दें या चेतावनी दें।
- रीड टाइम पर जीवंतता (liveness) सत्यापित करें – रजिस्ट्री प्रविष्टि का परामर्श करते समय, जाँचें कि क्या रिकॉर्ड की गई प्रोसेस आईडी अभी भी OS पर चल रही है। मृत प्रक्रियाओं (dead processes) से संबंधित प्रविष्टियों को हटा दें।
- ब्लॉकिंग के बजाय एडवाइजरी को प्राथमिकता दें – डेवलपर्स को नियंत्रण बनाए रखने दें। एक चेतावनी उन्हें जारी रखने, रोकने या रद्द करने की अनुमति देती है, जिससे डेडलॉक (deadlock) से बचा जा सकता है।
- प्रतीक्षा अवस्थाओं (waiting states) को ट्रैक करें – जब कई एजेंट सक्रिय होते हैं, तो डेवलपर का ध्यान ही बाधा (bottleneck) बन जाता है। प्रदर्शित करें कि कौन से एजेंट मानवीय इनपुट की प्रतीक्षा कर रहे हैं ताकि काम को पुन: प्राथमिकता दी जा सके।
यह सब JSON फाइलों की एक साधारण डायरेक्टरी के साथ बनाया जा सकता है; इसके लिए किसी बाहरी डेटाबेस या मैसेज बस की आवश्यकता नहीं है। सरल स्टोरेज फॉर्मेट सिस्टम को ऑडिट करने में आसान और विभिन्न वातावरणों (environments) में पोर्टेबल बनाता है।
जोखिम और प्रति-तर्क (Risks and counter-points)
कुछ टीमें तर्क दे सकती हैं कि हार्ड लॉक सुरक्षा की गारंटी देता है: कोई भी दो एजेंट कभी भी एक ही फाइल में नहीं लिख सकते। इसका नुकसान कम लचीलापन (resilience) है—क्रैश हुए सत्र अनाथ (orphaned) लॉक छोड़ देते हैं जो पूरे वर्कफ़्लो को रोक देते हैं।
किन बातों का ध्यान रखें
यदि आप कई AI-संचालित कोड असिस्टेंट्स का उपयोग कर रहे हैं, तो "शेयर नथिंग" एडवाइजरी पैटर्न उन्हें एक-दूसरे के काम में बाधा डालने से रोकने के लिए एक व्यावहारिक मार्ग प्रदान करता है। स्टेट को अलग करके, इरादे (intent) को जल्दी उजागर करके और मनुष्यों को यह तय करने देने के कि कब आगे बढ़ना है, यह विधि सुरक्षा और आधुनिक डेवलपमेंट पाइपलाइनों की मांग वाले लचीलेपन के बीच संतुलन बनाती है।