Google ने 22 अक्टूबर को Elephant-Goldfish Model जारी किया। यह ओपन सोर्स प्लगइन AI एजेंटों के साथ सॉफ्टवेयर विकास में योजना बनाने के चरण को व्यवस्थित करने के लिए बनाया गया है। इसका मुख्य विचार सरल है: एक सत्र परियोजना का संदर्भ और उद्देश्य सँभालकर रखता है, जबकि अलग एजेंटों को डिजाइन दस्तावेज दिया जाता है, ताकि वे अस्पष्टता, छूटी हुई धारणाएँ और कमियाँ ढूँढ़ें। कोड लिखना आवश्यकताएँ स्पष्ट करने और समीक्षा के बाद होना चाहिए, उनकी जगह नहीं लेना चाहिए।
Google के अनुसार, प्लगइन शुरू में उसके इंजीनियरों के लिए विकसित किया गया था और हजारों कर्मचारी इसका उपयोग करते हैं। यह कंपनी का दिया हुआ आँकड़ा है, इस तरीके से बने सॉफ्टवेयर की गुणवत्ता का स्वतंत्र माप नहीं। रिपॉजिटरी Apache 2.0 लाइसेंस के तहत उपलब्ध है और दस्तावेज में एक और स्पष्टीकरण है: यह Google का आधिकारिक समर्थन प्राप्त उत्पाद नहीं है। रोजमर्रा के विकास कार्य में इसे शामिल करने पर विचार कर रही टीमों के लिए यह अंतर महत्वपूर्ण है।
संदर्भ याद रखना और नए सिरे से देखना, दोनों क्यों जरूरी हैं
Elephant-Goldfish नाम काम के बँटवारे का रूपक है। Elephant संदर्भ से भरपूर सत्र है, जो चर्चा का इतिहास, आर्किटेक्चर और बातचीत के दौरान लिए गए छोटे निर्णय सँभालता है। Goldfish अपेक्षाकृत साफ शुरुआत करता है: वह योजना वाली बातचीत में जमा हुए स्पष्टीकरणों पर निर्भर हुए बिना विनिर्देश पढ़ता और परखता है। यहाँ 2 नए प्रशिक्षित मॉडल या किसी नई मॉडल प्रशिक्षण प्रणाली की घोषणा नहीं की गई है।
यह बँटवारा मिलकर काम करने की एक परिचित समस्या से जुड़ा है, जो AI के बिना भी होती है। किसी मुद्दे पर लंबी बातचीत कर चुके लोग अक्सर जानते हैं कि उनका मतलब क्या है, भले ही उनका दस्तावेज उसे अच्छी तरह समझाता न हो। नया पाठक जब किसी वाक्य का अलग अर्थ निकालता है, तो वह कमी सामने आती है। यह तरीका उस क्षण को प्रक्रिया का जानबूझकर तय हिस्सा बनाना चाहता है, इससे पहले कि अस्पष्ट विनिर्देश ऐसी फाइलों और फंक्शन में बदल जाए जिन्हें बाद में बदलना कठिन हो।
बातचीत अलग कर देने से सही समीक्षा की गारंटी नहीं मिलती। एजेंट कोई दोष छोड़ सकता है, छोटी समस्या को जरूरत से ज्यादा महत्व दे सकता है या अधूरी योजना से सहमत हो सकता है। संभावित लाभ संरचना में है: समीक्षा को अपनी भूमिका और इनपुट मिलता है, वह उसी बातचीत में गायब नहीं होती जिसने योजना बनाई थी। कौन सी आपत्तियाँ उचित हैं और कौन से बदलाव समाधान बेहतर बनाते हैं, यह इंजीनियर को अब भी तय करना है। एजेंटों की संख्या अपने आप गुणवत्ता का प्रमाण नहीं है।
कोड से पहले 3 चरण
Google की घोषणा मिलकर डिजाइन करने के 3 चरण बताती है। पहले समस्या तय की जाती है और विकल्पों पर बहस होती है, इस नियम के साथ कि उस चरण में कोड नहीं लिखा जाएगा। फिर Markdown दस्तावेज तैयार होता है, जिसमें समस्या, तकनीकी तरीका, विचार किए गए विकल्प और लागू करने की विस्तृत योजना शामिल होती है। अंत में अलग एजेंट जाँचते हैं कि दस्तावेज स्पष्ट है और कार्यान्वयन के लिए तैयार है या नहीं।
यह केवल विकास उपकरण में एक और कमांड जोड़ना नहीं, बल्कि जोर बदलना है। प्रगति को एजेंट के बनाए कोड की मात्रा से मापने के बजाय बीच का पड़ाव ऐसा दस्तावेज है जिसे दूसरा व्यक्ति समझ और परख सके। इससे टीम पहले ही चर्चा कर सकती है कि सफलता किसे माना जाएगा, किन फाइलों में बदलाव अपेक्षित है और क्या काम के दायरे से बाहर है। ये उत्पाद और इंजीनियरिंग के निर्णय हैं, भले ही उन्हें शब्द देने में AI मदद करे।
इस तरीके से ऐसा दस्तावेज भी बनता है जिसकी ओर कार्यान्वयन बदलने पर लौटा जा सकता है। लिखित विनिर्देश यह सुनिश्चित नहीं करता कि कोड उसके अनुरूप रहेगा, लेकिन तुलना का आधार देता है। मूल निर्णय का रिकॉर्ड न हो तो जानबूझकर किए बदलाव और काम के दौरान अनजाने में आई भिन्नता के बीच फर्क करना कठिन हो सकता है। इसलिए संभावित मूल्य केवल पहली बार कोड तैयार करने तक सीमित नहीं, बल्कि बाद में यह समझाने तक जाता है कि वही समाधान क्यों चुना गया।
समीक्षा की शुरुआत समझ से होती है
Google की समीक्षा प्रक्रिया में अलग एजेंट को पहले दस्तावेज का आर्किटेक्चर और उद्देश्य समझाना होता है। यदि वह सही ढंग से उनका वर्णन नहीं कर पाता, तो यह संकेत है कि विनिर्देश अभी अस्पष्ट है। इसके बाद आलोचनात्मक समीक्षक सीमांत स्थितियाँ, छिपी निर्भरताएँ और तर्क की कमियाँ खोजते हैं। एक और जाँच कार्यान्वयन की तैयारी और उसे शुरू करने के लिए जरूरी जानकारी देखती है।
यह क्रम इसलिए उपयोगी है क्योंकि टिप्पणियों की लंबी सूची गहन लग सकती है, जबकि समीक्षक ने समस्या ही गलत समझी हो। दोबारा समझाने की शर्त ध्यान को इस सवाल से हटाती है कि पाठ पेशेवर लगता है या नहीं, और इस पर लाती है कि कोई दूसरा व्यक्ति या एजेंट उसके आधार पर काम कर सकता है या नहीं। समझ गलत हो तो निर्देशों का एक पन्ना जोड़ने से बेहतर किसी मुख्य वाक्य को सुधारना हो सकता है। समझ सही हो तो डिजाइन की ही जाँच की जा सकती है।
कार्यान्वयन के लिए तैयार होने का अर्थ भी सावधानी से लेना चाहिए। विस्तृत दस्तावेज फाइलों, डेटा संरचनाओं और इंटरफेस की अनिश्चितता दूर कर सकता है, लेकिन वास्तव में लिखे गए कोड के परीक्षण की जगह नहीं लेता। वह अपने आप उत्पादन परिवेश की हर स्थिति भी नहीं जाँचता। उसका अर्थ यह है कि लागू करने के लिए एक निश्चित योजना मौजूद है, यह नहीं कि बदलाव को व्यापक सुरक्षा मंजूरी मिल गई है या उसमें कोई दोष नहीं है।
खुला प्लगइन, जिम्मेदारी डेवलपर की
Google इस प्लगइन को ऐसे तरीके का हिस्सा बताती है जिसमें इंजीनियरिंग संबंधी विवेक मनुष्य के पास रहता है। रिपॉजिटरी के दस्तावेज में Antigravity, Claude Code और Codex के लिए इंस्टॉलेशन के तरीके तथा दूसरे परिवेशों के लिए मार्गदर्शन है। इसका उपयोग करने वाली टीम को अपने परिवेश और संस्करण के अनुरूप दस्तावेज देखना होगा। इंस्टॉलेशन विकल्पों की सूची हर कार्यस्थल में एक जैसा व्यवहार या समान समर्थन सुनिश्चित नहीं करती।
लॉन्च की घोषणा में कंपनी ने ऐसी कोई संख्यात्मक तुलना नहीं दी जो साबित करे कि प्लगइन कितनी त्रुटियाँ रोकता है या हर परियोजना में कितना समय बचाता है। अतिरिक्त योजना दोबारा काम करने की जरूरत घटा सकती है, लेकिन उसमें समय, पढ़ना और टिप्पणियों पर निर्णय लेना भी लगता है। छोटे कार्य में यह लागत अधिक महसूस हो सकती है; कई प्रणालियों पर निर्भर बदलाव में पहले स्पष्टता लाने का महत्व अलग हो सकता है। निर्णय काम के दायरे पर निर्भर करता है।
इजराइल की टीमों के लिए इसकी प्रासंगिकता मुख्य रूप से मौजूदा विकास उपकरणों के साथ कार्यप्रवाह में है। घोषणा में इजराइल के लिए अलग पहुँच का रास्ता या हिब्रू के लिए विशेष समर्थन का वादा नहीं है। इससे एक व्यापक सिद्धांत निकलता है: जब एजेंट कोई बदलाव करने वाला हो, तो निर्देश अपने आप समझ आने चाहिए। बातचीत की याददाश्त पर निर्भर दस्तावेज उपकरण, डेवलपर या समीक्षक बदलने पर अपना अर्थ खो सकता है।
यहाँ खबर ऐसे उपकरण का जारी होना है जो एजेंटों के साथ काम में योजना और समीक्षा की भूमिका स्पष्ट करता है। वह इंजीनियर से अपनी प्रणाली समझना छोड़ने के लिए नहीं कहता, बल्कि यह परखने का तरीका देता है कि उस समझ को इस तरह लिखा गया है या नहीं कि दूसरे उसका उपयोग कर सकें। प्रक्रिया सफल हो तो लंबी बातचीत ही उद्देश्य को सँभालने वाली अकेली जगह नहीं रहती: एक दस्तावेज होता है, उसे आलोचनात्मक नजर से पढ़ने वाले होते हैं और अंतिम निर्णय के लिए जिम्मेदार व्यक्ति होता है।