Raif Agentic Development: रायफाइज़ेनबैंक में विकास का AI-रूपांतरण

सभी को नमस्कार। मेरा नाम आंद्रेई उसावका है। मैं रायफाइज़ेनबैंक में कॉर्पोरेट व्यवसाय वित्तपोषण के विकास दिशा का नेतृत्व करता हूँ।

मेरा मुख्य फोकस इस समय हमारे बिज़नेस यूनिट का AI-रूपांतरण है।

इसका अर्थ है उत्पादन और परिचालन प्रक्रियाओं का रीडिज़ाइन। इसका अर्थ है यह समझना कि हमें कौन-सी तकनीकें कहाँ लागू करनी हैं, भूमिकाओं की संरचना और सामग्री की समीक्षा कैसे करनी है, और बहुत कुछ जो हमें उन महत्वाकांक्षी लक्ष्यों को प्राप्त करने के लिए करना आवश्यक है, जिनके बारे में मैं थोड़ा आगे बताऊँगा।

तीन मुख्य विचार जो मैं चाहता हूँ कि आप इस बैठक से लेकर जाएँ।

• पहला यह है कि अक्सर मौजूदा प्रक्रियाओं में AI लागू करने की आवश्यकता नहीं होती, बल्कि प्रक्रियाओं को AI के इर्द-गिर्द पुनर्निर्मित करना चाहिए।
• दूसरा Output और Outcome की दुविधा है। ऐसे लक्ष्य कैसे चुनें जो आपको मौजूदा प्रक्रियाओं को रीडिज़ाइन करने के लिए प्रेरित करें।
• और तीसरा एजेंट की गलती है। यह उसके लिए हाथ से काम पूरा करने का कारण नहीं है। बल्कि यह सिस्टम को और बेहतर ढंग से कॉन्फ़िगर करने का कारण है।

2025–2026 में GenAI प्रौद्योगिकियों का एक सामान्य कार्यान्वयन कैसा दिखता है?

अक्सर हम, उदाहरण के लिए, एक प्रोडक्ट डेवलपमेंट टीम लेते हैं और हर भूमिका को उसका अपना AI एजेंट देते हैं।

• प्रोडक्ट को ChatVRD मिलेगा,
• Backender को Codex या Claude मिलेगा, और हर भूमिका तुरंत देखेगी कि समय की एक इकाई में वह कई गुना अधिक Output दे सकती है। प्रोडक्ट के पास उसी समय इकाई में बहुत अधिक स्पेक्स होंगे, Backender के पास बहुत अधिक कोड होगा। और लगता है कि हमारा हर कदम तेज़ हो गया है।

लेकिन स्थानीय तेज़ियाँ उस प्रभाव में नहीं जुड़तीं जिसे व्यवसाय महसूस करे, जिसे ग्राहक महसूस करे। ऐसा क्यों होता है? क्योंकि भूमिकाओं के बीच, लोगों के बीच कतारें, प्रतीक्षाएँ, हस्तांतरण मौजूद होते हैं, जो जानकारी के किसी हिस्से को विकृत और खो देते हैं तथा पुनर्कार्य की ओर ले जाते हैं। और इसलिए हमारी समग्र प्रभावशीलता नहीं बढ़ती।

यदि हम मैक्रोइकोनॉमिक आँकड़ों को देखें, तो हम देख सकते हैं कि प्रति घंटे का उत्पादन बढ़ता है, जबकि समग्र उत्पादकता — जो मूलतः अतिरिक्त पूंजी और लोगों से परे की दक्षता है — का विकास लगभग शून्य क्षेत्र में, संकट-पूर्व वर्षों के स्तर पर है। और पिछली सदी के 80 के दशक के अंत में अर्थशास्त्री रॉबर्ट सोलो ने देखा कि कंप्यूटर युग हर जगह दिखाई देता है, सिवाय श्रम उत्पादकता के आँकड़ों के। इस तरह सोलो विरोधाभास आया, और हम अब मूलतः उसका दूसरा पुनर्जन्म देख रहे हैं।

पिछली सदी के 90 के दशक की शुरुआत के प्रोसेस इंजीनियरिंग के एक केस को देखना भी दिलचस्प है। IBM Credit, IBM ग्राहकों के लिए खरीदारी का वित्तपोषण। क्लासिक क्रेडिट प्रक्रिया: क्रेडिट आवेदन का पंजीकरण, क्रेडिट विश्लेषण, शर्तों की स्थापना और आगे। कई विभाग, कई प्रमुख भूमिकाएँ। तदनुसार, शोधकर्ताओं ने देखा कि इस प्रक्रिया के दौरान सभी कर्मचारियों का कुल वास्तविक काम कितना समय लेता है। पता चला कि केवल डेढ़ घंटा। लेकिन ग्राहक आवेदन करने से परिणाम प्राप्त करने तक 144 घंटे प्रतीक्षा करता है। यह लगभग एक सप्ताह है। और पता चला कि यदि हर कर्मचारी को दो गुना तेज़ कर दिया जाए, तो ग्राहक के लिए बचत केवल 45 मिनट होगी, जो, मानिए, 144 घंटों की तुलना में नगण्य है। और सामान्यतः, इस केस पर काम करने वाले शोधकर्ताओं में से एक ने एक दिलचस्प विचार रखा कि कंप्यूटरों से उन प्रक्रियाओं को स्वचालित करने की कोशिश की जा रही है जिन्हें बस समाप्त कर देना चाहिए था और उनका पूर्ण, पूर्ण रीडिज़ाइन करना चाहिए था। और सामान्यतः, IBM Credit ने कंप्यूटरों के बिना भी यह कर लिया। वहाँ, मूलतः, प्रक्रिया में शामिल सभी भूमिकाओं को एक में समेट दिया गया। यहाँ मैं पिछली बैठक के प्रोडक्ट इंजीनियर की ओर संकेत कर रहा हूँ। और सामान्यतः, इससे उनके यहाँ ग्राहक के लिए 144 घंटे 4 घंटे में बदल गए।

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

लोग क्यों? क्योंकि पहले केवल मनुष्य ही असंरचित जानकारी को इनपुट के रूप में ले सकता था, अपनी विशेषज्ञता और कहीं भी डिजिटाइज़ न किया गया संचित अनुभव लागू कर सकता था और निर्णय प्राप्त कर सकता था।

बड़े भाषा मॉडलों के आने से ऐसे निर्णय-निर्माण नोड्स को भी स्वचालित करना संभव हुआ, क्योंकि LLM इस काम को काफ़ी अच्छी तरह संभालता है। और इसलिए हमारे पास व्यवसाय प्रक्रियाओं को केवल AI की सहायता से ही नहीं, बल्कि AI के इर्द-गिर्द भी रूपांतरित करने की संभावना आई है।

हालाँकि एक प्रश्न उठता है: हम कैसे समझेंगे कि जो रूपांतरण हम कर रहे हैं, वह प्रभावी, उपयोगी है? यहाँ मैं output और outcome की प्रबंधन की क्लासिक दुविधा की याद दिलाऊँगा। इनमें अंतर क्या है? Output ऐसे संकेतक, प्रमाण हैं कि काम चल रहा है। ये इस बात की व्यक्तिपरक अनुभूति हो सकते हैं कि मेरे हाथ में AI एजेंट आ गया और गति बढ़ गई। ये merge requests, pull-requests, एजेंट द्वारा लिखी गई कोड लाइनों की संख्या हो सकते हैं। ये सभी इस स्थिति में आवश्यक हैं कि काम हो रहा है, लेकिन ये यह गारंटी नहीं देते कि किया जा रहा काम उपयोगी है और ग्राहक को उपयोगी प्रभाव देता है। दूसरी ओर, outcome वही प्रभाव है जिसे हम प्राप्त करना चाहते हैं, उदाहरण के लिए, जब हम कोड लिखते हैं। ये वे बदलाव हैं जिन्हें हमारा ग्राहक महसूस करता है। अक्सर यह दुविधा लक्ष्य निर्धारित करते समय इस प्रकार दिखाई देती है। आप देख सकते हैं कि एक टीम या पूरी कंपनी अपने सामने सभी टीमों में AI लागू करने का लक्ष्य रखती है। या, उदाहरण के लिए, harness बनाना, प्लेटफ़ॉर्म बनाना, या हमारे प्लेटफ़ॉर्म ऑफ़र में कोई ऐसी-वैसी क्षमता जोड़ना। इससे क्या होता है? इससे यह होता है कि वास्तव में AI सभी टीमों में लागू कर दिया गया, वास्तव में प्लेटफ़ॉर्म, harness इत्यादि बना दिया गया। हालाँकि, इस बात से परे कि हमने कुछ बना दिया, इसके कौन-से प्रभाव हुए, यह अक्सर स्पष्ट नहीं होता। अक्सर व्यवसाय मेट्रिक्स उसी स्तर पर बने रहते हैं जिस पर वे संबंधित निर्माण से पहले थे।

लेकिन outcome लक्ष्य अलग तरह से तैयार होता है। उदाहरण के लिए, हम कह सकते हैं कि हम चाहते हैं कि ग्राहक द्वारा माँगा गया कोई भी बदलाव, कोई भी फीचर ग्राहक को 24 घंटे से कम समय में मिल जाए। यही वह outcome है, उदाहरण के लिए, जिस पर हमारी टीमें और हमारी कंपनी केंद्रित हैं। हम चाहते हैं कि ग्राहक को जो भी बदलाव चाहिए, वह उसे 24 घंटे से कम में मिल सके। लेकिन इसके अतिरिक्त, हम चाहते हैं कि यह बदलाव लोगों की भागीदारी के बिना स्वायत्त रूप से लागू हो। और हम चाहते हैं कि गुणवत्ता और विश्वसनीयता प्रभावित न हों।

हम अपने मौजूदा चरण में अपना time to market सरल रूप से Jira में कार्य दर्ज होने से लेकर संबंधित बदलाव के प्रोडक्शन में पहुँचने तक गिनते हैं। इसका अर्थ है कि मार्ग का यह खंड discovery प्रक्रिया के एक भाग को कवर करता है। लेकिन discovery प्रक्रिया का एक महत्वपूर्ण भाग अभी इस मापन के दायरे से बाहर है। हम इस पर तब अधिक केंद्रित होंगे जब हम अपनी पूरी delivery pipeline को पूर्णतः स्वचालित कर लेंगे। और यहाँ स्वचालन के हमारे अच्छे परिणाम हैं। विशेष रूप से, हमारी विकास प्रक्रिया के रीडिज़ाइन के परिणामस्वरूप हम median time to market को 36 गुना कम करने में सफल हुए, और 85वाँ percentile 40 गुना से अधिक। और अब हमारी 50% से अधिक समस्याएँ 24 घंटे से कम में स्वायत्त रूप से पूरी हो जाती हैं, तथा कॉर्पोरेट वित्तपोषण दिशा के भीतर कुल उत्पाद विकास का 85% एजेंट कन्वेयर से होकर जाता है।

मेरी राय में, हम इस तक काफ़ी लंबे समय में पहुँचे। यह इस ग्राफ़ में देखा जा सकता है। यहाँ, वैसे, लॉगरिदमिक स्केल है। 2025 में ही हमारे पास अग्रणी मॉडलों की पहुँच थी, हमारे पास AI एजेंट थे। हालाँकि, जैसा देखा जा सकता है, इससे हमारा time to market मौलिक रूप से कम नहीं हुआ। अगस्त तक यह मूलतः एक flatline था। और अगस्त में कुछ ऐसा हुआ कि हमारा time to market नाटकीय रूप से घट गया।

नीचे के ग्राफ़ के साथ संबंध देखा जा सकता है कि अगस्त से हमारे यहाँ एजेंट कन्वेयर द्वारा किए जाने वाले कार्यों का हिस्सा तेज़ी से बढ़ा, और वह बढ़ना जारी है। और आशा है कि वर्ष के अंत तक 100% हो जाएगा। यह प्रश्न उठाया जा सकता है: शायद हमने गुणवत्ता की कीमत पर या कार्यों को किसी विशेष तरीके से काटना शुरू करके गति खरीदी? लेकिन ऐसा नहीं है। हमारे time to market के लिए counter-metrics हैं। हम निश्चित रूप से गुणवत्ता, विश्वसनीयता और हमारे यहाँ कार्यों को कैसे काटा जाता है, इन सबका ध्यान रखते हैं। और यहाँ यह ध्यान रखना महत्वपूर्ण है कि हमारा defect rate लगभग उसी स्तर पर बना हुआ है जो पहले था। वास्तव में हमारे rollback और hotfix दो गुना भी घट गए हैं। परिवर्तनों के आकार को, उदाहरण के लिए, फ़ाइलों, कोड लाइनों इत्यादि में मापा जा सकता है। हम देखते हैं कि ये मेट्रिक्स भी एजेंट कन्वेयर लागू होने से पहले के लगभग उसी स्तर पर हैं।

