00:00:00[संगीत]
00:00:21>> नमस्ते सबको, शुभ दोपहर।
00:00:22मैं अपनी बात की शुरुआत एक स्वीकारोक्ति के साथ करने जा रहा हूँ।
00:00:26मैंने ऐसा कोड शिप किया है, जिसे मैं पूरी तरह समझ नहीं पाया था।
00:00:29इसे जनरेट किया, टेस्ट किया, डिप्लॉय किया, लेकिन यह समझा नहीं सका कि यह कैसे काम करता है।
00:00:33और बात यह है कि, मुझे यकीन है कि आप सबने भी ऐसा किया होगा।
00:00:37>> [हँसी]
00:00:40>> तो अब जब हम सब मान चुके हैं कि हम ऐसा कोड शिप करते हैं
00:00:41जिसे हम अब और नहीं समझते, तो मैं आपको एक सफर पर ले जाना चाहता हूँ,
00:00:44यह देखने के लिए कि यह सब कैसे हुआ।
00:00:46पहले, इतिहास को देखें, तो पता चलता है कि इतिहास खुद को दोहराता है।
00:00:50दूसरा, हम एक जाल में फंस गए हैं।
00:00:52हमने "आसान" को "सरल" समझ लेने की गलती की है।
00:00:55अंत में, इसका एक समाधान है, लेकिन इसके लिए हमें अपनी सोच को आउटसोर्स नहीं करना होगा।
00:01:00तो, मैंने पिछले कुछ साल नेटफ्लिक्स में AI टूल्स को अपनाने में मदद करने में बिताए हैं।
00:01:05और मुझे कहना होगा कि इसकी रफ्तार वाकई बहुत तेज है।
00:01:07बैकलॉग के जो काम पहले दिनों में होते थे, अब घंटों में हो जाते हैं।
00:01:10और बड़े रिफैक्टर्स जो सालों से अटके हुए थे, वे आखिरकार पूरे किए जा रहे हैं।
00:01:15लेकिन यहाँ एक बात है।
00:01:16बड़े प्रोडक्शन सिस्टम हमेशा अप्रत्याशित तरीकों से फेल होते हैं।
00:01:19जैसे हाल ही में क्लाउडफ्लेयर के साथ जो हुआ उसे ही देख लीजिए।
00:01:21जब ऐसा होता है, तो बेहतर होगा कि आप उस कोड को समझें जिसे आप डिबग कर रहे हैं।
00:01:23और समस्या यह है कि अब हम इतनी गति और इतनी मात्रा में कोड जनरेट कर रहे हैं,
00:01:28कि हमारी समझ उसका साथ नहीं दे पा रही है।
00:01:29सच तो यह है कि, मैंने खुद भी ऐसा किया है।
00:01:34मैंने ढेर सारा कोड जनरेट किया, उसे देखा और सोचा, मुझे नहीं पता कि यह क्या करता है।
00:01:39लेकिन टेस्ट पास हो गए, काम बन गया, इसलिए मैंने इसे शिप कर दिया।
00:01:41यहाँ गौर करने वाली बात यह है कि यह वास्तव में कुछ नया नहीं है।
00:01:44सॉफ्टवेयर इंजीनियरों की हर पीढ़ी ने अंततः एक ऐसी दीवार का सामना किया है जहाँ
00:01:48सॉफ्टवेयर की जटिलता उनकी प्रबंधन क्षमता से बाहर हो गई।
00:01:50हम सॉफ्टवेयर संकट का सामना करने वाले पहले लोग नहीं हैं,
00:01:52लेकिन हम इसे जनरेशन के इस अनंत पैमाने पर झेलने वाले पहले जरूर हैं।
00:01:56तो चलिए थोड़ा पीछे मुड़कर देखते हैं कि यह सब कहाँ से शुरू हुआ।
00:01:5860 के दशक के अंत और 70 के दशक की शुरुआत में, उस समय के कुछ स्मार्ट कंप्यूटर वैज्ञानिकों ने
00:02:03एक साथ आकर कहा, कि हम एक सॉफ्टवेयर संकट में हैं।
00:02:06सॉफ्टवेयर की मांग बहुत बड़ी है, और फिर भी हम इसकी बराबरी नहीं कर पा रहे हैं।
00:02:11प्रोजेक्ट्स में बहुत समय लग रहा है, और काम बहुत धीमा है।
00:02:15हम अच्छा काम नहीं कर पा रहे हैं।
00:02:16तभी डाइकस्ट्रा ने एक बहुत ही शानदार बात कही थी।
00:02:20उन्होंने कहा था, उनके एक लंबे उद्धरण को संक्षेप में कहूँ तो, कि जब हमारे पास कुछ कमजोर कंप्यूटर थे,
00:02:23तब प्रोग्रामिंग एक छोटी सी समस्या थी।
00:02:26और अब जब हमारे पास विशाल कंप्यूटर हैं, तो प्रोग्रामिंग एक विशाल समस्या बन गई है।
00:02:31वे समझा रहे थे कि जैसे-जैसे हार्डवेयर की शक्ति 1,000 गुना बढ़ी,
00:02:34सॉफ्टवेयर के लिए समाज की जरूरतें भी उसी अनुपात में बढ़ गईं।
00:02:37और इसने हम प्रोग्रामर्स को तरीके और साधनों के बीच यह सोचने पर मजबूर कर दिया,
00:02:41कि हम इतने बड़े पैमाने पर सॉफ्टवेयर का समर्थन कैसे करें?
00:02:43तो यह सब एक चक्र की तरह होता रहता है।
00:02:4770 के दशक में हमें C प्रोग्रामिंग भाषा मिली, ताकि हम बड़े सिस्टम लिख सकें।
00:02:5080 के दशक में हमारे पास पर्सनल कंप्यूटर आ गए, अब हर कोई सॉफ्टवेयर लिख सकता था।
00:02:5390 के दशक में हमें ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग मिली।
00:02:56पेचीदा पदानुक्रमों वाली मुसीबत, उसके लिए जावा का शुक्रिया।
00:03:002000 के दशक में एजाइल आया, और हमारे पास स्प्रिंट्स और
00:03:03स्कम मास्टर्स आ गए जो हमें बताते थे कि क्या करना है, वॉटरफॉल खत्म हो गया।
00:03:062010 के दशक में क्लाउड, मोबाइल, डेवऑप्स सब आ गया,
00:03:09सॉफ्टवेयर ने वाकई पूरी दुनिया पर कब्जा कर लिया।
00:03:10और आज हमारे पास AI है, को-पायलट, कर्सर, क्लॉड, कोडेक्स, जेमिनी, आप जो भी कहें।
00:03:17हम कोड उतनी ही तेजी से जनरेट कर सकते हैं जितनी तेजी से हम उसे समझा सकते हैं।
00:03:19पैटर्न वही है, लेकिन पैमाना वाकई बदल गया है, अब यह अनंत है।
00:03:23फ्रेड ब्रुक्स, आप शायद उन्हें "द मिथिकल मैन मंथ" लिखने के लिए जानते होंगे।
00:03:29उन्होंने 1986 में "नो सिल्वर बुलेट" नाम का एक पेपर भी लिखा था।
00:03:32इसमें उन्होंने तर्क दिया कि ऐसा कोई एक आविष्कार नहीं होगा जो हमें
00:03:36सॉफ्टवेयर उत्पादकता में कई गुना सुधार दे सके।
00:03:38क्यों?
00:03:40क्योंकि उन्होंने कहा था कि कठिन हिस्सा कोडिंग के यांत्रिकी, सिंटैक्स,
00:03:44टाइपिंग या बॉयलरप्लेट नहीं था।
00:03:45वह वास्तविक समस्या को समझना और समाधान डिजाइन करना था।
00:03:49कोई भी टूल उस बुनियादी कठिनाई को खत्म नहीं कर सकता।
00:03:52अब तक हमने जो भी टूल और तकनीक बनाई है, वह केवल यांत्रिकी को आसान बनाती है।
00:03:55लेकिन मुख्य चुनौती,
00:03:57कि क्या बनाना है और इसे कैसे काम करना चाहिए, आज भी उतनी ही कठिन है।
00:04:00तो अगर समस्या यांत्रिकी में नहीं है, तो हम इसके लिए अनुकूलन क्यों करते रहते हैं?
00:04:06अनुभवी इंजीनियर भी अब ऐसे कोड के साथ कैसे रह जाते हैं जिसे वे नहीं समझते?
00:04:09मुझे लगता है इसका जवाब उन दो शब्दों में है जिन्हें हम अक्सर मिला देते हैं, "सरल" (Simple) और "आसान" (Easy)।
00:04:14हम अक्सर इन्हें एक-दूसरे की जगह इस्तेमाल करते हैं, लेकिन
00:04:16इनका मतलब बिल्कुल अलग होता है।
00:04:18स्पीकर डिनर में मेरा खुलासा हो गया था कि मैं क्लोजर (Clojure) वाला बंदा हूँ, तो
00:04:21यह यहाँ काफी स्पष्ट है।
00:04:23क्लोजर प्रोग्रामिंग भाषा के निर्माता रिच हिकी ने,
00:04:252011 के अपने टॉक "सिंपल मेड ईजी" में इसे समझाया था।
00:04:29उन्होंने "सरल" (Simple) को परिभाषित किया कि जिसमें एक ही तह हो, एक ही गुंथाव हो और कोई उलझन न हो।
00:04:33हर हिस्सा एक ही काम करता है और दूसरों के साथ गुंथा हुआ नहीं होता।
00:04:36उन्होंने "आसान" (Easy) को परिभाषित किया जो पास में हो, जो पहुंच के भीतर हो।
00:04:39जिसे आप बिना मेहनत के हासिल कर सकें।
00:04:41कॉपी करो, पेस्ट करो और शिप कर दो।
00:04:43सरलता संरचना के बारे में है।
00:04:45आसानी निकटता के बारे में है।
00:04:48बात यह है कि हम किसी चीज को सिर्फ चाहने भर से सरल नहीं बना सकते।
00:04:51सरलता के लिए सोच, डिजाइन और उलझनों को सुलझाने की जरूरत होती है।
00:04:54लेकिन हम किसी चीज को हमेशा आसान बना सकते हैं।
00:04:56बस उसे करीब ले आओ।
00:04:57एक पैकेज इंस्टॉल करें, AI से जनरेट करें, या स्टैक ओवरफ़्लो से कोई समाधान कॉपी कर लें।
00:05:03आसान रास्ता चुनना मानवीय स्वभाव है।
00:05:06हमारा दिमाग इसी तरह बना है।
00:05:07जैसा कि मैंने कहा, स्टैक ओवरफ़्लो से कुछ कॉपी करना आसान है क्योंकि वह ठीक सामने है।
00:05:10एक ऐसा फ्रेमवर्क जो जादू की तरह सब कुछ संभाल ले, बस इंस्टॉल करें और शुरू हो जाएं।
00:05:14लेकिन आसान का मतलब सरल नहीं होता।
00:05:15आसान का मतलब है कि आप अपने सिस्टम में जल्दी से चीजें जोड़ सकते हैं।
00:05:18सरल का मतलब है कि आपने जो काम किया है उसे आप समझ सकते हैं।
00:05:20हर बार जब हम आसान को चुनते हैं, तो हम आज गति चुन रहे होते हैं और भविष्य के लिए जटिलता।
00:05:24और सच कहें तो, यह समझौता पहले काम कर जाता था।
00:05:27हमारे कोड बेस में जटिलता इतनी धीरे जमा होती थी कि
00:05:31जरूरत पड़ने पर हम उसे रिफैक्टर, दोबारा सोच और दोबारा बना सकते थे।
00:05:34मुझे लगता है कि AI ने उस संतुलन को खत्म कर दिया है।
00:05:36क्योंकि यह सबसे बड़ा "आसान बटन" है।
00:05:37यह आसान रास्ते को इतना
00:05:38रुकावट-रहित बना देता है कि हम अब सरल रास्ते के बारे में सोचते तक नहीं हैं।
00:05:41जब कोड तुरंत सामने आ जाता है, तो आर्किटेक्चर के बारे में क्यों सोचना?
00:05:44तो चलिए मैं आपको दिखाता हूँ कि यह कैसे होता है।
00:05:47कैसे एक साधारण काम जटिलता के जाल में बदल जाता है
00:05:50उस संवादात्मक इंटरफ़ेस के जरिए जिसे हम सभी प्यार करने लगे हैं।
00:05:52यह एक बनावटी उदाहरण है, लेकिन मान लीजिए हमारा एक ऐप है,
00:05:55हम उसमें कुछ ऑथेंटिकेशन जोड़ना चाहते हैं।
00:05:57हम कहते हैं "auth जोड़ो", तो हमें एक अच्छी और साफ auth.js फाइल मिल जाती है।
00:06:01उसे कुछ बार दोहराते हैं, तो वह पाँच मैसेज देता है।
00:06:02आप सोचते हैं, ठीक है, अब हम OAuth भी जोड़ेंगे,
00:06:04क्योंकि अब हमारे पास एक auth.js और एक OAuth.js है।
00:06:07हम काम जारी रखते हैं, और पाते हैं कि सेशन्स खराब हो गए हैं।
00:06:11और हमें बहुत सारे कंफ्लिक्ट्स मिलते हैं।
00:06:12और जब तक आप 20वें स्टेप तक पहुँचते हैं, तब तक आप वास्तव में चर्चा नहीं कर रहे होते।
00:06:15आप उन संदर्भों (contexts) को संभाल रहे होते हैं जो इतने जटिल हो गए हैं कि आपको खुद भी याद नहीं रहता
00:06:18कि आपने उसमें क्या-क्या पाबंदियाँ जोड़ी थीं।
00:06:20छोड़े गए तरीकों का बेकार कोड (dead code)।
00:06:22वो टेस्ट जिन्हें बस किसी तरह चलाने के लिए ठीक कर दिया गया।
00:06:25तीन अलग-अलग समाधानों के टुकड़े क्योंकि अंत में आप कहते हैं, "अरे, रुकिए।"
00:06:28हर नया निर्देश आर्किटेक्चरल पैटर्न्स को मिटा रहा होता है।
00:06:31हमने कहा यहाँ ऑथेंटिकेशन चलाओ, उसने कर दिया।
00:06:33जब हमने कहा इस एरर को ठीक करो, उसने कर दिया।
00:06:35गलत आर्किटेक्चरल फैसलों का कोई विरोध नहीं होता।
00:06:38कोड बस आपकी ताज़ा फरमाइश को पूरा करने के लिए बदल जाता है।
00:06:40हर बातचीत सरल के बजाय आसान को चुन रही है।
00:06:43और आसान का मतलब हमेशा अधिक जटिलता होता है।
00:06:46हम जानते हैं कि क्या बेहतर है, लेकिन जब आसान रास्ता इतना ही आसान हो, तो हम उसे अपना लेते हैं।
00:06:50और जटिलता तब तक बढ़ती रहेगी जब तक बहुत देर न हो जाए।
00:06:52AI वाकई "आसानी" को उसके चरम तक ले जाता है।
00:06:58तय करें कि आप क्या चाहते हैं, और तुरंत कोड पाएं।
00:07:00लेकिन इसमें एक खतरा है।
00:07:02जनरेट किया गया कोड आपके कोड बेस के हर पैटर्न को एक समान मानता है।
00:07:06जब कोई एजेंट आपके कोड बेस का विश्लेषण करता है, तो हर लाइन सुरक्षित रखने वाला एक पैटर्न बन जाती है।
00:07:10लाइन 47 पर जो ऑथेंटिकेशन चेक है, वह एक पैटर्न है।
00:07:13वह अजीब सा GRPC कोड जो GraphQL जैसा काम कर रहा है जिसे मैंने शायद 2019 में जोड़ा था,
00:07:18वह भी एक पैटर्न है।
00:07:19तकनीकी कर्ज (technical debt) कर्ज के रूप में दर्ज नहीं होता, वह बस और अधिक कोड बन जाता है।
00:07:22यहाँ असली समस्या जटिलता है।
00:07:25मैं जानता हूँ कि मैं इस टॉक में बिना परिभाषित किए बार-बार उस शब्द का इस्तेमाल कर रहा हूँ।
00:07:29लेकिन इसके बारे में सोचने का सबसे अच्छा तरीका यह है कि यह सरलता का उल्टा है।
00:07:31इसका सीधा सा मतलब है "आपस में गुंथा हुआ"।
00:07:33और जब चीजें जटिल होती हैं, तो हर चीज हर दूसरी चीज को छूती है।
00:07:36आप दस अन्य चीजों को प्रभावित किए बिना एक चीज नहीं बदल सकते।
00:07:41तो वापस फ्रेड ब्रुक्स के "नो सिल्वर बुलेट" पेपर पर आते हैं।
00:07:43उसमें उन्होंने बताया था कि हर सिस्टम में मुख्य रूप से दो तरह की जटिलता होती है।
00:07:47एक है "अनिवार्य जटिलता" (essential complexity), जो वास्तव में उस वास्तविक समस्या की
00:07:51बुनियादी कठिनाई है जिसे आप हल करने की कोशिश कर रहे हैं।
00:07:53यूजर्स को भुगतान करना होगा, ऑर्डर्स पूरे होने चाहिए।
00:07:56यह वह जटिलता है जिसके लिए आपका सॉफ्टवेयर सिस्टम वास्तव में मौजूद है।
00:08:00और दूसरा, यह "आकस्मिक जटिलता" (accidental complexity) का विचार है।
00:08:03बाकी सब कुछ जो हमने रास्ते में जोड़ा है, जैसे वर्कअराउंड्स, प्रोटेक्टिव कोड,
00:08:06फ्रेमवर्क्स, और वो एब्स्ट्रैक्शंस जो कुछ समय पहले सही लगते थे।
00:08:09यह वह सब सामान है जिसे हमने कोड को काम करने लायक बनाने के लिए इकट्ठा किया है।
00:08:11एक वास्तविक कोड बेस में, ये दोनों तरह की जटिलताएं हर जगह होती हैं।
00:08:16और वे आपस में इतनी उलझ जाती हैं कि उन्हें अलग करने के लिए संदर्भ,
00:08:19इतिहास और अनुभव की जरूरत होती है।
00:08:20AI द्वारा जनरेट किया गया आउटपुट ऐसा कोई भेद नहीं करता।
00:08:24और इसलिए हर पैटर्न सुरक्षित बना रहता है।
00:08:26यहाँ नेटफ्लिक्स में हमारे द्वारा किए जा रहे काम का एक वास्तविक उदाहरण है।
00:08:32मेरे पास एक सिस्टम है जिसमें एक एब्स्ट्रैक्शन लेयर है जो हमारे पुराने
00:08:35ऑथराइजेशन कोड (जो हमने करीब 5 साल पहले लिखा था) और एक नए सेंट्रलाइज्ड ऑथ सिस्टम के बीच है।
00:08:41हमारे पास अपने पूरे ऐप को दोबारा बनाने का समय नहीं था, इसलिए
00:08:42हमने बस बीच में एक जोड़ (shim) लगा दिया।
00:08:44तो अब हमारे पास AI है, नए सिस्टम का सीधे उपयोग करने के लिए अपने कोड को रिफैक्टर करने का यह एक शानदार मौका है,
00:08:47यह एक साधारण अनुरोध लगता है, है ना?
00:08:50पर नहीं, पुराना कोड अपने ऑथराइजेशन पैटर्न से इतना मजबूती से जुड़ा हुआ था,
00:08:56जैसे हमारे पास बिजनेस लॉजिक में गुंथे हुए परमिशन चेक थे,
00:08:59डेटा मॉडल में रची-बसी रोल की धारणाएं थीं, और सैकड़ों फाइलों में फैले ऑथ कॉल्स थे,
00:09:03एजेंट रिफैक्टरिंग शुरू करता, कुछ फाइलों तक पहुँचता, और
00:09:07ऐसी डिपेंडेंसी का सामना करता जिसे वह सुलझा नहीं पाता था, और फिर वह नियंत्रण से बाहर होकर हार मान लेता।
00:09:10या इससे भी बुरा, वह पुराने सिस्टम के कुछ मौजूदा लॉजिक को बनाए रखने की कोशिश करता
00:09:16और नए सिस्टम का उपयोग करके उसे दोबारा बनाने लगता, जो मुझे लगता है कि बिल्कुल भी सही नहीं है।
00:09:19बात यह है कि, वह उन जोड़ों (seams) को नहीं देख सका।
00:09:23वह यह पहचान नहीं सका कि बिजनेस लॉजिक कहाँ खत्म हुआ और ऑथ लॉजिक कहाँ शुरू हुआ।
00:09:26सब कुछ इतना उलझा हुआ था कि पूरी जानकारी होने के बावजूद,
00:09:30AI कोई साफ रास्ता नहीं ढूंढ सका।
00:09:33जब आपकी आकस्मिक जटिलता इतनी उलझ जाती है,
00:09:35तो उसे बेहतर बनाने में AI कोई खास मदद नहीं कर पाता।
00:09:38मैंने पाया है कि यह केवल ऊपर से और परतें ही जोड़ता है।
00:09:40हम फर्क बता सकते हैं, या कम से कम तब बता सकते हैं जब हम सोचने के लिए पर्याप्त समय लें।
00:09:45हम जानते हैं कि कौन से पैटर्न अनिवार्य हैं और
00:09:47कौन से सिर्फ इसलिए हैं क्योंकि किसी ने उन्हें कुछ साल पहले वैसे ही हल किया था।
00:09:50हमारे पास वह संदर्भ होता है जिसे AI नहीं समझ सकता, लेकिन
00:09:53तभी जब हम काम शुरू करने से पहले इन अंतरों को समझने का समय निकालें।
00:09:56तो आप वास्तव में इसे कैसे करते हैं?
00:10:01जब आप एक विशाल कोड बेस को देख रहे हों, तो आप आकस्मिक और अनिवार्य जटिलता को कैसे अलग करते हैं?
00:10:04नेटफ्लिक्स में मैं जिस कोड बेस पर काम करता हूँ उसमें जावा की लगभग दस लाख लाइनें हैं, और
00:10:07उसकी मुख्य सर्विस में पिछली बार जाँच करने पर लगभग पचास लाख टोकन थे।
00:10:10मेरे पास ऐसा कोई कॉन्टेक्स्ट विंडो नहीं है जो इसे संभाल सके।
00:10:13इसलिए जब मैं इस पर काम करना चाहता था, तो मैंने पहले सोचा,
00:10:17कि शायद मैं इस कोड बेस के बड़े हिस्सों को कॉन्टेक्स्ट में कॉपी कर सकता हूँ और
00:10:19देख सकता हूँ कि क्या पैटर्न उभर कर सामने आते हैं,
00:10:23यह देखने के लिए कि क्या वह खुद ही समझ पाएगा कि क्या हो रहा है।
00:10:24और ठीक पिछले ऑथराइजेशन रिफैक्टर की तरह ही,
00:10:26आउटपुट अपनी ही जटिलता में खो गया।
00:10:29इसका परिणाम यह हुआ कि आउटपुट अपनी ही जटिलता में उलझ कर रह गया।
00:10:31इस वजह से मुझे कुछ अलग करने पर मजबूर होना पड़ा।
00:10:34मुझे चुनना पड़ा कि क्या शामिल करना है: डिज़ाइन डॉक्स, आर्किटेक्चर, डायग्राम, और भी बहुत कुछ।
00:10:37मुख्य इंटरफेस, आप जो भी कहें।
00:10:39और घटकों को कैसे इंटरैक्ट करना चाहिए और किन पैटर्न्स का पालन करना चाहिए, इसकी आवश्यकताओं को लिखने में समय लगा।
00:10:42देखा जाए तो, मैं एक 'स्पेक' (विवरण) लिख रहा था।
00:10:4350 लाख टोकन घटकर केवल 2,000 शब्दों का विवरण बन गए।
00:10:45और फिर इसे एक कदम और आगे ले जाते हुए, उस स्पेक का उपयोग करके
00:10:49कोड निष्पादित करने के लिए चरणों का एक सटीक सेट तैयार किया।
00:10:52कोई अस्पष्ट निर्देश नहीं, बस ऑपरेशंस का एक सटीक क्रम।
00:10:55मैंने पाया कि इससे बहुत साफ़-सुथरा और केंद्रित कोड तैयार हुआ जिसे मैं समझ सकता था।
00:10:58इसलिए मैंने इसे पहले परिभाषित किया, और इसके निष्पादन की योजना बनाई।
00:11:02यही वह दृष्टिकोण बना जिसे मैंने कुछ समय पहले "कॉन्टेक्स्ट कम्प्रेशन" कहा था।
00:11:05लेकिन आप इसे कॉन्टेक्स्ट इंजीनियरिंग कहें, या स्पेक्ट्रा इन डेवलपमेंट, जो भी आप चाहें।
00:11:11नाम से कोई फर्क नहीं पड़ता।
00:11:13महत्वपूर्ण केवल यह है कि सोच-विचार और योजना बनाना ही काम का मुख्य हिस्सा बन जाता है।
00:11:15तो चलिए मैं आपको बताता हूँ कि यह व्यावहारिक रूप से कैसे काम करता है।
00:11:16तो हमारे पास है पहला चरण: शोध।
00:11:20मैं शुरुआत में ही सब कुछ इसमें डाल देता हूँ।
00:11:22आर्किटेक्चर डायग्राम, दस्तावेज़, स्लैक थ्रेड्स।
00:11:26मतलब, हम इस पर कई बार चर्चा कर चुके हैं।
00:11:28लेकिन वास्तव में जितना हो सके उतना संदर्भ (कॉन्टेक्स्ट) लाएँ जो आपके द्वारा किए जा रहे बदलावों के लिए प्रासंगिक हो।
00:11:31और फिर कोडबेस का विश्लेषण करने और कंपोनेंट्स एवं डिपेंडेंसीज़ का नक्शा बनाने के लिए एजेंट का उपयोग करें।
00:11:32यह एक बार में होने वाली प्रक्रिया नहीं होनी चाहिए।
00:11:35मुझे गहराई से सवाल पूछना पसंद है, जैसे कि "कैशिंग के बारे में क्या?"
00:11:36"यह विफलताओं को कैसे संभालता है?"
00:11:39और जब इसका विश्लेषण गलत होता है, तो मैं इसे सुधारता हूँ।
00:11:42और अगर इसमें संदर्भ की कमी होती है, तो मैं उसे प्रदान करता हूँ।
00:11:43प्रत्येक दोहराव इसके विश्लेषण को और बेहतर बनाता है।
00:11:46यहाँ आउटपुट एक एकल शोध दस्तावेज़ होता है।
00:11:47कि क्या मौजूद है, क्या किससे जुड़ा है,
00:11:49और आपके बदलाव से क्या प्रभावित होगा।
00:11:51घंटों की खोजबीन मिनटों की रीडिंग में सिमट जाती है।
00:11:55मुझे पता है कि डेक्स ने आज सुबह इसका ज़िक्र किया था, लेकिन यहाँ मानवीय जाँच (ह्यूमन चेकपॉइंट) बहुत महत्वपूर्ण है।
00:11:57यही वह जगह है जहाँ आप वास्तविकता के खिलाफ विश्लेषण की पुष्टि करते हैं,
00:11:59पूरी प्रक्रिया में यह सबसे प्रभावशाली क्षण है।
00:12:01यहाँ गलतियाँ पकड़ें और बाद की आपदाओं को रोकें।
00:12:03अब दूसरे चरण पर चलते हैं।
00:12:09अब जब आपके हाथ में कुछ ठोस शोध है,
00:12:12तो हम एक विस्तृत कार्यान्वयन योजना (इम्प्लीमेंटेशन प्लान) बनाते हैं: वास्तविक कोड संरचना,
00:12:15फंक्शन सिग्नेचर, टाइप डेफिनिशन और डेटा फ्लो।
00:12:17आप इसे ऐसा बनाना चाहते हैं कि कोई भी डेवलपर इसका पालन कर सके।
00:12:20मैं इसकी तुलना "पेंट बाय नंबर्स" से करता हूँ।
00:12:22आपको इसे अपने सबसे जूनियर इंजीनियर को सौंपने में सक्षम होना चाहिए और कहना चाहिए, "इसे करो।"
00:12:25और अगर वे इसे लाइन-दर-लाइन कॉपी करते हैं, तो इसे बस काम करना चाहिए।
00:12:28इसी चरण में हम कई महत्वपूर्ण आर्किटेक्चरल निर्णय लेते हैं।
00:12:30सुनिश्चित करें कि जटिल लॉजिक सही है।
00:12:32सुनिश्चित करें कि व्यावसायिक आवश्यकताएं अच्छी प्रथाओं का पालन कर रही हैं।
00:12:35सुनिश्चित करें कि अच्छी सर्विस बाउंड्रीज़ और स्पष्ट अलगाव है, ताकि
00:12:38अनावश्यक कपलिंग को रोका जा सके।
00:12:43हम समस्याओं को होने से पहले ही पहचान लेते हैं क्योंकि हमने उन्हें अनुभव किया है।
00:12:45AI के पास वह विकल्प नहीं है।
00:12:50वह हर पैटर्न को एक आवश्यकता की तरह मानता है।
00:12:52इस चरण का असली जादू रिव्यू की गति में है।
00:12:54हम मिनटों में इस योजना की पुष्टि कर सकते हैं और जान सकते हैं कि वास्तव में क्या बनने वाला है।
00:12:57और जिस गति से हम कोड जेनरेट करना चाहते हैं, उसके साथ तालमेल बिठाने के लिए,
00:12:59हमें उतनी ही तेज़ी से यह समझने में सक्षम होना होगा कि हम क्या कर रहे हैं।
00:13:01अंत में, हमारे पास कार्यान्वयन (इम्प्लीमेंटेशन) है, और अब जब हमारे पास एक स्पष्ट योजना है
00:13:05और स्पष्ट शोध का आधार है, तो यह चरण काफी सरल होना चाहिए।
00:13:10और यही मुख्य बात है।
00:13:13जब AI के पास पालन करने के लिए एक स्पष्ट स्पेसिफिकेशन होता है, तो कॉन्टेक्स्ट साफ़ और केंद्रित रहता है।
00:13:18हमने लंबी बातचीत की जटिलता के चक्र को रोक दिया है।
00:13:22और 50 मैसेजेस वाले क्रमिक कोड के बजाय,
00:13:26हमारे पास तीन केंद्रित आउटपुट हैं, जिनमें से प्रत्येक को आगे बढ़ने से पहले सत्यापित किया गया है।
00:13:28कोई छोड़े हुए दृष्टिकोण नहीं, कोई परस्पर विरोधी पैटर्न नहीं,
00:13:31और कोई "अरे रुको" वाले पल नहीं जो हर जगह बेकार कोड छोड़ देते हैं।
00:13:32मेरे लिए, इसका असली फायदा यह है कि आप इस काम के बड़े हिस्से को करने के लिए बैकग्राउंड एजेंट का उपयोग कर सकते हैं,
00:13:36क्योंकि आपने सारा सोच-विचार और कठिन परिश्रम पहले ही कर लिया है।
00:13:38वह बस कार्यान्वयन शुरू कर सकता है, आप किसी और चीज़ पर काम कर सकते हैं, और
00:13:41वापस आकर रिव्यू कर सकते हैं।
00:13:44और आप इसे जल्दी रिव्यू कर सकते हैं क्योंकि आप बस यह पुष्टि कर रहे हैं कि यह आपकी योजना के अनुरूप है,
00:13:48न कि यह समझने की कोशिश कर रहे हैं कि कहीं कुछ नया तो नहीं गढ़ दिया गया।
00:13:52यहाँ बात यह है कि हम AI का उपयोग अपने लिए सोचने के लिए नहीं कर रहे हैं।
00:13:56हम इसे यांत्रिक (मेकेनिकल) हिस्सों को गति देने के लिए उपयोग कर रहे हैं
00:13:59ताकि इसे समझने की हमारी क्षमता बनी रहे।
00:14:01शोध तेज़ है, योजना अधिक विस्तृत है, और कार्यान्वयन साफ़-सुथरा है।
00:14:04हालाँकि, सोच-विचार, संश्लेषण (सिंथेसिस) और निर्णय लेने का काम हमारा ही रहता है।
00:14:07तो, याद है वह ऑथराइज़ेशन रिफैक्टर जिसके बारे में मैंने कहा था कि AI उसे नहीं संभाल सकता?
00:14:12बात यह है कि अब हम वास्तव में उस पर काम कर रहे हैं और
00:14:15उसमें अच्छी प्रगति कर रहे हैं।
00:14:17इसका कारण यह नहीं है कि हमें बेहतर प्रॉम्प्ट मिल गए हैं।
00:14:21हमने पाया कि हम सीधे शोध, योजना और कार्यान्वयन में कूद ही नहीं सकते थे।
00:14:26हमें वास्तव में यह बदलाव खुद अपने हाथों से करना पड़ा।
00:14:34बिना AI के, बस कोड पढ़ना, डिपेंडेंसीज़ को समझना और यह देखने के लिए बदलाव करना कि क्या बिगड़ता है।
00:14:37वह मैन्युअल माइग्रेशन, सच कहूँ तो, काफी कष्टदायक था, लेकिन वह अत्यंत महत्वपूर्ण था।
00:14:39उसने उन सभी छिपी हुई बाधाओं को उजागर किया, किन नियमों का पालन करना ज़रूरी था,
00:14:42और अगर ऑथराइज़ेशन बदला तो कौन सी सेवाएँ बाधित होंगी।
00:14:45ऐसी चीज़ें जो कोई भी कोड विश्लेषण हमारे लिए सतह पर नहीं ला पाता।
00:14:46और फिर हमने उस मैन्युअल माइग्रेशन की पुल रिक्वेस्ट को अपनी शोध प्रक्रिया में डाला
00:14:49और भविष्य के किसी भी शोध के लिए इसे एक बीज (सीड) के रूप में इस्तेमाल किया।
00:14:52तब AI देख सका कि एक साफ़-सुथरा माइग्रेशन कैसा दिखता है।
00:14:53बात यह है कि इनमें से प्रत्येक इकाई थोड़ी अलग है, इसलिए हमें जाकर
00:14:59उससे सवाल पूछने पड़ते हैं कि, "हे, इसके बारे में हम क्या करें?"
00:15:02कुछ चीज़ें एन्क्रिप्टेड हैं, कुछ नहीं।
00:15:05हमें बार-बार दोहराव के माध्यम से हर बार वह अतिरिक्त संदर्भ देना पड़ा।
00:15:09तब, और केवल तभी, हम एक ऐसी योजना तैयार कर सके जो शायद एक बार में काम कर जाए।
00:15:14और यहाँ "शायद" ही मुख्य शब्द है, क्योंकि हम अभी भी पुष्टि कर रहे हैं,
00:15:19अभी भी समायोजन कर रहे हैं, और अभी भी नए मामलों (एज केसेस) की खोज कर रहे हैं।
00:15:23यह तीन चरणों वाला दृष्टिकोण कोई जादू नहीं है।
00:15:27यह केवल इसलिए काम करता है क्योंकि हमने वह एक माइग्रेशन हाथ से किया।
00:15:29हमें उस समझ को अपनी प्रक्रिया में शामिल करने से पहले उसे खुद मेहनत करके हासिल करना पड़ा।
00:15:32मुझे अब भी लगता है कि कोई जादुई समाधान (सिल्वर बुलेट) नहीं है।
00:15:35मुझे नहीं लगता कि बेहतर प्रॉम्प्ट, बेहतर मॉडल या बेहतर स्पेक्स लिखना ही समाधान है।
00:15:41बस अपने सिस्टम को इतनी गहराई से समझने की ज़रूरत है कि आप उसमें सुरक्षित रूप से बदलाव कर सकें।
00:15:45तो आखिर यह सब क्यों किया जाए?
00:15:47AI के साथ तब तक दोहराव क्यों न करें जब तक वह काम न कर जाए?
00:15:55अंततः मॉडल इतने शक्तिशाली हो जाएंगे कि यह बस काम करेगा।
00:15:57मेरे लिए, सिर्फ "काम कर जाना" ही काफी नहीं है।
00:16:01उस कोड में अंतर है जो टेस्ट पास करता है और उस कोड में जो प्रोडक्शन में टिकता है।
00:16:02उन प्रणालियों के बीच जो आज काम करती हैं और
00:16:06उन प्रणालियों के बीच जिन्हें भविष्य में कोई और बदल सके।
00:16:09असली समस्या यहाँ ज्ञान की कमी (नॉलेज गैप) है।
00:16:11जब AI सेकंडों में हज़ारों लाइन कोड जेनरेट कर सकता है,
00:16:15तो उसे समझने में आपको घंटों, शायद दिन लग सकते हैं अगर वह जटिल हो।
00:16:18कौन जाने, शायद कभी नहीं, अगर वह वास्तव में बहुत उलझा हुआ हो।
00:16:21यहाँ एक ऐसी बात है जिसके बारे में मुझे नहीं लगता कि अभी बहुत से लोग बात कर रहे हैं।
00:16:24हर बार जब हम जनरेशन की गति के साथ तालमेल बिठाने के लिए सोचना छोड़ देते हैं,
00:16:27तो हम सिर्फ ऐसा कोड नहीं जोड़ रहे होते जिसे हम नहीं समझते।
00:16:28हम समस्याओं को पहचानने की अपनी क्षमता भी खो रहे होते हैं।
00:16:31वह अंतर्ज्ञान जो कहता है, "अरे, यह जटिल होता जा रहा है,"
00:16:34वह कमज़ोर पड़ जाता है जब आप अपने ही सिस्टम को नहीं समझते।
00:16:38पैटर्न की पहचान अनुभव से आती है।
00:16:41जब मैं किसी खतरनाक आर्किटेक्चर को पहचानता हूँ,
00:16:45तो इसलिए क्योंकि मैं ही वह व्यक्ति हूँ जो रात के तीन बजे उसे ठीक कर रहा होता हूँ।
00:16:48जब मैं सरल समाधानों पर ज़ोर देता हूँ,
00:16:52तो इसलिए क्योंकि मुझे किसी और के बनाए जटिल विकल्पों को बनाए रखना पड़ा है।
00:16:56AI वही जेनरेट करता है जो आप उससे मांगते हैं।
00:16:58यह पिछली विफलताओं से मिले सबक को शामिल नहीं करता।
00:17:00तीन चरणों वाला दृष्टिकोण इसी अंतर को पाटता है।
00:17:03यह समझ को ऐसे दस्तावेज़ों में समेट देता है जिन्हें हम जनरेशन की गति से रिव्यू कर सकें।
00:17:09इसके बिना, हम बस उतनी तेज़ी से जटिलता जमा कर रहे हैं जितनी तेज़ी से हम उसे समझ भी नहीं सकते।
00:17:11AI कोड लिखने के हमारे तरीके के बारे में सब कुछ बदल देता है, लेकिन ईमानदारी से,
00:17:12मुझे नहीं लगता कि यह इस बारे में कुछ भी बदलता है कि सॉफ्टवेयर खुद विफल क्यों होता है।
00:17:16हर पीढ़ी ने अपने सॉफ्टवेयर संकट का सामना किया है।
00:17:17डाइक्स्ट्रा की पीढ़ी ने सॉफ्टवेयर इंजीनियरिंग का अनुशासन बनाकर इसका सामना किया,
00:17:21और अब हम अनंत कोड जनरेशन के साथ अपने संकट का सामना कर रहे हैं।
00:17:23मुझे नहीं लगता कि समाधान कोई दूसरा टूल या कार्यप्रणाली है।
00:17:25यह याद रखना है जो हम हमेशा से जानते हैं, कि सॉफ्टवेयर बनाना एक मानवीय प्रयास है।
00:17:29कठिन हिस्सा कभी भी कोड टाइप करना नहीं था।
00:17:33यह जानना था कि आखिर टाइप क्या करना है।
00:17:37जो डेवलपर्स कामयाब होंगे वे सिर्फ वे नहीं होंगे जो सबसे ज़्यादा कोड जेनरेट करते हैं।
00:17:39वे वे होंगे जो समझते हैं कि वे क्या बना रहे हैं,
00:17:44जो अभी भी बारीकियों को देख सकते हैं, जो पहचान सकते हैं कि वे गलत समस्या का समाधान कर रहे हैं।
00:17:47वह काम अभी भी हमारा है।
00:17:50वह काम सिर्फ हमारा ही रहेगा।
00:17:54मैं एक सवाल के साथ अपनी बात समाप्त करना चाहता हूँ, और मुझे नहीं लगता कि सवाल यह है कि
00:17:56क्या हम AI का उपयोग करेंगे या नहीं।
00:18:01यह तो तय हो चुका है।
00:18:05समय आगे बढ़ चुका है।
00:18:06मेरे लिए, सवाल यह होगा कि क्या हम तब भी अपने सिस्टम को समझ पाएंगे
00:18:09जब AI हमारा अधिकांश कोड लिख रहा होगा।
00:18:13धन्यवाद।
00:18:15>> [तालियाँ]
00:18:18[संगीत]
00:18:19Eso seguimos siendo nosotros.
00:18:20Eso solo seremos nosotros.
00:18:21Quiero terminar con una pregunta, y no creo que la pregunta sea si
00:18:25usaremos o no la IA.
00:18:26Esa es una conclusión inevitable.
00:18:28El barco ya ha zarpado.
00:18:30Para mí, la pregunta será si seguiremos entendiendo nuestros propios sistemas
00:18:33cuando la IA esté escribiendo la mayor parte de nuestro código.
00:18:35Gracias.
00:18:37>> [APLAUSOS]
00:18:39[MÚSICA]