Google ने अपने डेवलपमेंट एनवायरनमेंट Antigravity में /boost नाम की एक नई कमांड जोड़ी है। इसे चलाने पर एक अकेले कोडिंग असिस्टेंट के बजाय एक मल्टी-एजेंट रीज़निंग पाइपलाइन शुरू होती है: एक ऑर्केस्ट्रेटर समस्या को पढ़ता है और उसे कार्यों में बाँटता है, उन्हें अलग-थलग दायरों में काम करने वाले विशेषज्ञ एजेंटों को सौंपता है, फिर नतीजे को स्वतंत्र सत्यापन राउंड से गुज़ारता है जो आप तक कुछ भी पहुँचने से पहले वास्तव में टेस्ट चलाते हैं। असली ख़बर यह नहीं है कि AI तेज़ी से कोड लिखता है। असली ख़बर यह है कि कोडिंग टूल ने सत्यापन को ख़ुद टूल के भीतर बनाना शुरू कर दिया है।

Google ने असल में क्या घोषणा की

Antigravity के आधिकारिक दस्तावेज़ों के अनुसार, /boost ख़ास तौर पर कठिन सॉफ़्टवेयर इंजीनियरिंग के लिए बनाया गया है: कॉन्करेंसी बग और रेस कंडीशन, एल्गोरिद्मिक ऑप्टिमाइज़ेशन, सूक्ष्म रिग्रेशन जो दिखते और ग़ायब होते रहते हैं, और कई फ़ाइलों में फैली जटिल रिफ़ैक्टरिंग। ये ठीक वही समस्याएँ हैं जिनमें एक पारंपरिक सिंगल-टर्न असिस्टेंट विफल रहता है, क्योंकि इन्हें हल करने के लिए सीधे जनरेशन के बजाय प्रयोग और पीछे लौटने की ज़रूरत होती है।

यह कमांड तीन स्पष्ट चरणों में चलती है:

  • योजना: एक प्राथमिक ऑर्केस्ट्रेटर आपका प्रॉम्प्ट प्राप्त करता है, वर्कस्पेस के संदर्भ की जाँच करता है, निष्पादन की रणनीति बनाता है और चुनौती को अलग-अलग, सत्यापन-योग्य उप-कार्यों में बाँटता है।
  • वितरित निष्पादन: ऑर्केस्ट्रेटर इन उप-कार्यों को विशेषज्ञ एजेंटों को सौंपता है। इम्प्लीमेंटेशन वर्कस्ट्रीम कोड और यूनिट टेस्ट लिखती हैं। इन्वेस्टिगेशन वर्कस्ट्रीम किसी भी फ़ाइल को बदले बिना मूल कारण की डिबगिंग करती हैं और कॉल ग्राफ़ ट्रेस करती हैं। लोकल वेरिफ़िकेशन एजेंट रिपोर्ट करने से पहले परिकल्पनाओं को जाँचने के लिए बिल्ड टारगेट और टेस्ट सूट चलाते हैं।
  • डिलीवरी से पहले सत्यापन: ऑर्केस्ट्रेटर निष्कर्षों को एकत्र करता है और पूरे टेस्ट सूट और एज केस के विरुद्ध रिग्रेशन जाँच चलाता है। अगर कोई असर्शन विफल होता है, तो त्रुटि का निदान स्वचालित सुधार के लिए अगले चक्र में भेजा जाता है, और आपको सत्यापित बदलावों का सारांश तभी मिलता है जब सब कुछ पास हो जाता है।

यह सब अस्थायी, अलग-थलग worktree के भीतर चलता है, यानी एजेंट आपके प्रोजेक्ट की वर्किंग कॉपी पर प्रयोग नहीं करते।

एक नहीं, तीन मोड

Google तीन अलग-अलग निष्पादन मोड का दस्तावेज़ीकरण करता है, और उनके बीच का अंतर ही व्यावहारिक रूप से उपयोगी हिस्सा है:

  • डिफ़ॉल्ट एजेंट: इंटरैक्टिव कोडिंग, कोडबेस नेविगेशन और सामान्य रिफ़ैक्टरिंग। कार्य की अवधि सेकंड से मिनट तक, एक सिंगल-एजेंट लूप, एक बार का सत्यापन। सभी प्लान पर उपलब्ध।
  • /boost: गहरी रीज़निंग और ज़िद्दी बग। कार्य की अवधि सेकंड से घंटों तक, तीन चरणों वाला पदानुक्रम, कई राउंड का स्वतंत्र सत्यापन। सशुल्क प्लान पर उपलब्ध।
  • /teamwork-preview: बड़े माइग्रेशन या पूरे सबसिस्टम के निर्माण पर कई दिनों तक काम करने वाली एजेंट टीमें, जिनमें Explorer, Worker, Critic और Auditor जैसी नामित भूमिकाएँ हैं, साथ ही सत्यापन गेट हैं जो किसी माइलस्टोन को मंज़ूरी मिलने से पहले जानबूझकर कोड को तोड़ने की कोशिश करते हैं।

इस क्रम पर ध्यान दीजिए: कार्य जितना बड़ा, निवेश उतना ही ज़्यादा गति के बजाय समीक्षा में जाता है। सॉफ़्टवेयर प्रोजेक्ट चलाने वाले हर व्यक्ति के लिए यह ध्यान देने लायक़ संकेत है।