यह समझने के लिए कि अगस्त में हमारे यहाँ ऐसा कौन-सा महत्वपूर्ण बदलाव हुआ, इतना नाटकीय प्रभाव क्यों हुआ, यह बताना आवश्यक है कि हम harness की अवधारणा को कैसे देखते हैं, हमारे लिए वे कौन-कौन से प्रकार हैं? हम अपने लिए वैश्विक, ऊपरी स्तर पर, उदाहरण के लिए, दो प्रकारों में बाँटते हैं। ये inner harness और outer harness हैं। Inner harness मूलतः OpenCode, Codex, Claude Code इत्यादि है। वह सब जिसे आप डाउनलोड कर सकते हैं, खरीद सकते हैं, अपने यहाँ स्थानीय रूप से इंस्टॉल करके उपयोग कर सकते हैं।

Outer harness वह चीज़ है जो बहुत-से एजेंटों को एक उत्पादन प्रणाली, औद्योगिक विकास में बदल देती है। औद्योगिक विकास क्या है? ये इंजीनियरिंग प्रथाएँ, शैली, गुणवत्ता, security, reliability हैं। यह सब वह है कि आपकी कंपनी में विकास प्रक्रिया को अपनाने का तरीका क्या है। इस विशेषज्ञता को खरीदना और इंस्टॉल करना संभव नहीं है। यह आपके पास है, और केवल आप ही जानते हैं कि आपके लिए यह कैसे काम करनी चाहिए। और हमारा outer harness, जिसे हमने Atomic नाम दिया, मूलतः इस सारी विशेषज्ञता को एक निष्पादन योग्य प्रक्रिया के रूप में लागू करता है। अर्थात यह कोई हैंडबुक, निर्देशों इत्यादि का सेट नहीं है। यह सब किसी एक ऐसी गतिशील मशीन का हिस्सा है। और यह मशीन, यह outer harness, मूलतः उत्पादन अनुबंध को लागू करती है। उत्पादन अनुबंध पाँच मुख्य प्रश्नों के उत्तर हैं:

• लक्ष्य कौन निर्धारित करता है,
• स्वायत्तता की सीमाएँ क्या हैं,
• प्रक्रिया के दौरान कौन-से सत्यापन अनिवार्य हैं और वे कैसे निष्पादित होते हैं,
• हमारा definition of done क्या है और, वास्तव में,
• संचालन के दौरान होने वाली त्रुटियों के प्रति हम कैसे दृष्टिकोण रखते हैं, कैसे प्रतिक्रिया करते हैं।

आगे मैं इनमें से प्रत्येक प्रश्न के बारे में विस्तार से बताऊँगा। हमारे लिए मुख्य परिवर्तनों में से एक यह है कि हमने अपनी टीमों में मौजूद सभी विशेषज्ञ भूमिकाओं को एक इंजीनियरिंग भूमिका से बदल दिया। यह product engineer है।

मूलतः, पहले हमारे पास बैकएंडर, फ्रंटएंडर थे; हमारे पास काफ़ी समय से टेस्टर्स और एनालिस्ट नहीं थे, लेकिन सामान्यतः LLM के आने के साथ स्पष्ट हो गया कि कोई भी इंजीनियर जनरलिस्ट हो सकता है यदि उसके पास पर्याप्त इंजीनियरिंग विशेषज्ञता और कम-से-कम computer science के क्षेत्र में ज्ञान हो। हमारा प्रोडक्ट लक्ष्य निर्धारित करता है। मूलतः इसका अर्थ है कि वह कहता है कि हम किसके लिए और क्यों बना रहे हैं, हम किस मेट्रिक को बदलना चाहते हैं। और product engineer प्रोडक्ट द्वारा लाई गई इस मंशा को एजेंट के साथ मिलकर स्पेसिफ़िकेशन में बदलता है, उसे एजेंट प्रणाली को कार्यान्वयन के लिए देता है और उसकी स्वीकृति करता है। हमने अपने इंजीनियर के पैमाने को कई गुना बढ़ाया है। अर्थात, यदि पहले, उदाहरण के लिए, हम अपने बैकएंड इंजीनियर को Codex या Claude Code देते थे, तो वह ऐसा असेंबलर बन जाता था जो कन्वेयर पर शक्तिशाली विद्युत उपकरण से सशक्त है और उस विद्युत उपकरण के साथ मिलकर अंतिम उत्पाद की बड़े मॉड्यूलों वाली असेंबली स्वयं करता है। अर्थात, यदि उसके साथ कुछ हो जाए या यदि हम इस प्रक्रिया को किसी तरह स्केल करना चाहें, तब भी हम एक bottleneck से टकराते हैं, जो मनुष्य है। इसके विपरीत, हमारा product engineer इस कन्वेयर को विकसित करने और सुधारने पर केंद्रित है। अर्थात वह guardrails बनाता और सुधारता है, सीमाएँ और स्वीकृति के नियम निर्धारित करता है, नए असाधारण मामलों का विश्लेषण करता है, सिस्टम को प्रशिक्षित करता है।

हम स्पेसिफ़िकेशनों को कैसे देखते हैं और सामान्यतः एजेंट प्रणाली के लिए लक्ष्य कैसे निर्धारित करते हैं? यहाँ स्पेसिफ़िकेशनों के प्रति हमारा दृष्टिकोण है कि उन्हें मंशा की अनिश्चितता कम करनी चाहिए, न कि कार्यान्वयन योजना को विस्तार से लिखना चाहिए। हमने वर्णनात्मक स्पेक्स आज़माए, लेकिन वे हमारे लिए काम नहीं किए। हमने SDD फ्रेमवर्क में विभिन्न स्पेसिफ़िकेशन, driven-development फ्रेमवर्क में स्पेसिफ़िकेशन आज़माए। हालाँकि अंत में हम एक काफ़ी हल्के संस्करण तक पहुँचे, जिसमें हमारे पास एक ऐसी प्रणाली है जिसके माध्यम से प्रोडक्ट और इंजीनियर कार्य निर्धारित करने के चरण में परस्पर संवाद करते हैं। सामान्यतः, वे self-control से पास हो जाते हैं। यह लगभग इस तरह दिखता है। प्रोडक्ट किसी एजेंट चैट में आता है। एजेंट के पास प्रोडक्ट monorepository तक पहुँच होती है। और तदनुसार, जब कोई व्यक्ति कहता है, “मैं ऐसा फीचर बनाना चाहता हूँ,” तो एजेंट के पास उसकी मंशा की तुलना पहले से निष्पादन योग्य कोड के रूप में वास्तव में काम कर रही चीज़ से करने की क्षमता होती है। उसे दुनिया का कोई मॉडल बनाने में बहुत कम समय लगता है। फिर प्रोडक्ट कई प्रश्नों के उत्तर देता है, कुछ टिप्पणियाँ देता है, जिसके बाद हमारे पास मंशा का एक स्पेसिफ़िकेशन आता है। इसके बाद product engineer काम सँभालता है और फिर से एजेंट के साथ मिलकर डिज़ाइन समाधान तैयार करता है। बड़ी बात यह भी कई प्रश्नों के उत्तर देने, आवश्यक होने पर कुछ सुधारात्मक टिप्पणियाँ देने, और परिणाम में product design document प्राप्त करने तक सिमटती है। डिज़ाइन डॉक्यूमेंट विस्तार से नहीं लिखता कि कौन-सी फ़ाइलें बदलनी हैं, कौन-से फ़ंक्शन जोड़ने हैं इत्यादि। हम इसमें विश्वास नहीं करते। हम मानते हैं कि एजेंट को मूलतः एक स्पष्ट goal, एक स्पष्ट लक्ष्य देना चाहिए, जिसके लिए एजेंट Kill Clearance कर सके। अर्थात यहाँ functional requirements, non-functional requirements, acceptance criteria हैं।

शायद सबसे महत्वपूर्ण गुण, वह सहमति जिसने हमें अपना time-to-market कई गुना बढ़ाने दिया, इस बात की सहमति है कि हमारा definition of done कैसा है।

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

एक ऐसा कन्वेयर बनाने का विचार बहुत आकर्षक लगता था जिसमें planner हो, executor हो, tester हो, हर तरह के critics हों इत्यादि। पता चला कि ऐसा कन्वेयर mono-agent प्रणाली से बहुत खराब काम करता है। यहाँ हमारा अनुभव Google के उस शोध से मेल खाता है जिसने स्थापित किया कि क्रमिक कार्यों में multi-agent प्रणालियाँ mono-agent प्रणालियों से खराब परिणाम देती हैं। हम इसे अपने लिए इस प्रकार तैयार करते हैं: “एजेंट के लिए cognitive continuity सुनिश्चित करना महत्वपूर्ण है,” ताकि वह मनुष्य की तरह कार्य के कार्यान्वयन में काफ़ी nonlinear ढंग से आगे बढ़ सके, ताकि उस पर किसी चरण या विशिष्ट भूमिका मुखौटे द्वारा लगाए गए कठोर प्रतिबंध न हों। अर्थात वह कोड का अन्वेषण कर सकता है, कोड लिख सकता है, किसी भी क्रम में टेस्ट चला सकता है, environment से, परिवेश से संवाद कर सकता है, डिज़ाइन में कुछ छूटे हुए पहलू ढूँढ सकता है। और हम मूलतः उसे इस तरह fit भी करते हैं कि यदि उसे लक्ष्य निर्धारण में या अपने प्रयास के दौरान कोई गंभीर दोष मिलता है, तो वह हर कीमत पर उसे पूरा करने की कोशिश न करे, बल्कि हार मान ले, कहे कि “मैं fail हो गया।” और इस प्रकार हमारे पास गंभीर दोष को दूर करने का अवसर आता है।

ऊपरी स्तर पर हमारी प्रणाली इस तरह दिखती है। अर्थात देखा जा सकता है कि यहाँ कई मुख्य स्तर हैं। एक एजेंट स्तर है, मूलतः वे ही Inner Harness भाग हैं। वहाँ कार्य निर्धारण के लिए उत्तरदायी एजेंट है। एक एजेंट है जो निष्पादन के लिए उत्तरदायी है। यह इसी Harness component का सबसे बड़ा भाग है। एक Refine एजेंट है, जिसका काम traces, टिप्पणियों इत्यादि के ऐतिहासिक स्तर में सुधार के बिंदु ढूँढना है। और हमारे पास एक बहुत बड़ा, अतुलनीय रूप से बड़ा हिस्सा है। यह deterministic code है, मैं इसे “सिस्टम” कहता हूँ। क्लासिक Python कोड। वहाँ, उदाहरण के लिए, controller जैसी एक entity है, जो बहुत-सी बहुत महत्वपूर्ण चीज़ों के लिए उत्तरदायी है। उदाहरण के लिए, वह यह सुनिश्चित करती है कि निष्पादक एजेंट ने वास्तव में वे सभी गुणवत्ता जाँच कीं जिनके बारे में वह दावा करता है कि वे पूरी हो चुकी हैं। अर्थात यह सिस्टम एजेंट के बाद बचने वाले काम के प्रमाणों का परीक्षण करता है। यह सिस्टम त्रुटियों से उबरने के लिए उत्तरदायी है। उदाहरण के लिए, कोई infrastructure component झिलमिला गया या, पता नहीं, पूरी प्रणाली गिर गई। इस स्थिति में हम state और संचित प्रगति नहीं खोते। हम लगभग उसी बिंदु से पुनः आरंभ करते हैं जहाँ हम गिरे थे। यही भाग error budgets, self-healing और कई अन्य चीज़ों के लिए उत्तरदायी है। हमारा एजेंट स्वयं कोई MR नहीं बनाता। यह फिर से deterministic component करता है। अर्थात, सिद्धांततः, हम देख सकते हैं कि सिस्टम non-deterministic stochastic component के ऊपर एक deterministic परत है। हम एजेंट की बात पर विश्वास नहीं करते। इस तथ्य के बावजूद कि एजेंट के पास परियोजना में मौजूद हर संभव प्रकार के टेस्ट चलाने, linters, checks इत्यादि चलाने की क्षमता है, ये जाँचें फिर भी CI/CD pipeline के दौरान और controller द्वारा merge request बनाए जाने से पहले अतिरिक्त रूप से चलेंगी। अर्थात हम यहाँ बदलाव को merge request के रूप में किसी मनुष्य को review के लिए सौंपने से पहले सभी संभावित स्वचालित जाँचें करने का प्रयास करते हैं जो हमारे लिए उपलब्ध हैं। और अंत में हमारे पास review है। और स्पष्ट है कि जब हमने अपने कन्वेयर की performance इतनी कई गुना बढ़ा दी, तो हमारे पास review करने के लिए बहुत अधिक कोड हो गया। और स्पष्ट है कि इंजीनियरों का फोकस इस review को सुनिश्चित करने की ओर स्थानांतरित हो जाता है।

और इतनी मात्रा के कोड का पुराने तरीके से review करना असंभव हो जाता है। इसलिए हमारे इंजीनियर diff के review पर केंद्रित नहीं होते। हम एक परत जोड़ते हैं जो इन diffs को उन निर्णयों के सेट में बदल देती है जिन्हें एजेंट ने प्रक्रिया के दौरान लिया था। अर्थात मूलतः कोई रिपोर्ट, संभवतः कुछ visualizations के साथ, जिसका review कोई व्यक्ति कर सकता है। यदि उसे आवश्यकता हो, तो वह भीतर जाकर कोई विशिष्ट diff देखेगा। लेकिन मूलतः, diff का सीधा review हमारे यहाँ एजेंट प्रणाली भी करती है।

यह हमारा operational dashboard है, जिससे हमारी टीम अपना दिन शुरू और समाप्त करती है। वास्तव में, यहाँ दिखता है कि अगस्त के लिए 900 से अधिक कार्य पहले ही एजेंट प्रणाली से होकर गुज़रे हैं। यह काफ़ी पुराना screenshot है। वास्तव में वहाँ एक हज़ार से बहुत अधिक हैं। और हमारा cumulative success rate लगभग 70% है। यह 90 दिनों की अवधि के लिए है। यहाँ ऐसी महत्वपूर्ण मेट्रिक दिखती है जैसे पहली बार में स्वीकृति। Pass at one, 31%। यह मूलतः उन कार्यों का हिस्सा है जिनमें एजेंट ने समाधान को इतनी आदर्श तरह से संभाला कि reviewer को कोई टिप्पणी करने योग्य बात नहीं मिली और उसने बस इस समाधान को स्वीकार कर लिया। हमारा यह हिस्सा बढ़ रहा है। सामान्यतः, हमें हमारे लिए मुख्य मेट्रिक्स की वृद्धि सुनिश्चित करने में क्या सहायता करता है? प्रक्रियाओं में कई मुख्य बदलाव। उदाहरण के लिए, पहले हमारे यहाँ सेवाओं, फ्रंटएंड्स, टेस्ट्स इत्यादि को अलग-अलग repositories में रखना प्रचलित था। खैर, ऐतिहासिक रूप से ऐसा बन गया था। इसलिए जब आपको कोई फीचर बनाना होता है, तो आपको कई merge requests बनाने होते हैं और इन merge requests के संबंधित master और deploy में विलय का orchestration करना होता है। हम monorepository की अवधारणा पर चले गए। अर्थात हम एक सीमित प्रोडक्ट संदर्भ लेते हैं और उसकी सभी services, fronts, tests, wiki, जो कुछ भी हो, को एक एकल monorepository में एकत्र करते हैं। यह हमें, पहला, उस प्रोडक्ट में, उस प्रोडक्ट क्षेत्र में किसी भी feature बदलाव, किसी भी नए फीचर को केवल एक merge request से जोड़ने देता है। और दूसरा, यह एजेंट को अन्वेषण के दौरान, विश्लेषण में और निष्पादन के दौरान उच्च-गुणवत्ता समाधान deliver करने के लिए, यह समझने के लिए कि वह किस दुनिया, किस environment के साथ काम कर रहा है, संभावित रूप से सबसे व्यापक संदर्भ तक पहुँच देता है।

हमने अपने पूरे Harness निर्माण से जो सबसे महत्वपूर्ण सबक सीखा, वह यह है कि premature optimization बुराई है। शुरुआती चरणों में, जब आप कन्वेयर बना रहे हों, तो माचिस बचाने, tokens, dollars इत्यादि बचाने की कोशिश नहीं करनी चाहिए। दुर्भाग्यवश, इससे आप बस अपने संसाधन खर्च करते हैं। हमने शुरुआत में, निश्चित रूप से, यह चोट खाई। हमने शुरुआत एक कमज़ोर मॉडल लेने से की, उसके इर्द-गिर्द एक अत्यधिक जटिल Harness बनाने की कोशिश की, जो उसे हमारी चाही दिशा में धकेले। और हम उस entropy से लड़ रहे थे जो उसी family के मॉडल के अगले संस्करण के release के दौरान केवल कुछ महीनों में स्वयं गायब हो गई। अर्थात हमने कुछ ऐसे पहिए बनाने में बहुत संसाधन खर्च किए जिन्हें हमने तुरंत फेंक दिया। सामान्यतः, तब से हम ऐसी गलतियाँ न करने का प्रयास करते हैं। हम तैयार component base लेते हैं। ये agent frameworks हैं, हमारे मामले में LangChain ecosystem है। workflow management के तैयार tools। Observability tools, LLM gateways। इनसे हम अपनी Outer Harness प्रक्रिया का निर्माण, मॉडलिंग करते हैं। इन्हीं blocks की सहायता से हम अपनी आंतरिक उत्पादन प्रक्रिया को मॉडल करते हैं, जिसे हम स्वाभाविक रूप से तैयार रूप में खरीद नहीं सकते।

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

एजेंट अक्सर शब्दबहुल होता है, वह अक्सर ऐसे टेस्ट बनाता है जो सामग्री की बजाय रूप को टेस्ट करते हैं, वे व्यवहार की बजाय रूप को टेस्ट करते हैं। और ऐसे टेस्ट अपने आप में बहुत कम मूल्य रखते हैं। और इस समस्या को किसी तरह व्यवस्थित रूप से ठीक करने के लिए, हमने आत्म-सुधार का एक स्वायत्त चक्र विकसित किया। यह किसी अवधि में एक बार चलता है, प्रोडक्ट monorepo में MR पर डेवलपर्स की पहले न देखी गई सभी टिप्पणियाँ पढ़ता है, फिर वास्तव में एजेंट उनका विश्लेषण करता है, कुछ सामान्य दोहराई जाने वाली घटनाएँ पहचानने और यह परिकल्पनाएँ रखने की कोशिश करता है कि इसे व्यवस्थित रूप से कैसे ठीक किया जा सकता है। इन परिकल्पनाओं के बाद, वह merge request के रूप में प्रोडक्ट monorepo में, स्वयं एजेंट कन्वेयर की monorepo में बदलाव प्रस्तावित करता है, यदि, उदाहरण के लिए, लगता है कि system prompt बदलकर समस्या ठीक की जा सकती है।

हमारे पास ऐसे 60 से अधिक प्रस्ताव पहले ही तैयार और टीम द्वारा स्वीकार किए जा चुके हैं, और इससे पहली कोशिश में समाधान की मेट्रिक में काफ़ी सुखद वृद्धि हुई है।

डिलीवरी की गति को सामान्य स्थिति बनाने के लिए चार मुख्य क्षेत्रों पर ध्यान केंद्रित करना आवश्यक है।

• पहला और शायद सबसे महत्वपूर्ण, दो सबसे महत्वपूर्ण चीज़ों में से एक, upstream में कार्य निर्धारण की गुणवत्ता है। अर्थात कार्य किस कार्य-निर्धारण के साथ, किस अनिश्चितता स्तर के साथ एजेंट के पास काम के लिए आता है। अर्थात यहाँ सारी महत्वपूर्ण अनिश्चितता को बिल्कुल शुरुआती चरण में दूर करना महत्वपूर्ण है।
• दूसरा, एक स्थिर सत्यापन वातावरण, स्थिर environment है जिसमें एजेंट काम करता है। यह आवश्यक है कि टेस्ट flaky न हों, infrastructure झिलमिलाए नहीं, dependencies mockable हों इत्यादि। अर्थात मूलतः यहाँ सभी मानक इंजीनियरिंग प्रथाएँ लागू होती हैं।
• तीसरा, एजेंट आपके विचार नहीं पढ़ सकता। इसलिए टीम के समझौते लोगों के दिमागों में नहीं रहने चाहिए, बल्कि उन्हें, उदाहरण के लिए, skills, prompts, ऐसी किसी चीज़ में स्थानांतरित होना चाहिए जहाँ तक एजेंट पहुँच सके, जिससे वह समाधान करते समय निर्देशित हो।
• चौथा, सभी संभव जाँचें प्रक्रिया में शामिल होनी चाहिए। Deterministic जाँचें अत्यंत महत्वपूर्ण हैं। क्लासिक इंजीनियरिंग प्रथाएँ हमें उत्पादों, प्रणालियों के बीच उपयुक्त सीमाएँ बनाने में मदद करती हैं। यहाँ domain-driven design अच्छी तरह काम करता है। integration, unit tests इत्यादि की काफ़ी उच्च coverage होनी चाहिए। static analysis जोड़ना चाहिए इत्यादि।

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

मेरा मानना है कि इसे ठीक करने का तरीका टीम की मानसिकता पर काम करने, उन बदलावों में टीम की भागीदारी पर काम करने तक सिमटता है जिन्हें आप रणनीतिक रूप से महत्वपूर्ण मानते हैं। और निश्चित रूप से definition of done के स्तर पर आप यह भी कह सकते हैं कि आपके यहाँ काम किस बिंदु से स्वीकार माना जाता है — केवल तब जब उसे एजेंट ने किया हो। full-in जाना आवश्यक नहीं है; आप ऐसा बदलाव काफ़ी सीमित क्षेत्र में लागू कर सकते हैं। उदाहरण के लिए, हमने इस रूपांतरण की शुरुआत इस तरह की कि पाँच में से एक विशिष्ट टीम पूरी तरह नए कार्य तरीके पर चली गई।

यह महत्वपूर्ण है कि वहाँ रूपांतरण का वास्तव में पूरा तत्व हो, ऐसा न हो कि काम का यह भाग मैं एजेंटों से कराऊँगा और काम का यह भाग पुराने तरीके से करूँगा। यदि आपके पास यह वैकल्पिकता रह जाती है, तो यह वैकल्पिकता हमेशा रूपांतरण के विरुद्ध लागू होगी। बहुत हद तक इसलिए कि लोग गलतियों से डरते हैं, जबकि मेरी राय में गलतियाँ, पहला, ऐसे रूपांतरण के दौरान अपरिहार्य हैं, और दूसरा, वे आवश्यक हैं, क्योंकि इन्हीं गलतियों के कारण अंततः सिस्टम सीखता है।

इसलिए ऐसे रूपांतरण के दौरान नेता को जो मुख्य निर्णय लेने चाहिए, वे हैं: पहला, लक्ष्य को outcome के रूप में तैयार करना, अर्थात ऐसी चीज़ के रूप में जिसे ग्राहक महसूस कर सकता है, अनुभव कर सकता है। इस लक्ष्य के लिए ऐसी महत्वाकांक्षा तैयार करना कि पुराने कार्य तरीके से वह बस अप्राप्य हो। कर्मचारियों की संरचना की समीक्षा करना, अर्थात टीम में आपकी कौन-सी भूमिकाएँ हैं, क्या आपके पास भूमिकाओं की श्रृंखला, विभिन्न चरणों के बीच हस्तांतरण हैं। यदि हैं, तो प्रक्रिया में बदलावों का एक मालिक बनाना बेहतर है। यह सुनिश्चित करने के लिए काम करना चाहिए कि आपके पास स्वचालित नियंत्रण आए, कि सभी जाँचें प्रक्रियाओं में अंतर्निहित और स्वचालित हों। और demo trap को दूर करना चाहिए। मैं इस स्थिति को ऐसा कहता हूँ जिसमें टीम प्रबंधन के सामने एजेंट का सुंदर प्रदर्शन करती है जो काम स्वायत्त रूप से करता है, प्रेज़ेंटेशन layout करता है, कोड लिखता है इत्यादि, और फिर आप देखते हैं कि टीम कैसे काम करती है, तो वहाँ सब कुछ पहले की तरह मैनुअल ड्राइव पर होता है। इस demo trap को समाप्त करना चाहिए। और शायद ऐसा एक महत्वपूर्ण बिंदु जो हमारे लिए अच्छी तरह काम किया, वह है कि आप अपनी North Star metric लेते हैं, हमारे लिए यह Time to Market है, और उसके विभिन्न घटकों को लेते हैं, उन्हें ऐसे dashboard पर रखते हैं जिसे आप वास्तव में real-time में देखते हैं, और हर कार्य-दिन की शुरुआत उसी dashboard से करते हैं।

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

