00:00:00भले ही क्लाउड कोड (Claude Code) AI डेवलपमेंट के लिए सबसे शक्तिशाली टूल्स में से एक है,
00:00:03लेकिन यह कुछ खास कामों में क्यों अटक जाता है? हाल ही में Anthropic द्वारा पेश किए गए फीचर्स
00:00:08और हमारे द्वारा बनाए गए वर्कफ़्लोज़ के बीच, इसके इस्तेमाल का तरीका
00:00:12कुछ ही हफ्तों में पूरी तरह बदल गया है। हमारी टीम हर दिन क्लाउड कोड का उपयोग कर रही है
00:00:16और यह केवल डेवलपमेंट के लिए नहीं बल्कि रिसर्च, प्रोडक्शन पाइपलाइन को मैनेज करने
00:00:21और उन कामों को ऑटोमेट करने के लिए भी है जिनका कोड से कोई लेना-देना नहीं है। तो चलिए मैं आपको वो सब दिखाता हूँ
00:00:26जो हमने समझा है। Anthropic ने हाल ही में क्लाउड कोड के लिए “इन्साइट्स” (insights) कमांड जोड़ा है। यह
00:00:31एक निश्चित समय अवधि के आपके सभी पिछले क्लाउड कोड सेशन्स का विश्लेषण करता है और एक रिपोर्ट तैयार करता है। यह रिपोर्ट
00:00:36आपके काम करने के तरीके का विश्लेषण करती है, आपकी कमियों को उजागर करती है, बताती है कि आप क्या सही कर रहे थे
00:00:40और क्या गलत, और आपको सुधार के तरीके बताती है। हमारी मुख्य रुचि यह पहचानने में थी कि
00:00:45चीजें कहाँ गलत हुईं, क्योंकि वहीं से हम खुद को बेहतर बनाना सीख सकते हैं। रिपोर्ट ने उन क्षेत्रों को
00:00:49हाइलाइट किया जहाँ हमें सबसे ज्यादा परेशानी हुई और वर्कफ़्लो को बेहतर बनाने के लिए फीचर्स के सुझाव भी दिए।
00:00:54उदाहरण के लिए, हमें एक सेशन याद है जहाँ मुख्य एजेंट बार-बार टास्क लिस्ट
00:00:58चेक कर रहा था जब हम एजेंट टीमों का उपयोग कर रहे थे। इसके कारण सेशन में बहुत समय लग रहा था और
00:01:03हमें इसे खुद ही बंद करना पड़ा। भविष्य में ऐसा होने से रोकने के लिए, हम इस प्रॉम्प्ट को
00:01:07cloud.md में कॉपी कर सकते हैं ताकि जब भी हम मल्टी-एजेंट्स के साथ क्लाउड कोड का उपयोग करें, तो क्लाउड
00:01:12बिना वजह समय बर्बाद न करे और उस पर काम करे। हम इन टिप्स को भविष्य के वर्कफ़्लोज़ के लिए अपने प्रोजेक्ट्स में जोड़ सकते हैं ताकि
00:01:17समय के साथ क्लाउड कोड का हमारा अनुभव बेहतर होता जाए। हमारी टीम ने क्लाउड कोड के साथ
00:01:22काफी समय बिताया है और सबसे महत्वपूर्ण कदम अभी भी यही है कि आप एजेंट को कॉन्टेक्स्ट (संदर्भ) कितने अच्छे से देते हैं।
00:01:26यह प्रोजेक्ट की ज़रूरतों के छोटे हिस्से हो सकते हैं या आपके द्वारा उपयोग किए जा रहे फ्रेमवर्क्स और
00:01:30लाइब्रेरीज़ के डॉक्यूमेंटेशन, क्योंकि जब आप सही कॉन्टेक्स्ट देते हैं, तो गलतियाँ लगभग शून्य हो जाती हैं
00:01:35क्योंकि उसे पता होता है कि किस पर काम करना है। प्रोजेक्ट डॉक्यूमेंटेशन के लिए, हम इसे खुद लिखने के बजाय
00:01:39क्लाउड से लिखवाना पसंद करते हैं। हमने क्लाउड को एक विशिष्ट प्रॉम्प्ट दिया जिसमें प्रोजेक्ट के विचार को
00:01:44ज़रूरी डॉक्यूमेंट्स में बाँटने के लिए सभी आवश्यक जानकारी थी। हमने इसे चार डॉक्यूमेंट्स बनाने के लिए कहा,
00:01:48जिनमें से प्रत्येक ऐप के एक विशिष्ट पहलू पर केंद्रित था। सबसे महत्वपूर्ण PRD है
00:01:53जिसमें प्रोजेक्ट की ज़रूरतों और दायरे के बारे में जानकारी होती है। फिर architecture.md है
00:01:57जिसमें डेटा फ़ॉर्मेटिंग, फ़ाइल स्ट्रक्चर, API और सभी आर्किटेक्चर विवरण लिखे होते हैं।
00:02:02फिर decision.md है जिसमें इस प्रोजेक्ट को बनाने के दौरान क्लाउड द्वारा लिए गए सभी निर्णय होते हैं,
00:02:08जो भविष्य के लिए एक संदर्भ के रूप में काम करते हैं। और फिर सबसे महत्वपूर्ण है feature.json जिसमें
00:02:12एक विशिष्ट JSON फ़ॉर्मेट में सभी फीचर्स होते हैं। इसमें टोकन-कुशल तरीके से प्रत्येक फीचर के बारे में
00:02:17सभी विवरण होते हैं और इसमें इस बात के मानदंड होते हैं कि फीचर कब पूरा माना जाएगा, साथ ही क्या लागू किया गया है
00:02:22और क्या नहीं, इसका ट्रैक रखने के लिए एक “passes” की (key) होती है। अब जब आपका बड़ा काम
00:02:27छोटे हिस्सों में बँट गया है, तो हमें Context 7 MCP के माध्यम से इसे लागू करने के लिए
00:02:31ज़रूरी टूल्स के डॉक्यूमेंटेशन देने होंगे। इसमें सभी लाइब्रेरीज़ और फ्रेमवर्क्स के डॉक्यूमेंटेशन हैं और यह
00:02:36अक्सर अपडेट होता रहता है ताकि एजेंट नवीनतम डॉक्यूमेंट्स ले सकें और मॉडल की जानकारी तथा
00:02:41वर्तमान अपडेट के बीच के अंतर को भर सकें। MCP सेटअप करने में केवल कुछ ही कदम लगते हैं। एक बार इंस्टॉल हो जाने पर,
00:02:46इसने Context 7 के टूल्स का उपयोग किया और सीधे लाइब्रेरी की जानकारी प्राप्त की। इससे यह
00:02:50नवीनतम डॉक्यूमेंटेशन का उपयोग कर पाता है, डिपेंडेंसी मिसमैच के कारण होने वाली कोड गलतियों को रोकता है और
00:02:55ज़्यादा सटीक परिणाम देता है। अब “हुक्स” (hooks) एक और कम उपयोग किया जाने वाला फीचर है। क्लाउड कोड में हुक्स
00:03:00शेल कमांड्स हैं जो लाइफसाइकिल के विशिष्ट बिंदुओं पर चलते हैं। ऐसे कई प्रकार हैं जो
00:03:05सेशन शुरू होने पर, किसी टूल के उपयोग से पहले या बाद में ट्रिगर होते हैं। लेकिन सबसे महत्वपूर्ण हिस्सा
00:03:11उन्हें विशिष्ट एग्जिट कोड्स (exit codes) के साथ सेटअप करना है। एग्जिट कोड्स क्लाउड कोड को बताते हैं कि कार्रवाई को
00:03:16आगे बढ़ाना है, रोकना है या अनदेखा करना है। एग्जिट कोड 0 का मतलब है सफलता। एग्जिट कोड 2 का मतलब है रोकने वाली त्रुटि (blocking error)।
00:03:22तो जब भी क्लाउड कुछ ऐसा करने की कोशिश करता है जो उसे नहीं करना चाहिए, तो वह एग्जिट कोड 2 पर पहुँचता है, उसे एरर मैसेज मिलता है
00:03:27और वह खुद को सुधार सकता है। इन दोनों के अलावा कोई भी एग्जिट कोड नॉन-ब्लॉकिंग होता है, वर्बोज़ मोड में दिखता है,
00:03:32और काम जारी रहता है। यह एग्जिट कोड 2 महत्वपूर्ण है क्योंकि इसका उपयोग करके आप
00:03:37एजेंट के व्यवहार को नियंत्रित कर सकते हैं। यदि आपने कभी क्लाउड कोड के साथ टेस्ट-ड्रिवन डेवलपमेंट पर काम किया है,
00:03:41तो आपने गौर किया होगा कि यदि वह टेस्ट पास नहीं कर पाता, तो वह टेस्ट को ही बदलने लगता है। इसे रोकने के लिए,
00:03:46हमने एक कस्टम हुक सेटअप किया है जो टूल के उपयोग से पहले (pre-tool use) ट्रिगर होता है। यह हुक टेस्ट स्क्रिप्ट्स को
00:03:50बदलने से बचाता है। यदि वह जिस पाथ पर काम करने की कोशिश कर रहा है वह एक टेस्ट डायरेक्टरी है या उसमें “test” शब्द है,
00:03:55तो यह एक एरर मैसेज दिखाता है कि टेस्ट फ़ोल्डर्स में बदलाव की अनुमति नहीं है और
00:04:00एग्जिट कोड 2 वापस कर देता है। इस हुक के साथ, जब हमने क्लाउड को टेस्ट रन करने का प्रॉम्प्ट दिया और टेस्ट
00:04:05फेल हो गए, तो उसने टेस्ट फ़ाइल्स को बदलने की कोशिश की। लेकिन स्क्रिप्ट ने उसे ब्लॉक कर दिया और “बदलाव से ब्लॉक किया गया”
00:04:10संदेश दिखाई दिया। इसने क्लाउड को उन फ़ाइल्स को एडिट करने से रोक दिया जिन्हें उसे एडिट नहीं करना चाहिए। यदि आपने
00:04:15MCP के साथ काम किया है, तो आप जानते हैं कि वे कॉन्टेक्स्ट विंडो को भर देते हैं। और जब आप किसी बड़े प्रोजेक्ट पर काम कर रहे होते हैं,
00:04:19तो कनेक्टेड MCPs की संख्या बढ़ जाती है। इसलिए सभी MCP टूल्स कॉन्टेक्स्ट विंडो में आ जाते हैं
00:04:25और वह भर जाती है। इसी उद्देश्य के लिए, क्लाउड कोड में एक एक्सपेरिमेंटल MCP CLI मोड है जो इसे हल करता है।
00:04:31हमने एक्सपेरिमेंटल MCP CLI फ्लैग को true पर सेट किया। इसे सेट करने के बाद, वे सभी MCPs जो कॉन्टेक्स्ट में
00:04:36दिख रहे थे, गायब हो गए और MCP टूल्स द्वारा कोई कॉन्टेक्स्ट विंडो नहीं ली गई। सवाल यह था कि
00:04:41टूल्स तक कैसे पहुँचा जाए अगर वे अब मेमोरी में नहीं हैं। सभी टूल स्कीमा को पहले से लोड करने के बजाय,
00:04:45क्लाउड कोड MCP CLI info और MCP CLI calls का उपयोग करता है और यह बैश (bash) के माध्यम से सभी कनेक्टेड
00:04:52MCPs को इन टूल्स के ज़रिए चलाता है। फ्लैग सेट होने के साथ, जब हमने इसे प्रॉम्प्ट दिया, तो सीधे
00:04:56MCP टूल को कॉल करने के बजाय, इसने उन्हें MCP CLI टूल्स के माध्यम से कॉल किया और उन्हें MCP टूल्स के बजाय बैश कमांड के रूप में चलाया।
00:05:03इस तरह, इसने केवल मांग पर आवश्यक टूल को लोड किया, जिससे कॉन्टेक्स्ट का भारी होना रुक गया। साथ ही,
00:05:08यदि आप हमारे कंटेंट का आनंद ले रहे हैं, तो हाइप बटन दबाने पर विचार करें क्योंकि यह हमें और अधिक
00:05:13कंटेंट बनाने और अधिक लोगों तक पहुँचने में मदद करता है। अब हमारे पिछले वीडियो में, हमने गिट (git) का उपयोग करने पर
00:05:18ज़ोर दिया है ताकि एजेंट के सभी कामों को वर्जन कंट्रोल में ट्रैक किया जा सके। यदि एजेंट चीजों को सही ढंग से
00:05:23लागू नहीं करते हैं तो आप वापस भी जा सकते हैं। हमने एक वीडियो भी कवर किया है जहाँ हमने एक एजेंट को लंबे समय तक चलने वाले
00:05:28काम पर चलाने के लिए गिट का उपयोग किया था जिसे आप चैनल पर देख सकते हैं। हमने अलग-अलग वर्क ट्रीज़ (work trees) पर काम करने के लिए
00:05:32पैरेलल एजेंट्स का उपयोग किया ताकि वे एक-दूसरे से अलग रहते हुए प्रोजेक्ट के सभी फीचर्स बना सकें।
00:05:37इस तरह, हम बाद में बिना किसी हस्तक्षेप के उनके आउटपुट को एक साथ मर्ज कर सकते थे क्योंकि एक ही फ़ाइल पर काम करने वाले
00:05:41एजेंट्स के बीच टकराव (conflicts) होता है। ब्रांचेस (branches) को प्राथमिकता नहीं दी जाती क्योंकि वे टकराव पैदा करती हैं। एजेंट्स को
00:05:46अलग-अलग ब्रांचेस चेक आउट करने में कठिनाई होती है क्योंकि ब्रांचेस एक ही वर्किंग डायरेक्टरी साझा करती हैं लेकिन वर्क ट्रीज़ नहीं।
00:05:50इसलिए हमने इसे एक प्रॉम्प्ट दिया जहाँ हमने कई फीचर्स प्रदान किए जिन्हें लागू करने की आवश्यकता थी
00:05:55और निर्दिष्ट किया कि प्रत्येक एजेंट को एक अलग वर्क ट्री पर काम करना चाहिए। इसने प्रत्येक वर्क ट्री के लिए एक अलग
00:05:59एजेंट का उपयोग किया और फीचर्स को अलग-थलग तरीके से लागू किया, भले ही उनके काम के विवरण
00:06:03कुछ बिंदुओं पर ओवरलैप हो रहे थे। क्लाउड द्वारा अलग-अलग ब्रांचेस में सभी फीचर्स को सही ढंग से लागू करने के बाद,
00:06:08हमने आउटपुट को मर्ज करवा दिया ताकि हमें एक ही वर्किंग डायरेक्टरी में सभी फीचर्स मिल सकें।
00:06:13अब एरर चेकिंग का बोझ एजेंट पर डालने के लिए स्ट्रिक्ट मोड (strict mode) आवश्यक है। यह कुछ ऐसा है
00:06:18जो आपको अपनी भाषा के लिए सेटअप करना चाहिए क्योंकि यह बग्स को तब पकड़ लेता है
00:06:22जब आप बिल्ड करते हैं, न कि तब जब यूज़र्स उन्हें रनटाइम पर देखते हैं। चूँकि हमारी प्राथमिक भाषा टाइपस्क्रिप्ट (TypeScript) है,
00:06:26हम हमेशा अपने प्रोजेक्ट्स में स्ट्रिक्ट मोड को true पर सेट करते हैं। यह नल (null) वैल्यूज़ और इम्प्लिसिट टाइप्स के लिए चेक चालू करता है,
00:06:31स्ट्रिक्ट टाइपिंग और नल चेक लागू करता है और कुल मिलाकर इसका मतलब है कम रनटाइम एरर्स। यह
00:06:36AI एजेंट्स के लिए मायने रखता है क्योंकि उनके पास रनटाइम एरर्स को पकड़ने का कोई इन-बिल्ट तरीका नहीं है। स्ट्रिक्ट मोड
00:06:41रनटाइम फेलियर की संभावना को कम करता है और सुनिश्चित करता है कि कंपाइलर इन समस्याओं को संभाले। एजेंट
00:06:46ज्ञात सुधारों को लागू करने के लिए टर्मिनल में एरर लॉग्स पर भरोसा कर सकते हैं। प्रोजेक्ट का परीक्षण केवल
00:06:51स्क्रिप्ट्स द्वारा करवाने के बजाय, टेस्टिंग की एक अतिरिक्त लेयर जोड़ना फायदेमंद है। आप यूज़र स्टोरीज़ लिखते हैं
00:06:56जो बताती हैं कि ऐप बनने के बाद टेस्टिंग प्रक्रिया का मार्गदर्शन करने के लिए यूज़र सिस्टम के साथ कैसे इंटरैक्ट करता है।
00:07:00हम वास्तव में अपने प्रोजेक्ट्स को लागू करने से पहले यूज़र स्टोरीज़ को परिभाषित करते हैं क्योंकि यह एक
00:07:05मानक निर्धारित करता है जिसका पालन किया जाना चाहिए। एक प्रॉम्प्ट का उपयोग करते हुए, क्लाउड ने एक फ़ोल्डर के अंदर
00:07:10कई स्टोरीज़ लिखीं जिनमें वे सभी संभावित तरीके थे जिनसे एक यूज़र सिस्टम के साथ इंटरैक्ट कर सकता है। प्रत्येक स्टोरी में
00:07:15ऐप का एक विशिष्ट पहलू, उसकी प्राथमिकता और एजेंट के परीक्षण के लिए स्वीकृति मानदंड (acceptance criteria) होते हैं।
00:07:21यूज़र स्टोरीज़ में बेस्ट-केस और एज-केस सहित सभी संभावित टेस्ट परिदृश्य शामिल थे। ये स्टोरीज़
00:07:26मूल रूप से एजेंटों को बताती हैं कि हमारे द्वारा बनाए गए सिस्टम के साथ कैसे इंटरैक्ट करना है। सिस्टम के साथ इंटरैक्ट करने के
00:07:31सही निर्देशों के साथ, कोई भी एजेंट उसी सिद्धांतों को ऐप पर लागू कर सकता है और यूज़र की अपेक्षाओं पर बेहतर खरा उतर सकता है।
00:07:35स्टोरीज़ डॉक्यूमेंट होने के बाद, हमने क्लाउड से उन्हें एक-एक करके लागू करने के लिए कहा
00:07:40और उसे प्रत्येक स्टोरी में दिए गए ऑप्टिमल पाथ से शुरू करने का प्रॉम्प्ट दिया, यह सुनिश्चित करते हुए कि सभी एज-केस कवर किए गए हैं।
00:07:45इस तरह इम्प्लीमेंटेशन में कम कमियाँ रहीं और कुल मिलाकर बेहतर यूज़र सैटिस्फैक्शन मिला।
00:07:50अब वे सभी टिप्स जिनके बारे में हम बात कर रहे हैं, AI Labs Pro में रेडी-टू-यूज़ टेम्प्लेट्स के
00:07:55रूप में उपलब्ध हैं। जो लोग नहीं जानते, उनके लिए बता दें कि यह हमारी हाल ही में लॉन्च की गई कम्युनिटी है
00:08:00जहाँ आपको रेडी-टू-यूज़ टेम्प्लेट्स, प्रॉम्प्ट्स, सभी कमांड्स और स्किल्स मिलते हैं जिन्हें आप इस वीडियो और
00:08:05पिछले सभी वीडियो के लिए सीधे अपने प्रोजेक्ट्स में प्लग कर सकते हैं। यदि आपको हमारे काम में वैल्यू मिली है और
00:08:10चैनल को सपोर्ट करना चाहते हैं, तो यह इसका सबसे अच्छा तरीका है। लिंक्स डिस्क्रिप्शन में हैं।
00:08:14तो हमें जितना हो सके पैरेललाइजेशन (parallelization) का उपयोग करने की ज़रूरत है क्योंकि इसी तरह एजेंट अपने वर्कफ़्लो की
00:08:20गति बढ़ाता है और उन चीजों को लागू करता है जिन्हें एक-दूसरे का इंतज़ार करने की ज़रूरत नहीं है। हम जानते हैं कि क्लाउड
00:08:25स्वचालित रूप से पता लगा लेता है कि कोई काम पैरेलल में चल सकता है या क्रमवार और खुद निर्णय लेता है, लेकिन
00:08:29खुद एजेंट बनाना भी बुरा नहीं है। हमने इन एजेंट क्षमताओं को अपने पिछले वीडियो में भी कवर किया था
00:08:34जहाँ हमने बात की थी कि आप अपने वर्कफ़्लो को तेज़ करने के लिए एजेंटों का उपयोग कैसे कर सकते हैं, लेकिन यह गति
00:08:39बढ़ी हुई टोकन खपत की कीमत पर आती है। फिर भी पैरेललाइजेशन का प्रयास सार्थक है। एक समय पर
00:08:43हम उसी मॉडल का उपयोग करके Opus 4.6 के सुधारों के प्रभाव पर रिसर्च कर रहे थे और स्रोत प्रदान करने के बावजूद
00:08:49वह तथ्यों को लेकर गलत जानकारी (hallucinations) दे रहा था। वह बार-बार गलत जानकारी लिख रहा था और हमें
00:08:54उसे बार-बार सही करना पड़ रहा था। इस रिसर्च को करना व्यर्थ लग रहा था क्योंकि हमें चीजों को
00:08:58खुद ही ठीक करते रहना पड़ रहा था। इसे दोबारा होने से रोकने के लिए हमने पैरेलल एजेंट्स का उपयोग किया। हमने एक रिसर्च टास्क
00:09:03सेटअप किया जहाँ हम KimiK 2.5 और क्लाउड की एजेंट स्वार्म (swarm) क्षमताओं की तुलना करना चाहते थे।
00:09:09हमने दो एजेंटों का उपयोग किया—एक रिसर्च करने के लिए और दूसरा रिसर्च एजेंट के काम की जाँच (fact check) करने के लिए। मुख्य
00:09:14विचार यह था कि दोनों एजेंट एक-दूसरे से संवाद करें ताकि यह सुनिश्चित हो सके कि निष्कर्ष सटीक हैं और
00:09:19हमें वह खुद न करना पड़े। इस सेटअप में एक एजेंट काम करता है जबकि दूसरा उसका आलोचनात्मक रूप से विश्लेषण करता है,
00:09:24जिससे उन्हें काम करने का एक विपरीत (adversarial) तरीका मिलता है। रिसर्च एजेंट ने पहले शुरू किया और
00:09:28फैक्ट-चेकर तब तक ब्लॉक रहा जब तक कि रिसर्च एजेंट ने पहला ड्राफ्ट तैयार नहीं कर लिया। एक बार पहला ड्राफ्ट
00:09:33तैयार हो जाने के बाद, फैक्ट-चेकर ने उसकी पुष्टि करना शुरू किया। उसने तुरंत डेटा में कई अशुद्धियों की पहचान की
00:09:38जो रिसर्च एजेंट ने सूचीबद्ध की थीं और अब हमें उन्हें मैन्युअल रूप से पकड़ने की ज़रूरत नहीं थी। दोनों एजेंट एक-दूसरे के साथ
00:09:43संवाद करते रहे और फैक्ट-चेकिंग प्रक्रिया को कड़ा रखा। एक एजेंट दूसरे की गलत जानकारी को पकड़ने के लिए समर्पित था।
00:09:47ऐसे कई काम हैं जिन्हें आप इस तरह के एडवरसैरियल सेटअप में चला सकते हैं। न केवल रिसर्च बल्कि डेवलपमेंट वर्क में भी,
00:09:52जहाँ एक एजेंट फीचर लागू करता है और दूसरा प्लान के अनुसार इम्प्लीमेंटेशन का रिव्यू करता है।
00:09:57क्लाउड कोड के निर्माता के शब्दों में, एजेंट बेहतर काम करता है यदि उसके पास अपने काम को सत्यापित करने का
00:10:02कोई तरीका हो। यहाँ मुख्य विचार एजेंट को “आँखें” देना है, यानी यह जाँचने की क्षमता कि
00:10:07लागू किया गया फीचर सही है और अपेक्षाओं पर खरा उतरता है या नहीं। चूँकि ये एजेंट टर्मिनल-बेस्ड हैं,
00:10:12वे उन समस्याओं को नहीं पहचान सकते जो रनटाइम पर होती हैं, विशेष रूप से क्लाइंट-साइड पर। हम
00:10:17एजेंट के काम को सत्यापित करने के लिए कई तरीकों का उपयोग करते हैं। पहला है क्लाउड क्रोम एक्सटेंशन जो
00:10:21DOM कैप्चरिंग, कंसोल लॉग चेकिंग जैसे ब्राउज़र-केंद्रित टूल्स प्रदान करता है। दूसरा टूल Puppeteer MCP है।
00:10:26यह उपयोगी है क्योंकि यह एक अलग ब्राउज़र में चलता है जिसमें आपके मौजूदा सेशन्स नहीं होते,
00:10:31जैसा कि क्लाउड के क्रोम एक्सटेंशन में होता है। यह अलग-थलग रहता है और आपके किसी भी वर्तमान सेशन में हस्तक्षेप नहीं करता है,
00:10:36इसलिए आपको प्राइवेसी की एक अतिरिक्त लेयर मिलती है। लेकिन हमारा पसंदीदा विकल्प वर्सेल (Vercel) का एजेंट ब्राउज़र है।
00:10:41यह कोई MCP नहीं बल्कि एक CLI टूल है जो एजेंटों को ब्राउज़र टेस्टिंग क्षमताएँ देता है। इसमें नेविगेशन,
00:10:46स्क्रीनशॉट कैप्चर करने और बहुत कुछ करने के टूल्स हैं। अन्य टूल्स के विपरीत यह केवल स्क्रीनशॉट के आधार पर नेविगेट नहीं करता है।
00:10:51इसके बजाय यह एक्सेसिबिलिटी ट्री का उपयोग करता है जहाँ प्रत्येक एलिमेंट का एक विशिष्ट संदर्भ होता है। यह पूरे DOM को
00:10:56हज़ारों टोकन से सिकोड़कर लगभग 200 से 400 टोकन तक ले आता है इसलिए यह बहुत अधिक टोकन-कुशल है।
00:11:01क्लाउड क्रोम एक्सटेंशन के साथ यही मुख्य समस्या थी जिसे एजेंट ब्राउज़र ने हल किया। वह पूरे DOM को
00:11:07कॉन्टेक्स्ट विंडो में लोड कर देता है और उसे जल्दी खत्म कर देता है। हमने claude.md में निर्देश भी जोड़े हैं
00:11:12कि क्लाउड MCP-बेस्ड टेस्टिंग पर जाने से पहले एजेंट ब्राउज़र पर भरोसा करे। इसलिए क्लाउड एजेंट ब्राउज़र को
00:11:17प्राथमिक वेरिफिकेशन मेथड के रूप में उपयोग करता है। लेकिन यहाँ एक और नज़रिया है। टेस्टिंग हमेशा महत्वपूर्ण होती है लेकिन
00:11:23गलतियों को कम करने का एक तरीका है जिसमें टेस्ट या कोड रिव्यू की ज़रूरत नहीं पड़ती। हम क्लाउड को उन चीजों की भविष्यवाणी करने के लिए कहते हैं
00:11:28जो अभी तक नहीं हुई हैं। हम क्लाउड को इम्प्लीमेंटेशन की जाँच करने और उन क्षेत्रों की पहचान करने के लिए कहते हैं
00:11:33जहाँ ऐप फेल हो सकता है। यह इसलिए काम करता है क्योंकि हम क्लाउड को उन विफलताओं के पैटर्न के साथ मिलान करके
00:11:38संभावित समस्याओं की भविष्यवाणी करने का मौका दे रहे हैं जो अन्य ऐप्स में पहले से मौजूद थीं,
00:11:43भले ही हमने खुद टेस्टिंग के दौरान उन्हें अभी तक न देखा हो। यह क्लाउड को कोड को
00:11:47पहले की तुलना में एक अलग नज़रिए से देखने के लिए मजबूर करता है। जब हमने इसे ऐसा करने के लिए कहा,
00:11:52तो इसने उन महत्वपूर्ण कमियों की पहचान की जो हमारी मल्टी-लेयर टेस्टिंग प्रक्रिया से भी बच निकली थीं और ऐसी
00:11:5718 समस्याओं को ढूँढा जो प्रोडक्शन में हानिकारक हो सकती थीं। लेकिन हमारी टेस्टिंग प्रक्रियाओं ने उन्हें नहीं पकड़ा था।
00:12:01उन्हें तभी पहचाना जा सका जब हमने क्लाउड को प्रोजेक्ट को दूसरे नज़रिए से देखने के लिए प्रेरित किया।
00:12:06इसी के साथ हम इस वीडियो के अंत में पहुँचते हैं। यदि आप चैनल को सपोर्ट करना चाहते हैं और
00:12:10हमें इस तरह के वीडियो बनाते रहने में मदद करना चाहते हैं, तो आप नीचे सुपर थैंक्स बटन का उपयोग करके ऐसा कर सकते हैं।
00:12:15हमेशा की तरह देखने के लिए धन्यवाद, और मैं आपसे अगले वीडियो में मिलूँगा।