डेव्हलपर्स आता ओव्हरराईट झालेल्या स्टेट फाइल्स किंवा लपलेल्या फाईल क्लॅशेची (file clashes) भीती न बाळगता एकाच वेळी अनेक कोडिंग-एजंट सेशन्स सुरू करू शकतात. एक 'अॅडव्हायझरी "शेअर-नथिंग" पॅटर्न' (advisory “share-nothing” pattern) प्रत्येक एजंटच्या वर्कस्पेसला वेगळे करतो आणि संभाव्य संघर्षांची (conflicts) सूचना देतो. हा दृष्टिकोन 'हार्ड लॉक्स'ऐवजी (hard locks) एका हलक्या वजनाच्या रजिस्ट्रीचा (registry) वापर करतो, जी काम सुरू होण्यापूर्वीच ओव्हरलॅपिंग कामाची सूचना देते, ज्यामुळे एखादा सेशन क्रॅश झाला तरी पाइपलाइन्स सुरू राहतात.
पॅरलल एजंट्समुळे समस्या का निर्माण होतात
एकाच रिपॉझिटरीमध्ये एकापेक्षा जास्त ऑटोमेटेड कोडिंग असिस्टंट चालवल्यामुळे कोड जनरेशन, टेस्टिंग किंवा रिफॅक्टरिंगचा वेग वाढतो. प्रत्यक्षात, दोन समस्या लगेच समोर येतात.
- स्टेट करप्शन (State corruption) – दोन एजंट्स एकाच स्टेट फाईलमध्ये लिहितात; नंतरची प्रक्रिया आधीच्या प्रक्रियेला ओव्हरराईट करते, ज्यामुळे प्रगती पुसली जाते.
- फाईल कोलिजन (File collision) – दोन एजंट्स एकमेकांशी अनभिज्ञ राहून एकाच सोर्स फाईलमध्ये बदल करतात. जेव्हा 'डिफ' (diff) मध्ये भिन्न बदल दिसून येतात, तेव्हा हा संघर्ष उशिरा लक्षात येतो.
या दोन्ही समस्यांमुळे डेव्हलपरचा वेळ वाया जातो आणि शोधणे कठीण असे बग्स (bugs) निर्माण होऊ शकतात.
"शेअर नथिंग" (share nothing) नियम
मूळ कल्पना सोपी आहे: प्रत्येक एजंटला डिस्कवर स्वतःचा खाजगी स्क्रॅचपॅड (scratchpad) मिळतो आणि तो फक्त त्याच सेशनच्या फाईल्समध्ये लिहितो. प्रत्येक ब्रांचसाठी फक्त एक जाणीवपूर्वक शेअर केलेली फाईल वापरण्याची परवानगी आहे आणि ती "लास्ट-रायटर-विन्स" (last-writer-wins) नियमाचे पालन करते—जो एजंट शेवटी लिहितो, तोच अंतिम मजकूर ठरवतो.
एक प्रेझन्स लेअर (presence layer) प्रत्येक सक्रिय सेशनचा मागोवा घेते:
- ब्रांचचे नाव
- स्पर्श केलेल्या (touched) फाईल्सची यादी
- शेवटच्या हालचालीचा टाइमस्टॅम्प (Timestamp)
जेव्हा नवीन सेशन सुरू होते, तेव्हा ते रजिस्ट्रीचा सल्ला घेते. जर दुसरे एखादे सेशन आधीच त्याच फाईल्स हाताळत असेल, तर काम सुरू होण्यापूर्वीच डेव्हलपरला चेतावणी मिळते.
अॅडव्हायझरी विरुद्ध ब्लॉकिंग लॉक्स (Advisory vs. blocking locks)
पारंपारिक लॉक फाइल्स एका बंद रस्त्यासारख्या (dead-end road) काम करतात: एकदा लॉक घेतल्यावर, जोपर्यंत तो रिलीज होत नाही तोपर्यंत इतर कोणतीही प्रक्रिया थांबते. जर संबंधित सेशन क्रॅश झाले, तर लॉक अनिश्चित काळासाठी राहू शकतो, ज्यामुळे जुन्या (stale) लॉक फाइल्स मॅन्युअली शोधणे भाग पडते.
अॅडव्हायझरी मॉडेल अधिक लवचिक आहे. जेव्हा संभाव्य संघर्ष आढळतो तेव्हा ते चेतावणी देते, परंतु नवीन सेशन थांबवत नाही. जर रजिस्ट्री एन्ट्री जुनी असेल—म्हणजेच ती तयार करणारी प्रक्रिया आता अस्तित्वात नसेल—तरीही सिस्टम फक्त चेतावणी देते, ज्यामुळे डेव्हलपरला पुढे जायचे की नाही याचा निर्णय घेता येतो.
हा पॅटर्न कसा लागू करायचा
- रायटरनुसार स्टेट विभाजित करा (Partition state by writer) – प्रत्येक एजंटला तात्पुरत्या फाईल्स आणि स्टेटसाठी स्वतःची डिरेक्टरी द्या. खरोखर जागतिक (global) डेटासाठी शेअर केलेल्या फाईल्स राखून ठेवा आणि तिथेच "लास्ट-रायटर-विन्स" नियम लागू करा.
- सुरुवातीलाच जागरूकता निर्माण करा (Inject awareness at launch) – एजंट सुरू होण्यापूर्वी, प्रेझन्स रजिस्ट्री वाचा आणि विनंती केलेल्या फाईलची यादी सध्याच्या एन्ट्रीजशी तपासा. ओव्हरलॅप आढळल्यास प्रक्रिया थांबवा किंवा चेतावणी द्या.
- वाचताना जिवंतपणाची (liveness) पडताळणी करा – रजिस्ट्री एन्ट्री तपासताना, नोंदवलेला प्रोसेस आयडी (process ID) अजूनही OS वर सुरू आहे की नाही हे तपासा. मृत (dead) प्रक्रियांशी संबंधित एन्ट्रीज काढून टाका.
- ब्लॉकिंगपेक्षा अॅडव्हायझरीला प्राधान्य द्या – डेव्हलपर्सना नियंत्रण ठेवू द्या. चेतावणीमुळे त्यांना काम सुरू ठेवणे, थांबवणे किंवा रद्द करणे शक्य होते, ज्यामुळे डेडलॉक (deadlock) टाळता येतो.
- वेटिंग स्टेट्सचा मागोवा घ्या (Track waiting states) – जेव्हा अनेक एजंट्स सक्रिय असतात, तेव्हा डेव्हलपरचे लक्ष हे अडथळा (bottleneck) बनते. कोणते एजंट्स मानवी इनपुटची वाट पाहत आहेत ते दर्शवा, जेणेकरून कामाला पुन्हा प्राधान्य देता येईल.
हे सर्व साध्या JSON फाईल्सच्या डिरेक्टरीसह तयार केले जाऊ शकते; यासाठी कोणत्याही बाह्य डेटाबेस किंवा मेसेज बसची (message bus) आवश्यकता नाही. साध्या स्टोरेज फॉरमॅटमुळे ही सिस्टम ऑडिट करणे सोपे होते आणि ती विविध वातावरणात (environments) सहज वापरता येते.
जोखीम आणि प्रतिवाद
काही टीम्स असा युक्तिवाद करू शकतात की 'हार्ड लॉक' सुरक्षिततेची हमी देते: कोणतेही दोन एजंट्स एकाच फाईलमध्ये लिहू शकत नाहीत. परंतु, याचा तोटा म्हणजे कमी लवचिकता (resilience)—क्रॅश झालेल्या सेशन्समुळे 'ऑर्फन लॉक' (orphaned locks) राहतात, ज्यामुळे संपूर्ण वर्कफ्लो थांबतो.
काय लक्षात ठेवावे
जर तुम्ही एकापेक्षा जास्त AI-चालित कोडिंग असिस्टंट्स वापरत असाल, तर "शेअर नथिंग" अॅडव्हायझरी पॅटर्न त्यांना एकमेकांच्या कामात अडथळा आणण्यापासून रोखण्यासाठी एक व्यावहारिक मार्ग प्रदान करतो. स्टेट वेगळी करून, हेतू लवकर स्पष्ट करून आणि पुढे कधी जायचे याचा निर्णय मानवांना देऊन, ही पद्धत सुरक्षितता आणि आधुनिक डेव्हलपमेंट पाइपलाइन्सची लवचिकता यांचा समतोल राखते.