Q1: सुनिए, आंद्रेई, आपने कहा था कि आपके पास एक mono-agent है, लेकिन review मनुष्य करता है। क्या, उदाहरण के लिए, अलग-अलग मॉडलों के स्वतंत्र एजेंटों के orchestrated पैनलों से कोड review को बदलने का विचार नहीं था? और यदि मनुष्य review करता है, तो bottleneck — क्या वह नया bottleneck नहीं बन गया?

• Speaker 1: हाँ, निश्चित रूप से, मनुष्य नया bottleneck बन गया है, लेकिन मनुष्य हमारा एकमात्र reviewer नहीं है। हमारे पास किसी न किसी रूप में agent reviewer है, जो कुछ अतिरिक्त feedback देता है, उसे सबसे पहले मनुष्य को देता है, निष्पादक एजेंट को नहीं, क्योंकि अन्यथा हमारे यहाँ adversarial loops उत्पन्न होते हैं, और काम चक्रीय होकर परिणाम नहीं दे सकता। पैनलों के दृष्टिकोण से, यह शायद, पहला, हमारे लिए हमारी शुरुआती iterations में काम नहीं किया, जब हम कुछ multi-agent, multi-role systems बना रहे थे। इससे हमें अपेक्षित परिणाम नहीं मिला। और हमने यह रास्ता चुनने का निर्णय लिया कि जटिलता केवल तभी जोड़ेंगे जब वह उचित हो। अर्थात यदि हम देखते हैं कि निष्पादक एजेंट अपना काम नहीं संभाल रहा, तभी हम कुछ अतिरिक्त भूमिकाएँ, चरण इत्यादि जोड़ेंगे।

Q2: आंद्रेई, बिज़नेस यूनिट्स और agent development के बारे में बोलते हुए, आपने विशेष रूप से agent development को किस पैमाने पर लागू करना शुरू किया? किन सेवाओं के पैमाने पर?

• खैर, यहाँ शायद कई चीज़ें भूमिका निभाती हैं। पहला, यदि हमारे बिज़नेस यूनिट के पैमाने की बात करें, तो कुल मिलाकर लगभग 170 लोग हैं। इनमें agile टीमें और operational support दोनों हैं। यदि उन सेवाओं की संख्या की बात करें जिन्हें एजेंट कन्वेयर किसी न किसी रूप में विकसित करता है, तो हमारे पास 200 से अधिक प्रोडक्ट, सर्विस repositories थीं। हमने उन्हें ऐसी 10 product monorepos में समेट दिया। इसलिए हमारा पैमाना काफ़ी बड़ा है। ये सभी सेवाएँ भी वर्षों तक लिखी गईं। कोड की मात्रा बहुत विशाल है। यहाँ शायद इस प्रश्न का कोई सार्वभौमिक उत्तर नहीं है कि एजेंट को कोड से निपटने की क्षमता कैसे दी जाए। ये इंजीनियरिंग प्रथाएँ हैं, अर्थात आपका कोड कैसे डिज़ाइन किया गया है, टेस्ट कैसे लिखे गए हैं। यह फिर से उन उपकरणों का प्रश्न है जो आप एजेंट को codebase के अन्वेषण के लिए देते हैं। उदाहरण के लिए, कुछ समय पहले, जब हमारे पास थोड़े कमजोर मॉडल और हमारे एजेंट की कुछ अलग architecture थी, हम कोड पर semantic search करते थे। अर्थात उसे index करते थे इत्यादि। फिर हमने इसे छोड़ दिया, क्योंकि मौजूदा चरण में मौजूदा मॉडलों के लिए ripgrep तुलनीय परिणाम देता है और किसी upfront indexing की आवश्यकता नहीं रखता। अर्थात यह सब काफ़ी चक्रीय है। मुझे लगता है यहाँ प्रश्न अधिक इस बात का है कि अलग-अलग चीज़ें आज़मानी चाहिए। समय के साथ उन प्रथाओं पर फिर लौटना चाहिए जो काम नहीं कर पाईं। संभव है कि वे मॉडल के नए संस्करण में या आपके द्वारा उपयोग किए जा रहे framework में काम करें।

Q3: क्या ऐसी किसी प्रक्रिया का कोई उदाहरण है जिसे एजेंट ने बिल्कुल विकसित किया हो? यदि यह कोई विचार नहीं है।

• खैर, शायद मैं यहाँ सीधे business process के बारे में नहीं बोलूँगा। हमारे पास बहुत-सी अलग-अलग सेवाएँ हैं जो इस business process को लागू करती हैं। मूलतः, हमारी agile टीमें कॉर्पोरेट वित्तपोषण की क्रेडिट प्रक्रिया को स्वचालित करती हैं। वहाँ अलग-अलग चीज़ें हैं। powers of attorney जारी करना, certification, अर्थात अधिकृत व्यक्तियों के हस्ताक्षर का प्रमाणीकरण इत्यादि। अर्थात वहाँ कई तरह की प्रणालियाँ हैं। और बड़ी बात में, यदि प्रश्न इस तक सिमटता है कि एजेंट मनुष्य के काम की तुलना में कितने जटिल बदलाव करता है, तो वही सारा काम जो मनुष्य करता था, अब एजेंट करता है। अर्थात हमारे यहाँ ऐसा नहीं है कि हमने काम का कोई हिस्सा एजेंट को छोड़ दिया और सबसे कठिन कार्य स्वयं करते हैं। ऐसा नहीं है, यह हमारे definition of done में ही दर्ज है।

Q4: नमस्ते, मैं एक tester हूँ। मैंने स्लाइड पर देखा कि आपने manual checks, manual testing छोड़ दिया है। और आपने इसे autotests पर डाल दिया: end-to-end, integration इत्यादि। यह जानना दिलचस्प है कि आप अब validation और verification का आवश्यक पैमाना कैसे निर्धारित करते हैं? यह बहुत तीखे संदर्भ में सुनाई देता है, मानो आपके यहाँ हर corner case के लिए बहुत-से end-to-end बन गए हों। आप इसे कैसे हल करते हैं?

• हमारे यहाँ testing pyramid तैयार करने, हमारी परियोजनाओं के लिए इष्टतम testing pyramid सुनिश्चित करने के संदर्भ में कुछ तैयारी का काम था। हम पूरे 2025 में इस पर काम कर रहे थे, यहाँ तक कि एजेंटों को बड़े पैमाने पर लागू करने से पहले भी। उस समय जब हम product engineers इत्यादि तक पहुँचे, तो हमारे लिए स्पष्ट हुआ कि हमें testing practices को किसी तरह एकीकृत करना होगा। इसलिए यहाँ कुछ तैयारी का काम किया गया था। यह कहने के लिए कि कोई वैज्ञानिक दृष्टिकोण है जिसका उपयोग समझने के लिए किया जा सकता है कि end-to-end tests का इतना हिस्सा, UI tests का इतना हिस्सा, unit tests का इतना हिस्सा हो और फिर सब अच्छा होगा, मुझे ऐसे किसी दृष्टिकोण की जानकारी नहीं है। हम यहाँ अधिक ऐतिहासिक ढंग से कार्य करते हैं। हमारे यहाँ मनुष्य किसी न किसी रूप में बना रहता है, लेकिन वर्तमान चरण में उपयोगकर्ताओं का महत्वपूर्ण हिस्सा हमारी प्रणालियों के लोग हैं। और फिर भी हमारे यहाँ product engineer के रूप में मनुष्य इन MRs को देखता है। अभी हम उस बिंदु से नहीं गुज़रे हैं जहाँ ऐसा करना भौतिक रूप से असंभव हो। इसलिए किसी न किसी तरह हम, संभवतः आँखों से और उपयोगकर्ताओं के feedback के माध्यम से, जो वे हमें सीधे chats में दे सकते हैं, साथ ही कुछ SDKs इत्यादि से, देखते हैं कि क्या कोई संकेत हैं जो बताते हैं कि गुणवत्ता में गिरावट हुई है। अभी हमारे यहाँ ऐसे संकेत नहीं हैं।

Q5: अच्छा, तो क्या मैं सही समझ रहा हूँ कि टीम स्तर पर यह तय होता है कि जो व्यक्ति एकबारगी MRs का review करता है, वह देखता और जाँचता है कि वहाँ किस प्रकार के tests लिखे गए हैं, कि वे मूल व्यवसायिक मंशा से पर्याप्त रूप से अच्छी तरह निपटते हैं?

• खैर, बहुत मोटे तौर पर, हाँ। और वह वही व्यक्ति है जिसने, सिद्धांततः, उस व्यवसायिक मंशा का product design स्वीकृत किया था। अर्थात हमारे यहाँ ऐसा विभाजन नहीं है कि एक व्यक्ति ने product design स्वीकृत किया, फिर एजेंट ने बनाया, फिर कोई तीसरा व्यक्ति इसे review करे। हमने इस प्रथा को छोड़ दिया है। अब इसमें कोई विशेष अर्थ नहीं है। यह पहला बिंदु है। दूसरा, हमारे पास पहले से skills के रूप में digitize की गई, कहें तो, engineering practices का एक विकसित सेट है, जो सुझाव देता है कि हम अपने बदलावों के लिए किस प्रकार के tests देखना अपेक्षित रखते हैं। अर्थात हम यहाँ भी कुछ रास्ता तय कर चुके हैं। स्वाभाविक रूप से, शुरुआती चरण में इंजीनियर प्रणालियों द्वारा उत्पन्न इस बड़ी मात्रा के slop को देखते हैं, नाराज़ होते हैं, कुछ टिप्पणियाँ छोड़ते हैं, skills को फिर से लिखते हैं। यह अपरिहार्य है, इसे किसी और तरह व्यवस्थित नहीं किया जा सकता।

Q6: बहुत दिलचस्प प्रस्तुति। दो प्रश्न हैं। एक छोटा, दूसरा विचार के लिए। ऐसी प्रक्रियाएँ हैं जो कानून के अक्षर के अनुसार महत्वपूर्ण हैं। Compliance, विभिन्न प्रकार की regulation। वहाँ आपकी कोई सफलताएँ हैं या नहीं?

• यह शानदार प्रश्न है, धन्यवाद। यहाँ वास्तव में अभी हम अटकते हैं। यह अपरिहार्य है, हम प्रणाली के इस हिस्से की rigidity से टकराएँगे। यह बाकी सब से धीमे बदलेगा। लेकिन फिर भी, हम मानते हैं कि यहाँ भी एक निश्चित... पहला, हम सहयोगियों के यहाँ बदलने, कुछ तकनीकें लागू करने की दिशा में प्रगति देखते हैं। दूसरा, हमारी कंपनी मूलतः API First है। विभागों के बीच हमारी सारी परस्पर क्रिया डिज़ाइन में API की ओर बढ़ती है। और हम इसमें बहुत दृढ़ता से विश्वास करते हैं। और तीसरा, मेरा मानना है कि कानून, कुछ regulatory standards भी धीरे-धीरे बदलेंगे, इस आधार पर कि हमारे लिए कौन-सी तकनीकें उपलब्ध हैं और वे आर्थिक अर्थ में क्या enable करती हैं।

Q7: अब कठिन प्रश्न। सामान्यतः, हम एजेंटीकरण कर रहे हैं, अपने knowledge management mechanics को स्थानांतरित कर रहे हैं। एक समस्या pip point 0 है, जब बदलाव करने के लिए पर्याप्त ज्ञान हो, एजेंट को context दिया जा सके। मुझे ऐसा लगा कि जब आपने सब कुछ monorepository में स्थानांतरित किया, तो आपने वास्तव में इस थीसिस को मेज़ से हटा दिया कि code एक commodity है। यह आपके यहाँ सत्य का बिंदु बन गया, जिसका उपयोग ज्ञान आधार के हिस्से के रूप में context में किया जाता है, ताकि एजेंट कुछ कर सके। क्या मेरा कथन सही है?

• सही कथन है, हाँ।

Q8: नमस्कार। मेरा एक संक्षिप्त प्रश्न है। प्रस्तुति में आपने बताया कि आप विकास को कई गुना या यहाँ तक कि दर्जनों गुना तेज़ कर सके। आपने अपने products को समान आँकड़ों से कैसे तेज़ किया, ताकि वे बिना अनिश्चितता के वर्णित लक्ष्य तैयार करें और आपका development शुरुआत में ही न रुक जाए? क्योंकि आपका कन्वेयर प्रोडक्ट्स के बिल्कुल आरंभ से उसी गति से शुरू होना चाहिए।