यह सिर्फ़ डेवलपर के लिए नहीं, बल्कि व्यवसाय के मालिक के लिए क्यों मायने रखता है

पिछले दो सालों से प्रोग्रामिंग में AI की चर्चा गति की चर्चा रही है: प्रति मिनट कितनी पंक्तियाँ जनरेट होती हैं। समस्या यह है कि असली प्रोजेक्ट में गति अड़चन नहीं है। अड़चन भरोसा है। क्या यह कोड उन मामलों में वाक़ई काम करता है जिन्हें किसी ने आज़माया ही नहीं?

/boost की संरचना परोक्ष रूप से यही कहती है कि उद्योग भी इसी निष्कर्ष पर पहुँचा है। तेज़ी से आने वाला कोड बेकार है अगर डिलीवरी के बाद उसकी डिबगिंग में दो हफ़्ते लगें। इसलिए यह टूल तीन नियमों के इर्द-गिर्द बनाया गया है जो किसी भी तकनीकी टीम पर लागू होते हैं, AI के साथ या उसके बिना:

  • लेखक अपने काम को ख़ुद अंक नहीं देता: सत्यापन करने वाला पक्ष लागू करने वाले पक्ष से अलग होता है। दशकों से कोड समीक्षा के पीछे यही सिद्धांत रहा है। अब इसे टूल के भीतर लागू किया जाता है।
  • सबूत का मतलब निष्पादन है, दावा नहीं: टेस्ट पास होने के दावे को मान लेने के बजाय टेस्ट वास्तव में चलाए जाते हैं और उनका असली आउटपुट जाँचा जाता है।
  • अलगाव मूल की रक्षा करता है: प्रयोग एक अलग कॉपी में होते हैं, इसलिए विफल प्रयास कभी प्रोजेक्ट में नहीं रिसते।

अगर आप सॉफ़्टवेयर डेवलपमेंट ख़रीद रहे हैं, तो अपने विक्रेता से पूछने के लिए ठीक यही तीन सवाल हैं: समीक्षा कौन करता है, टेस्ट पास होने का सबूत क्या है, और प्रयोग कहाँ होते हैं?

क्या नहीं बदलता

ऐसी ख़बर को इस घोषणा के रूप में पढ़ना आसान है कि अब इंजीनियरों की ज़रूरत नहीं रही। दस्तावेज़ बिल्कुल साफ़ तौर पर इसका उल्टा कहते हैं: एजेंट आपके वर्कस्पेस के लिए कॉन्फ़िगर किए गए फ़ाइल एक्सेस नियमों और कमांड अनुमति नीतियों को विरासत में लेते हैं, और कोई भी संरक्षित कमांड या भरोसेमंद दायरों के बाहर का संपादन उपयोगकर्ता के सामने अनुमति का अनुरोध रखता है। श्रृंखला के अंत में एक ज़िम्मेदार इंसान होता है।

और अनुमतियाँ इसका छोटा आधा हिस्सा हैं। एजेंट वह समस्या हल करता है जो आपने बताई। वह यह नहीं जान सकता कि ख़ुद विवरण ही ग़लत था। उसे नहीं पता कि आपका बिलिंग चक्र 30 तारीख़ को नहीं बल्कि 25 तारीख़ को बंद होता है, कि यह फ़ील्ड किसी सेल्स प्रतिनिधि को कभी नहीं दिखनी चाहिए, या कि जब आपका ग्राहक "ऑर्डर" कहता है तो उसका मतलब आपके मतलब से अलग होता है। आवश्यकताएँ तय करना, क्षेत्र को समझना और फ़ैसले की ज़िम्मेदारी लेना पूरी तरह इंसानी काम बना रहता है।

Origami में हम इसे कैसे देखते हैं

हम मल्टी-एजेंट टूल को वैसे ही देखते हैं जैसे किसी भी उत्पादकता टूल को: वे निष्पादन को तेज़ करते हैं, जवाबदेही को स्थानांतरित नहीं करते। हमारे यहाँ कोई भी प्रोजेक्ट प्रोडक्शन से पहले अब भी लिखित विनिर्देशों, मानवीय समीक्षा, एक टेस्ट सूट और एक स्टेजिंग एनवायरनमेंट से गुज़रता है, चाहे कोड किसी व्यक्ति ने लिखा हो या किसी एजेंट ने जनरेट किया हो। अपने टेस्ट ख़ुद चलाने वाला टूल इस श्रृंखला में एक स्वागत-योग्य जोड़ है, लेकिन वह इसकी एक कड़ी है, इसका विकल्प नहीं।

व्यवसाय के मालिक के लिए व्यावहारिक सीख: उम्मीद रखें कि ख़ास तौर पर जटिल काम में डिलीवरी की समय-सीमा घटेगी, लेकिन बिना टेस्ट, बिना दस्तावेज़ और बिना किसी मानवीय ज़िम्मेदार के कोई हैंडओवर स्वीकार न करें। ख़ुद की समीक्षा करने वाले टूल प्राप्त की जा सकने वाली गुणवत्ता की सीमा को ऊपर उठाते हैं। वे आपकी उस ज़रूरत को ख़त्म नहीं करते कि कोई यह गारंटी दे कि जो बनाया गया है वही है जो आपने माँगा था।

स्रोत