एआई-असिस्टेड से एआई-नेटिव तक: एक फ़्रंटियर डेवलपमेंट टीम का निर्माण — क्लेयर लिगुओरी, एडब्ल्यूएस
AAI Engineer
컴퓨터/소프트웨어경영/리더십AI/미래기술
스크립트
00:00:00क्लेयर लिगुओरी: मेरा नाम क्लेयर लिगुओरी है, और मैं AWS में सीनियर प्रिंसिपल इंजीनियर हूँ।
00:00:17मैं मुख्य रूप से किरो पर काम करती हूँ, जो हमारा एजेंट डिकोडिंग असिस्टेंट है, लेकिन आज मैं बात करना चाहती हूँ
00:00:23उन कुछ तौर-तरीकों के बारे में जो हमने अमेज़न के भीतर अमेज़न टीमों में देखे हैं, जहाँ हमने
00:00:28उत्पादकता में वृद्धि के बेहद रोमांचक परिणाम देखे हैं जो कि अब तक एआई के साथ हमने जो देखा है,
00:00:35उससे कहीं बढ़कर एक बड़ा सुधार है। मैं तीन साल से अधिक समय से एजेंटिक एआई पर काम कर रही हूँ,
00:00:43और जब कोडिंग सहायता में एआई की बात आती है, तो मैंने अपने उद्योग में हुए विकास को करीब से देखा है।
00:00:48सबसे पहले, हमारे पास यह इनलाइन कोड कंप्लीशन था जो अगली लाइन, शायद अगले फ़ंक्शन को लिखने में हमारी मदद करता था।
00:00:55हम चैट पर आगे बढ़े, अपने कोड के बारे में सवाल पूछे। पिछले साल किसी समय हर कोई
00:01:02वाइब कोडिंग करने लगा था, लेकिन अब हम उस चीज़ के शुरुआती अपनाने वाले चरण को देखना शुरू कर रहे हैं
00:01:08जिसे हम फ्रंटियर डेवलपमेंट कह रहे हैं। और पूरी तरह से अपने निजी अनुभव के आधार पर,
00:01:14मुझे इन सभी चरणों के साथ केवल 10 से 20% अधिक उत्पादक महसूस हुआ है
00:01:20जो इससे पहले आए थे। लेकिन अब अमेज़न के भीतर, हम कंपनी भर की अलग-अलग टीमों के साथ पायलट चला रहे हैं,
00:01:27और हमने उत्पादकता में औसतन 4.5 गुना सुधार देखा है और कभी-कभी 10 गुना से भी अधिक। तो,
00:01:34यहाँ वास्तव में कुछ बदल गया है क्योंकि अब हम उत्पादकता में ऐसे बड़े सुधार देख रहे हैं।
00:01:40और मैं उन लोगों को परिभाषित करना पसंद करती हूँ जिन्हें हम अमेज़न के भीतर फ्रंटियर डेवलपर्स कह रहे हैं
00:01:47तीन ऐसे व्यवहारों से जो मैं देख रही हूँ। एक है हैंड्स-ऑफ कोडिंग। फ्रंटियर डेवलपर्स शायद
00:01:54अपने द्वारा बनाए जाने वाले कोड का 1 से 2% ही लिखते हैं। बाकी एजेंट करते हैं। दूसरा यह है कि वे अपने
00:02:01एजेंटों के साथ कभी-कभार ही बातचीत करते हैं। वे अपने कोडिंग असिस्टेंट को बिना उनके हस्तक्षेप के
00:02:08एक बार में कई घंटों तक चलने देने का लक्ष्य रखते हैं। और तीसरा यह है कि वे निष्क्रिय समय को कम से कम करते हैं। ये फ्रंटियर डेवलपर्स
00:02:15कई एजेंटों को समानांतर रूप से चलाना पसंद करते हैं, जो कार्यों के बैकलॉग को तेज़ी से पूरा करते हैं। पहली बार जब मैंने एक फ्रंटियर
00:02:24डेवलपर टीम को देखा, तो वह बेडॉक मेंटल टीम थी। बेडॉक हमारी मॉडल होस्टिंग सेवा है। यह क्लॉड जैसे एलएलएम को होस्ट करती है
00:02:34और जीपीटी। और पिछले साल किसी समय हम जानते थे, या मैं हम कहती हूँ, लेकिन बेडॉक टीम जानती थी कि उन्हें
00:02:43एक नया इन्फफेरेंस डेटा प्लेन बनाने की आवश्यकता होगी। लेकिन उन्होंने 18 महीनों में 30 लोगों का अनुमान लगाया था। यह एक बड़ी,
00:02:52बड़ी सेवा है। और नया डेटा प्लेन बनाने, ग्राहकों को स्थानांतरित करने, मॉडल को स्थानांतरित करने में समय लगने वाला था
00:02:58और उन्होंने एक कदम पीछे हटने का फैसला किया। उन्होंने छह लोगों को लिया और किरो के साथ इसे 76 दिनों में बना डाला।
00:03:06तो यह एक बहुत बड़ी उपलब्धि थी। यह पहली बार था जब हमने अमेज़न के भीतर इस तरह की कोई चीज़ देखी थी।
00:03:12तो यह वास्तव में पाथफाइंडर टीम थी जिसने साबित कर दिया कि 20 गुना तक सुधार पाना संभव है। अब उन्होंने
00:03:21कमिट्स को देखा, और मैं कुछ अन्य तरीकों के बारे में बात करूँगी जिनसे हम उत्पादकता में सुधार को माप रहे हैं। लेकिन
00:03:27इस कहानी के साथ एक समस्या थी, जो यह थी कि, हाँ, इसे छह लोगों द्वारा बनाया गया था। इसे
00:03:34कंपनी के कुछ शीर्ष इंजीनियरों के साथ बनाया गया था, जिसमें दो प्रतिष्ठित इंजीनियर भी शामिल थे। तो यह
00:03:40सिर्फ छह लोगों की कोई आम टीम नहीं थी। ये वितरित प्रणालियों के विशेषज्ञ थे, एलएलएम और उनकी
00:03:49वास्तुकला के विशेषज्ञ थे। तो यह कहानी अद्भुत थी और अमेज़न में जंगल की आग की तरह फैल गई। लेकिन यह
00:03:57कई टीमों के लिए हासिल करना बहुत मुश्किल भी था। बहुत सारे सवाल थे कि, क्या इसे वास्तव में किसी अन्य टीम पर
00:04:03دوبارہ दोहराया जा सकता है? तो एक और प्रयोग जिसके बारे में मैं बात करना चाहती हूँ वह एक प्रायोगिक स्प्रिंट है जो
00:04:10प्राइम वीडियो संगठन में किया गया था। उन्होंने 10 दिन का स्प्रिंट लिया और एक प्रयोग किया जिसमें उन्होंने फिर से छह इंजीनियरों को
00:04:19एक कमरे में रखा और किरो के साथ धमाल मचाने दिया। उन्होंने प्रोजेक्ट डिलीवरी के समय के अनुमान को जो कि
00:04:2990 सप्ताह होने वाला था, इस 10 दिन के स्प्रिंट में हुई सारी प्रगति के आधार पर घटाकर 24 सप्ताह कर दिया।
00:04:36और उन्होंने अपने कमिट इतिहास को देखा और देखा कि वे इस 10-दिन के स्प्रिंट से पहले क्या करते थे
00:04:42और उन्होंने सिर्फ इन 10 दिनों में कितने कमिट्स दिए। और इसलिए इस स्प्रिंट ने वास्तव में
00:04:49यह साबित कर दिया कि हम एक बार फिर, बेडॉक मेंटल टीम द्वारा प्राप्त किए गए लक्ष्य के कम से कम करीब कुछ हासिल कर सकते हैं
00:04:58इंजीनियरों के एक अलग समूह के साथ। लेकिन फिर से, इस कहानी के साथ एक चुनौती थी, जो यह थी कि यह छह
00:05:05इंजीनियर एक कमरे में थे जिन्हें कोई ऑन-कॉल ड्यूटी नहीं थी, सीमित बैठकें थीं, बहुत कम रुकावटें थीं, जो हम सभी
00:05:12जानते हैं कि एक इंजीनियर के जीवन में आम बात है। और टीम के सीनियर इंजीनियर ने पिछले
00:05:20तीन सप्ताह इन छह इंजीनियरों के लिए विस्तृत आवश्यकताओं के साथ बहुत विस्तृत, छोटे, अच्छी तरह से परिभाषित कार्य बनाने में बिताए थे
00:05:28ताकि वे उन दो हफ्तों के लिए बस उन पर काम कर सकें। तो यह, एक बार फिर, जरूरी नहीं कि वास्तविक जीवन हो।
00:05:35यह एक संरचित स्प्रिंट था, समय का एक बिंदु जिसे वे हासिल करने में सक्षम थे। लेकिन फिर से,
00:05:41सवाल यह है कि क्या यह दैनिक कार्य के लिए वास्तविक टीमों पर प्राप्त करने योग्य है? तो अमेज़न स्टोर्स, जिसमें शामिल है
00:05:51Amazon.com, हमारी सभी खुदरा वेबसाइटें, साथ ही हमारे भौतिक स्टोर, ने एक अधिक संरचित पायलट किया।
00:05:59उन्होंने 50 टीमों को देखा जो पूरी तरह से सामान्य थीं, शुरुआती करियर के लोगों का सामान्य वितरण, मध्य-कैरियर
00:06:07के सीनियर इंजीनियर, और जो मौजूदा प्रणालियों पर काम करते थे। मेंटल टीम की तरह कुछ भी ग्रीनफील्ड नहीं जिसे जमीन से ऊपर
00:06:14बनाने का मौका मिला हो, बल्कि मौजूदा कोड बेस के साथ मौजूदा सिस्टम। और उन्होंने उन्हें पिछले साल के
00:06:21बेहतर हिस्से के लिए देखा, और उन्हें कुछ बेहद दिलचस्प लगा। उन्होंने पाया कि एक बड़ा अंतर था
00:06:28उन उत्पादकता लाभों में जो उन्होंने आधी टीमों और दूसरी आधी टीमों के बीच देखे। और इसमें,
00:06:34उन्होंने उत्पादन के लिए तैनाती वेग के उत्पादकता मीट्रिक का उपयोग किया। इसलिए केवल कमिट ही नहीं, वे कितने
00:06:41कमिट का उत्पादन कर रहे हैं, बल्कि हम ग्राहकों तक बदलाव कितनी जल्दी पहुँचा रहे हैं? हम कितनी जल्दी
00:06:48चीजों को शिप करने में सक्षम हैं? और उन्होंने देखा कि आधी टीमों के लिए, उन्होंने 3 गुना से कम की वृद्धि हासिल की। और उन्होंने जो
00:06:56पाया कि 3 गुना से कम उत्पादकता वृद्धि देखने के बीच का अंतर था, और इन टीमों ने जो देखा
00:07:01औसत 4.5 गुना, और कुछ मामलों में 10 से अधिक, यह था कि उन्होंने उपकरणों का उपयोग कैसे किया। इनमें से 90% टीमों ने किरो का उपयोग किया, हमारे पास मौजूद अन्य आंतरिक उपकरणों के बीच।
00:07:11और उन्होंने जो पाया वह यह था कि यह उपकरणों के बारे में नहीं था, यह उस तरीके के बारे में था जिस तरह से वे
00:07:18काम करते थे। जिन टीमों ने बड़े सुधार हासिल किए, उन्होंने जानबूझकर अपने काम करने के तरीके को बदल दिया,
00:07:26और अन्य लोगों ने बस अपने काम करने के मौजूदा तरीके के ऊपर किरो और हमारे पास मौजूद कुछ अन्य उपकरणों को छिड़क दिया।
00:07:31और कम से कम मेरे लिए, यह एक बड़ा पल था, कि मुझे क्यों महसूस नहीं हो रहा था
00:07:39उत्पादकता में संभावित रूप से भारी लाभ जिसका एआई ने वादा किया है, यह हमारे काम करने के तरीके को बदलने के बारे में है।
00:07:47तो इस पायलट के दौरान, वे गए और पायलट में शामिल टीमों का साक्षात्कार लिया, साथ ही बेडॉक मेंटल टीम, प्राइम वीडियो पर इन अन्य टीमों में से कुछ का साक्षात्कार लिया, और उन्होंने पाँच आदतें पाईं।
00:07:55और मैं आदतों शब्द का उपयोग बहुत विशिष्ट रूप से करती हूँ, क्योंकि एक बार फिर, यह उस एक स्प्रिंट के बारे में नहीं है, यह इसे दिन-प्रतिदिन करने के बारे में है।
00:08:03और जब उन्होंने इन टीमों के साथ साक्षात्कार किया तो उन्होंने पाया कि यह वास्तव में आदतें थीं जिन्हें उन्हें दिन-प्रतिदिन बनाना था।
00:08:09जब हम अपने काम करने के तरीके को बदलते हैं, तो इन आदतों को बनाना कठिन होता है, इन आदतों को बनाने में समय लगता है।
00:08:15तो आइए इनमें से प्रत्येक को एक-एक करके देखें। आदत नंबर एक एजेंट संदर्भ में निवेश कर रही है।
00:08:22तो आइए इनमें से हर एक पर एक-एक करके बात करते हैं। पहली आदत है एजेंट के संदर्भ (कंटेक्स्ट) में निवेश करना।
00:08:30हमारे दिमाग में बहुत सारी बातें होती हैं, और हम उस सारी जानकारी को दूसरों तक पहुँचाने की कोशिश करते हैं
00:08:35जैसे स्लैक बातचीत के ज़रिए, नए साथियों को सिखाते समय, कोड रिव्यू के दौरान और ऐसी ही अन्य चीज़ों से,
00:08:42स्टैंड-अप और स्प्रिंट प्लानिंग के ज़रिए, और उन्हें यह सब लिखकर रखना पड़ा। और उन्होंने जो आदत
00:08:50डाली, वह यह थी कि जब भी एजेंट कोई गलती करे या कोई काम उस तरह से न करे जैसे आप करते,
00:08:55तो सोचें कि मेरी स्किल्स फाइलों में क्या कमी है? मेरी स्टीयरिंग फाइलों में ऐसी क्या कमी है जो एजेंट को चाहिए थी?
00:09:01लेकिन जैसा कि हम जानते हैं, पिछले साल हमने मॉडल्स की क्षमताओं और उनके व्यवहार में भारी बदलाव देखे हैं।
00:09:09पिछले साल के बीच में सॉनेट 3.7 में कई ऐसी अजीब बातें थीं जिनके लिए हमें अपनी स्टीयरिंग फाइलों में
00:09:16बहुत सारे "यह मत करो" वाले निर्देश देने पड़े थे। और अब पिछले नवंबर से ओपस 4.5 के साथ हमें ऐसा करने की उतनी ज़रूरत नहीं पड़ती,
00:09:23और तब से लेकर अब तक छह महीने से ज़्यादा समय में मॉडल के कई नए वर्ज़न आ चुके हैं जिनमें सुधार हुए हैं।
00:09:29तो सवाल यह है, और नई आदत यह है कि क्या मुझे अभी भी अपनी स्टीयरिंग फाइलों में इन चीज़ों की ज़रूरत है?
00:09:35या यह सिर्फ संदर्भ को बेकार में बढ़ा रहा है? दूसरी आदत है गति बढ़ाने के लिए थोड़ा धीमा होना।
00:09:41शामिल की गई लगभग हर टीम ने बताया कि जब उन्होंने जानबूझकर काम करने का नया तरीका अपनाया, तो उनकी उत्पादकता
00:09:48वास्तव में कम हो गई। यह बात थोड़ी अजीब लगती है, है ना?
00:09:53उत्पादकता में वह तेज़ी से बढ़त देखने से पहले आपको सोच-समझकर इंजीनियरिंग का काम करना ही होगा।
00:09:59क्योंकि एजेंटों को सफल बनाने के लिए हमें अपने कोड बेस में असल काम करना होता है, खासकर मौजूदा कोड बेस में।
00:10:05इसलिए उन्हें एजेंट के संदर्भ को बेहतर बनाना पड़ा, मौजूदा टूल्स के एरर मैसेज सुधारने पड़े ताकि मॉडल को पता चल सके
00:10:11कि गलती होने पर क्या हुआ था। उन्होंने नए टूल्स बनाए, नए MCP सर्वर बनाए ताकि मॉडल को उसका काम पूरा करने में मदद मिल सके।
00:10:17कई टीमों ने अपने कोड बेस की संरचना को फिर से बदला ताकि एजेंट उसमें आसानी से नेविगेट कर सकें।
00:10:24और मैंने कोड बेस की प्रोग्रामिंग भाषा बदलने जैसे बड़े बदलाव भी देखे हैं।
00:10:29अक्सर मैंने टीमों को पाइथन और जावास्क्रिप्ट के साथ संघर्ष करते देखा है क्योंकि वे अनटाइप्ड भाषाएँ हैं।
00:10:36उनकी टेस्टिंग करना मुश्किल होता है। कोई कंपाइलर एरर नहीं मिलते। इसलिए मॉडल अंदाज़ा लगाता है
00:10:43और आपको जवाब दे देता है। इसलिए मैंने टीमों को टाइपस्क्रिप्ट पर जाते देखा है। अमेज़न के अंदर
00:10:50Rust बहुत लोकप्रिय हो गया है। इसका कंपाइलर बेहतरीन एरर मैसेज देता है। आपको ऐसा करने की ज़रूरत नहीं पड़ती।
00:10:56लेकिन मैंने कई टीमों को अपनी उत्पादकता बढ़ाने के लिए ऐसे सोच-समझकर बदलाव करते हुए देखा है।
00:11:03तीसरी आदत है एजेंटों को फीड देना, न कि उनकी नैनी (बेबीसिट) बनना।
00:11:09और मेरे लिए, यह उन खास पलों में से एक था जब मुझे समझ आया कि उत्पादकता में इतनी भारी बढ़ोतरी क्यों दिख रही है।
00:11:16अगर आप वाइब कोडिंग कर रहे हैं, अगर आप पूरे दिन अपने एजेंट के साथ आगे-पीछे बातचीत कर रहे हैं,
00:11:23तो ज़ाहिर है कि आप चार से पाँच गुना उत्पादकता में सुधार नहीं देख पाएंगे क्योंकि आप पूरे समय उस प्रक्रिया में शामिल हैं।
00:11:30शायद आप कोड जनरेट होने और रिव्यू के लिए वापस आने का इंतज़ार करते हुए 30 सेकंड से एक मिनट तक बैठे रहते हैं।
00:11:36अगर आप वहीं बैठकर उसका इंतज़ार करते रहेंगे, तो आप उठकर दूसरे काम नहीं कर पाएंगे।
00:11:42कई एजेंटों को एक साथ चलाना बहुत मुश्किल होता है। खुद को कई एजेंटों में विभाजित करना बहुत कठिन है।
00:11:48चीजें करना बहुत मुश्किल होता है। एजेंट्स को पैरेलल में चलाना काफी कठिन होता है। खुद को कई एजेंट्स में
00:11:55क्लोन करना बहुत मुश्किल है। इसलिए अगर आपकी बातचीत बाईं ओर की तरह दिखती है, तो आप
00:12:01उस एजेंट की देखरेख कर रहे हैं, बजाए इसके कि दाईं ओर की तरह जहाँ आप उसे खिला रहे हैं कि उसे क्या करना है और कैसे
00:12:08वह खुद को वैलिडेट कर सके। और वास्तव में यही मुख्य बात है ताकि एजेंट खुद को सुधार सकें और केवल तभी आपके पास वापस आएं
00:12:14जब यह एक निश्चित गुणवत्ता के स्तर को पूरा करता है, जब यह वास्तव में चलता है और कंपाइल होता है और टेस्ट पास करता है, जब
00:12:20यह टेस्ट करने योग्य होता है, जब इसमें वास्तव में हाई कवरेज होती है। और बेशक, अगला स्तर इन सभी
00:12:26सामग्री को अपनी स्टीयरिंग फ़ाइल में डालना है। ताकि यह हर बार आपके संकेत दिए बिना ऐसा करे।
00:12:33चौथी आदत है इरादे को स्पष्ट करना। अमेज़न में, हम स्पेक्ट्रम और विकास का बहुत अभ्यास करते हैं।
00:12:40हमने इसे काइरो उत्पाद में बनाया है। और इसलिए अमेज़न इंजीनियरों के लिए इसे अपनाना बहुत स्वाभाविक है
00:12:46काइरो में। मैंने आमतौर पर वाइब कोडिंग के साथ जो देखा है, वह फ़्रंटियर इंजीनियरिंग के विपरीत है,
00:12:54बहुत उच्च स्तर का संकेत देना, एजेंट को बहुत सारा कोड जनरेट करने देना, और फिर आगे-पीछे
00:13:02बातचीत करना यह कहते हुए कि, ओह, मेरा मतलब वास्तव में वह नहीं था। कि आपने आवश्यकताओं को बिल्कुल सही नहीं समझा है।
00:13:10नहीं, मैं वास्तव में इसे उस तरह से नहीं बनाना चाहता था। यहाँ एक तकनीकी डिज़ाइन है। और मुझे लगता है कि यह कम उत्पादक है
00:13:17कोड पर एजेंट के साथ पुनरावृत्ति करना जब इरादा ही गलत था। इसलिए अक्सर हमारे पास अमेज़न
00:13:26इंजीनियर अस्पष्ट, जटिल सुविधाओं के लिए विनिर्देश लिखने की इस प्रक्रिया से गुजरते हैं।
00:13:34और काइरो में, बेशक, आपको यह पूरा विनिर्देश लिखने की ज़रूरत नहीं है, आप मॉडल को जनरेट करवा सकते हैं
00:13:39इसे। लेकिन कोड के बारे में बात करने की तुलना में एक दस्तावेज़ के बारे में आगे-पीछे बातचीत में मॉडल के साथ पुनरावृत्ति करना बहुत आसान है,
00:13:46जो कोड परिवर्तन कोड बेस में फैले हुए हैं। पाँचवीं बात है टेस्टिंग को बाईं ओर शिफ्ट करना।
00:13:56यहाँ मुख्य बातों में से एक एजेंट को वह तेज़ फ़ीडबैक लूप देना है, क्योंकि यही वह चीज़ है जो इसे एक बार में घंटों तक काम करने देती है
00:14:04और खुद को सुधारना। एजेंट गलतियाँ करने जा रहा है, और यह ठीक है। लेकिन अगर आप इसे सही संकेत देते हैं, तो यह कर सकता है
00:14:12स्वयं को सुधारें और यह ऐसा करने में कुछ समय बिता सकता है। इसलिए मैंने टीमों को लिंटर्स, यूनिट टेस्ट जोड़ते हुए देखा है,
00:14:20इंटीग्रेशन टेस्ट, परफॉरमेंस टेस्ट, सिक्योरिटी टेस्ट। ये ऐसी चीजें हैं जो हम सब जानते हैं कि हमें करनी चाहिए थीं
00:14:24हर समय। यह अच्छी इंजीनियरिंग स्वच्छता और प्रथाएं हैं। लेकिन अब निवेश पर रिटर्न (ROI) मुझे लगता है कि आखिरकार
00:14:32हमारे लिए इसमें वास्तव में निवेश करने के लिए पर्याप्त है। एक बात जो मैंने बहुत सी टीमों को करते हुए देखी है वह है मॉक आउट करना
00:14:40सेवाएं। अक्सर इंटीग्रेशन टेस्ट के साथ, हम लाइव सहित संपूर्ण सिस्टम का एंड-टू-एंड परीक्षण करते थे
00:14:46सेवाएं। लेकिन हमने मॉक सेवाओं में बहुत निवेश किया है जो पूरी तरह से स्थानीय रूप से नियतिवादी के साथ चलती हैं
00:14:52प्रतिक्रियाएं, क्योंकि यह एजेंट को सब कुछ स्थानीय रूप से करने देती हैं। बिना सब कुछ अपने लैपटॉप पर करना
00:15:01कई अन्य सेवाओं को स्पिन अप किए बिना और क्लाउड सेवाओं से कनेक्ट किए बिना सब कुछ बहुत तेज हो जाता है।
00:15:07क्योंकि आपका एजेंट जितनी अधिक तेजी से फीडबैक प्राप्त कर सकता है, उसका मतलब है कि यह उतने ही अधिक लूप कर सकता है
00:15:14कर सकते हैं और आपका अपना एजेंट उतना ही अधिक उत्पादक हो सकता है। तो इन सब में, ये कुछ हैं
00:15:21ऐसी आदतें जो हमने देखी हैं। लेकिन बेशक, अगर मैं आपको बताऊँ कि यदि आप इन सभी आदतों को अपनाते हैं, तो यह मेरी भूल होगी,
00:15:28आप निर्वाण प्राप्त कर लेंगे, आप दुनिया के सबसे उत्पादक इंजीनियरिंग संगठन बन जाएंगे
00:15:35कभी देखा है। चीजें अभी भी कठिन हैं। हम अभी भी शुरुआती अपनाने के चरण में हैं और टीमें अभी भी हैं
00:15:42इसका पता लगा रहा हूँ। तो एक बात जो हमने अपनी टीमों में संगठनात्मक रूप से देखी है वह है इसका जोखिम
00:15:48थकान। मैंने यह शब्द नहीं गढ़ा है, मैं भूल गया हूँ कि किसने किस सम्मेलन में किया था, लेकिन FOMAT वास्तविक है। हमने देखा है
00:15:56इंजीनियर देर रात तक जागते हैं, उस सही संकेत को पाने की कोशिश कर रहे हैं जो उनके लिए काम करेगा
00:16:03एजेंट रात भर घंटों काम करता है ताकि वे सुबह उठकर कोड परिवर्तन तैयार पा सकें। संज्ञानात्मक भार
00:16:09जैसे-जैसे आप इन एकाधिक एजेंटों को समानांतर रूप से चलाते हैं, यह बढ़ जाता है, आप लगातार इनके बीच स्विच कर रहे होते हैं
00:16:15टर्मिनल टैब। और फिर हम देखते हैं कि AI आउटपुट की समीक्षा करना अक्सर कुछ लोगों के लिए तुलना में कठिन होता है
00:16:22इसे वास्तव में लिखना, विशेषकर करियर की शुरुआत में। वरिष्ठ इंजीनियरों ने पहले ही अपने अधिकांश हिस्से खर्च कर दिए हैं
00:16:29करियर दूसरों के कोड की समीक्षा कर रहा है। लेकिन करियर की शुरुआत के इंजीनियरों के पास अभी तक वह मांसपेशी नहीं है। और इसलिए समीक्षा कर रहा है
00:16:37यह उनके आदी होने की तुलना में बहुत अधिक संज्ञानात्मक भार की तरह महसूस हो सकता है और वास्तव में इसे लिख रहा है। दूसरा
00:16:44एक संगठनात्मक परिवर्तन है। इसलिए इंजीनियरों के रूप में हमारे काम करने के तरीके को बदलना पहले से ही कठिन है। जिस तरह से हम
00:16:52जब हम फ़्रंटियर इंजीनियर होते हैं तो हमारा पूरा दिन पूरी तरह से बदल जाता है। लेकिन संगठनों को भी करना पड़ता है
00:16:58फ़्रंटियर इंजीनियरिंग टीमों को सक्षम करने के लिए बदलाव करें। एक जिसे मैंने बहुत ही आम तौर पर देखा है वह है धीमा होना स्वीकार करना
00:17:07तेजी लाने के लिए। और मैं खुद इसका दोषी रहा हूँ। मेरे साथी नेता यह कहते हुए दोषी रहे हैं,
00:17:14खैर, आपके पास अब AI टूल हैं और मॉडल अब बहुत अद्भुत हैं। आप तेजी से क्यों नहीं जा रहे हैं?
00:17:22और ऐसा इसलिए है क्योंकि आपको अपने कोड बेस में निवेश करने के लिए उन दो महीनों को लेना होगा ताकि सर्वश्रेष्ठ का पता लगाया जा सके
00:17:29आपकी टीम के लिए सबसे अच्छे अभ्यास आपकी टीम पर कठिन आदत परिवर्तन करने के लिए। और यदि आप लगातार अपेक्षा कर रहे हैं
00:17:38हर महीने सुविधाएँ भेज रहे हैं, क्योंकि अब हमारे पास ये अद्भुत मॉडल हैं, और हम देख रहे हैं
00:17:44X पर सभी कंपनियाँ बता रही हैं कि वे एक दिन में 20 PR कैसे भेज रही हैं, हमें गति बढ़ाने के लिए धीमा होना होगा।
00:17:54दूसरा वास्तव में संगठन में बहुत तेज़ी से बहुत व्यापक होना है। मुझे लगता है कि अगर हमारे पास था
00:18:01विशाल संगठनों की सभी टीमों से तुरंत फ़्रंटियर टीमें होने की उम्मीद थी, हमारे पास यह नहीं होता
00:18:08पाथफाइंडर से जो सीख हमें मिली, वह स्प्रिंट प्रयोग से, पायलट से
00:18:16अमेज़न के भीतर की टीमें। और अब हमारे सामने चुनौती यह है कि हम इसे कैसे आगे बढ़ाएं? और 2026 इसी के बारे में है।
00:18:22अमेज़न के लिए यह है कि हम इसे 50 टीमों के बजाय अधिक से अधिक टीमों तक अगली 2000 टीमों तक कैसे पहुँचाएँ।
00:18:31और इसलिए मुझे लगता है कि जब आप इसे बहुत जल्दी रोल आउट करते हैं, तो आपके पास कई ऐसी टीमें होती हैं जो नहीं जानती हैं कि वे क्या कर रही हैं
00:18:37कर रहे हैं। आपको अपने स्वयं के संगठनों के लिए सर्वोत्तम अभ्यास खोजने का समय नहीं मिला है, संदर्भ
00:18:43जो आपके संगठन को चाहिए। और आखिरी बात यह है कि आपको नई बाधाएं मिलेंगी।
00:18:49पहले मैन्युअल रूप से कोड लिखना एक बाधा था। मुझे लगता है कि अमेज़न के भीतर, हमने पाया है
00:18:58निर्णय लेने की गति एक नई बाधा बन जाती है। जितना अधिक आप निर्णय की समीक्षा करने में समय बिताते हैं
00:19:05वास्तव में एक नया उत्पाद बनाने के लिए, उत्पाद का निर्माण करना उतना ही धीमा है क्योंकि कोड लिखने में केवल एक से दो महीने लगते हैं।
00:19:12किसी उत्पाद के लॉन्च से जुड़ी सभी समीक्षा प्रक्रियाएं बाधा बन जाती हैं।
00:19:20जब एक नया उत्पाद बनाने में 9 से 12 महीने लगते थे, तो इससे कोई खास फर्क नहीं पड़ता था
00:19:27चीजों का धोना। यदि उत्पाद बनाने के निर्णय में दो महीने लगे और फिर दो महीने
00:19:33लॉन्च को मंजूरी दें। लेकिन अब वे बाधाएं हैं। वे लंबी ध्रुव हैं। और इसलिए आपको सब कुछ मिल जाता है
00:19:40ये सभी चीजें जो आपको धीमा कर देती हैं। अक्सर मैं पाता हूँ कि फ़्रंटियर इंजीनियरिंग टीमें अधिक समय बिताती हैं
00:19:48कोड लिखने की तुलना में निर्णय लेने में। और इसलिए जितना अधिक आप तेजी से निर्णय ले सकते हैं, विशेष रूप से ऐसे निर्णय
00:19:54जिन्हें उलटना आसान हो, उतना ही बेहतर है। तो यहाँ सभी के लिए मेरा एक बड़ा निष्कर्ष यह है कि फ़्रंटियर
00:20:03इंजीनियरिंग आपके काम करने के तरीके को जानबूझकर बदलने के बारे में है। और यह कठिन है। इसमें समय लगता है।
00:20:10यह नई आदतें और काम करने का एक नया तरीका बना रहा है। और यह किसी भी इंजीनियरिंग टीम के साथ-साथ आपके
00:20:18संगठन पर भी लागू होता है। इसलिए मैं आपको इसके बारे में सोचने के लिए प्रोत्साहित करता हूँ कि आप AI टूल के साथ कैसे इंटरैक्ट कर रहे हैं और यह कैसे हो सकता है
00:20:27लूप में रहने से खुद को मुक्त करने के लिए बदलाव करें। धन्यवाद। यदि किसी के पास है तो मैं थोड़ी देर रुकूंगा
00:20:34पीछे प्रश्न। लेकिन आज समय देने के लिए धन्यवाद।