• हाँ, यह शानदार प्रश्न है। वहाँ मैंने यह आरक्षण भी किया था कि हमारे यहाँ वर्तमान चरण में discovery का एक भाग है। अर्थात हम delivery पर केंद्रित थे, discovery अभी महत्वपूर्ण हिस्से में कोष्ठक से बाहर है। अर्थात मैंने जो interface का उदाहरण दिखाया था, वह इस बात का एक prototype है कि हमारे यहाँ product कार्य कैसे निर्धारित करेगा। हम धीरे-धीरे प्रणाली के इस भाग को बाईं ओर विस्तार देने की कोशिश कर रहे हैं ताकि अधिकतम रूप से, discovery को भी कवर कर सकें। उदाहरण के लिए, स्पष्ट है कि यहाँ मंशा का केवल qualification हुआ, अर्थात एजेंट यह समझे कि मेरा क्या मतलब है। लेकिन मेरे पास यह मंशा आने से पहले भी कुछ काम हुआ था। हम मानते हैं कि यह काम भी विभिन्न connectors की सहायता से इसी प्रणाली के भीतर होना चाहिए: बाहरी परिस्थितियों का कुछ scouting, ग्राहकों का विश्लेषण इत्यादि। यह इसी surface में होना चाहिए। और हम अभी वहाँ बहुत गहराई तक नहीं गए हैं। अर्थात हमारे यहाँ कंपनी में इस दिशा में बिज़नेस यूनिट्स के बाहर भी काम चल रहा है। हमारे पास, उदाहरण के लिए, प्रभाव क्षेत्रों और focus क्षेत्रों के विभाजन का समझौता है। हम अभी अधिक delivery भाग पर केंद्रित हैं। लेकिन फिर भी हम सिद्धांततः अच्छी तरह जानते हैं कि हमें क्या करना है। हमारा यह backlog वर्षों से इकट्ठा हो रहा था। पहले हमें इसे प्रोसेस करना चाहिए।

Q9: TMS architect। पहले एक कहानी थी कि TMS किए जाते हैं, फिर यह सब स्वचालित होता है। यह सब कहाँ है, क्या यह निशान बना रहता है और बाद में tech support की complaints और बाकी सब कौन संभालता है?

• हमारे यहाँ यह ज़िम्मेदारी उसी तरीके के कारण ली जाती है जिससे हम यह देखते हैं कि परियोजना की टीम किसके लिए उत्तरदायी है। हमारे यहाँ यह ज़िम्मेदारी कभी केवल autotests की नहीं रही। और जहाँ तक TMS की बात है, पिछले साल हमारे सामने यह दुविधा थी कि हमारे पास जो comp divide tml था, उसे रखें, यह सब उसमें ले जाएँ या नहीं। हमने वहाँ कुछ handbooks, निर्देश लिखे ताकि इंजीनियर भी ऐसा कर सकें। इंजीनियरों ने इसे देखा, कहा कि यह सब बेकार है, और इसे छोड़ दिया। यह काम TMS के बिना होने लगा। हमारे मामले में — मैं यह नहीं कहता कि यह सभी के लिए लागू सार्वभौमिक नुस्खा है — हमने TMS और autotester के काम के इस अत्यधिक औपचारिक हिस्से, दोनों को छोड़ दिया। जहाँ तक testers का प्रश्न है, हमारे पास सरल दुविधा है: tester को product engineer बनना चाहिए।

Q10: लेकिन मान लें कि जब technical specification बनता है, decomposition होती है, तो सामान्यतः हम test documentation से उसके coverage के लिए TS की मात्रा का आकलन कर सकते हैं ताकि गुणवत्ता को समझ सकें और testing की दृष्टि से उसका आकलन कर सकें।

• हाँ, मैं समझता हूँ कि आप किस बारे में कह रहे हैं। मैंने भी ऐसी कंपनी में काम किया है जहाँ waterfall approach था, लेकिन अब हमारी कंपनी में agile है, अर्थात हमारे यहाँ ऐसा नहीं है कि हम कोई TS चलाते, लिखते और अपडेट करते हैं। अर्थात हमारे यहाँ प्रक्रिया कुछ अलग तरीके से और कुल मिलाकर एजेंटों पर व्यवस्थित है, विकास का हमारा अलग दृष्टिकोण है, हमारे पास TS नहीं है। अब भी, जब एजेंट कन्वेयर है, हमारे यहाँ विस्तृत TS नहीं लिखा जाता, tests की कोई मात्रा, testing.... हमारे पास spec है। Spec है। शायद वह उसी भूमिका को बदलता है जो आप TS को देते हैं। और हमारे लिए spec मुख्य प्रश्नों का उत्तर देता है.. फिर भी, इसे चलाने के कई प्रारूप हैं, यह TS, PRD, ADR, SDD और अन्य practices हो सकती हैं। सबने इसे अलग-अलग किया और करते हैं, लेकिन हमारे यहाँ काफ़ी सरल spec है: functional और non-functional requirements, non-goals, acceptance criteria। लेकिन हम spec में नहीं लिखते कि कौन-से tests करने हैं: एजेंट अपनी execution trajectory के भीतर स्वयं चुनता है कि क्या करना है। सामान्यतः हम इस विकल्प से अब संतुष्ट हैं, इस आधार पर कि skills में भी यह लिखा है कि वास्तव में क्या cover करना है, किस मात्रा में इत्यादि।

Q11: मेरा अंतिम प्रश्न है। यदि कार्य बहुत जटिल हो और कई products, services इत्यादि को प्रभावित करता हो, अर्थात उसे बहुत गहराई से groom करना हो, और वह स्वयं में बड़े backlog का स्रोत हो। इस स्थिति में एजेंट शायद इतनी बड़ी कहानी का सामना न कर पाए, जहाँ सब कुछ एक साथ करना हो। आपको या तो किसी solution architect को जोड़ना होगा, या उस व्यक्ति को जो आपके यहाँ इस भूमिका के लिए उत्तरदायी है?

• हमारे यहाँ इस भूमिका के लिए हमेशा developers ही उत्तरदायी होते हैं, हमारे पास solution architects नहीं थे। कंपनी में हमारे पास enterprise architects हैं, लेकिन उनका focus बिल्कुल दूसरे क्षेत्र में है। यदि इस तरह के requests को हमारे यहाँ कैसे हल किया जाता है उसकी बात करें, तो मैंने जो प्रणाली दिखाई थी, उसके भीतर decompose करने की क्षमता है। वहाँ happy pass दिखाया गया था, अर्थात सरल कार्य जो दर्ज होता है, किया जाता है और बस। लेकिन जटिल कार्यों के लिए हमारे delivery workflow के भीतर decompose करने की क्षमता है। अर्थात यह सब वहाँ किया जा सकता है, क्योंकि एजेंट के पास सभी product monorepos तक पहुँच है। अर्थात यदि कार्य उत्पादों के संगम पर उत्पन्न होता है, तो वह सभी उत्पादों का अध्ययन कर सकता है।

Q12: लेकिन इस स्थिति में उसे अपनी delivery के भीतर backlog तैयार करना चाहिए और समाधान मालिकों को वितरित करना चाहिए। और इस कहानी को कौन नियंत्रित करे? अर्थात यह आपके यहाँ execution है?

• एजेंट स्वयं ये सभी बदलाव करता है। एजेंट सभी product monorepositories में MRs करता है। फिर से, वह अपने पास पूरा context नियंत्रित करता है। आखिरकार, हमारे यहाँ approaches हैं। अब कोई भी harness जिसका आप उपयोग करते हैं, Claude Code, Codex इत्यादि, सभी अच्छे harnesses पूरे कोड का सारा context नियंत्रित करते हैं, यह समझने के लिए कि क्या करना है। साथ ही context गतिशील रूप से बदलता है: कुछ लोड होता है, कुछ अनलोड होता है। Context window, मूलतः, हर स्थिति में स्थिरता का मुख्य तत्व है।

Q13: क्या आप किसी उपकरण का उपयोग करते हैं, उदाहरण के लिए subagents, जो संकीर्ण कार्य करते हैं?

• हम अभी इस समय सुनिश्चित नहीं हैं। हमारे पास subagents tool है, वह कितना सक्रिय रूप से उपयोग होता है, इसे trajectories से, traces का अध्ययन करके देखना होगा। शुरुआत में यह हमारे लिए काफ़ी खराब काम करता था। उद्योग में, सच कहूँ तो, subagents पर मूलतः ध्रुवीय दृष्टिकोण है। हमने पहले एक ध्रुवीयता अपनाई: कोई subagents नहीं। फिर धीरे-धीरे इसे ढीला किया और कहा कि एजेंट अपने विवेक से, उदाहरण के लिए, read-only activities को subagent पर लोड कर सकता है। सिद्धांततः वह इसका उपयोग कर सकता है। यह मदद करता है या नहीं करता, ऐसे प्रयोग हमने नहीं किए जो दिखाते कि पहले कैसा था और अब कैसा है।

Q14: क्या कई घंटों के काम जैसे लंबे कार्यों के साथ काम करने की ऐसी कोई practice है?

• लंबे tasks के बारे में: हमारे यहाँ ऐसे लंबे tasks नहीं होते जो कुछ घंटों से अधिक में पूरे हों। अर्थात हमेशा चार घंटों से कम।

Q15: क्या tests के बारे में, अधिक सही कहें तो testing technologies के बारे में पूछ सकता हूँ? Functional tests फिर भी किसी framework पर बनाए गए हैं, जिसमें वास्तव में autotests लिखे जाते हैं और monorepo में रखे जाते हैं? या एजेंट स्वयं, पता नहीं, कोई Playwright लेता है और स्वयं चलाता है?

• फिर भी, अक्सर किसी मौजूदा product का परिष्करण होता है, उसमें पहले से कुछ स्थापित testing practices होती हैं। हम उसे नए-नए पहिए बनाने नहीं देते, कि वह सारे संभावित frameworks को छुए और ले आए। हमारे यहाँ ऐसा नहीं है। सैद्धांतिक रूप से ऐसा हो सकता है। उदाहरण के लिए, यदि हम किसी postmortem analysis के दौरान समझते हैं कि किसी अतिरिक्त प्रकार के testing की आवश्यकता होती जो अभी उपलब्ध frameworks के भीतर लागू नहीं किया जा सकता, तो हम कार्य बना सकते हैं। coverage का कार्य बनाते हैं, और आगे एजेंट, सिद्धांततः, इसे भी स्वायत्त रूप से संभाल सकता है।

Q16: एजेंट, जैसे कि यदि driver के अलावा: “चलो, smartphone पर button बना दो, बस एक बार element नहीं मिला,” सही?

• हाँ, हमारे यहाँ UI tests काफ़ी कम हैं, अर्थात वे अल्पसंख्यक हैं, केवल इसलिए कि प्रक्रिया स्वयं UI-heavy नहीं है। वहाँ एक interface है। मान लें, इससे थोड़ा आसान है कि यदि यह retail ग्राहक के लिए मोबाइल बैंक का front-heavy interface होता। यहाँ हमें इस भाग में काफी अधिक निवेश करना पड़ता।

Q17: प्रश्न यह है कि ऐसे इंजीनियर का सामान्य कार्य-दिन कैसा होता है? साधारण दृष्टिकोण से। यह स्पष्ट है कि वह एजेंटों की यह परत बनाता है और उसके निर्माण में उसका मूल्य है। क्या वह केवल यही करता है या कुछ और भी?

