पब्लिश होने की तारीख: 22 जून, 2026
डिजिटल समाधान उपलब्ध कराने वाली कंपनी, P2ER, Chrome DevTools for agents का इस्तेमाल करती है. इससे यह पक्का किया जाता है कि फ़ाइनल समीक्षा के लिए, सिर्फ़ ऐसे सॉफ़्टवेयर को लोगों तक पहुंचाया जाए जिसकी पुष्टि हो चुकी है और जो काम कर रहा हो. अपने वर्कफ़्लो को एजेंटिक इन्फ़्रास्ट्रक्चर में बदलकर, उन्होंने एआई एजेंट को यूज़र इंटरफ़ेस (यूआई) की पुष्टि करने का अधिकार दिया है. इससे, डिप्लॉयमेंट की फ़्रीक्वेंसी में बढ़ोतरी हुई है. अब हफ़्ते में एक बार के बजाय, दिन में कई बार डिप्लॉयमेंट किया जा सकता है.
चुनौती: मौजूदा ऐप्लिकेशन में क्वालिटी को बेहतर बनाना
P2ER, दुनिया भर के ब्रैंड के लिए बेहतरीन डिजिटल अनुभव उपलब्ध कराता है. इनमें कार बनाने वाली कंपनियां, घड़ी के ब्रैंड, और होटल इंडस्ट्री से जुड़ी कंपनियां शामिल हैं. उनकी मुख्य चुनौती, कई कंपनियों की तरह, जटिल और मौजूदा ऐप्लिकेशन के साथ काम करना था. एजेंटिक कोडिंग का इस्तेमाल करने वाली टीम को तीन मुख्य समस्याओं का सामना करना पड़ा:
- यूज़र इंटरफ़ेस (यूआई) की जांच करना. स्टैंडर्ड टेस्ट सुइट को डाइनैमिक डेटा से जुड़ी समस्याओं का सामना करना पड़ा. जैसे, P2ER के कुछ प्रोजेक्ट में होटल की कीमतों में उतार-चढ़ाव या सीज़नल ऑफ़र. मॉक डेटा से, इंटिग्रेशन की कमियां अक्सर छिप जाती हैं. हालांकि, कोई व्यक्ति इन कमियों को तुरंत ढूंढ सकता है.
- एजेंट के भरोसेमंद तरीके से काम न करने से जुड़ी समस्याएं. कभी-कभी, साफ़ तौर पर निर्देश न मिलने पर, एआई एजेंट किसी टास्क के पूरा होने का दावा कर देते थे. हालांकि, वे इसकी पुष्टि नहीं करते थे.
- कॉन्टेक्स्ट का न होना. बड़े टास्क और मॉडल के टाइम आउट होने की वजह से, एजेंट सेशन के लक्ष्यों को पूरा नहीं कर पाते थे. इस वजह से, डेवलपर के लिए यह पता लगाना मुश्किल हो जाता था कि एजेंट ने कौनसे टास्क शुरू किए थे और उन्हें पूरा करना है.
समाधान: कारीगरी के लिए इंफ़्रास्ट्रक्चर बनाना
P2ER ने एक ऐसा इन्फ़्रास्ट्रक्चर बनाया है जो एआई को "स्पैरिंग पार्टनर" के तौर पर देखता है. यह डेवलपमेंट के दोहराए जाने वाले पहलुओं को भी हैंडल कर सकता है. इस तरीके से, टीम को आर्किटेक्चर और क्रिएटिव तरीके से समस्या हल करने पर ध्यान देने का मौका मिलता है. इससे टीम को बेहतर काम करने में मदद मिलती है.
एजेंट के एमसीपी सर्वर के लिए, DevTools की मदद से अनुभव के आधार पर पुष्टि करने की सुविधा लागू करना
भरोसेमंद होने के लिए, P2ER ने अनुभव के आधार पर पुष्टि करने का नियम बनाया है.
इंजीनियरिंग से जुड़े इस निर्देश को प्रोजेक्ट की AGENTS.md फ़ाइल में शामिल किया गया है. इसमें बताया गया है कि:
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
टीम, एजेंट की बात पर भरोसा करने के बजाय, Chrome DevTools का इस्तेमाल करती है. इससे एजेंट को ऐप्लिकेशन को विज़ुअल और इंटरैक्टिव तरीके से नेविगेट करने के लिए, सुरक्षित माहौल मिलता है.
ये "टेस्टिंग एजेंट" कई ऐसे ज़रूरी टास्क पूरे करते हैं जिन्हें स्टैंडर्ड स्टैटिक टेस्ट पूरा नहीं कर पाते:
- डाइनैमिक डेटा की टेस्टिंग: एजेंट, स्टेजिंग एनवायरमेंट में भी असली और बदलते डेटा के आधार पर टेस्टिंग करते हैं. जैसे, अलग-अलग सीज़न में होटल की कीमतों में बदलाव. इससे उन्हें ऐप्लिकेशन का अनुभव ठीक उसी तरह मिलता है जिस तरह किसी उपयोगकर्ता को मिलता है. इसे DevTools की मदद से चालू किया जाता है. DevTools, एजेंट के इंटरैक्शन टूल के लिए काम करता है. जैसे,
new_page,navigate_page,fill,click, औरhover. इन टूल के बारे में,github-issue-testस्किल में बताया गया है. इससे एजेंट को डाइनैमिक तरीके से पुष्टि करने और उपयोगकर्ता के क्लिक पाथ को सिम्युलेट करने की अनुमति मिलती है. - विज़ुअल ऑडिट: एजेंट, Figma लेआउट और असल में लागू किए गए लेआउट के बीच विज़ुअल अंतर का पता लगाते हैं. एजेंट के लिए DevTools में मौजूद
take_screenshotटूल का इस्तेमाल करके, उनकीfigma-validateस्किल, लाइव Storybook रेंडर के हाई-रिज़ॉल्यूशन वाले स्क्रीनशॉट कैप्चर करती है. इससे, Figma एक्सपोर्ट के साथ साइड-बाय-साइड तुलना की जा सकती है. - इस्तेमाल करने से जुड़ी जांच: एजेंट, अनुवाद से जुड़ी ऐसी गड़बड़ियों या इस्तेमाल करने से जुड़ी समस्याओं का पता लगाते हैं जिन्हें अपने-आप काम करने वाली स्क्रिप्ट अक्सर नज़रअंदाज़ कर देती हैं. एजेंट, सीधे तौर पर ऐक्सेसिबिलिटी ट्री के साथ इंटरैक्ट करते हैं. साथ ही,
take_snapshotऔरtake_screenshotके ज़रिए हासिल किए गए विज़ुअल स्नैपशॉट की समीक्षा करते हैं. इससे वे यूज़र इंटरफ़ेस (यूआई) से जुड़ी गड़बड़ियों को स्कैन करते हैं. जैसे, MISSING_MESSAGE स्ट्रिंग. ऐसा, उन्हें ऑटोमेटेड पुष्टि करने के वर्कफ़्लो में साफ़ तौर पर बताया गया है.
सबटास्क को छोटे-छोटे हिस्सों में बांटना और उन्हें सेव करना
सेशन टाइमआउट और कॉन्टेक्स्ट के नुकसान से बचने के लिए, P2ER सब-एजेंट के ज़रिए काम को अलग-अलग हिस्सों में बांटता है. इसके बाद, वे अपने एजेंट को इस तरह ऑर्केस्ट्रेटर के तौर पर काम करने का निर्देश देते हैं:
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
इस प्रोसेस में, प्रॉडक्ट के मालिकों को अपडेट रखने के लिए, टीम ने एजेंटों के लिए एक कस्टम स्किल इंटिग्रेट की है. इससे वे GitHub की समस्याओं में अपने काम को ट्रैक कर सकते हैं. इससे यह पक्का होता है कि हर सब-एजेंट टास्क और उसके नतीजों को GitHub API का इस्तेमाल करके, सब-इश्यू के तौर पर सेव किया जाता है और उनका दस्तावेज़ बनाया जाता है. इससे ऑडिट ट्रेल और लगातार कॉन्टेक्स्ट बनता है, जिसे अन्य डेवलपर इस्तेमाल कर सकते हैं.
एक साथ कई काम करने के लिए, एनवायरमेंट को अलग-अलग करें
डेवलपमेंट प्रोसेस को बढ़ाने के लिए, P2ER अपने एजेंट के लिए हर टास्क के हिसाब से अलग-अलग एनवायरमेंट उपलब्ध कराता है, ताकि कई एजेंट एक साथ कोड चला सकें. इससे यूज़र इंटरफ़ेस (यूआई) की पुष्टि के दौरान, स्टेट में होने वाले टकराव और नेटवर्क से जुड़ी समस्याओं को रोका जा सकता है.
इस आइसोलेशन के लिए तकनीकी सेटअप में ये शामिल हैं:
- Git वर्कट्री को अलग करना: जब कई एजेंट एक साथ काम करते हैं, तो फ़ाइलें टकराने और वर्कस्पेस में गड़बड़ी होने से रोकने के लिए, टास्क अलग किए गए Git वर्कट्री में पूरे किए जाते हैं. हर एजेंट को एक फ़ाइल सिस्टम स्पेस मिलता है. इसमें एनवायरमेंट वैरिएबल कॉपी किए जाते हैं और डिपेंडेंसी को सिमलंक किया जाता है. इससे यह पक्का होता है कि फ़ाइल में किए गए बदलाव कभी भी एक-दूसरे को ओवरराइट न करें.
- यूनीक एनवायरमेंट: हर एजेंट और टास्क, Next.js डेवलपमेंट सर्वर को एक यूनीक आइसोलेटेड पोर्ट पर चलाता है. प्रोजेक्ट के नियमों के मुताबिक, सर्वर को
npx next dev -p <custom_port> --turbopackके साथ डाइनैमिक तौर पर शुरू किया जाता है, ताकि नेटवर्क से जुड़ी समस्याओं के बिना समानांतर तरीके से काम किया जा सके. - डेटाबेस के क्लोन: पैरलल टेस्टिंग के दौरान डेटा के टकराव को रोकने के लिए, P2ER प्रोग्राम के हिसाब से मुख्य डेटाबेस को डुप्लीकेट करता है. ऐसा एजेंट के स्टार्टअप के समय, टास्क के हिसाब से स्कीमा में किया जाता है. एजेंट की पुष्टि हो जाने और टास्क को मंज़ूरी मिल जाने के बाद, अपने-आप डेटा मिटाने की प्रोसेस, अलग किए गए डेटाबेस को मिटा देती है. इस लाइफ़साइकल से यह पक्का होता है कि हर एजेंट, नए वर्कस्पेस में काम करता है. साथ ही, वह कोई भी ऐसा डेटा नहीं छोड़ता जो किसी काम का न हो.
- टारगेट की गई टेस्टिंग: एजेंट के लिए Chrome DevTools के ज़रिए की जाने वाली सभी ब्राउज़र टेस्टिंग में, उस एजेंट इंस्टेंस को असाइन किया गया कस्टम पोर्ट ही टारगेट किया जाना चाहिए.
टेस्टिंग के लिए ज़रूरी है कि डिफ़ॉल्ट पोर्ट को हार्डकोड न किया जाए. इसके लिए,
http://localhost:<custom_port>जैसे टेस्ट टारगेट यूआरएल की ज़रूरत होती है.
असर: क्वालिटी बनाए रखते हुए, डेवलपमेंट की स्पीड में 10 गुना बढ़ोतरी हुई
ज़्यादा भरोसेमंद गार्डरेल के साथ एजेंटिक कोडिंग पर स्विच करने से, P2ER के आउटपुट में बदलाव आया. ये बदलाव, मूल रूप से इसलिए ज़रूरी थे, ताकि यह पक्का किया जा सके कि एजेंट भरोसेमंद तरीके से काम करे. हालांकि, इनसे डेवलपमेंट के पूरे लाइफ़साइकल को भी फ़ायदा मिला:
- काम के साइकल 10 गुना तेज़ी से पूरे होते हैं: अब ज़्यादातर समस्याएं एक दिन में हल हो जाती हैं. पहले, इन्हें हल होने में औसतन एक से तीन दिन लगते थे. डिप्लॉयमेंट फ़्रीक्वेंसी, हर हफ़्ते एक बार से बढ़कर हर दिन कई बार हो गई.
- QA टीमों का रणनीतिक फ़ोकस: एजेंट अब बुनियादी रिग्रेशन और "आसानी से मिलने वाले फ़ायदे" को पकड़ लेते हैं. इसलिए, टेस्टिंग टीम के सदस्य ज़्यादा गहराई से और जटिल टेस्ट के उदाहरणों पर फ़ोकस कर सकते हैं.
- हितधारकों के लिए बेहतर तरीके से लागू करना: अब लागू करने की प्रोसेस ज़्यादा बेहतर हो गई है, क्योंकि टेस्टिंग, प्रोग्रामर के स्टैंडर्ड "हैप्पी पाथ" से आगे बढ़ गई है.
- बेहतर कम्यूनिकेशन और ट्रेस करने की सुविधा: "मानवीय समस्या से लेकर लागू करने से जुड़ी उप-समस्या" नियम लागू करने से, हितधारकों को इस बारे में साफ़ तौर पर निर्देश मिलते हैं कि कौनसे तार्किक सुधार किए गए हैं. इसके लिए, उन्हें तकनीकी तौर पर लागू करने से जुड़ी जानकारी वाले टिकट पढ़ने की ज़रूरत नहीं होती. साथ ही, उन्हें यह भी पता चलता है कि इन सुधारों की जांच कैसे की जाए.
इसकी वजह से, डेवलपमेंट की प्रोसेस में तेज़ी आती है. उदाहरण के लिए, P2ER ने छह महीने में एक नया प्लैटफ़ॉर्म बनाया. अगर वह अपने पुराने तरीकों का इस्तेमाल करता, तो उसे कई साल लग जाते. समीक्षा करने वाला व्यक्ति, क्वालिटी की जांच करने के लिए आखिरी फ़ैसला लेता है. वह उन पुल अनुरोधों की समीक्षा करता है जिनकी पुष्टि एजेंट पहले ही कर चुके हैं.
टीमों के लिए तकनीकी जानकारी
इस वर्कफ़्लो को बनाते समय, P2ER ने कई ऐसी रणनीतियों की पहचान की जिनकी मदद से, वे एक्सपेरिमेंट से लेकर एजेंट की मदद से डेवलपमेंट मॉडल तक पहुंच पाए.
इन रणनीतियों से, दूसरी टीमों को एआई एजेंट को लागू करने के तरीके को बेहतर बनाने में मदद मिल सकती है:
स्क्रिप्ट इंजेक्शन और सीएलआई बैचिंग की मदद से, टोकन के इस्तेमाल को ऑप्टिमाइज़ करना
अगर एजेंट, सिर्फ़ चरण-दर-चरण नेविगेशन पर भरोसा करते हैं, तो लंबे डेवलपमेंट सेशन के दौरान एमसीपी सर्वर पर टोकन का इस्तेमाल ज़्यादा हो सकता है. उदाहरण के लिए, स्नैपशॉट लेना, आईडी ढूंढना, इनपुट भरना, और इंतज़ार करना. इस ओवरहेड को कम करने के लिए, P2ER दो तरीकों का इस्तेमाल करता है:
- इनलाइन स्क्रिप्ट इंजेक्शन: टारगेट किए गए इंटरैक्शन के लिए, जैसे कि जटिल React फ़ॉर्म के ज़रिए पुष्टि करने के लिए, एजेंट
evaluate_scriptटूल का इस्तेमाल करते हैं. इससे वे सीधे ब्राउज़र में वैनिला JavaScript इंजेक्ट कर पाते हैं. इससे, बिल्ट-इन सेटर ओवरराइड को बायपास किया जाता है और एक साथ कई कार्रवाइयाँ की जाती हैं. इससे बातचीत के कई टर्न सेव होते हैं. - सीएलआई स्क्रिप्ट बैचिंग: जब एजेंटों को "समस्या" आती है या उन्हें बहुत लंबा और बार-बार दोहराया जाने वाला ब्राउज़र फ़्लो मिलता है, तो वे सीएलआई बैचिंग फ़ॉलबैक पर स्विच करते हैं. बार-बार इस्तेमाल होने वाले अलग-अलग MCP टूल पर टोकन खर्च करने या स्क्रैच से कस्टम ऑटोमेशन स्क्रिप्ट लिखने के बजाय, P2ER, Chrome DevTools CLI को ब्राउज़र की कार्रवाइयों को बनाए रखने और बैच करने के लिए प्रॉम्प्ट करता है. इससे एजेंट, एक ही बार में कई चरणों वाले पूरे फ़्लो को प्रोग्राम के हिसाब से लागू कर सकते हैं. इससे मॉडल और टूल के बीच लगातार होने वाले कम्यूनिकेशन का बोझ काफ़ी कम हो जाता है.
ट्रेस विश्लेषण की मदद से, परफ़ॉर्मेंस ट्रैकिंग को ऑटोमेट करना
P2ER ने सिर्फ़ इंसानी सोच पर भरोसा करने के बजाय, एक ऐसी review-performanceस्किल बनाई है जो एजेंट के लिए DevTools का इस्तेमाल करती है. इससे ऑटोमेटेड Lighthouse ऑडिट और परफ़ॉर्मेंस ट्रेस किए जा सकते हैं.
एजेंट, performance_start_trace और performance_analyze_insight टूल का इस्तेमाल करके, Core Web Vitals (एलसीपी, आईएनपी, सीएलएस) को कैप्चर करते हैं और उनकी जांच करते हैं. साथ ही, मुख्य थ्रेड में आने वाली रुकावटों या लेआउट में होने वाले बदलावों का पता लगाते हैं. क्वालिटी गेट को पूरा करने के लिए, एजेंट पूरी lighthouse_audit चला सकते हैं. इससे खास तौर पर, सुलभता (a11y), एसईओ, और वेब से जुड़े सामान्य सबसे सही तरीकों में होने वाली समस्याओं से बचा जा सकता है. साथ ही, यह पक्का किया जा सकता है कि पुल अनुरोध के लिए सिर्फ़ अच्छी क्वालिटी का कोड सबमिट किया गया हो.
एजेंट के लिए Chrome DevTools की मदद से पुष्टि करने की प्रोसेस को बेहतर बनाना
P2ER, कस्टम स्किल के साथ-साथ, Chrome DevTools की मुख्य क्षमताओं का इस्तेमाल करता है. इससे एजेंट एमसीपी सर्वर की फ़ंक्शनल पुष्टि की जा सकती है. इसमें, अलग-अलग डिवाइसों को एमुलेट करने के लिए सर्वर का इस्तेमाल करना और रिस्पॉन्सिवनेस की जांच करना शामिल है. साथ ही, यह पक्का करना भी शामिल है कि यूज़र इंटरफ़ेस, अलग-अलग स्क्रीन साइज़ और डिवाइसों पर काम करता हो.
एमसीपी सर्वर का इस्तेमाल करके, एजेंट ऐप्लिकेशन पर नेविगेट कर सकते हैं. इससे उन्हें लेआउट और असल में लागू किए गए लेआउट के बीच अंतर का पता चल सकता है. साथ ही, वे ऐसी गड़बड़ियों की पहचान कर सकते हैं जिन्हें स्टैटिक टेस्ट में अक्सर अनदेखा कर दिया जाता है.
संसाधन
P2ER के इस्तेमाल के उदाहरण के बारे में ज़्यादा जानने के लिए, इससे जुड़ी GitHub रिपॉज़िटरी में बताई गई सभी स्किल के बारे में जानें.
खुद से शुरू करने और एजेंट के लिए DevTools की मदद से, इसी तरह के वर्कफ़्लो लागू करने के बारे में ज़्यादा जानने के लिए, इन संसाधनों को देखें: