Transcript
00:00:00SQLite को Rust में फिर से लिखा गया था।
00:00:02और मुझे पता है कि अभी-अभी bun को Rust में रीराइट किया गया है,
00:00:04और आप सोच रहे होंगे कि हर कोई
00:00:06सब कुछ Rust में क्यों रीराइट कर रहा है, पर यह Rust के बारे में नहीं है।
00:00:09यह SQLite के बारे में भी नहीं है।
00:00:11मुझे पता है कि Terso डेटाबेस मौजूद है,
00:00:15जो पहले से ही Rust में SQLite का
00:00:18एक आधुनिक री-इम्प्लिमेंटेशन है।
00:00:19अगर आप प्रोटेक्शन-रेडी
00:00:21SQLite Rust-आधारित डेटाबेस
00:00:23इस्तेमाल करना चाहते हैं, तो वही सही विकल्प है।
00:00:26इसके बजाय, यह प्रयोग, mini SQLite,
00:00:29जिसका लिंक नीचे दिया गया है और जिसे आप देख सकते हैं,
00:00:32SQLite या Rust के बारे में नहीं है।
00:00:34यह Cursor टीम का एक प्रयोग है,
00:00:37जो पूरी तरह से एजेंट स्वॉर्म्स और AI एजेंटों के
00:00:40एक सिस्टम को इंजीनियर करने, और यह पता लगाने के बारे में है कि क्या काम करता है
00:00:44और क्या काम नहीं करता, ताकि SQLite जैसी चीज़
00:00:47सिर्फ उसके डॉक्यूमेंट्स से बनाई जा सके,
00:00:51क्योंकि यह प्रयोग उसी के बारे में है।
00:00:53एक बेहद विस्तृत और बहुत दिलचस्प ब्लॉग पोस्ट है
00:00:56और हम उसमें गहराई से जानेंगे।
00:00:57उसमें बहुत सारी दिलचस्प बातें सीखने को मिलती हैं
00:00:59जिन पर हमें बात करनी है, और जिसका लिंक भी नीचे दिया गया है,
00:01:02जहाँ वे बताते हैं कि उन्होंने यह प्रयोग कैसे चलाया, और शुरुआती बिंदु
00:01:07तथा इस प्रयोग के पीछे का विचार SQLite के डॉक्यूमेंटेशन को लेना था,
00:01:12जो अगर एक डॉक्यूमेंट में रखा जाए, तो कुल 835 पेजों का है,
00:01:18जो बेशक, मुख्य रूप से इंसानों के लिए लिखा गया है।
00:01:23मेरा मतलब है, यह सबसे आसान डॉक्यूमेंटेशन नहीं है जो मैंने देखा है,
00:01:27लेकिन जाहिर है कि यह इंसानों के लिए बना है क्योंकि यह इन सभी AI एजेंट चीज़ों से काफी पुराना है।
00:01:32फिर भी, यह एक तरह से सुपर डिटेल्ड स्पेसिफिकेशन का काम करता है,
00:01:37एक बहुत ही विस्तृत स्पेसिफिकेशन, क्योंकि यह विस्तार से बताता है कि SQLite का इस्तेमाल कैसे करें
00:01:43और इसका अपेक्षित व्यवहार या इसके अपेक्षित फीचर्स क्या हैं।
00:01:48और Cursor टीम ने उस डॉक्यूमेंटेशन को लिया
00:01:52और फिर एक पब्लिक टेस्ट सेट, SQLogic टेस्ट को लिया,
00:01:57जो ऐसे टेस्ट्स का समूह है जो SQLite के व्यवहार का परीक्षण करते हैं
00:02:02या खासतौर पर क्वेरीज़ का परीक्षण करते हैं।
00:02:05और उन्होंने इसका इस्तेमाल यह जांचने के लिए किया कि क्या इम्प्लिमेंटेशन
00:02:09जो उनके एजेंटों ने उस डॉक्यूमेंटेशन के आधार पर बनाया है
00:02:13वास्तव में उस आधिकारिक या विशाल टेस्ट सूट के साथ काम करता है या नहीं।
00:02:19अब, शुरुआत में ही कुछ महत्वपूर्ण सावधानियाँ।
00:02:23यह टेस्ट सूट क्वेरीज़ और क्वेरी के व्यवहार का परीक्षण करने के बारे में है।
00:02:29यह SQLite के सभी फीचर्स और क्षमताओं का परीक्षण नहीं करता है।
00:02:35यह सामान्य रूप से परफॉरमेंस का परीक्षण नहीं करता है।
00:02:38यह कॉनकरंसी की जांच नहीं करता है।
00:02:40SQLite में बहुत सी ऐसी चीजें हैं, जिनका यह परीक्षण नहीं करता।
00:02:44और इस प्रयोग का परिणाम यह mini SQLite है, परिणामों में से एक,
00:02:49उन्होंने वास्तव में अलग-अलग एजेंट संयोजनों के साथ SQLite को कई बार फिर से बनाया।
00:02:53और हम इसमें गहराई से जाएँगे, यह केवल एक्सप्लोर करने के लिए है।
00:02:57यह प्रोडक्शन-रेडी नहीं है।
00:02:59यह वह नहीं है जिसका आप उपयोग करना चाहेंगे।
00:03:01यह बस एक ऐसे प्रयोग का आउटपुट है जहाँ लक्ष्य डॉक्यूमेंटेशन का उपयोग करना था
00:03:06और फिर SQLite को फिर से बनाना और उस रीबिल्ट वर्ज़न को उन सभी टेस्ट्स में पास कराना था।
00:03:13और Cursor टीम ने यहाँ विभिन्न मॉडल संयोजनों का उपयोग किया।
00:03:17संयोजन क्यों?
00:03:18क्योंकि जैसा कि हम जानेंगे, उन्होंने एक दृष्टिकोण का उपयोग किया
00:03:21जहाँ कई एजेंटों ने एक साथ काम किया, प्लानर, वर्कर और रिव्यूअर एजेंट।
00:03:28और उन्होंने यहाँ अलग-अलग संयोजनों के साथ उस SQLite डेटाबेस को फिर से बनाया और फिर समान गुणवत्ता के लिए मापा।
00:03:37तो इन सभी संयोजनों ने समान प्रकार की गुणवत्ता हासिल की, समान मात्रा में टेस्ट्स पास किए, लेकिन उन्होंने मापा कि किस संयोजन में कितनी लागत आई।
00:03:45उदाहरण के लिए, प्लानर और वर्कर दोनों एजेंटों के लिए GPT 5.5 का उपयोग करने पर डॉक्यूमेंटेशन के आधार पर Rust में SQLite के इम्प्लिमेंटेशन की लागत लगभग $10,000 आई।
00:03:59दूसरी ओर, Opus 4.8 को Composer 2.5 के साथ मिलाना - और Composer 2.5 Cursor का वह बहुत तेज़, बहुत सस्ता, बहुत कुशल, लेकिन बहुत ज्यादा बुद्धिमान मॉडल नहीं है - इन दोनों को मिलाने से अन्य संयोजनों की तरह ही समान गुणवत्ता और पासिंग टेस्ट्स मिले, वो भी लागत के एक छोटे से हिस्से में, केवल $1,300 में।
00:04:24और यहाँ विचार Opus 4.8 का उपयोग करने का था, जो बेशक अधिक सक्षम मॉडल है, प्लानिंग और कार्यों को डिजाइन करने के लिए, जिन्हें फिर उन वर्कर एजेंटों को सौंपा जाता है जो Composer 2.5 का उपयोग कर रहे हैं।
00:04:39और यह इस लेख से एक महत्वपूर्ण सीख है, जो जाहिर है एकदम नई नहीं है।
00:04:44अगर आप सॉफ़्टवेयर बना रहे हैं, तो आप खुद भी ऐसा कर सकते हैं।
00:04:47काम की जटिलता के आधार पर अपने काम को विभिन्न कार्यों में विभाजित करना एक अच्छा विचार है जो विभिन्न एजेंटों द्वारा निष्पादित किए जाते हैं, सब-एजेंटों का उपयोग करके, जहाँ कुछ एजेंट प्लानिंग पर ध्यान केंद्रित करते हैं,
00:05:03कुल काम के एक केंद्रित कार्य को डिजाइन करने के आधार पर, ताकि यह एक व्यक्तिगत कार्य बन जाए, और फिर उस कार्य को लागू करने वाले कई एजेंट हों।
00:05:14क्योंकि यह पता चलता है कि केवल अच्छा कोड लिखने के लिए, यदि संदर्भ अच्छा है, तो आपको अनिवार्य रूप से उच्चतम बुद्धिमत्ता (frontier intelligence) की आवश्यकता नहीं है।
00:05:24यानी अगर कार्य स्पष्ट रूप से परिभाषित है, अगर उस कार्य विवरण में सभी उपयोगी जानकारी मौजूद है, और फिर अन्य कारक भी मायने रख सकते हैं।
00:05:33उदाहरण के लिए, यह बात मायने रख सकती है कि आसपास का कोडबेस कैसा दिखता है, या आपके द्वारा एजेंट को दिए गए उदाहरण कैसे दिखते हैं।
00:05:39यह सब आउटपुट को प्रभावित करता है, लेकिन केवल कोड लिखने वाले वर्कर एजेंटों की संख्या बढ़ाई जा सकती है यदि कार्य अच्छी तरह से निर्दिष्ट हो और संदर्भ अच्छा हो।
00:05:49और अधिकांश प्रयोग इसी बारे में था।
00:05:52एक ऐसा सिस्टम कैसे डिज़ाइन किया जाए जो इस पैमाने के कार्य को संभाल सके।
00:05:57क्योंकि, जैसा कि मैंने उल्लेख किया है, आपके प्रोजेक्ट्स के लिए भी, प्लानर और वर्कर एजेंटों को रखना विचार करने योग्य है।
00:06:07अब, ज़ाहिर है कि सभी कार्यों के लिए ऐसा नहीं है।
00:06:10यदि आपके पास कोई त्वरित बग फिक्स है, या कोई बहुत सरल कार्य है, तो अपने एजेंट को सीधे बताना बिल्कुल ठीक है।
00:06:19“अरे, मुझे यह समस्या है।
00:06:20मैं चाहता हूँ कि तुम यह करो।”
00:06:21इसे कुछ अतिरिक्त संदर्भ दें और इसे अपना काम करने दें।
00:06:24कोडिंग एजेंट हार्नेस के आधार पर, यह सब-एजेंट भी शुरू कर सकता है।
00:06:28फिर भी, Claude Code ऐसा कर सकता है।
00:06:31PI जैसे अन्य हार्नेस ऐसा नहीं कर सकते यदि आप उन्हें सही एक्सटेंशन न दें।
00:06:36लेकिन बिना सब-एजेंटों के भी, कई कार्यों को केवल एक एजेंट द्वारा निपटाया जा सकता है।
00:06:43लेकिन अधिक जटिल प्रोजेक्ट्स और कार्यों के लिए, यह विभाजन उपयोगी हो सकता है, जिसमें रिव्यूअर एजेंट भी शामिल हैं।
00:06:51यह एक ऐसी चीज़ है जो मुझे व्यक्तिगत रूप से भी पसंद है।
00:06:54दोबारा कहूँ तो, कार्य की जटिलता के आधार पर।
00:06:56लेकिन यह विभाजन वास्तव में बहुत अच्छी तरह से काम करता है।
00:06:59और ज़ाहिर है कि यह कोई क्रांतिकारी नई बात नहीं है।
00:07:02नया यह है कि इस SQLite रीराइट जैसी चीज़ के लिए, आपके पास प्लानर, वर्कर और रिव्यूअर एजेंटों की कई समानांतर प्रक्रियाएँ होती हैं, कई वर्कर्स, लेकिन कई प्लानर और रिव्यूअर भी।
00:07:18और वे आपस में टकराते रहते हैं।
00:07:19Cursor टीम को आखिर में यही पता चला।
00:07:22अब, इस ब्लॉग पोस्ट में, जो बहुत, बहुत दिलचस्प है।
00:07:26उन्होंने उल्लेख किया कि इस वर्ष की शुरुआत में, उन्होंने पहले से ही एक एजेंट हार्नेस के साथ एक प्रयोग चलाया था जहाँ उन्होंने शुरुआत से एक वेब ब्राउज़र बनाया था।
00:07:33और अब उन्होंने उस SQLite रीराइट को करने के लिए उसी हार्नेस या एजेंटों के उसी सिस्टम का उपयोग किया।
00:07:40लेकिन उन्होंने एक प्रयोग के रूप में अपनी नई सीख के आधार पर एक नया सिस्टम भी बनाया।
00:07:47और फिर इस प्रयोग और इस ब्लॉग पोस्ट में, वे इन विभिन्न दृष्टिकोणों की तुलना करते हैं और SQLite को फिर से बनाने वाले सिस्टम को सेट अप और चलाने के दौरान आई सभी चुनौतियों का विश्लेषण करते हैं।
00:07:59और एक ऐसे सिस्टम के साथ काम करते समय, जहाँ कई, सैकड़ों या हज़ारों वर्कर्स एक साथ काम करते हैं, पहली चुनौती जिसका उन्होंने सामना किया, वह थी कि पारंपरिक वर्ज़न कंट्रोल, यानी Git, अब काम नहीं आता।
00:08:13जैसा कि वे स्वॉर्म के बारे में एक पिछली पोस्ट में लिखते हैं, हम जानते हैं कि Git और Cargo जैसे टूल कन्करेंसी कंट्रोल के लिए मोटे लॉग (coarse locks) पर निर्भर करते हैं, जिसका अर्थ है कि डेटा का एक ही हिस्सा लॉक रहता है ताकि एक साथ कई राइटर न हो सकें।
00:08:30यह एक डेवलपर के लिए ठीक है, लेकिन सैकड़ों समवर्ती एजेंटों द्वारा उत्पादित काम की मात्रा के लिए अव्यावहारिक है।
00:08:36इस वर्ष की शुरुआत वाले ब्राउज़र स्वॉर्म ने लगभग 1000 कमिट प्रति घंटे का शिखर छुआ था।
00:08:41तो वह वह स्वॉर्म है जिसने उस ब्राउज़र को फिर से बनाया था।
00:08:45नया सिस्टम, जिसे उन्होंने इस प्रयोग के लिए डिज़ाइन किया है, लगभग 1000 कमिट प्रति सेकंड तक पहुँचता है।
00:08:52तो पुराना स्वॉर्म, जिसे उन्होंने इस साल की शुरुआत में चलाया था, उसमें 1000 कमिट प्रति घंटे थे, जो जाहिर तौर पर अधिकांश इंसानों की तुलना में थोड़ा अधिक है।
00:09:02हालाँकि, नए सिस्टम में लगभग 1000 कमिट प्रति सेकंड थे, जो हैरान कर देने वाला है और स्पष्ट रूप से वह नहीं है जिसके लिए Git बनाया गया था।
00:09:14ज़ाहिर सी बात है।
00:09:15गतिविधि की इस दर को सुविधाजनक बनाने के लिए, हमने शुरुआत से एक नया वर्ज़न कंट्रोल सिस्टम बनाया।
00:09:21इस लेयर को खुद बनाने की एकमात्र वजह थ्रूपुट ही नहीं थी।
00:09:25सिस्टम में हर बदलाव वर्ज़न कंट्रोल सिस्टम से होकर गुजरता है।
00:09:29इसलिए यह वह जगह है जहाँ टकराव सबसे पहले दिखाई देते हैं।
00:09:31और अगले भाग में बताए गए कई समन्वय तंत्र सीधे इसी के अंदर लागू किए गए हैं।
00:09:37और यह वाकई दिलचस्प है।
00:09:39उन्होंने AI एजेंट युग के लिए एक नया वर्ज़न कंट्रोल सिस्टम बनाया।
00:09:43क्योंकि पुराना वाला, Git, जिसे हम सभी इस्तेमाल करते हैं, उसमें कोई खराबी नहीं है।
00:09:48बिल्कुल स्पष्ट कर दूँ।
00:09:49हम यहाँ एक ऐसे पैमाने और कार्य पर प्रयोग की बात कर रहे हैं जिसे हममें से कई लोग कभी नहीं करेंगे, कम से कम जल्दी तो नहीं।
00:09:57लेकिन फिर भी, पुराना सिस्टम Git इस तरह से नहीं बना है कि सैकड़ों एजेंट, सैकड़ों संस्थाएँ एक ही कोड पर एक साथ काम कर सकें।
00:10:07इसलिए उन्होंने एक नया वर्ज़न कंट्रोल सिस्टम बनाया जो बेहद उच्च कन्करेंसी को संभाल सकता है, और जो एजेंटों के माध्यम से संघर्षों को हल करने में भी मदद कर सकता है।
00:10:19क्योंकि ज़ाहिर है कि यह वर्ज़न कंट्रोल सिस्टम ही है जहाँ संघर्ष तब दिखाई देते हैं जब दो बदलाव किसी फ़ाइल में कोड के एक ही हिस्से को प्रभावित करते हैं।
00:10:28तो यह यहाँ पहली महत्वपूर्ण बात है।
00:10:30उन्होंने इस प्रयोग को कुशलतापूर्वक चलाने या करने में सक्षम होने के लिए एक बिल्कुल नया वर्ज़न कंट्रोल सिस्टम बनाया।
00:10:37अब स्वाभाविक रूप से, जैसा कि उन्होंने यहाँ उल्लेख किया है, उन्हें 1000 कमिट प्रति सेकंड के पैमाने और बदलाव की दर पर कई समस्याओं का सामना करना पड़ा।
00:10:48उदाहरण के लिए, और यह वास्तव में दिलचस्प है कि उन्हें ये सभी समस्याएँ आईं और उन्होंने इन्हें कैसे हल किया, क्योंकि यह हमें दिखाता है कि भविष्य में सॉफ़्टवेयर इंजीनियरिंग कैसी दिख सकती है, कम से कम कुछ परिदृश्यों में।
00:11:01स्प्लिट-ब्रेन डिज़ाइन की समस्या।
00:11:03दो प्लानर, एक-दूसरे से अनजान, कोडबेस के विभिन्न हिस्सों में अलग-अलग तरीकों से एक ही अवधारणा को लागू करते हैं।
00:11:10यानी डुप्लीकेशन, कोडबेस के अलग-अलग हिस्सों में अलग-अलग तरीकों से एक ही कॉन्सेप्ट।
00:11:16आप आमतौर पर उसे निकालकर उस लॉजिक का पुनः उपयोग करना चाहेंगे, है ना?
00:11:21हमने इसे प्रॉम्प्टिंग के जरिए ठीक किया।
00:11:24तो यहाँ कोई फैंसी नया सिस्टम नहीं बनाया गया, बल्कि प्रॉम्प्टिंग के ज़रिए ठीक किया गया।
00:11:28प्लानर्स खुद डिज़ाइन संबंधी निर्णय लेते हैं, न कि उन्हें दूसरों को सौंपते हैं।
00:11:34और हम उनसे यह सुनिश्चित करने की मांग करते हैं कि दो सौंपे गए सब-ट्री एक ही सवाल पर निर्णय न लें।
00:11:39तो यह यहाँ सेटअप का सवाल है।
00:11:40यह सब यह सुनिश्चित करने के बारे में है कि जैसे ही आप उस सिस्टम को प्लानर्स, वर्कर्स आदि में विभाजित करते हैं, आप यह सुनिश्चित करते हैं कि आपके विभिन्न प्लानर्स के पास स्पष्ट रूप से परिभाषित कार्य हों, जिनमें टकराव और ओवरलैप होने की संभावना बहुत कम हो।
00:12:02तो यह, बेशक, इंसानों के डिज़ाइन से शुरू होता है।
00:12:08यानी आप कार्य कैसे सेट करते हैं, आप कैसे प्रॉम्प्ट करते हैं, सही?
00:12:11हमने इसे प्रॉम्प्टिंग के जरिए ठीक किया।
00:12:13तो यह प्रक्रिया उन सभी समानांतर नोड्स और लीव्स के साथ एजेंटों के ट्री में नीचे तक जाती है, जहाँ आप यह सुनिश्चित करना चाहते हैं कि जब एजेंट कार्यों को उप-कार्यों में विभाजित करते हैं, तो उन एजेंटों को ऐसे कार्य बनाने के लिए प्रॉम्प्ट किया जाए जिनके ओवरलैप होने की संभावना कम हो।
00:12:34तो यह अंततः इंसानों के लिए एक प्लानिंग चुनौती है, जो कि मानवीय पक्ष से सही तरीके से सिस्टम सेट करने के बारे में है।
00:12:43तो इस तरह उन्होंने इस समस्या को हल किया या इससे निपटे।
00:12:47एक और समस्या जिसका उन्होंने सामना किया, वह थी प्लानर्स के बीच विवाद।
00:12:51विवाद का एक कठिन रूप तब होता है जब दो प्लानर एक-दूसरे के बारे में जानते हैं और उन्हीं फ़ाइलों में बार-बार बदलाव करके बहस करते हैं।
00:12:59समस्या यह है कि वास्तविकता की दो अलग तस्वीरों और मर्ज टूल से असहमति ठीक नहीं हो सकती।
00:13:04इसके बजाय, हम एजेंटों से साझा डिज़ाइन डॉक्यूमेंट्स में निर्णयों को रिकॉर्ड करवाते हैं।
00:13:08किसी निर्णय पर निर्भर कोड अपने डॉक्यूमेंट पर वापस एक संकलित जाँच संदर्भ (compiled check reference) ले जाता है।
00:13:13जब प्लानर अनजाने में एक-दूसरे का विरोध करते हैं, तो एक रिकॉन्साइलर डॉक्यूमेंट्स को मिलाता है और संदर्भ समाधान को आगे बढ़ाता है।
00:13:21तो आखिरकार, पिछले बिंदु से संबंधित, प्लानर्स के बीच काम विभाजित करते समय भी, स्वाभाविक रूप से सॉफ़्टवेयर विकास में, आप ओवरलैप या साझा डोमेन, साझा लॉजिक, साझा क्षेत्रों से पूरी तरह नहीं बच सकते जिन्हें कोडबेस में प्लानर्स और अंततः वर्कर्स द्वारा छुआ जाना आवश्यक है।
00:13:43इसलिए जब प्लानर एजेंट किसी इम्प्लिमेंटेशन पर बहस करने लगे, तो उन्होंने एक रिकॉन्साइलर एजेंट लाकर उसे ठीक किया, जो उन प्लानर्स द्वारा तैयार किए गए डॉक्यूमेंट्स को मर्ज करता है।
00:13:59जिन्हें वर्कर्स को सौंपने के लिए तैयार किया गया था।
00:14:02उनके बीच एक रिकॉन्साइलर चरण था जो आपस में भिड़ने वाले प्लानर एजेंटों के डॉक्यूमेंट्स को मिलाता था ताकि वे एक सुसंगत भाषा बोलें और एक इम्प्लिमेंटेशन पर सहमत हों, जिससे यह भी सुनिश्चित हो सके कि एक ही चीज़ को कोडबेस के अलग-अलग हिस्सों में अलग-अलग तरीकों से दोबारा लागू न किया जाए।
00:14:21तो जैसा कि मैं समझता हूँ, ये दोनों मिलकर काम करते हैं।
00:14:24अब स्वाभाविक रूप से, उन्हें मर्ज कॉन्फ्लिक्ट्स का भी सामना करना पड़ा।
00:14:29इसलिए प्लानिंग करना और यह सुनिश्चित करना कि वहाँ कोई ओवरलैपिंग न हो या कम से कम ओवरलैपिंग हो, और प्लानर्स एक ही भाषा बोलें, यह पहला महत्वपूर्ण कदम है।
00:14:38लेकिन फिर भी, कई वर्कर्स, यहाँ तक कि एक ही प्लान पर काम करने वाले कई वर्कर्स भी, स्वाभाविक रूप से एक ही फ़ाइलों को छूने और एक-दूसरे का विरोध करने की बहुत अधिक संभावना रखते हैं।
00:14:50इसलिए कई अन्य वर्कर्स ऐसे हैं जो यह ध्यान नहीं रखने वाले कि वे एक ही फ़ाइलों पर काम न करें।
00:14:55इसलिए वे एक ही फ़ाइलों पर काम करने से नहीं बचेंगे।
00:14:57इसीलिए वे समान फ़ाइलों पर ही काम करेंगे।
00:14:58टकराव को हल करने के लिए, उन्हें रुकना होगा, दूसरे एजेंट के संदर्भ को समझना होगा और उसके अनुसार मर्ज करना होगा।
00:15:03स्वाभाविक रूप से, यदि दो एजेंट या दो इंसान एक ही फ़ाइल पर काम करते हैं, तो उस संघर्ष को हल करने के लिए, दोनों को रुकना होगा, चाहे वे एजेंट हों या इंसान, या सामान्य रूप से उन्हें रुकना ही होगा ताकि निर्णय लिया जा सके,
00:15:19एक ऐसा इम्प्लिमेंटेशन जो संघर्ष को हल करे।
00:15:23हालाँकि, वर्कर एजेंट इसमें खराब होते हैं और व्यावहारिक रूप से या तो दूसरे बदलाव को ओवरराइड कर देते हैं या अपने खुद के बदलाव को छोड़ देते हैं।
00:15:29और शायद आपने भी इस पर ध्यान दिया होगा।
00:15:31मैंने तो निश्चित रूप से दिया है।
00:15:32यदि आप एक या अधिक AI एजेंटों के साथ किसी कोडबेस में काम करते हैं और कोई बदलाव करते हैं।
00:15:38ठीक है, मुझे पता है कि यह डरावना है, लेकिन आप अभी भी कोड लिख सकते हैं।
00:15:40तो मान लीजिए कि आप कोई बदलाव करते हैं।
00:15:42आप कोड में कुछ बदलते हैं।
00:15:44एजेंट हमेशा उसे अनडू करके ओवरराइड कर देगा।
00:15:48यह उन बदलावों का सम्मान नहीं करता है।
00:15:50उसका अपना एक एजेंडा होता है।
00:15:52और अगर उसने तय कर लिया है कि उसे उस दी गई फ़ाइल को संपादित करना ही है, तो वह ऐसा करेगा।
00:15:57और उसे इससे कोई फर्क नहीं पड़ता कि आपने इस बीच इसमें कोई बदलाव किया है या नहीं।
00:16:01अगर आपने उस बदलाव को कमिट कर दिया है तो यह थोड़ा अलग है क्योंकि ये एजेंट पोस्ट-ट्रेन किए जाते हैं और फाइन-ट्यून होते हैं ताकि आपके कमिट को आसानी से अनडू न करें।
00:16:13लेकिन अगर यह बिना कमिट किया गया बदलाव है, तो वर्कर को कोई फर्क नहीं पड़ता।
00:16:17एजेंट को कोई परवाह नहीं होती।
00:16:19और ठीक यही बात उन्होंने यहाँ भी देखी।
00:16:21इसे ठीक करने के लिए, हमने एक ऐसा सिस्टम बनाया जहाँ एक निष्पक्ष तीसरा एजेंट मर्ज कॉन्फ्लिक्ट्स में हस्तक्षेप करता है और सभी पक्षों की ओर से उन्हें हल करता है।
00:16:29इसका एकमात्र लक्ष्य निष्पक्ष और कुशल होना है, ठीक वैसे ही जैसे इंजीनियरिंग टीमों में मर्ज कतारें (merge queues) काम करती हैं।
00:16:35और मुझे लगता है कि यह भी दिलचस्प है।
00:16:38यह फिर से एक तरह का तालमेल बिठाना (reconciliation) है।
00:16:41यह फिर से, जैसा कि मैं समझता हूँ, उन एजेंटों को रोकने के बारे में है, ठीक पुरानी दुनिया की तरह जहाँ आपको रुकना पड़ता था और एक कदम पीछे हटकर समाधान खोजना पड़ता था
00:16:49किसी संघर्ष का समाधान।
00:16:51लेकिन यह स्पष्ट रूप से जो दिखाता है, और यह भी कोई नई सीख नहीं है, वह यह है कि सही संदर्भ दिए जाने के साथ ताज़ा संदर्भ होना बेहद महत्वपूर्ण है।
00:17:03चाहे आप Cursor की तरह बड़े पैमाने के कार्य को संभाल रहे हों, जो हम सभी नहीं करते, या आप बस छोटे पैमाने के प्रोजेक्ट पर काम कर रहे हों,
00:17:12प्लानर, वर्कर और रिव्यूअर एजेंटों के बीच विभाजन होने का बड़ा लाभ मुख्य रूप से, या अक्सर यह होता है कि आप ताज़ा संदर्भ विंडो (context window) के साथ काम करते हैं।
00:17:24इसका मतलब यह नहीं है कि यह खाली संदर्भ विंडो है।
00:17:26इसका केवल यह अर्थ है कि आपके पास ताज़ा एजेंट सत्र हैं जो किसी दिए गए कार्य के लिए केवल सही संदर्भ से भरे हुए हैं।
00:17:33उदाहरण के लिए, एक वर्कर अपने खुद के काम की समीक्षा करने में काफी खराब होता है क्योंकि उसकी संदर्भ विंडो में उस काम को लागू करने का सारा संदर्भ होता है।
00:17:41इसलिए वह पक्षपाती होता है, अगर आप इसे इस तरह कहना चाहें।
00:17:44इसलिए एक रिव्यूअर एजेंट को एक नई संदर्भ विंडो से शुरुआत करनी चाहिए, उसे यह जानकारी मिलनी चाहिए कि वर्कर ने क्या काम किया, योजना क्या थी, किन फ़ाइलों को छुआ गया, लेकिन इसके अलावा कुछ नहीं।
00:17:55ताकि वह ईमानदारी से उस काम की समीक्षा कर सके।
00:17:59इसीलिए सही संदर्भ से भरी ताज़ा संदर्भ विंडो इतनी महत्वपूर्ण हैं।
00:18:04और यहाँ भी बिल्कुल वही बात है जहाँ उन्होंने बिना किसी पक्षपात के एक नए एजेंट के माध्यम से सही संदर्भ के साथ मर्ज कॉन्फ्लिक्ट्स को हल किया।
00:18:17और फिर मैं मानता हूँ कि सिस्टम इस तरह से सेट किया गया था कि उन वर्कर एजेंटों को यह जानकारी मिले कि यह संघर्ष का समाधान है और उन्हें इसे ओवरराइड नहीं करना चाहिए, या नए वर्कर एजेंट शुरू किए गए।
00:18:30यह मुझे पूरी तरह से स्पष्ट नहीं है।
00:18:32एक और समस्या जो उनके सामने आई, वह थी मेगा-फ़ाइलें।
00:18:35कुछ फ़ाइलें एजेंटों के काम करने के लिए विशेष रूप से लोकप्रिय जगहें होती हैं।
00:18:39प्रत्येक एजेंट केवल थोड़ा सा कोड जोड़ सकता है और कोई भी एक एजेंट फ़ाइल को छोटा रखने के लिए ज़िम्मेदार नहीं होता है।
00:18:45ये मेगा-फ़ाइलें सब कुछ जाम कर देती हैं।
00:18:49वे ट्रांसपार्ट करने, डिफ करने, मर्ज करने में महंगी होती हैं और लगातार टकराव का कारण बनती हैं।
00:18:54फिर से, यह भी कुछ ऐसा है जिसका सामना आपने बहुत छोटे पैमाने पर किया होगा।
00:19:00मैंने निश्चित रूप से किया है।
00:19:01चीजों में से एक जो हमारे पास है।
00:19:02खासकर टेस्टिंग के लिए।
00:19:03मेरा अनुभव यह है कि एजेंट्स को एक ही फाइल में लगातार और टेस्ट जोड़ना पसंद होता है।
00:19:08और जाहिर है, यह सिर्फ टेस्टिंग तक सीमित नहीं है, लेकिन वहां मुझे यह अक्सर देखने को मिलता है।
00:19:13और खासकर तब जब आपके पास multiple agents काम कर रहे हों और हर एजेंट का अपना एजेंडा हो।
00:19:18उन्हें कोई फर्क नहीं पड़ता क्योंकि वे इंसान नहीं हैं।
00:19:21वे भला किसी बात की परवाह कैसे कर सकते हैं?
00:19:23वे बस टॉस्क निष्पादित कर रहे हैं, है ना?
00:19:24उन्हें किसी फाइल के साइज या सिस्टम के ओवरऑल आर्किटेक्चर से कोई मतलब नहीं होता।
00:19:30अगर आपके पास सिर्फ टॉस्क पूरे करने वाले एजेंट्स का ग्रुप है, तो एक समय बाद आपका कोडबेस अराजकता की ओर बढ़ जाएगा।
00:19:37क्योंकि एजेंट्स को परवाह नहीं होती।
00:19:39उन्हें सिर्फ अपना टॉस्क पूरा करने से मतलब होता है।
00:19:42और ये मेगा फाइल्स, बेशक, उस समस्या का एक स्पष्ट संकेत हैं।
00:19:48कि आपके प्रोजेक्ट में जितने ज्यादा एजेंट्स लंबे समय तक काम करते हैं, ये फाइल्स उतनी ही बनने लगती हैं।
00:19:55वहां ऐसा कोई एजेंट नहीं है जो उस फाइल को विभाजित करने या कोडबेस को अच्छी तरह से व्यवस्थित रखने के लिए जिम्मेदार हो।
00:20:02यह उनके एजेंडे में शामिल ही नहीं है।
00:20:04इसलिए, इसे ठीक करने के लिए, हमने वर्कर एजेंट्स को फूली हुई फाइलों को फ्लैग करने का एक तरीका दिया।
00:20:09एक बार फ्लैग होने के बाद, हमने नए कमिट रोक दिए और एक बाहरी एजेंट उस अत्यधिक बढ़ी हुई फाइल को छोटे मॉड्यूल्स में तोड़ देता है।
00:20:16तो, फिर से एक नया एजेंट सामने आता है।
00:20:19यह एक ऐसा पैटर्न है जो हम यहां देखते हैं।
00:20:21इन सभी समस्याओं के लिए, बात केवल एक समस्या की पहचान करने और फिर सही टॉस्क दिए गए नए एजेंट्स का उपयोग करने की थी,
00:20:28सही संदर्भ देकर उस समस्या को हल करना था ताकि बाकी एजेंट्स अपना काम जारी रख सकें।
00:20:35और मेगा फाइल्स के मामले में भी यही बात लागू होती है।
00:20:38ओसिफिकेशन (जड़ता), एक और समस्या जिसका उन्होंने सामना किया।
00:20:40एजेंट्स ने इंसानों की मौजूदगी वाले मौजूदा कोडबेस में काम करके यह सीखा है,
00:20:44कि कोर कोड को नहीं छूना है, भले ही उसमें बदलाव की जरूरत क्यों न हो।
00:20:48तो, यह वह नहीं है जिसका जिक्र मैंने पहले किया था।
00:20:50जब आप उस फाइल में कोई बदलाव करते हैं जिस पर एजेंट काम कर रहा है और वह उसे बस छोड़ देता है।
00:20:55इसके बजाय यह सामान्य बात के बारे में है।
00:20:57किसी प्लान और आपके द्वारा दिए गए प्रॉम्प्ट के आधार पर एजेंट का एक स्पष्ट टॉस्क होता है।
00:21:03और उसमें, बेशक, कुछ फाइलों को बदलना शामिल होता है।
00:21:07अब, एक चीज जो हम पहले से जानते हैं या एजेंट्स के साथ काम करते हुए हर दिन देखते हैं, वह यह है कि मॉडल के आधार पर,
00:21:16कुछ मॉडल्स मौजूदा कोड को हटाने या बदलने में बहुत संकोच करते हैं।
00:21:21वे पुराने कोड को हटाने और साफ करने के बजाय कोडबेस में 10 फॉलबैक, 10 if-चेक और अधिक से अधिक लेगेसी कोड जोड़ते चले जाते हैं।
00:21:31यह सुनिश्चित करने के लिए कि एजेंट वास्तव में किसी फ़ंक्शन को हटाए या किसी कोड फाइल से छुटकारा पाए, आपको स्पष्ट प्रॉम्प्ट देना पड़ता है।
00:21:39वे खुद से ऐसा नहीं करते हैं क्योंकि फाइन-ट्यूनिंग की वजह से, साफ तौर पर ये मॉडल प्रोवाइडर ऐसे मॉडल नहीं बनाना चाहते,
00:21:47जो मनमर्जी से काम करें और हर तरह के प्रोडक्शन कोड को खराब कर दें।
00:21:50लेकिन जब किसी ब्राउनफील्ड प्रोजेक्ट में काम न कर रहे हों, या किसी ऐसे मौजूदा कोडबेस में काम न कर रहे हों जो शायद प्रोडक्शन में चल रहा हो,
00:21:57तब कोड को न छूने और सारे कोड को हमेशा के लिए बनाए रखने की यह प्रवृत्ति बेहद समस्याग्रस्त और कष्टप्रद हो सकती है।
00:22:05और इससे अन्य साइड इफेक्ट्स भी हो सकते हैं जैसे उन्होंने यहां सामना किया, जहां एजेंट्स दूसरे एजेंट्स द्वारा लिखे गए कोड में सुधार ही नहीं करते थे,
00:22:16बल्कि बार-बार उसी के ऊपर कोड बनाते रहते थे, जिससे आखिरकार एक भारी-भरकम कोडबेस बन जाता है।
00:22:23इसे ठीक करने के लिए, हमने जानबूझकर किए जाने वाले बदलावों (breaking changes) की अनुमति दी।
00:22:27कोई एजेंट जो कोर बदलाव को सार्थक समझता है, वह अपने स्कोप से बाहर एक केंद्रित पैच बना सकता है और यह बताते हुए एक कमेंट छोड़ सकता है कि उसने ऐसा क्यों किया।
00:22:36और यह, फिर से, छोटे पैमाने पर वही है जो आप अपने प्रोजेक्ट्स में कर सकते हैं जो मैं कर रहा हूँ।
00:22:41आप स्पष्ट रूप से अनुमति देना चाहते हैं और अपने एजेंट्स से कहना चाहते हैं, हे, हम इसे बना रहे हैं।
00:22:46हम शुरुआती डेवलपमेंट चरण में हैं।
00:22:48यह अभी लाइव नहीं है।
00:22:49मुझे ब्रेकिंग बदलाव चाहिए।
00:22:51इसलिए कोड को सख्ती से साफ करें।
00:22:54रिफैक्टरिंग का स्वागत है।
00:22:56इस तरह की चीजें।
00:22:58आप एजेंट्स और इन AI मॉडल्स को प्रोत्साहित करना चाहते हैं और उनके फाइन-ट्यूनिंग निर्देशों को ओवरराइड करना चाहते हैं।
00:23:04ताकि उनके इन-बिल्ट ज्ञान को दूर किया जा सके और यह सुनिश्चित हो सके कि वे केवल अधिक कोड जोड़ने के बजाय वास्तव में कोडबेस को विकसित कर सकें।
00:23:14तो फिर से, कुछ ऐसा जिसे हम यहां छोटे पैमाने पर देख सकते हैं, जिसे बेशक बड़े पैमाने पर देखा गया है।
00:23:19अब समीक्षा करने के लिए, उन्होंने “रिव्यू लेंस” नामक दृष्टिकोण का उपयोग किया।
00:23:24तो हमारे पास प्लानर और वर्कर एजेंट्स हैं, लेकिन जाहिर है कि आगे का काम बनाने और लूप को तब तक रीस्टार्ट करने के लिए उस काम की समीक्षा की जानी चाहिए जब तक कि कोई बग ठीक न हो जाए या कोडबेस बेहतर स्थिति में न आ जाए।
00:23:38एक ऐसे सिस्टम में जो लंबे समय तक चलने वाला और मल्टी-एजेंट दोनों है, गलतियां जमा होती हैं और झुंड (swarm) को छोटी गलतियों के बड़ा बनने से पहले खुद को सुधारने के तरीके की जरूरत होती है।
00:23:47फिर से, यह बात समझ में आती है।
00:23:48हम सबने इसे छोटे पैमाने पर भी देखा है।
00:23:50हमने कई प्रकार के रिव्यू लेंसों के साथ प्रयोग किया, जैसे कि रिव्यू एजेंट को वर्कर की पूरी ट्रांसक्रिप्ट देना या केवल उसका आउटपुट या केवल कोडबेस देना।
00:24:00हमने अलग-अलग ट्रेनिंग और अलग-अलग पर्सनालिटी वाले अलग-अलग मॉडल्स पर चलने वाले रिव्यूअर्स को भी आजमाया।
00:24:05कोई भी अकेला लेंस सब कुछ नहीं पकड़ पाता, लेकिन आपस में जुड़े हुए लेंस ठीक उसी तरह काम करते हैं जैसे सेल्फ-ड्राइविंग सिस्टम बिना किसी एक आदर्श कंपोनेंट के भी इंसानी विश्वसनीयता से ऊपर पहुँच जाते हैं।
00:24:16समीक्षा पर खर्च की गई कंप्यूटिंग लागत का रिटर्न बहुत अधिक है क्योंकि समीक्षा उस काम की तुलना में बहुत सस्ती है जिसकी वह जांच करती है।
00:24:21हमें लगता है कि यह स्टैक्ड रिव्यू सिस्टम रन की निरंतर गुणवत्ता का एक मुख्य कारण था।
00:24:28तो यहाँ मुख्य बात यह है।
00:24:30एक या अधिक रिव्यूअर एजेंट्स के लिए पूरे कोडबेस की समीक्षा करना असंभव है।
00:24:39यह बहुत ज्यादा है।
00:24:41इसके बजाय, उन्होंने अलग-अलग तरीकों के साथ प्रयोग किया जैसे कि इसे पूरी ट्रांसक्रिप्ट देना या केवल आउटपुट या केवल कोडबेस देना।
00:24:47और अंत में उन्हें जो पता चला वह यह था कि जिस चीज ने उनकी मदद की, वह थी अलग-अलग पर्सना और अलग-अलग फोकस लेंस वाले विभिन्न रिव्यूअर्स का होना, जहाँ वे अलग-अलग पहलुओं पर ध्यान केंद्रित करते थे।
00:25:00जैसा कि मैं समझता हूँ, उन्हें कोडबेस दें और शायद इस बारे में कुछ जानकारी दें कि वर्कर ने क्या किया।
00:25:06और फिर यह संयोजन था, अनिवार्य रूप से कंबाइंड कई रिव्यूअर्स का आउटपुट, जिसने एक समग्र समीक्षा परिणाम दिया जिसे फिर से एक प्लानर द्वारा योजना में बदलने के लिए इस्तेमाल किया जा सकता था और वर्कर कोड को ठीक कर सकते थे।
00:25:23और फिर से, छोटे पैमाने पर, मुझे लगता है कि यह कुछ ऐसा है जिसे आप या हम भी लागू कर सकते हैं।
00:25:28अब, जाहिर है, हम फिर से कहेंगे कि हम उस तरह की चीजें नहीं बना रहे हैं।
00:25:34लेकिन मेरे अनुभव में भी जो चीज वास्तव में अच्छी तरह से काम करती है, वह है अलग-अलग कार्यों वाले multiple reviewer agents का होना, जिनमें से एक इस पर ध्यान केंद्रित कर सकता है कि, हे, क्या यह इडियोमैटिक Rust है?
00:25:46यदि Fable 5 आपको अनुमति देता है तो दूसरा परफॉरमेंस और सिक्योरिटी संबंधी मुद्दों पर ध्यान केंद्रित कर सकता है।
00:25:51एक अन्य रिव्यूअर नेमिंग पैटर्न्स पर ध्यान केंद्रित कर सकता है यदि यह कुछ ऐसा है जिस पर आप ध्यान केंद्रित करना चाहते हैं, इत्यादि।
00:25:58तो आपके पास अलग-अलग लेंस हैं और फिर आप उन रिव्यूअर्स को सही संदर्भ देते हैं।
00:26:03फिर से, ऐसा कुछ जैसे, हे, हमारे पास उस फीचर पर काम करने वाले वर्कर थे।
00:26:07शायद उन्हें वर्कर की योजना दें और शायद वर्कर द्वारा किए गए मोटे तौर पर कदमों के बारे में कुछ जानकारी दें, लेकिन उससे ज्यादा कुछ नहीं।
00:26:15और फिर आपके पास अलग-अलग रिव्यूअर्स से यह सारा आउटपुट होता है और आप उसे फिर से मिला सकते हैं, शायद किसी अन्य रिव्यूअर के साथ।
00:26:22मुझे जो पसंद है वह यह भी है कि समीक्षा परिणामों की समीक्षा करने के लिए एक रिव्यूअर हो, जिसके पीछे विचार यह है कि मॉडल के आधार पर, वे चीजें ढूंढना पसंद करते हैं।
00:26:36चाहे आप उन्हें कोई भी कोड दें, यह एक सिंगल लाइनर भी हो सकता है।
00:26:40मुझे कभी-कभी ऐसा महसूस होता है और वे उसमें पांच कमियां ढूंढ लेंगे।
00:26:43इसलिए मेरे अनुभव में, रिव्यूअर से उन समीक्षा निष्कर्षों को वर्गीकृत कराना और जो वास्तव में समस्याएं नहीं हैं उन्हें हटा देना बहुत अच्छी तरह से काम कर सकता है।
00:26:55और जैसा कि उन्होंने लिखा है, यह फिर से रिव्यूअर्स का संयोजन है, रिव्यूअर्स का यह स्टैक जो अच्छे परिणाम देने में मदद कर सकता है, जिसे बाद में फिर से उठाकर लागू किया जा सकता है।
00:27:06अब, फिर से, यह हमेशा आपके टॉस्क के पैमाने पर, आपके द्वारा बनाए जा रहे सॉफ्टवेयर पर निर्भर करता है।
00:27:11जाहिर है, सॉफ्टवेयर के कई हिस्सों के लिए यह सब बहुत जटिल है, लेकिन यह इस बात की एक अच्छी झलक है कि भविष्य में सॉफ्टवेयर इंजीनियरिंग कैसी दिख सकती है, ऐसे सिस्टम कैसे दिख सकते हैं, जिसे मैं व्यक्तिगत रूप से बहुत दिलचस्प मानता हूँ।
00:27:27अब, एक आखिरी चीज़ जो उन्होंने की वह यह कि उन्होंने एजेंट्स को माहौल (environment) को आकार देने दिया।
00:27:32यहाँ विचार यह था कि उन्होंने एजेंट्स को अंत में एक फील्ड गाइड लिखने दी, एक दस्तावेज या दस्तावेजों का संग्रह जहाँ उन्होंने एजेंट्स को इसके अलावा कोई निर्देश नहीं दिया था कि यह फील्ड गाइड समग्र टॉस्क के लिए संदर्भ के रूप में कार्य करे, जिससे एजेंट्स मेमोरी बना सकें, साझा मेमोरी कह सकते हैं, जो उन सीखों या मुख्य मुद्दों के बारे में है जिनकी शायद पहचान की गई थी और ऐसी ही चीजें।
00:28:00ताकि उनके पास एजेंट्स के लिए नोट्स रखने और फैसलों को डॉक्यूमेंट करने के लिए यह अतिरिक्त मेमोरी सिस्टम मौजूद हो, यदि आप इसे ऐसा कहना चाहें।
00:28:10और कुल मिलाकर मुझे, Rust पर BUN रीराइट की तरह ही, यह प्रयोग बहुत, बहुत दिलचस्प लगता है।
00:28:16यह डरावना भी हो सकता है।
00:28:17मैं यह पूरी तरह समझता हूँ।
00:28:18और मुझे लगता है कि हमें यह निष्कर्ष नहीं निकालना चाहिए कि अब से सभी सॉफ्टवेयर इसी तरह बनाए जाने चाहिए।
00:28:24मेरा मतलब है, एक तो यह सॉफ्टवेयर का प्रोडक्शन-रेडी हिस्सा भी नहीं है।
00:28:28और इसे प्रोडक्शन-रेडी बनाने में निश्चित रूप से काफी समय लगेगा।
00:28:33इसे कम करके नहीं आंका जाना चाहिए।
00:28:35ऐसा नहीं है कि आप कुछ ही घंटों में ऐसा कुछ बना सकते हैं और फिर इसे प्रोडक्शन-रेडी बनाना बस कुछ और घंटों का काम है।
00:28:43आखिरी 20% की तुलना में शुरुआत के 80% को हासिल करना बहुत आसान और तेज हो सकता है।
00:28:48हम सब यह जानते हैं।
00:28:49तो यह एक महत्वपूर्ण सीख है।
00:28:51बेशक यह समझना भी जरूरी है कि SQLite को फिर से लिखने का यह विशिष्ट कार्य, हां, हो सकता है कि उसे वे डॉक्यूमेंट मिले हों और फिर यहां इस टेस्ट सूट का इस्तेमाल किया गया हो।
00:29:04लेकिन जाहिर है, एक तो यह बहुत ही विस्तृत स्पेसिफिकेशन है, कुछ ऐसा जो आपके पास नए प्रोजेक्ट्स के लिए नहीं होता।
00:29:13यदि आप कोई नया सॉफ्टवेयर बना रहे हैं, तो आपके पास 20 साल से भी अधिक पुराने सॉफ्टवेयर के डॉक्यूमेंटेशन जितना विस्तृत स्पेसिफिकेशन नहीं होता।
00:29:24और जाहिर है, भले ही उन एजेंट्स को केवल डॉक्यूमेंटेशन ही दिया गया हो, SQLite का सोर्स कोड और अन्य सोर्स कोड जैसे Terso द्वारा Rust में अन्य री-इम्प्लिमेंटेशन, इस्तेमाल किए गए अधिकांश या इन सभी मॉडलों के ट्रेनिंग डेटा का हिस्सा हो सकते हैं और होने की बहुत संभावना है।
00:29:46इसलिए ऐसा नहीं है कि यह इन मॉडलों के लिए बिल्कुल नया था।
00:29:51यह एक बिल्कुल नए सॉफ्टवेयर के बनने जैसा नहीं है जहाँ इटरेशन (दौराह) भी उसे बनाने का एक महत्वपूर्ण हिस्सा होता है।
00:29:58आपके लिए बहुत कठिनाई होगी और मैं तो यहाँ तक कहूँगा कि किसी भी नए सॉफ्टवेयर को बिना उसमें लगातार बदलाव किए शुरुआत से बनाना असंभव है।
00:30:11क्योंकि आप पहले से ही एक परफेक्ट स्पेसिफिकेशन नहीं लिख सकते और फिर काम खत्म नहीं कर सकते।
00:30:17जब आप कुछ बना रहे होते हैं, तो चाहे वह किसी भी पैमाने पर हो, आप हमेशा नई चीजें या ऐसी चीजें खोजते हैं जिन्हें आप बदलना चाहते हैं।
00:30:26और इसलिए, बेशक, यह इस बात का प्रतिनिधित्व नहीं करता है कि सामान्य रूप से सॉफ्टवेयर कैसे बनाया जाएगा या बनाया जाना चाहिए।
00:30:34हालाँकि, यह एक बहुत ही दिलचस्प प्रयोग है।
00:30:37यह एक बहुत ही दिलचस्प प्रयोग है और इसमें मुख्य सीखें हैं जो हम सभी के लिए मायने रखती हैं।
00:30:43ऐसी मुख्य बातें जो जाहिर तौर पर बिल्कुल नई नहीं हैं, जैसे अपने काम को बांटना, सिर्फ सही संदर्भ के साथ नए कॉन्टेक्स्ट विंडोज का होना।
00:30:50ऐसी दिलचस्प अंतर्दृष्टि कि शायद नए वर्ज़न कंट्रोल सिस्टम सामने आएंगे और भविष्य में उनकी आवश्यकता होगी।
00:30:57और, बेशक, यह भी कि मल्टी-एजेंट ऑकेस्ट्रेशन अब एक अहम चीज़ बनती जा रही है।
00:31:01अब, वह सब, बेशक, यह भी साबित करता है कि इन प्रणालियों, इन एजेंट प्रणालियों को डिजाइन करने वाले इंसान और नए सॉफ्टवेयर के लिए इंसान, विशेष रूप से यह निर्णय भी लेते हैं कि उस सॉफ्टवेयर को कैसे डिजाइन किया जाना चाहिए।
00:31:21स्पेक फाइलें लिखना, भले ही वे इस जितनी विस्तृत न हों, और सॉफ्टवेयर आर्किटेक्चर के साथ आना और फिर एजेंट सिस्टम बनाना जो उन्हें लागू कर सकें और फिर उनकी समीक्षा कर सकें, जो महत्वपूर्ण है।
00:31:33यह वह दिशा है जहाँ हम सब बढ़ रहे हैं और, भले ही यह सब बदल रहा है और निश्चित रूप से वैसा नहीं है जैसा हमने छह साल पहले सॉफ्टवेयर बनाया था, यह कुछ ऐसा है जो मुझे उत्साहित करता है।
00:31:45मुझे लगता है कि यह वास्तव में दिलचस्प है कि हम एजेंटिक सिस्टम बनाने के साथ-साथ स्वयं सॉफ्टवेयर आर्किटेक्चर को डिजाइन करने, दोनों के लिए उस सिस्टमिक सोच वाले क्षेत्र में जा रहे हैं।
00:31:59और फिर हम दोनों को मिलकर काम करने देते हैं।
00:32:01मुझे इस तरह के प्रयोग बहुत, बहुत दिलचस्प लगते हैं।
00:32:04यहाँ की सीख बहुत, बहुत दिलचस्प है।
00:32:07और छोटे, अधिक सरलीकृत पैमाने पर इनमें से कुछ सीख रोज़मर्रा के सॉफ्टवेयर और डेवलपमेंट प्रोजेक्ट्स के लिए भी मायने रख सकती हैं।
00:32:17लेकिन हमेशा की तरह, मुझे बताएं कि आपके विचार क्या हैं और आप इस तरह के प्रयोगों के बारे में क्या सोचते हैं।