• यहाँ सामान्यतः यह कहना चाहिए कि product engineer एक भूमिका के रूप में हमारे लिए moving target निकला। अर्थात, उदाहरण के लिए, पिछले वर्ष के अंत में जब हमने इसे लागू किया, तो मूलतः हम अपने आप से यह प्रश्न पूछ रहे थे: क्या विजयी GenAI की दुनिया में मौजूदा भूमिका मॉडल — बैकएंडर, फ्रंटएंडर, टेस्टर्स — प्रासंगिक है? हमने निर्णय लिया कि प्रासंगिक नहीं है, कि ऐसे generalist engineers चाहिए जो पूरे stack को समझते हों। और बड़ी बात में, generalist engineers product engineers में बदल गए। हमने सोचा था कि वे मुख्यतः हाथ से या coding agents के साथ functionality लिखेंगे। परिणामस्वरूप, अब हमारे इंजीनियर बहुत कम कोड लिखते हैं। जब हमारे पास एजेंट कन्वेयर आया, तो उन्होंने, बड़ी बात में, कन्वेयर का कोड लिखने के अलावा कोड लिखना बंद कर दिया। इसलिए, शायद उनका 70% समय टीम कार्य, टीम interaction के काफ़ी क्लासिक तत्वों में जाता है। हम क्या कर रहे हैं, किसके लिए, क्यों, कैसे, किस कारण इत्यादि। आगे, निश्चित रूप से, लक्ष्य निर्धारण और review महत्वपूर्ण फोकस लेते हैं। अब शायद अधिक review, क्योंकि कोड की मात्रा काफ़ी बड़ी है। हम हर कीमत पर बदलावों को 24 घंटे से कम में आगे बढ़ाने का प्रयास करते हैं। इसलिए यह महत्वपूर्ण है कि वे जो प्राप्त करते हैं उसकी गुणवत्ता पर अधिक ध्यान दें। तदनुसार, जब वे ऐसा करते हैं, तो टिप्पणियाँ छोड़ते हैं। वे तुरंत feedback से projects और skills को सुधारने जा सकते हैं। वे तुरंत Harness टीम से बात करने जा सकते हैं, सोच सकते हैं कि कन्वेयर एजेंटों को कौन-सी क्षमताएँ दी जा सकती हैं। अर्थात यह बदलता रहता है। Q18: यदि सब ऐसे काम करता है, तो उन्हें देखना चाहिए कि किए गए बदलाव पिछले projects को न तोड़ दें?
• क्या आपका मतलब है कि नई corrections, नई skills विरोधाभासी न हों? हाँ। हमने समझा कि हमारे यहाँ ऐसा होता है, कि यह drift है। हमने ऐसी प्रणाली तैयार की जो इन drifts का विश्लेषण करती है, उन्हें पहचानती है। और वास्तव में, यह भी एजेंट self-improvement cycle के भीतर होता है। अर्थात वह वास्तव में skills में विरोधाभास ढूँढता है। Q19: Regressions होते हैं, और आप नए कार्य में वे समस्याएँ पा सकते हैं जिन्हें वह पहले संभाल रहा था। और अब वह degrade होने लगा?
• वहाँ इससे भी बुरा है: skill code में परस्पर-विरोधी paragraphs सामने आ सकते हैं, क्योंकि, उदाहरण के लिए, अलग-अलग लोगों ने अलग-अलग समय पर वह skill लिखी। अलग-अलग एजेंटों ने इसे अलग-अलग कोणों से देखा। हम ऐसी चीज़ें अब पहचानते हैं, ठीक करते हैं, ताकि वे समग्र हों। किसी विशेषज्ञता की skill digitize और गैर-विरोधाभासी हो।

Q20: ठीक है, आपने टीम ली, रूपांतरित की। भूमिकाएँ हटा दीं, सबको product engineers बना दिया। और आगे मान लें कि कोई जटिल feature है। वह, जैसा मैं समझा, आपके यहाँ domain areas के अनुसार decompose होता है। और काफी सूक्ष्म रूप से crystallize होता है। क्योंकि यदि मैं किसी बड़ी feature को टीम को दूँ, तो मेरे channel में इन product engineers की धारा होगी। वे स्वयं आपस में किसी तरह सहमति बनाएँगे, interaction करेंगे। ठीक वैसी ही चीज़ बनेगी जो पहले भूमिकाओं के बीच थी। अर्थात इन बहुत-से product engineers के बीच भी interaction शुरू होगा और उसमें कुछ समय लगने लगेगा। क्योंकि वे अपने किसी domain area के context में हैं और संभवतः अपने background के साथ। अर्थात आप इतनी सूक्ष्मता से कार्यों को तोड़ते हैं, फिर उन्हें इन पाँच इंजीनियरों में से प्रत्येक को एक-एक बाँटते हैं। वे फिर किसी तरह संवाद करते हैं, और अंत में अपने MRs की जाँच करते हैं? क्या यह इसी तरह काम करता है?

• हमारे यहाँ ऐसा काम नहीं करता। लेकिन शायद हमारे यहाँ ऐसे बड़े बदलाव, जो एक साथ तीन से अधिक product monorepos, कुछ संबंधित प्रणालियों को प्रभावित करते हों, हम शायद अभी तक वहाँ नहीं पहुँचे। फिर भी, शायद प्रोडक्ट्स ऐसे बदलाव लेकर delivery में हमारे पास आते भी नहीं। वे स्वयं इन बदलावों को किसी तरह decompose करने का प्रयास करते हैं।

Q21: काम को इस तरह decompose किया जाता है कि वह बिल्कुल एक इंजीनियर पर आ जाए। न्यूनतम तक crystallize होता है?

• Crystallize नहीं होता। अर्थात हमारे पास एक एजेंट है जो planning के लिए उत्तरदायी है। आप उसके पास मंशा लेकर आ सकते हैं। यदि लगता है कि यह मंशा बहुत जटिल है, तो इसे घटक भागों में बाँटा जा सकता है। चाहे वह जटिल हो या नहीं, हम प्रवेश पर इसका आकलन नहीं कर सकते। हम इसे repositories की संख्या और संरचना से समझते हैं, अर्थात, उदाहरण के लिए, किसी निश्चित स्तर के कितने कार्य होने चाहिए। अधिकांश काम अक्सर design के अनुसार एक product monorepository के ढाँचे, सीमाओं में आ जाता है। यदि कुछ संगम पर आता है, अर्थात कई products में बड़ा काम हो, तो उसे, उदाहरण के लिए, दो-तीन कार्यों में तोड़ा जाएगा। उनके लिए वही इंजीनियर उत्तरदायी होगा जो वास्तव में एजेंट के साथ मिलकर उस बदलाव की योजना बनाता है। अर्थात ऐसा नहीं है कि हम इसे तीन एजेंटों में वितरित करेंगे। अर्थात बड़े कार्य के लिए एक इंजीनियर उत्तरदायी है। एक बदलाव, एक व्यक्ति। बदलावों के लिए व्यक्ति को end-to-end उत्तरदायी होना चाहिए, चाहे वे कितने भी बड़े हों। लेकिन हम बस इस बड़ेपन को कम करने का प्रयास करते हैं। Q22: इसका मतलब सुपर planning होना चाहिए, अर्थात कार्य हमेशा ऐसा हो कि एक व्यक्ति उसके लिए end-to-end उत्तरदायी हो सके। कोई छोटा-सा, कहें तो, interaction, execution। क्या वास्तव में बस आदर्श planning करनी होगी?
• खैर, सच कहूँ तो, मैंने नहीं सुना कि हमारी टीमें इससे पीड़ित रही हों। शायद हमने इसे और भी पहले के किसी चरण में जीत लिया था। लेकिन हमारा अधिक ऐसा... संक्षेप में, हमारे यहाँ waterfall नहीं है, हमारी बहुत agile culture है। और हमारे यहाँ हम सिद्धांततः प्रयास करते हैं, खैर, इसे क्या कहते हैं... ऐसे कार्य जिनके बारे में बिल्कुल नहीं पता कि कैसे करना है, है न? मैं ऐसी-वैसी कोई चीज़ चाहता हूँ, नहीं जानता कि वह कैसे काम करेगी, लेकिन मैं इसे आपके backlog में डाल दूँगा और आप आगे जैसे चाहें समझें। यह एक story point है या एक लाख story points? लेकिन हमारे यहाँ ऐसे कार्य बस backlog में पहुँचते ही नहीं। हमारे product managers और टीम काफी उचित तरीके से दृष्टिकोण रखते हैं और discovery चरण में, delivery से पहले अनिश्चितता दूर करते हैं। यह सब discovery के बारे में है। Q23: संक्षेप में: ग्राहक से कोई कार्य आया, और वह पाँच ग्राहकों से जुड़ा हुआ है। ग्राहक के पास जाना है, दूसरे के यहाँ क्या हो रहा है जानना है, designers, analysts, products के पास जाना है, यह सब इकट्ठा कर उस feature को जीतना है। और वास्तव में यह एक व्यक्ति करता है?
• खैर हाँ, हमारे यहाँ वास्तव में एक व्यक्ति ऐसा कर सकता है, लेकिन सिद्धांततः पहले भी यही होता था। एक व्यक्ति यह सब समझ सकता है।

Q24: Designers के बारे में। मुझे इस श्रृंखला में designers भी नहीं दिखे। यदि कोई इच्छा है, खैर, नया design बनाना है, नए components से फिर से करना है इत्यादि, तो यह पूरी कहानी कैसे होती है?

• हम इसे अधिकांशतः discovery का भाग मानते हैं। हमारे पास design system है, जो किसी kit के रूप में लागू है, जो एजेंट को उपलब्ध है। अर्थात एजेंट पहले ही सिद्धांततः UI Kit से interface बना सकता है।

Q25: खैर, क्या यह designer का review होना चाहिए?

• खैर, इससे यह होता है कि discovery चरण में design mockup आ सकता है। फिर से, हमारे यहाँ UI काफ़ी कम है। विशेषकर ऐसा UI जिसे बहुत बारीकी से जाँच की आवश्यकता हो, क्योंकि हमारे यहाँ सीधे ग्राहक के लिए बहुत कम screens हैं। हमारे यहाँ अधिकतर screens कर्मचारियों के लिए interface हैं। दिल पर हाथ रखकर कहूँ तो, हम कर्मचारियों के लिए interfaces की proofreading पर designer का संसाधन खर्च करने के लिए तैयार नहीं हैं।

Q26: जहाँ तक मुझे याद है, अब ग्राहकों के लिए demo बदल गया है। और क्या आपने हर बनाए गए feature के लिए भुगतान को फिर से गिनना शुरू किया?

• हमारे यहाँ शायद हम इस मामले में outsource नहीं हैं, है न? अर्थात हम in-house development का समय और विशेषज्ञता बेचते नहीं हैं। आंतरिक ग्राहकों के लिए demo के दृष्टिकोण से, खैर, बड़ी बात में वह पहले की तरह ही दिखता है। अर्थात हम अब भी कुछ features दिखाते हैं। इसमें Harness टीम का एक section जुड़ गया है, जो, जैसे, उत्पादन प्रक्रिया की सफलताएँ दिखाता है।

Q27: क्या व्यवसाय और कर्मचारियों को ये बदलाव पसंद हैं?

• हमारे यहाँ व्यवसाय सचमुच हर महीने कार्य फेंकता है, investments दर्ज करता है, credit programs, नई pensions। इसलिए यहाँ बहुत कम काम पड़ता है, सब निकट है। पहला, इस दृष्टिकोण से। दूसरा, हमारे अपने operational line employees हैं। वे प्रोत्साहित, प्रेरित हैं। लोगों को अधिक सक्रिय रूप से स्वीकार करते हैं। हमारे यहाँ सबके साझा लक्ष्य हैं। शायद हमारे लिए यह समस्या थोड़ी कम स्पष्ट है। हम सब कुछ पूर्णतः करने की कोशिश करते हैं।

Q28: जो व्यक्ति बाद में उसे निष्पादित करता है, उसे कार्य किस रूप में मिलता है? कौन और क्या चाहता है इसके कुछ विकसित वर्णन, या सचमुच दो पंक्तियाँ जैसे "एक सुंदर button बना दो"?

• पहले हमारे यहाँ बड़ी variability का प्रश्न था, जब लोग हाथ से कार्यों को इकट्ठा करते, उन्हें Jira में दर्ज करते, तो सब कुछ व्यक्ति की गति पर निर्भर होता था। कहीं बिल्कुल one-liners होते थे, कार्य के बारे में दो पंक्तियाँ इत्यादि। इसलिए हमने यह प्रणाली विकसित की ताकि वह हमारी variability को न्यूनतम करे। इसलिए हम प्रोडक्ट से पूरी तरह ठोस मंशाएँ प्राप्त करते हैं: क्या और क्यों, कौन-सी metric, कौन-सा mechanics अपेक्षित है। प्रोडक्ट स्वयं एजेंट के साथ यह सब स्पष्ट और विकसित करता है। और तदनुसार, आगे इंजीनियर इसे इसी रूप में सँभालता है। और बस एजेंट के साथ मिलकर यह brainstorm करता है कि इसे बेहतर ढंग से कैसे लागू किया जाए

Q29: आप कौन-से मॉडल उपयोग करते हैं? अभी सब चीनी मॉडलों पर जा रहे हैं?

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

Q30: मेरे यहाँ ऐसा हुआ कि विकास के लिए मैं DeepSeek 4.1 उपयोग करता हूँ, और GLM 5.3 उसका verification करता है। और ऐसा होता है कि हाल में वे सच में एक-दूसरे को समझना बंद कर चुके हैं। खैर, यह आसान नहीं है।

• उन सभी में, जैसे, यह, ject, intelligence होता है, अर्थात ताकत और कमज़ोरियाँ। GLM वह ढूँढ सकता है जो Kimi ने नहीं पाया, और वह छोड़ सकता है जो GPT आसानी से पाएगा। अर्थात वे सभी एक-दूसरे के पूरक होने चाहिए।

Q31: दूसरा प्रश्न, Harness किस टीम ने बनाया, और उससे निकलने वाला प्रश्न यह कि वह यह कैसे कर पाई? अर्थात मैं भी यही सोच रहा था कि आपने प्रयोगशालाओं से शुरुआत की, तुरंत नहीं बल्कि बारी-बारी से, और आगे यह प्रक्रिया कैसे सुसज्जित हुई?

• लेकिन विकास टीम स्वयं, जैसे, 4 लोगों की थी, साथ में मैं; अलग-अलग इंजीनियर थे, दो क्लासिक generalist engineers, दो NLP engineers। काम लगभग आधे साल तक, शायद, फुरसत के आधार पर चला, अर्थात आधे साल में हमने harness के चार prototypes बनाए जो काम नहीं कर रहे थे, फिर एक महीने में एक ऐसा बनाया जो काम करता था, और अगस्त में सभी को उस पर स्थानांतरित करना शुरू किया। और मेरे पास एक काफ़ी सरल heuristic था, मैंने बस समझ लिया कि यह काम करता है। जब मैं समझ गया कि यह काम करता है, उदाहरण के लिए, फिर से, मेरे और टीम के आधार पर, हमने वहाँ बहुत-सी ऐसी चीज़ें चलाईं जो आम तौर पर अलग-अलग टीमों में जिनसे हम टकराते हैं उनका अनुकरण करती थीं। जब मुझे समझ आया कि यह ठीक काम करेगा, लेकिन अनिवार्य रूप से हम कुछ त्रुटियों से टकराएँगे, और इन त्रुटियों के बिना हम एजेंट प्रणाली को बेहतर नहीं करेंगे, तो हमने, इसके बावजूद कि मैंने कहा था कि सीमित रूप से कार्य करना चाहिए, all-in किया। अर्थात सभी टीमों को, कहें तो, यह प्रोत्साहन मिला कि पूरा विकास एजेंट कन्वेयर से होकर हो, हाथ से कोड न लिखा जाए। हमारे यहाँ कुछ अपवाद थे। अर्थात हमने पहले एक ऐसे प्रोजेक्ट को अपवाद बनाया जो delivery के critical path पर है, एक सामान्य, जैसे, worldwide migration, जिसकी कड़ी deadline होनी थी। अर्थात हम वहाँ कुछ दिखाना, कुछ गलतियाँ पाना नहीं चाहते थे। यह सचमुच छह में से एक टीम थी। और एक system था, जिसे दो लोग support करते थे और करते हैं, वहाँ commissions, पुरानी चीज़ें, Windows इत्यादि। हम वहाँ sandbox के साथ उलझना नहीं चाहते थे, कहें तो। उसे एक ओर कर दिया, कहा, साथियो, बाद में समझेंगे। बस इतना ही, बाकी सभी इस कहानी में चले गए।

Q32: क्या आपके पास context और memory व्यवस्थित करने के लिए कोई frameworks हैं?

• मैं समझ गया। यार, हम भी इस विषय पर, मैंने अभी पहिए बनाने के बारे में ही कहा था। हमने पहले खुद पहिए बनाने शुरू किए, हमने सोचा, हमें अपने products का context किसी तरह ऐसे रूप में व्यवस्थित करना चाहिए जिसमें एजेंट उसे बेहतर समझ सके। हमने Deep Wiki का अपना implementation design करना शुरू किया। बहुत अच्छा नहीं निकला। और उस समय जब हमें समझ आया कि बहुत अच्छा नहीं निकल रहा, Lang Chain ने OpenWiki जारी कर दिया, और हम हर जगह OpenWiki पर चले गए। अर्थात हमारे पास बस pipelines हैं, वे रात में product monorepos की Wiki का विश्लेषण करती हैं। यह एजेंट को उपलब्ध है। और जहाँ तक किसी memory की बात है, हम अभी उस स्थिति तक नहीं पहुँचे हैं कि कोई ऐसी ठीक... अर्थात अभी यह स्पष्ट नहीं है कि इस memory की आवश्यकता क्यों है? अर्थात उसे कौन-से ठोस निर्णय याद रखने चाहिए?

Q33: अर्थात, उदाहरण के लिए, हमने भूमिकाओं के लिए clarification courses बनाना शुरू किया। और यह अधिक यथार्थवादी हो गया। (अस्पष्ट)?

• नहीं, मैं इस paradigm में बिल्कुल विश्वास नहीं करता। मैंने परिणाम देखे हैं। खैर, मैंने देखा है कि लोग वास्तविक जीवन में इसे आज़माने, उपयोग करने, लागू करने की कोशिश कैसे करते थे। और यह काम नहीं करता था। और इसी के आधार पर हम इस निष्कर्ष पर पहुँचे कि यह काम नहीं करता। और साथ ही role-based conveyors के साथ हमारी विफलताओं ने मुझे इस ओर धकेला कि ऐसा काम बहुत खराब करेगा।

Q34: क्या आप अपना अनुभव साझा कर सकते हैं। आप टीम में आए और कहा... अब तुम backend नहीं, frontend नहीं हो। तुम अब बस engineer हो। प्रतिरोध के साथ कैसे काम किया? टीमों ने कैसे प्रतिक्रिया दी? और सामान्यतः आपने यह environment कैसे पुनर्निर्मित किया?

• खैर, हमें इसमें बहुत समय लगा। किसी Harness engineering से भी अधिक। अर्थात हम इसकी ओर बढ़ रहे थे। लेकिन शायद मैं पिछले summer से ही तैयारी कर रहा था। और इसकी शुरुआत इस प्रकार की presentations से हुई कि उद्योग कहाँ जा रहा है, उसमें क्या हो रहा है, ऐसा क्यों है, उस काम के लिए जो आप करते हैं संभवतः दो साल बाद पैसे क्यों नहीं मिलेंगे।

Q35: यह स्पष्ट है। लेकिन जब बदलावों का समय सीधे आया तो?

• हम वहाँ बाकी सभी कंपनियों से बहुत पहले चले गए। पिछले साल पतझड़ में हमने कहा कि साथियो, उदाहरण के लिए, testers, fronts, जो कुछ हमारे पास था, ops, आपको product platforms बनाना होगा। हम आपको आवश्यक training देने के लिए तैयार हैं। चलिए, अब सभी साथ बैठते हैं, जो कुछ team agreements, engineering practices इत्यादि के वर्णन के संदर्भ में कम है, उसे बैठकर standardize करते हैं। और हम यह काम, standardization कर रहे थे। इसके माध्यम से, मूलतः, कुछ engineers, उदाहरण के लिए, backenders, testing की कुछ बारीकियाँ सीख रहे थे जिन्हें वे पहले नहीं जानते थे, जिनसे नहीं निपटते थे। अब इसमें कुछ समय लगा। बड़ी बात में, अंततः हमने यह सारा काम फेंक दिया। हमने जो handbooks लिखे थे, वे नई वास्तविकताओं में आंशिक रूप से skills में चले गए, आंशिक रूप से अब कोई उनका उपयोग नहीं करता। लेकिन यह क्रमिक adoption, लोगों को शांत करने के दृष्टिकोण से उपयोगी था।

Q36: और क्या कुछ experts बचे हैं जो, मान लें, architecture देखते हैं या फिर भी?

• हमारे यहाँ बहुत अप्रिय cases थे, हम सोचते थे कि हमारे पास expert है, पद को सचमुच expert कहा जाता था, और वे वहाँ कुछ trendbooks लिखने इत्यादि के लिए भी उत्तरदायी थे। जब वे ये trendbooks लिख रहे थे और अपनी expertise प्रस्तुत कर रहे थे, तो पता चला कि इस expertise की गहराई उतनी अप्राप्य नहीं थी जितना हम पहले सोचते थे। वह सचमुच महसूस की जा सकती है और सामान्य क्लासिक engineering roles में आसानी से स्थानांतरित होती है। हमारे पास मजबूत expert-generalists हैं, मेरे पास ऐसे कई generalists हैं जो बिल्कुल कोई भी काम कर सकते हैं, उनके पास computer science के किसी भी क्षेत्र में शक्तिशाली reasoning है। लेकिन बाकी दूसरे experts हमारे यहाँ नहीं बचे हैं, और इन experts का उपयोग भी मैं किसी के solutions verify करने के लिए नहीं करता, बल्कि Harness निर्माण या उसके किसी हिस्से के optimization में कोई अत्यंत असामान्य कार्य हल करने के लिए करता हूँ, जो हम पहले नहीं करते थे, संक्षेप में RnD।

Q37: अंतिम प्रश्न। पहले टीमें बड़ी थीं, आपने यह काम शुरू किया, आपके यहाँ कितने प्रतिशत कटौती या optimization हुआ? या ऐसा नहीं हुआ, आपने सभी के लिए नई जगह ढूँढ ली?

• वास्तव में, हमने किसी तरह costs optimize करने या कटौती करने की कोशिश नहीं की, हमारा लक्ष्य TTM था और है। ऐसे उदाहरण थे कि लोगों ने, उदाहरण के लिए, स्वयं चुना कि यह उनके लिए नहीं है। मैं कंपनी N में और tester के रूप में काम करूँगा। या, यार, मैं नहीं समझता कि मैं tester से engineer कैसे बनूँगा यदि मैं अब कोड नहीं लिखता। ऐसे लोगों ने स्वयं निर्णय लिया कि उनका कंपनी के साथ रास्ता एक नहीं है। हम किसी को force नहीं करते। हमारे यहाँ, मूलतः, शायद attrition rate 5% से 8% के स्तर पर है। ऐसे radical बदलावों को देखते हुए यह बिल्कुल सामान्य है।

Q38: आपने प्रस्तुति में कहा कि आपके यहाँ system analysis काफी समय से नहीं था। लेकिन उन कंपनियों को क्या करना चाहिए जहाँ system analysis काफी समय से था। और बहुत-सी जगहें हैं जहाँ कुछ लिखा हुआ है। BTS, FOD। वहाँ, पता नहीं, कुछ user documentation। और यह सारी documentation आपस में विरोधाभासी है। कोई एकल entry point नहीं है। वह काफी व्यापक है। कोड भी बहुत अधिक है, यह सब अलग-अलग repositories में पड़ा है। तदनुसार, मुझे एजेंट कन्वेयर बनाने के लिए... मेरी अब ऐसी समस्या है कि मेरे सभी एजेंट अविश्वसनीय context में जाते हैं। वे मुझे कुछ कहते हैं, असत्यों के आधार पर निर्णय लेते हैं। इससे कैसे लड़ें?

• प्रोडक्ट का काम पूर्ण documentation से अधिक महत्वपूर्ण है। साधारण telemetry। संभवतः अधिकांश मामलों में हमारी दुनिया में ऐसा ही होगा। लेकिन जहाँ हमारे पास थे... हमने उपयोगी context बचाया, उदाहरण के लिए, business description के स्तर पर। उदाहरण के लिए, कुछ regulation, standards, complex products के descriptions, वे अपरिवर्तित रहते हैं। यह बचा और बस सशर्त product monorepo में स्थानांतरित हो गया। हाँ, बाकी सब, ये कुछ tables, schemes, designs। लेकिन यह हमेशा समस्या थी। एजेंटों इत्यादि से पहले भी यह पुराना हो जाता था। और इसका कोई सामान्य समाधान कि कैसे... खैर, समाधान, प्रयास थे, जैसे: चलिए कोई architecture test बनाएँ, वहाँ... संक्षेप में, testing और verification की कोई परत जोड़ें। यह कठिन था, बहुत महँगा। हमने यह नहीं किया। हम ऐसी चीज़ें बस फेंक देते थे और मानते थे कि यही कार्यों को हल करने का तरीका है।

Q39: एजेंटों के साथ आपके कौन-से गंभीर incidents हुए?

• सामान्यतः, एजेंटों से पहले भी हमेशा थे... नहीं, यदि incident rate metric देखें, मैंने दिखाया था: जैसे defect rate उसी स्तर पर बना हुआ है जो पहले था। विशेष रूप से corporate business, corporate lending की विशिष्टता के कारण किसी बड़े पैमाने के incidents। खैर, ऐसे incidents काफी असंभावित हैं। जहाँ, संक्षेप में, हमारे यहाँ संभावित blast radius काफी महत्वपूर्ण है, वहाँ हम double-check, triple-check करते हैं। अर्थात हम कोशिश करते हैं। वहाँ वास्तव में कुछ financial postings, tranches इत्यादि में बहुत बुरी गलती हो सकती है। यहाँ हमारे यहाँ ये systems एजेंटों से पहले ही हर तरह की conditions, tests, checks से घिरे हुए थे। और वे इतने अच्छे डिज़ाइन किए गए थे, मेरी राय में, हमने उनके redesign पर बहुत मेहनत की थी, कि अब वहाँ कोई incident नहीं होता। खैर, शायद अभी समय नहीं हुआ। शायद हम यहाँ तीन महीने रहे हैं, शायद कल ही कुछ हो जाए।

Q40: time-to-market metric पर प्रश्न। अलग-अलग domains के development के parallel models। आप कहते हैं कि आपने time-to-market सुधारा, लेकिन parallelism तो बना रहा, विशेषकर merge requests के conflicts और ऐसी सारी परेशानियाँ। यदि मैं सही समझता हूँ, मान लें, अच्छी तरह डिज़ाइन किया गया domain model, हाँ, लेकिन फिर भी product या आपका backlog उसी domain को change कर सकता है, है न, और conflicts हल करने होते हैं। क्या वे आपके यहाँ agent layer के स्तर पर हल होते हैं, products, features की planning के स्तर पर, या कैसे?

• खैर, निश्चित रूप से planning के स्तर पर हल नहीं होते, कम-से-कम मुझे ऐसा कोई समाधान तरीका ज्ञात नहीं है, शायद वह कहीं मौजूद हो, मुझे बस उसके बारे में नहीं पता। यह सब पहले से ही स्तर पर हल होता है.... अभी याद करूँ कि हमने कैसे किया। अर्थात एजेंट स्वयं rebase करता है। अर्थात, बड़ी बात में, हमारे यहाँ trunk-based है, हमारे यहाँ linear history है, हमारे यहाँ ये सभी conflicts किसी तरह अलग ढंग से MR में हल होने चाहिए। लोग अब ये conflicts हल नहीं करते, बड़ी बात में एजेंट conflicts हल करते हैं, और अधिकांश मामलों में इसे संभाल लेते हैं।

Q41: और यदि यह केवल समानांतर में हो रहा हो, जैसे एक पहले ही review हो चुका है, प्रोडक्शन के लिए तैयार है, दूसरा ठीक उसी domain पर भी प्रोडक्शन के लिए तैयार है?

• खैर, एजेंट वास्तव में... वहाँ पूरी तरह एजेंट नहीं, प्रणाली जटिल है। approaches, strategies स्वयं को लागू करती हैं।

Q42: और blockers के साथ क्या करते हैं? उदाहरण के लिए domain lock के साथ। जैसे हम domains को edit नहीं करते जब तक किसी दूसरे domain का संपादन चल रहा हो और human approval न हो जाए।

• सच कहूँ तो, मैंने नहीं सुना कि हमारे यहाँ ऐसे conflicts होते रहे हों...

Q43 Monorepo में? Monorepo में तो वे हमेशा उत्पन्न होंगे? खैर, जब आप एक domain edit करते हैं, एक product feature A चाहता है, दूसरा product feature B चाहता है?

• आह, नहीं, हमारे यहाँ एक domain के कई products नहीं हैं। अर्थात प्रबंधन स्तर पर solutions की एक समझदार queue संरचित है। ऐसा कह सकते हैं, सही। और एक और महत्वपूर्ण बिंदु, वैसे: मैंने जो प्रक्रिया दिखाई थी, उसमें एजेंटों में से एक अन्य बातों के साथ यह भी अध्ययन करता है कि आप जो feature चाहते हैं, क्या वह पहले से मौजूद चीज़ों से विरोधाभासी तो नहीं है। अर्थात, सशर्त रूप से, क्या आप वहाँ काम की सीमाओं को तोड़ना, प्रणाली में कुछ परस्पर-विरोधी paragraphs जोड़ना तो नहीं चाहते जो नहीं होने चाहिए। वह design से ही अलग तरह काम करता है। आप उस behavior को तोड़ने की कोशिश कर रहे हैं जिसे लोगों ने पहले commit किया था। यह पहला। दूसरा। यही चीज़ मूलतः मौजूदा tasks को भी scan करती है ताकि सुनिश्चित हो कि पहले से कोई विरोधाभास नहीं है। क्योंकि हम इन विरोधाभासों को अभी सीधे हल करने की कोशिश करते हैं। मैं इस भाग को भूल गया था, क्योंकि यह बहुत पहले बनाया गया था। क्योंकि उसके बाद इस भाग में बहुत कुछ, कई आयाम किए गए हैं। अर्थात विरोधाभासों का resolve भी यहीं, प्रणाली के इस भाग में हो सकता है। इस तरह, एजेंट कन्वेयर में आपके पास वास्तव में मूलतः तैयार कार्यों की queue आती है, जिस पर pre-base trivial और सुरक्षित होता है।

Q44: मैं समझ गया, क्योंकि pre-base वही चीज़ है जहाँ एजेंट समय-समय पर अच्छी तरह गलती करता है। और दूसरा बिंदु: models, infrastructure, temperature, reasoning इत्यादि को ट्यून किया?

• पिछले साल हमने temperatures, reasoning के साथ सक्रिय रूप से खेला। मौजूदा दृष्टिकोण में हम ऐसा न करने की कोशिश करते हैं। हम default settings का उपयोग करने की कोशिश करते हैं। क्योंकि तुलना कैसे करें, यह स्पष्ट नहीं है। benchmarks, evals, judges में काफ़ी शक्तिशाली निवेश चाहिए। इंजीनियरों का अधिक ध्यान इस regeneration को देखने में लगाना चाहिए जो models करने लगते हैं। फिर से, यह सब अक्सर खराब तरह से quantifiable comparisons हैं। यह स्वाद की बात है। और हम इसके साथ नहीं खेलते। हम यह करने की कोशिश करते हैं कि किसी instructions के स्तर पर ऐसा परिणाम आए जो मनुष्य के लिए स्वीकार्य हो।

Q45: और फिर models स्वतंत्र हैं। यदि, उदाहरण के लिए, तीसरे models में इससे मूलतः इस बात से स्वतंत्र हो पाता है कि कौन कौन है। यदि आपको कोई अगला selection करना हो।

• यहाँ हम model-agnostic हैं। अभी हम नीचे जाकर simple models पर downscaling न करने की कोशिश करते हैं। हमारे पास अभी इसके लिए पैसे हैं कि यह न करें। और यह करने के लिए benches में भी शक्तिशाली निवेश करना होगा। लेकिन benchmark के लिए हमारे पास किसी न किसी तरह पहले से बहुत अधिक material हो गया है। पहले अलग-अलग engineering practices वाली अलग-अलग projects के historical tail से tasks इकट्ठा करने पड़ते थे। अब हमारे यहाँ plus-minus co-agent system का functioning है। उदाहरण के लिए, projects की practices अधिक समतल हो गई हैं। tasks के आकार plus-minus समतल हो गए हैं। tasks का description plus-minus स्पष्ट है। हर जगह एक जैसा। इसलिए अब benchmark के लिए material अधिक समृद्ध है। खैर, संभवतः कुछ समय बाद इस पर काम शुरू करेंगे।

Q46: तो क्या यहाँ SDD बिल्कुल उपयोग नहीं होता? या mirror की तरह?

• लेकिन OpenWiki, बल्कि mirror नहीं है, मैं इसे एजेंट के लिए navigation का सरलीकरण कहता हूँ। उसे आवश्यक चीज़ समझने, ढूँढने के लिए लगने वाले hops की संख्या कम करना। अर्थात इसे अलग-अलग तरीकों से हल किया जा सकता है, लेकिन हम Semantic Search उपयोग नहीं करते, हम किसी grep, ripgrep इत्यादि पर अधिक निर्भर हैं। इसलिए यहाँ OpenWiki मदद करता है। और यदि विशेष रूप से SDD की बात करें, तो यह दूसरे स्तर की entity है। हमने वहाँ अपने development में, vibe-coding में भी, उदाहरण के लिए, कोई OpenSpec, Spec Kit उपयोग करने का प्रयास किया। Spec Kit के बारे में, सच कहूँ तो, मुझे यह भी याद नहीं कि हमारे वहाँ क्या परिणाम थे। OpenSpec में हम काफी लंबे समय तक ठीक Harness engineering टीम के भीतर रहे। लेकिन कुछ साथियों को यह पसंद था, टीम के कुछ लोगों को। फिर मैं आया, देखा कि यह कैसा दिखता है। मैंने सोचा: यार, यह सच कहूँ तो जटिल है। वही परिणाम बहुत कम अनावश्यक प्रक्रिया से पाया जा सकता है। यह आगे-पीछे चलाना, मूलतः। हाँ, हाँ। विचार स्पष्ट है: जितने अधिक tokens आप निर्देशित brainstorming पर खर्च करेंगे, उतना बेहतर परिणाम संभवतः किसी संभाव्यता सीमा में पाएँगे। लेकिन अब हम इस practice से दूर जा रहे हैं और बल्कि बहुत हल्का ऐसा spec SDD बना रहे हैं उस प्रारूप में, जैसे Anthropic का हाल में Playbook था। और उन्होंने वह Playbook प्रकाशित किया, जिसमें कहा था कि हमारे पास Intent.Markdown, Spec.Markdown, Design.Markdown, कुछ ऐसा है। और वहाँ सचमुच हमारे यहाँ यह प्रणाली बहुत समान रूप से लागू है। सब कुछ मुख्य code के उसी Git repository में commit होता है, लेकिन किसी कठोर workflow के बिना, जो, उदाहरण के लिए, OpenSpec की विशेषता है, और निश्चित रूप से उससे कम verbosity स्तर के साथ।

Q47: तो spec फिर भी कहीं रखी होती है?

• हाँ-हाँ, बिल्कुल। यह महत्वपूर्ण भाग है।

Q48: आंद्रेई, शायद मैंने सुनने में चूक की। आप वास्तव में role teams के समूह और role policy से क्या कहते हैं? क्या यह agent analyst, agent developer, agent tester है? हाँ, आपने कहा कि शुरुआत में हम role-based conveyor से निराश हुए, और फिर ऐसा करना शुरू किया जैसा अब करते हैं।

• आह, हाँ-हाँ-हाँ। वहाँ था... मैं याद करने की कोशिश कर रहा हूँ कि हमारे पास क्या था। वास्तव में, मुझे लगता है बहुत निकट है। उदाहरण के लिए, Codex Planning जैसे prompts थे। हमारे पास planner था, जिसे विस्तृत implementation plan देना होता था। हमारे पास implementer था, जिसे implementation plan लागू करना होता था। मुझे लगता है, उसे tests लिखने का अधिकार नहीं था। अतिरिक्त रूप से test writer था। और मुझे लगता है, हर phase के लिए adversaries थे, जिन्हें सुनिश्चित करना होता था, यदि कुछ अनुचित दिखे तो काम फिर से शुरू कराना होता था। हाँ, यह हमारे यहाँ काम नहीं किया।

Q49: तो अब एजेंट एक है?

• खैर, एक मुख्य executor, जो मूलतः end-to-end core का मालिक है। ऐसा एक samurai warrior। उसके पास और भी हैं, खैर, कहें तो... पूरी तरह advisors नहीं, लेकिन, संक्षेप में, reviewer चल सकता है। काम पूरा होने पर वह चलता है, एजेंट को कुछ feedback दे सकता है, और एजेंट एक बार कुछ पूरा कर सकता है या अनदेखा कर सकता है। वह इस feedback से असहमत हो सकता है, और तब यह स्पष्ट रूप से दर्ज होगा: इसे अनदेखा किया गया। और तदनुसार, बड़ी बात में हम role chains न बनाने की कोशिश करते हैं

Q50: दूसरा प्रश्न। एक इंजीनियर एक कार्य करता है। जब मैं इंजीनियर के कार्य-दिन के बारे में पूछता हूँ, जब वह टीम में आता है और वहाँ टीम synchronization करता है, तो यह टीम synchronization क्या है?

• खैर, मेरे लिए यह समझना महत्वपूर्ण है, मान लें, कि मेरे पास tunnel vision नहीं होना चाहिए, क्योंकि मुझे कार्य मिला और मैं अकेला उसे करने चला गया, लेकिन इससे आपके लोग, पहला, सनकी हो जाते हैं, शायद उनके लिए काम करना दिलचस्प नहीं रहता, वे स्वयं को केवल executors की तरह महसूस करते हैं, और कोई इसलिए कि अब वह अपना सारा काम अकेले करता है। इसलिए हमारे यहाँ सभी इंजीनियर पूरी तरह प्रोडक्ट context में डूबे हैं, ग्राहक की समस्याएँ हल करते हैं। वे सोचते हैं कि इसे कैसे लागू किया जाए। हमारी ऐसी टीमें हैं। हमारी ऐसी टीमें, बड़ी टीमें हैं, हर कोई अपना कार्य करता है। अब हमारे यहाँ ऐसी टीमें हैं।