एजेंटिक कोडिंग: इंडस्ट्री के लीडर के साथ राउंडटेबल डिस्कशन

नमस्ते दोस्तो.

आपने इस हफ़्ते या पिछले दो दिनों में, Android पर काम करने वाले Google के कई कर्मचारियों से सुना होगा.

इसलिए, हमने सोचा कि कॉन्फ़्रेंस को खत्म करने से पहले, Android डेवलपर कम्यूनिटी के कुछ लोगों से बात की जाए.

हम एजेंटिक कोडिंग और असल दुनिया पर इसके असर के बारे में बात करेंगे.

सबसे पहले हम अपना परिचय देंगे.

मेरा नाम बेन है और मैं Android DevRel टीम में हूं.

इस कॉन्फ़्रेंस में, आपने पहले ही मेरी बात सुन ली है. हालांकि, चलिए पैनल में शामिल अन्य लोगों से बात करते हैं.

नमस्ते दोस्तों.

मेरा नाम विनय है और मैं Databricks में एआई टूलिंग से जुड़े कामों में मदद करता हूं.

मुझे यहां आकर बहुत खुशी हो रही है.

नमस्ते, मैं लुइस आर्टोला हूं.

मैं Google Maps के लिए काम करता हूं.

मैं उन टीमों का नेतृत्व करता/करती हूं जो एजेंटिक अनुभव बनाने और सॉफ़्टवेयर डेवलपमेंट साइकल को बेहतर बनाने के लिए, एआई का इस्तेमाल करती हैं.

नमस्ते, मैं अनीस डेविस हूं.

मैं Ford में काम करता हूं.

मैं उन इंजीनियरिंग टीमों का नेतृत्व करता हूं जो सदस्यता और लॉयल्टी से जुड़े प्रॉडक्ट डेवलप करती हैं.

नमस्ते दोस्तों.

मेरा नाम टाई स्मिथ है.

मैं Uber में काम करती हूं और हमारे डेवलपर की मदद करती हूं.

यह काफ़ी समय से मोबाइल पर उपलब्ध है.

पिछले कुछ सालों में, हमारा ज़्यादा फ़ोकस एआई टूल के इस नए और रोमांचक दौर पर रहा है.

नमस्ते दोस्तों.

मेरा नाम कौशिक गोपाल है.

मैं Instacart में प्रिंसिपल इंजीनियर के तौर पर काम करता हूं. मैंने Android डेवलपमेंट पर Fragmented नाम का पॉडकास्ट शुरू किया है.

जैसा कि टाई ने बताया, आजकल हमने अपनी रणनीतियों में थोड़ा बदलाव किया है. हम एआई के डेवलपमेंट के बारे में बात करते हैं.

ठीक है।

इसलिए, हमारे पास 30 मिनट हैं.

मुझे लगता है कि यह सेशन बहुत तेज़ी से आगे बढ़ेगा. इसलिए, हम सीधे मुश्किल सवालों पर आते हैं.

Android DevRel में, हमने हमेशा कहा है कि हम ऐप्लिकेशन बनाने की प्रोसेस को तेज़ और आसान बनाना चाहते हैं.

अब एआई आ गया है और आपने हमें यहां यह कहते हुए सुना है, "यह वाकई में है.

हमें लगता है कि इससे ऐप्लिकेशन बनाना ज़्यादा तेज़ और आसान हो गया है."

लेकिन मैं यह जानना चाहता हूं कि क्या हम वाकई में ऐप्लिकेशन को तेज़ी से शिप कर रहे हैं या फिर हम सिर्फ़ ऐसा कोड जनरेट कर रहे हैं जो किसी काम का नहीं है?

चलो विनय, शुरू करते हैं.

ठीक है।

हां, हम सब एक-दूसरे को देख रहे हैं.

शानदार.

इसलिए, अगर सिर्फ़ आंकड़ों पर गौर करें, तो हमें साफ़ तौर पर दिखता है कि पीआर और कोड की लाइनों के मामले में, हमें काफ़ी तेज़ी से बढ़ोतरी देखने को मिली है. इस वजह से, हमें कोड को स्टोर करने जैसी चीज़ों को लेकर भी चुनौतियों का सामना करना पड़ रहा है, है न?

इसलिए, यह तेज़ी बहुत मायने रखती है.

हालांकि, यह साफ़ तौर पर नहीं पता है कि इससे नतीजों पर क्या असर पड़ता है. मुझे लगता है कि पूरी इंडस्ट्री यह पता लगाने की कोशिश कर रही है कि नतीजों के लिए सही मेट्रिक क्या है और इससे मुनाफ़े पर क्या असर पड़ता है.

हालांकि, मुझे यह सुविधा काम करती हुई ज़रूर दिखती है.

मुझे लगता है कि हमने पिछले छह महीनों में, उससे पहले की तुलना में ज़्यादा कोड शिप किए हैं. हालांकि, मैं इस बारे में ज़्यादा जानकारी नहीं दूंगा, लेकिन यह बहुत लंबे समय की बात है.

इस वजह से, मुझे लगता है कि प्रॉडक्टिविटी को मेज़र करने की हमारी रणनीति में भी बदलाव हुआ है. क्या ऐसा है?

क्योंकि इसके बारे में सोचने के कई तरीके हैं.

हम यह पता लगाने की कोशिश कर रहे हैं कि मीडियन को कैसे बढ़ाया जाए, है न?

क्योंकि जब आप आउटलायर और मीडियन को देखते हैं, तो लोगों की इन दो कैटगरी के बीच 5 से 10 गुना का अंतर होता है. हमारा फ़ोकस फ़्लोर को बढ़ाना, मीडियन को बढ़ाना, और उन लोगों को उनके आस-पास के साथियों की तरह ही प्रॉडक्टिव बनाना है जो हमें प्रॉडक्टिव लगते हैं.

हमें कई तरह की भूमिकाएं देखने को मिलती हैं.

कुछ लोग बहुत तेज़ी से आगे बढ़ रहे हैं.

कुछ लोग ऐसे हैं जो दिन में 100 पीआर करते हैं और शानदार काम कर रहे हैं.

हालांकि, यह एक ऐसा स्पेस है जिसमें वे काम कर रहे हैं.

शायद वे ज़्यादा ग्रीनफ़ील्ड हैं या वे टूल का इस्तेमाल करने में ज़्यादा माहिर हैं.

हमें ऐसे लोग भी दिखते हैं जो ब्राउनफ़ील्ड या प्लैटफ़ॉर्म पर काम करते हैं. वे अलग तरह के काम करते हैं. शायद वे काम उतनी तेज़ी से नहीं होते, क्योंकि उन्हें इंसानी फ़ैसले के साथ ज़्यादा समय बिताना पड़ता है. साथ ही, यह पक्का करना पड़ता है कि चीज़ें खराब न हों.

इन दोनों के कॉम्बिनेशन से, पहले के मुकाबले काफ़ी तेज़ी से काम हो रहा है. हालांकि, मुझे लगता है कि हमारे लिए असल में दिलचस्प विषय यह है कि भले ही हम ज़्यादा शिपिंग कर रहे हैं, लेकिन क्या कारोबार असल में असली उपयोगकर्ताओं को ज़्यादा शिपिंग कर रहा है?

यह एक ऐसा क्षेत्र है जिसमें हम पिछले साल से निवेश कर रहे हैं. इससे हमें यह समझने में मदद मिलती है कि क्या हम सिर्फ़ कोड ही नहीं, बल्कि सुविधाओं को भी तेज़ी से उपलब्ध करा रहे हैं?

शुरुआती सिग्नल से पता चलता है कि हम ऐसा कर रहे हैं. हालांकि, यह सिर्फ़ पीआर से काफ़ी अलग है.

मुझे लगता है कि जो हुआ है वह बहुत साफ़ है. लोग बहुत ज़्यादा शिप कर रहे हैं. जैसे, पीआर की संख्या बढ़ गई है.

हालांकि, मुझे लगता है कि अभी भी ज़्यादातर लोग यह सोचते हैं कि "हम एआई और अपने पास मौजूद इस टूल का इस्तेमाल करके, मौजूदा प्रोसेस को कैसे बेहतर बना सकते हैं?"

है न?

जैसे, पहले हम जिस तरह से कोड शिप करते थे, उससे ऐसा लगता है कि हम हमेशा किसी इंसान को इस तरह से सोचते थे कि वह इसे प्रोडक्शन तक ले जाएगा.

हालांकि, मुझे लगता है कि अब हम जो देख रहे हैं वह यह है कि हां, यह काम करता है.

हम और डिवाइस शिप कर रहे हैं.

हालांकि, हमें हर उस समस्या का सामना करना पड़ रहा है जो पहले कभी नहीं देखी गई थी, है न?

क्योंकि हमें पहले कभी ऐसी समस्याएं नहीं आईं. हालांकि, अब हम कई चरणों वाले साइकल के एक हिस्से को टर्बोचार्ज कर रहे हैं. मुझे लगता है कि यहीं से यह दिलचस्प हो रहा है. जैसे, "ठीक है.

हम ज़्यादा कॉन्टेंट डिलीवर कर रहे हैं, लेकिन अब यह इफ़ेक्ट की बौछार जैसा है."

इसलिए, हमें अन्य चुनौतियों का सामना करना पड़ रहा है.

यह बहुत दिलचस्प बात है. क्योंकि, जब इस बारे में सोचा जाता है, तो कई अलग-अलग चरण होते हैं. हालांकि, बड़े लेवल पर देखें, तो उन्हें तीन चरणों में बांटा जा सकता है, है न?

कोडिंग की जा रही है, जो साफ़ तौर पर तेज़ी से आगे बढ़ रही है.

ऐप्लिकेशन या गेम, प्रोडक्शन के लिए तैयार है या नहीं, यह कई चीज़ों पर निर्भर करता है. जैसे, कानूनी और निजता से जुड़ी चीज़ें. साथ ही, ऐसी चीज़ें जो आपको कुछ नया करने की अनुमति देती हैं. इसके बाद, लॉन्च करने की बारी आती है, है न?

इसके बाद, शिपिंग का मतलब अलग-अलग जगहों के हिसाब से अलग-अलग होता है, है न?

अगर आपका प्रॉडक्ट पूरी तरह से सर्वर साइड पर है, तो शिपिंग का मतलब ज़्यादा आसान प्रोसेस हो सकता है. वहीं, अगर आपको कोई ऐसा प्रॉडक्ट शिप करना है जो उपभोक्ता के पास जाता है, तो उसे एक्सपेरिमेंट में शामिल करना, सफ़र के बीच में होने जैसा है, है न?

आपको अब भी बहुत सारे एक्सपेरिमेंट और मेज़रमेंट करने होंगे. यह आपकी उस बात से जुड़ा है जिसमें आपने कहा था कि आपको ऐसा लगता है कि आप किसी मेट्रोपॉलिटन एरिया में हैं, फ़्रीवे पर हैं, और आपको चोक पॉइंट मिल गया है. इसके बाद, आप तेज़ी से आगे बढ़ने लगते हैं और आपको लगता है कि "हां, बहुत बढ़िया.

मैं बहुत तेज़ी से आगे बढ़ रहा हूँ," लेकिन अब आपको अगले चोक पॉइंट का सामना करना पड़ता है.

एआई की मदद से, हमें यह साफ़ तौर पर पता चल रहा है कि रुकावटें कहां आ रही हैं. इनमें से कुछ रुकावटों का कोडिंग या टेक्नोलॉजी से कोई लेना-देना नहीं है.

यह प्रोसेस और लोगों से जुड़ा है. साथ ही, यह इस बारे में है कि एआई की मदद से इसे कैसे ऑप्टिमाइज़ किया जाए.

यह एक दिलचस्प चुनौती है कि एंड-टू-एंड प्रोसेस को कैसे आसान बनाया जाए.

हम इस बारे में एक दिलचस्प तरीके से सोच रहे हैं कि किसी व्यक्ति या टीम के पास, प्रॉडक्ट को पूरी तरह से शिप करने की कितनी एजेंसी है?

इसलिए, अगर हम अंदरूनी तौर पर देखें, तो ऐसी कई टीमें हैं जो शायद इंटरनल टूल बना रही हैं या ऐसी चीज़ें बना रही हैं जो ग्राहक को शिप नहीं की जाती हैं.

वे बहुत तेज़ी से शिपिंग कर रहे हैं, है न?

उनके पास अपने ग्राहकों तक तुरंत प्रॉडक्ट पहुंचाने की पूरी सुविधा होती है.

अगर आपके पास कोई बाहरी प्रॉडक्ट है, तो उसे अब भी उपयोगकर्ता के साथ एक्सपेरिमेंट करना होगा. इसके अलावा, आपको ऐप स्टोर के रोल आउट होने के समय या डिज़ाइन और प्रॉडक्ट के साथ काम करने के बारे में पता होना चाहिए. ये सभी अन्य समस्याएं बढ़ती जा रही हैं. साथ ही, कोड लिखने वाले लोगों के पास इस पर तेज़ी से काम करने के लिए बहुत कम एजेंसी है.

इसलिए, वे सिस्टम में मौजूद अन्य समस्याओं को हल करने की कोशिश कर रहे हैं.

इसलिए, मुझे लगता है कि इन दोनों को अलग-अलग हिस्सों में बांटने से, यह पता चलता है कि आपके कारोबार की प्रोसेस को कहां बेहतर बनाया जा सकता है.

हां, मैं सहमत हूं. मुझे लगता है कि इंजीनियरिंग कभी भी रुकावट नहीं थी.

मैं सालों से यह बात कह रहा हूं.

इंजीनियरिंग में काम करने का तरीका काफ़ी व्यवस्थित होता है. कारोबार की तरफ़ से हमेशा यह सवाल पूछा जाता था कि "समस्या क्या है?"

आपको इसके 10 अलग-अलग जवाब मिलेंगे.

इसके बाद, "ठीक है.

अब, प्रॉडक्ट की मदद से इन समस्याओं को हल करने के बारे में बात करते हैं.

अब, चलिए इस बारे में थोड़ा सोचते हैं.

चलिए, अब डिज़ाइन के बारे में थोड़ी बात करते हैं.

इसे वहां किक करो."

जब तक यह इंजीनियरिंग टीम तक पहुंचता है, तब तक हमें पता चल जाता है कि हमें क्या करना है.

इसके बाद, हम Stack Overflow पर जाते हैं और कुछ चीज़ें कॉपी-पेस्ट करके, उन्हें शिप कर देते हैं.

इसलिए, एआई की मदद से मुझे सबसे ज़्यादा तेज़ी से काम करने में मदद मिल रही है. खास तौर पर, नियमों का पालन करने से जुड़े काम में.

जैसे, हम हमेशा से XYZ को आधुनिक बनाना चाहते थे या हम हमेशा से Spring Boot वर्शन को तेज़ी से अपग्रेड करना चाहते थे.

हम यह काम बहुत तेज़ी से कर रहे हैं.

हालांकि, मुझे नहीं लगता कि असल में सुविधाओं की डिलीवरी में कोई खास सुधार हुआ है.

आप सभी ने इस बात पर ज़ोर दिया है कि शायद समस्या अब दूसरी जगह आ गई है. अब आपको ऐसी प्रोसेस में समस्या आ रही है जो पहले समस्या नहीं थी, लेकिन अब है.

हालांकि, ये प्रोसेस शायद पहले मिले सबक से ही बनी हैं, है न?

क्या आपको इन चीज़ों को बदलने का दबाव महसूस हो रहा है? मुझे लगता है कि कोड रिव्यू सबसे अहम है.

कोड रिव्यू का भविष्य कैसा होगा?

फ़िलहाल, हम क्या कर रहे हैं?

इसलिए, मुझे आपके सुझाव जानकर खुशी होगी.

यह बात मेरे उस पॉइंट से जुड़ी है जो मैंने पहले बताया था.

मुझे लगता है कि इनमें से ज़्यादातर रुकावटें इसलिए हैं, क्योंकि हमने सोचा कि अगर आपके पास कोई जादुई छड़ी हो और आपको सॉफ़्टवेयर इंजीनियरिंग को फिर से बनाना हो और आज आपके पास एआई हो, तो क्या हम उसी तरह की चीज़ों का इस्तेमाल करेंगे? क्या हम वही काम करेंगे?

उदाहरण के लिए, कोड की समीक्षा इसलिए की जाती थी, क्योंकि हमें किसी व्यक्ति की ज़रूरत होती थी, ताकि वह चीज़ों को पास कर सके. जैसे, आखिरी बार क्रॉस-चेक करना.

मुझे लगता है कि इसमें भी बदलाव हो रहा है. जैसे, अब हम कोड रिव्यू के बारे में जिस तरह से सोच रहे हैं, शायद हमें इस विचार के लिए तैयार रहना चाहिए कि अगर नाम को रीफ़ैक्टर किया जा रहा है या कोड को रीफ़ैक्टर करने की कोशिश की जा रही है, और आपको पता है कि आपके पास बेहतरीन टेस्ट हैं, जो ज़ाहिर तौर पर सभी के पास होते हैं.

हमने एआई से लिखवाया है, तो कोई बात नहीं.

नहीं, मेरा मतलब है कि क्या आप उस एजेंट से बेहतर काम कर पाएंगे?

मुझे नहीं पता, शायद इसकी समीक्षा करने में समय बर्बाद नहीं करना चाहिए.

इसके अलावा, अगर आपको कोई गड़बड़ी मिलती है और आपको अपने सीईओ का कॉल आता है, जिसमें वे कहते हैं, "अरे, इस गड़बड़ी की वजह से हमें X डॉलर का नुकसान हो रहा है," तो शायद आपको उन जगहों और सिस्टम की पहचान करनी चाहिए जहां, "अरे, यह एक अहम जगह है.

यह कोई ज़रूरी हिस्सा नहीं है." इसके बाद, फिर से कल्पना करने की कोशिश करें.

मुझे नहीं लगता कि आज के समय में हम इस तरह से काम करते हैं, है न?

आज के समय में, "अरे, एक पीआर है.

मैं इंजीनियर हूं.

मेरा ध्यान इस चीज़ पर है.

यह ऊपर की ओर जाएगा.

मैं आधी रात को भी विनय को कोड रिव्यू के लिए परेशान कर देता हूं, क्योंकि मुझे बस इस चीज़ को मर्ज करना होता है."

इसके उलट, शायद हमें इनमें से कई चीज़ों के बारे में फिर से सोचना चाहिए.

मैं पूरी तरह सहमत हूं. मुझे लगता है कि कोड रिव्यू करना, पुष्टि करने से जुड़ी समस्या है. मेरा मतलब है कि अगर मुझे किसी चीज़ की पुष्टि करने की अपनी क्षमता पर पूरा भरोसा है, तो क्या मैं अब भी अपने सभी पीआर के कोड रिव्यू करूंगा?

शायद नहीं, है ना?

इसलिए, कोड रिव्यू के दो मकसद होते हैं.

पहला, यह पुष्टि करना कि हम सही काम कर रहे हैं और दूसरा, शिक्षा. सही है?

जैसे, आपके आस-पास के लोगों को पता होता है कि आप क्या कर रहे हैं और वे आपके फ़ैसले से सहमत हैं या नहीं.

इसलिए, कुछ काम ऐसे हैं जिन्हें हमें तेज़ी से करना चाहिए और यह पक्का करना चाहिए कि वे कोड और रिलीज़ में शामिल हों.

यह बात 100% मामलों पर लागू नहीं होती, लेकिन मुझे लगता है कि यह काफ़ी ज़्यादा मामलों पर लागू होती है.

मुझे लगता है कि हम ये बदलाव करने के लिए तैयार हैं. एक कम्यूनिटी के तौर पर, हम सभी को यह पक्का करना होगा कि हमारे सिस्टम इसके लिए तैयार हों, क्योंकि यह बदलाव होने वाला है.

इससे बचने का कोई तरीका नहीं है.

फ़नल का टॉप लेवल काफ़ी बड़ा होता है. इसमें कई प्लैटफ़ॉर्म होते हैं, जिनकी मदद से ज़्यादा पीआर बनाए जा सकते हैं.

आपकी रफ़्तार, प्रोसेस के सबसे धीमे चरण के बराबर होती है.

कई टीमों के लिए, यह कोड रिव्यू है. तेज़ी से आगे बढ़ने वाली टीमों ने इस सच्चाई को समझ लिया है और स्वीकार कर लिया है.

हां, और अगर हम खुद के साथ ईमानदार रहें, तो मुझे लगता है कि मैंने जितने पीआर देखे हैं उनमें से 70% मुझे अच्छे लगे.

जैसे, अगर हम दुनिया के सभी कोड बेस खोजें, तो पीआर टिप्पणियां सिर्फ़ "मुझे अच्छा लगा", एलजीटीएम, हर जगह होंगी.

इंजीनियरिंग प्रोफ़ेशनल के तौर पर, कभी-कभी हम खुद को ज़रूरत से ज़्यादा क्रेडिट दे देते हैं.

हमें लगता है कि हम इस लिस्ट में शामिल हैं.

"क्या उन्होंने कमांड पैटर्न का इस्तेमाल किया?"

नहीं, हम बस कहते हैं, "ठीक है.

हां, मुझे यह सही लग रहा है."

तो फिर मैं किसी एजेंट से ऐसा क्यों नहीं करा सकता?

मुझे लगता है कि आने वाले समय में, हमें यह देखने को मिलेगा कि मुझे क्या अच्छा लगता है. जैसे, इसकी क्या विशेषताएं हैं, ऐसे कौनसे व्यवहार हैं जिनकी वजह से आपको ऐसा महसूस हुआ?

इसके बाद, पक्का करें कि एजेंट भी उसी चीज़ को खोजे.

इसके अलावा, समीक्षा करने के अलग-अलग तरीकों के बारे में भी सोचें.

जैसे, मुझे उन लोगों के बारे में पता है जो आजकल Twitter पर हैं. वे यह बात कहते हैं, है न?

जैसे, अब पीआर की पुष्टि करते समय, अपने एजेंट से इसे अलग तरीके से विज़ुअलाइज़ करने के लिए कहें, है न?

नमस्ते, मुझे पहले की फ़ोटो दिखाओ.

मुझे बदलाव के बाद की इमेज दिखाओ.

मुझे वे टेस्ट दिखाओ जो तुमने लिखे हैं. मुझे कोड की लाइन-बाय-लाइन समीक्षा नहीं चाहिए.

लेकिन यह चुनौती देता है तुम कुछ कहने वाले थे, लुइस?

नहीं, मुझे लगता है कि यह सोचने पर मजबूर करने वाली बात है, है ना?

इस तरह, हम एक ऐसी स्थिति में पहुंच जाएंगे जहां आपको सीएल या पीआर को बिना किसी मानवीय हस्तक्षेप के पास करने में कोई परेशानी नहीं होगी.

इसलिए, मैं थोड़ा अलग नज़रिया पेश करना चाहूंगा. मेरा मानना है कि जब हम फ़्रिक्शन की बात करते हैं, तो हमें लगता है कि फ़्रिक्शन खराब होता है. हालांकि, फ़्रिक्शन अच्छा और खराब, दोनों तरह का होता है.

मुझे लगता है कि समीक्षाएं अब भी अच्छी रुकावट की कैटगरी में आती हैं.

यह इस बात पर निर्भर करता है कि हम डेवलपर के लिए इसे कितना आसान बनाते हैं, है न?

कभी-कभी, यह इस बारे में नहीं होता कि हम उस समय, उस समीक्षा को बेहतर या ज़्यादा असरदार कैसे बनाएं?

इससे एआई की मदद से, डेवलपमेंट को ज़्यादा सटीक बनाया जा सकता है, है ना?

क्योंकि अगर आप सिर्फ़ एआई का इस्तेमाल करने के तरीके पर निर्भर हैं, जैसे कि अच्छे इनपुट से बेहतर आउटपुट मिलते हैं, लेकिन खराब इनपुट से वाकई खराब आउटपुट मिलते हैं, है न?

इसलिए, मुझे लगता है कि अगर आपको बेहतर नतीजे चाहिए, तो आपको एआई का इस्तेमाल करके प्रोसेस को बेहतर बनाना होगा. इसके लिए, आपको शुरुआत से ही एआई का इस्तेमाल करना होगा. जैसे, आर्किटेक्चर को बेहतर तरीके से समझने के लिए एआई का इस्तेमाल करना, ताकि डेवलपर को कम मेहनत करनी पड़े और कोड की क्वालिटी बेहतर हो.

इस वजह से, डेवलपर को समीक्षाओं के लिए ज़्यादा इंतज़ार नहीं करना पड़ता.

मुझे लगता है कि इस पर ज़्यादा विवाद नहीं होगा, क्योंकि ज़्यादातर लोगों को पता है कि आने वाले समय में, यह सारा कोड बिना किसी मैन्युअल समीक्षा के ही इस्तेमाल किया जाएगा.

मुझे लगता है कि इस दौरान, हम एक ऐसी स्थिति में हैं जहां मॉडल बेहतर हो रहे हैं. हमें इस बात की कम चिंता है कि वे कोई तकनीकी गलती करेंगे. हमें इस बात की ज़्यादा चिंता है कि वे कोई कारोबारी गलती करेंगे या फ़ैसला लेने या आइडिया देने में कोई समस्या होगी.

इसलिए, यह भी सिग्नल में शामिल हो जाता है. हालांकि, समीक्षा के दौरान इसे अलग किया जा सकता है.

जैसे, क्या हमें पीआर में लाइन-दर-लाइन समीक्षा करनी चाहिए या फिर उस मकसद की समीक्षा करनी चाहिए जिसे वे बाद में पुश करने की कोशिश कर रहे हैं?

हम इस बारे में कुछ अलग-अलग तरीकों से सोच रहे हैं.

पहला यह कि हम उपयोगकर्ता को ज़्यादा काम की जानकारी कैसे दें, ताकि वह उसे प्राथमिकता दे सके?

दूसरा यह कि ऐसे कौनसे सुरक्षित क्षेत्र हैं जहां हम एक्सपेरिमेंट कर सकते हैं और इस तरह के प्रोग्राम में तेज़ी से आगे बढ़ सकते हैं?

जैसा कि कौशिक ने कहा, सभी क्षेत्रों में एक जैसी मेहनत की ज़रूरत नहीं होती.

हम इसकी पहचान कर सकते हैं और कुछ को तेज़ी से आगे बढ़ा सकते हैं. साथ ही, जोखिम को कम कर सकते हैं. हालांकि, हमें उन क्षेत्रों को ध्यान में रखना होगा जो ज़्यादा अनुपालन-उन्मुख हैं या जो ज़्यादा घर्षण के साथ बहुत बुनियादी हैं. ऐसा तब तक करना होगा, जब तक हम न सिर्फ़ मॉडल पर, बल्कि उनमें जाने वाले इनपुट पर भी भरोसा करने के बिंदु तक नहीं पहुंच जाते

वे सही फ़ैसले थे.

जैसे, Uber ऐप्लिकेशन में नए Android मॉड्यूल को फिर से बनाना.

सभी Android डेवलपर को मुफ़्त राइड दी जा रही हैं. शायद आप उस कोड को देखना चाहें.

मुझे इस बारे में हमारे सीईओ से बात करनी होगी.

माफ़ करें, कौशिक.

हालांकि, मुझे यह भी लगता है कि इस समस्या को हल किया जा चुका है.

हमारे पास पहले से ही फ़ीचर फ़्लैग मौजूद हैं.

हमारे पास पहले से ही ब्लू-ग्रीन डिप्लॉयमेंट है.

हमारे पास पहले से ही बहुत सारे पीस हैं.

चुनौती यह है कि हम इसे करने में बहुत व्यस्त रहे हैं.

हम पहले से ही व्यवहार को ट्रैक कर रहे हैं.

हमारे पास इस तरह का सारा डेटा है, लेकिन यह अलग-अलग सिस्टम में मौजूद है.

हम पहले से ही घटनाओं को ट्रैक करते हैं.

हमारे पास बहुत सारा डेटा है, लेकिन उसे एक साथ इकट्ठा करके, पूरी जानकारी देना, यह एक ऐसी चीज़ है जो मौजूद नहीं है.

जब हमें यह पता चल जाएगा कि इन सभी अलग-अलग कंपनियों में, इंजीनियरिंग के हिसाब से कॉन्टेक्स्ट सर्विस कैसी दिखती है, तो हमें चिंता करने की ज़रूरत नहीं होगी. ऐसा इसलिए, क्योंकि पीआर मर्ज होने के बाद भी यह सुरक्षित रहेगा.

क्योंकि हमें पता है कि हमने उसे फ़ीचर फ़्लैग के पीछे रखा है.

हमारे पास ब्लू-ग्रीन डिप्लॉयमेंट है.

हमारे पास जांचने की पूरी क्षमता है.

इसके बाद, आपको पूरा भरोसा हो जाएगा कि आप यह कह सकें, "अरे, इसे पाइपलाइन में डाल दो."

अगर कुछ गलत होता है, तो हमारे पास रास्ते में ये सभी गार्ड और गेट हैं.

मुझे लगता है कि जवाब देने की स्पीड भी बहुत मायने रखती है, है न?

अगर आपको पता है, तो चलिए एक मिनट के लिए Android को चुनते हैं. अगर Android में कोई बदलाव किया जा रहा है और उसे Play Store के ज़रिए शिप करना है और फिर उसे आपके उपभोक्ताओं के लिए रोल आउट करना है, तो उसे तुरंत ठीक करने की आपकी क्षमता वाकई कम हो जाती है. इसके मुकाबले, अगर कोई ऐसा काम किया जा रहा है जिसमें अंदरूनी निगरानी के साथ अंदरूनी डिप्लॉयमेंट किया जा रहा है और कोई एजेंट तुरंत उस पर काम कर रहा है, तो आपके पास तेज़ी से आगे बढ़ने के ज़्यादा अवसर होते हैं.

इसलिए, मेरा एक सवाल यह है कि इन ऐप्लिकेशन पर काम करने की ज़रूरत है, लेकिन फिर आपके पास ये ग्रीनफ़ील्ड ऐप्लिकेशन हैं जो आसान हैं. इसके बाद, आपके पास ये ब्राउनफ़ील्ड ऐप्लिकेशन हैं. इसके बाद, ऐसा समय आता है, जब आपको इन जांचों को करने के लिए समय चाहिए होता है, ताकि आप एआई के इस्तेमाल को बढ़ा सकें.

मुझे पता है कि आप में से कई लोग बड़े ऐप्लिकेशन पर काम करते हैं, है न?

इसलिए, मुझे यह जानने में दिलचस्पी है कि इस बारे में आपकी क्या राय है?

क्या ऐसा होता है कि सीईओ से कहा जाए कि मुझे तीन महीने का समय दें, ताकि मैं इस ऐप्लिकेशन को एआई के लिए तैयार कर सकूं? या फिर, हर दिन इसमें कुछ न कुछ जोड़ा जाता है?

हाँ।

वे ऐसा कभी नहीं करते.

मुझे ऐसा नहीं लगता.

मेरा मतलब है कि ज़्यादातर कंपनियों को कभी भी यह सुविधा नहीं मिलेगी.

मुझे लगता है कि हमें इसे उसी तरह से समय देना होगा जैसे हम टेक डेट को देते थे. जैसे, अपने समय का 20% हिस्सा इस पर खर्च करें और उसका 5% हिस्सा प्रॉम्प्ट को बेहतर बनाने में लगाएं.

इसके बाद, यह भी समझें कि प्रॉम्प्ट क्या करता है और कॉन्टेक्स्ट को बेहतर बनाएं.

जैसा कि हम इस बारे में बात कर रहे हैं, मुझे लगता है कि इंजीनियरों को अब भी यह समझ नहीं आया है कि यह कैसे काम करता है.

यह अब भी बहुत जादुई और रहस्यमयी लगता है. इसलिए, वे इसे इस तरह से कॉन्फ़िगर और ट्यून नहीं कर रहे हैं जिससे उन्हें इससे बेहतर वैल्यू और परफ़ॉर्मेंस मिल सके.

इसलिए, मुझे लगता है कि लीडर को यह सोचना चाहिए कि "हमें अपनी टीम को बेहतर बनाने के लिए क्या करना चाहिए, ताकि वे समझ सकें कि यह कैसे काम करता है और फिर हम ज़्यादा फ़ायदा पा सकें?"

यह उसी का एक हिस्सा है.

यह इतनी तेज़ी से बदल रहा है कि अगर मैं किसी टीम को एक हफ़्ते तक ताज़ातरीन चीज़ें सीखने और उन्हें लागू करने के लिए कहूं और फिर उनके पास सीखने या एक्सपेरिमेंट करने के लिए समय न हो, तो अगले साल तक वे नई सुविधाओं से काफ़ी पीछे रह जाएंगे.

इसलिए, हमें यह सब करना होगा. हम एक तरह से, उड़ते हुए विमान को बना रहे हैं. इसमें हम सुरक्षा के लिए रेलिंग लगा रहे हैं, सीख रहे हैं, और चीज़ों के होने के साथ-साथ उनमें बदलाव कर रहे हैं. टीमों को इस पर नज़र रखनी होगी.

बड़े संगठनों में, हमारी कुछ टीमों की तरह ही ऐसी टीमें होती हैं जो उस जानकारी को समझने की कोशिश करती हैं. साथ ही, उसे थोड़ा और ज़्यादा काम का और समझने लायक बनाती हैं.

हालांकि, फ़िलहाल यह इंडस्ट्री में सभी के लिए एक चुनौती है.

मुझे इसमें थोड़ा बदलाव करना है.

आप में से कई लोग डेवलपर इन्फ़्रास्ट्रक्चर में काम करते हैं.

हज़ारों पीआर, क्या आपके टेस्टिंग इन्फ़्रास्ट्रक्चर, आपके सर्वर, सब पिघल रहे हैं?

मुझे युद्ध की कुछ कहानियां सुननी हैं.

Ty?

हां.

वे कमाल कर रहे हैं.

मेरा सीआई हर रात मुझे सुलाने के लिए रोता है.

फ़िलहाल, हमारी डेवलपर इन्फ़्रास्ट्रक्चर टीमों को कंप्यूटिंग और परफ़ॉर्मेंस से जुड़ी समस्याओं का सामना करना पड़ रहा है.

जैसे, कोड रेड की स्थिति.

उन्हें वॉल्यूम में काफ़ी बढ़ोतरी दिखती है.

हम एजेंट के आर्किटेक्चर में बदलाव कर रहे हैं.

हम जल्द से जल्द Bazel के साथ रिमोट बिल्ड एक्ज़ीक्यूशन और कैश मेमोरी को बढ़ाने की कोशिश कर रहे हैं. हम यह देख रहे हैं कि सभी मुख्य चीज़ों को हर समय कैसे सही रखा जाए या क्या हम कुछ क्षेत्रों में एजेंट के साथ फ़ॉरवर्ड फ़िक्स करना शुरू कर सकते हैं. हम इंजीनियर से आने वाले वॉल्यूम को देख रहे हैं, सेल्फ़-हीलिंग सीआई या कम फ़ीडबैक लूप जैसी चीज़ें करने की कोशिश कर रहे हैं. सभी टीमें इन सभी में सक्रिय रूप से निवेश कर रही हैं, ताकि कुछ हद तक दक्षता बनाए रखते हुए ग्रोथ को बनाए रखा जा सके.

हालांकि, यह बहुत मुश्किल है.

हां, मैं टाय की हर बात से सहमत हूं. हालांकि, मुझे लगता है कि इससे हमें खुद से ईमानदारी से यह सवाल पूछने की ज़रूरत है कि अगर हमें इस पॉइंट से 10 गुना आगे बढ़ना है, तो क्या हम तैयार हैं?

ज़्यादातर लोगों के लिए, इसका जवाब शायद 'नहीं' है.

इसलिए, आने वाले समय के बारे में सोचते हुए, हम जान-बूझकर अपने लक्ष्य को उस स्केल से मैच करने की कोशिश कर रहे हैं जिसे इंफ़्रास्ट्रक्चर सपोर्ट कर सके.

एआई ने हम सभी को ज़्यादा महत्वाकांक्षी बना दिया है, क्योंकि हमने पहले ही एक अहम छलांग देखी है. इसलिए, हम ईमानदारी से अपने सिस्टम के बारे में फिर से सोच रहे हैं.

सही कहा. हम यह सोचते हैं कि कौनसा सिस्टम काम करना बंद कर सकता है या हमें लगता है कि वह काम करना बंद कर देगा. साथ ही, हम यह सोचते हैं कि हम ऐसा क्या कर सकते हैं जिससे हमें पहले से ही पता चल जाए कि वह सिस्टम काम करना बंद कर देगा?

असल में, हम चाहते हैं कि आपको कोई परेशानी न हो.

सही कहा. जब तक हमें लगता है कि हम कंट्रोल में हैं, तब तक सभी खुश रहते हैं.

जब भी हमें कोई ऐसी चीज़ मिलती है जिसकी हमें उम्मीद नहीं थी, तो मुझे पता होता है कि यह सभी के लिए बुरी खबर है.

है न?

इसलिए, यह समय पीछे मुड़कर देखने, ऑडिट करने, और यह पता लगाने के लिए सही है कि आगे क्या गड़बड़ी होने वाली है. ऐसा इसलिए, क्योंकि गड़बड़ी तो होगी ही.

यह तो होना ही है.

हम बस इस समस्या को पहले ही हल करना चाहते हैं.

मुझे Inflow के सीईओ का एक दिलचस्प कोट याद आ रहा है.

उन्होंने बताया कि Google को कोड की अरबों लाइनों तक पहुंचने में, करीब 20 साल लगे. हालांकि, एआई की मदद से अब हमारी कई कंपनियां कुछ ही सालों में इस मुकाम तक पहुंच जाएंगी.

मुझे नहीं लगता कि सभी कंपनियां, डेवलपमेंट के लिए Google के लेवल का इन्फ़्रास्ट्रक्चर बनाने के लिए तैयार हैं.

इस विषय पर, क्या आपकी कंपनियां खर्च की कोई सीमा लागू करती हैं?

जैसे, कुछ डेवलपर हर काम के लिए टोकन खर्च कर रहे हैं. वे हर समय सबसे बेहतरीन मॉडल का इस्तेमाल करते हैं. ऐसे में, टोकन को कैसे मैनेज किया जाए?

जैसे, क्या आपको कोई रणनीति मिली या उन्हें आज़ादी देना बेहतर है, क्योंकि एक्सपेरिमेंट करने से अच्छे नतीजे मिलते हैं?

मेरे हिसाब से, पिछले साल हमने कई एक्सपेरिमेंट किए.

सभी काम करें.

इस साल की पहली छमाही में भी, शायद इसका इस्तेमाल सही तरीके से किया गया हो.

सितंबर से, टोकन की सीमाएं लागू हो गई हैं.

इसलिए, हमने डेवलपर के लिए टोकन के इस्तेमाल की सीमाएं तय की हैं.

इसके बाद, हमारे पास इंस्ट्रुमेंटेशन होते हैं, ताकि वे समझ सकें कि आपके सेशन अच्छे और सही हैं या नहीं?

एक सही सेशन का क्या मतलब है?

क्या आपको हर सेशन में इतने टर्न मिल रहे हैं?

टर्न क्या होता है?

इसलिए, हम टूल का इस्तेमाल करके डेवलपर को भी जानकारी देने की कोशिश कर रहे हैं.

मुझे लगता है कि यह सिर्फ़ पहला कदम है.

किसी समस्या को ठीक करने से पहले, आपको उसके बारे में पता होना चाहिए.

इसलिए, उन्हें यह बताना ज़रूरी है कि यह मुफ़्त में नहीं मिलता.

पहले, ऐसा लगता था कि एआई का इस्तेमाल करने के लिए कोई शुल्क नहीं देना पड़ता.

लोग इसका इस्तेमाल कर रहे थे.

मुझे "मेरी ब्रांच बदलें" जैसा कुछ चाहिए. जैसे, "ओह, कोई बात नहीं अनीस, मैं आपके लिए वह ब्रांच बदल दूँगा, 5 डॉलर," सही है?

अब हम उस जगह पर पहुंच रहे हैं जहां, "ठीक है, मैं कमांड लाइन पर जाकर खुद ही ऐसा कर सकता हूं, है न?"

इसलिए, मुझे लगता है कि हम इंजीनियर को असल लागत के बारे में जानकारी देना शुरू करेंगे.

ऐसा नहीं है कि मैं ईसीएस इंस्टेंस को स्पिन अप करके, उनसे दूर भाग जाऊं.

जब AWS पहली बार लॉन्च हुआ था, तब हमें लगा था कि "हां, मैं अपना इंस्टेंस खर्च कर सकता हूं."

और हम कंपनी का बहुत सारा पैसा खर्च कर रहे थे.

मुझे लगता है कि टोकन के साथ भी ऐसा ही अभी चल रहा है.

मुझे लगता है कि व्यावहारिक सीमाएं भी दिलचस्प अवसर पेश करती हैं, है न?

क्योंकि जब आप इस बारे में सोचते हैं कि शुरुआत में, हमने एलएलएम का इस्तेमाल कैसे शुरू किया, तो आप उन पर सब कुछ डाल देते थे, है ना?

वे कोड की जांच करते थे, चीज़ों को समझते थे, और आपके लिए जादू करते थे, है न?

हालांकि, इसके लिए आपको तीसरे पक्ष को पैसे चुकाने होंगे.

हम असल में असली हैं-- आपको पता है, इंडस्ट्री को यह एहसास हो रहा है.

इस वजह से, डेवलपर और संगठनों को यह सोचना पड़ रहा है कि इसे कैसे ऑप्टिमाइज़ किया जाए, है न?

मैं आपको एक ठोस उदाहरण देता हूँ: अगर आपके पास एक ऐसा जनरेटर है जो यूज़र इंटरफ़ेस कॉम्पोनेंट बना रहा है और उन्हें एक खास स्ट्रक्चर, यूनिट टेस्ट वगैरह का पालन करना है, तो आप मॉडल से उसे तुरंत जनरेट क्यों करवाएँगे, अगर आपके पास एक ऐसा डिटरमिनिस्टिक टूल जनरेट करने का विकल्प है जो आपके लिए उसे बना सके, है ना?

इसलिए, आपके पास टोकन और इस्तेमाल की सीमाओं का फ़ायदा उठाने के कई मौके हैं. इससे आपको ज़्यादा असरदार तरीके से काम करने में मदद मिलेगी.

हां, और उन थीम के साथ, हमने सीमाएं तय की हैं. कम से कम Instacart पर तो ऐसा ही है.

लेकिन मुझे लगता है कि इसका मकसद यह नहीं है कि एआई का इस्तेमाल कम किया जाए. इसका मकसद यह है कि एआई का इस्तेमाल सही तरीके से किया जाए या जैसा कि आपने कहा, आत्मनिरीक्षण किया जाए, है न?

जैसे, आपको कुछ मॉडल का इस्तेमाल कब करना चाहिए और अन्य मॉडल का इस्तेमाल कब करना चाहिए.

आपको पता है कि समय बताने या Git ब्रांच बदलने के लिए, आपको Fable या Astra की ज़रूरत नहीं है.

है न?

इसके लिए, आपको स्क्रिप्ट लिखने में थोड़ा समय देना होगा. यह सुविधा हमेशा के लिए मुफ़्त है.

इससे टोकन बर्बाद नहीं होते.

है न?

इसलिए, मुझे लगता है कि अगर आप कुछ ऐसा जोड़ सकें कि पाबंदी का मकसद, इस्तेमाल को सीमित करना नहीं है, बल्कि आपको हर चीज़ को एक साथ इस्तेमाल करने के बजाय, कुछ अलग सोचने में मदद करना है.

है न?

मुझे आपकी बात पसंद आई. पिछले साल, हमने कई एक्सपेरिमेंट किए.

इस साल ऐसा लगता है कि हम इस चीज़ का असरदार तरीके से इस्तेमाल कैसे करें?

हाँ।

यहां की कहानियां हमें बहुत पसंद हैं.

खास तौर पर, ज़्यादा एक्सपेरिमेंट करने से लेकर, बेहतर परफ़ॉर्मेंस और जवाबदेही के बीच संतुलन बनाने तक.

यह निवेश कई अलग-अलग सोर्स से आ सकता है.

जैसे, डेवलपर को ट्रेनिंग देना और उन्हें विज़िबिलिटी देना.

जैसा कि अनीस ने गतिविधि के सेशन की लागत और जानकारी के बारे में बताया था.

हम डिफ़ॉल्ट रूप से सुरक्षित रहने की सुविधा में निवेश करते हैं. इससे, अनचाहे इंटरैक्शन से बचने में मदद मिलती है. साथ ही, यह पक्का किया जाता है कि इस्तेमाल की जा रही स्किल असरदार हों और उनमें कोई गड़बड़ी न हो.

साथ ही, उन्हें यह भी पता चलता है कि वे जो खर्च कर रहे हैं उसका क्या असर हो रहा है.

इसलिए, आपको पता है कि हमारे पास टोकन की सीमाएं हैं.

जब कोई डेवलपर इन सीमाओं तक पहुंच जाता है, तो वह एक क्लिक करके, वजह बता सकता है और उसका मैनेजर उसे मंज़ूरी दे सकता है.

इसलिए, अगर कोई अच्छा काम हो रहा है, तो हम चाहते हैं कि वे उसे देखें.

हालांकि, अगर वे कुछ ऐसा कर रहे हैं जिससे पैसे बर्बाद हो रहे हैं या वे कुछ ऐसा एक्सपेरिमेंट कर रहे हैं जिसके लिए वे अपने मैनेजर को यह नहीं बता सकते कि उन्हें उस पर पैसे क्यों खर्च करने चाहिए, तो इससे उन्हें उस पर नज़र रखने में भी मदद मिलती है.

इससे न सिर्फ़ काम नहीं होता, बल्कि यह भी देखना और कहना पड़ता है कि क्या यह मॉडल सही है?

क्या इसका वज़न सही है?

ज़ाहिर है कि कॉम्पिटिशन की वजह से, इन टोकन की कीमत कम होने लगी है.

हालांकि, आम तौर पर हमारे इंजीनियर इस बारे में सोचते हैं कि हम उन्हें जो पैसे दे रहे हैं उनका सही इस्तेमाल हो. मुझे लगता है कि फ़िलहाल यह सही और बेहतर तरीका है.

साथ ही, आने वाले समय में उन्हें इस बारे में सोचने की ज़रूरत ही न पड़े.

है न?

आपको ऑटोमैटिक मॉडल रूटिंग जैसी सुविधाएं चाहिए, ताकि आपको इस बारे में कभी सोचना न पड़े.

हालांकि, तब तक के लिए यह एक अच्छी स्थिति है.

हाँ।

मुझे लगता है कि हमारा ज़्यादातर फ़ोकस, मॉडल राऊटर जैसी चीज़ों पर रहा है. इससे हम डेवलपर को फ़ैसला लेने की ज़िम्मेदारी से आज़ाद कर पाते हैं और टास्क को सही मॉडल पर मैप करने की कोशिश करते हैं.

हालांकि, यह सही ट्रिपवायर होने के बारे में भी है.

इसलिए, हम टोकन की सीमाओं के बारे में कुछ तरीकों से सोचते हैं.

हम डेवलपर को कभी ब्लॉक नहीं करना चाहते.

हालांकि, हम यह पक्का करना चाहते हैं कि कुछ समय के लिए रुककर, यह देखा जाए कि बजट को सही जगहों पर और सही तरीके से खर्च किया जा रहा है या नहीं.

उदाहरण के लिए, रोज़ाना वीडियो जनरेट करने की सीमाएँ तय की गई हैं. ये सीमाएँ, ट्रिपवायर की तरह काम करती हैं. डेवलपर इन्हें खुद अनब्लॉक कर सकता है.

उन्हें बस पोर्टल पर जाना होगा, एक बटन पर क्लिक करना होगा, और कहना होगा, "अरे, मुझे

मेरे पास पूरा कंट्रोल है."

है न?

यह सिर्फ़ एक आसान तरीका है, क्योंकि हर कोई लूप कर रहा है. ये लूप रात भर चल सकते हैं और हम नहीं चाहते कि इससे लागत बढ़े.

इसलिए, यह बहुत सही है.

दूसरी ओर, हम यह भी पक्का करना चाहते हैं कि हमारे डेवलपर के पास बेहतरीन मॉडल उपलब्ध हों.

हालांकि, इस कैटगरी के मॉडल के लिए, हमने एक फ़्रंटियर बजट बनाया है.

इसलिए, महीने का बजट तय किया जाता है.

यह काफ़ी ज़्यादा है.

आपको ब्लॉक नहीं किया गया है.

अगर आपको अपने खाते को अनब्लॉक करना है, तो इसके लिए एक अपवाद प्रोसेस है.

यह आपके मैनेजर के पास जाता है.

यह वह पल होता है, जब आपको बताना होता है कि आप क्या कर रहे हैं.

प्लैटफ़ॉर्म टीम के तौर पर, हम फ़ैसले नहीं लेते. ऐसा इसलिए, क्योंकि ये फ़ैसले उन लोगों को लेने चाहिए जो काम कर रहे हैं.

फ़्रंटियर मॉडल के इस्तेमाल के मामले में भी, हम आपको तय सीमा के साथ पूरी सुविधा देते हैं.

यह तरीका इसलिए काम करता है, क्योंकि इससे प्रोसेस को पहले से अनुमानित बनाया जा सकता है.

है न?

हम यह पक्का करना चाहते हैं कि जब हम टोकन खर्च करने का बजट तय कर रहे हों, तो हमने अपनी योजना को ध्यान में रखा हो. यह सभी के लिए एक चुनौती है. इन लीवर की मदद से, हम ऐसा कर पाते हैं.

क्या आपको पता है कि मुझे इन बातचीत में सबसे दिलचस्प क्या लगता है?

मुझे लगता है कि ऐसा इसलिए है, क्योंकि हम सभी कंपनियों में काम करते हैं.

इसलिए, एंटरप्राइज़.

इसलिए, हमें हर टोकन के लिए पैसे चुकाने पड़ते हैं.

है न?

हालांकि, इंटरनेट पर एक ऐसा हिस्सा भी है जहां लोग सदस्यता के लिए पैसे चुकाते हैं.

इसलिए, उनके लिए यह एक अलग तरह का कैलकुलेशन है.

है न?

हालांकि, मुझे लगता है कि आपको पता है कि कुछ समय बाद सभी लोग एक ही पूल में होंगे. यहां आपको हर टोकन के बारे में सोचना होगा.

इसके बाद, हमें ज़्यादा ज़िम्मेदारी से काम करना होगा. ठीक वैसे ही जैसे अभी कंपनियों को करना पड़ता है.

या फिर, किसी ऐसी फ़्रंटियर लैब में काम करते हैं जहां आपको अनलिमिटेड बजट मिलता है.

इसके बाद, आपको बस काम करते रहना है. साथ ही, आपको एआई नेटिव तरीके से काम करने के कई दिलचस्प तरीके बनाने हैं, जो Twitter पर हर जगह मौजूद हैं.

हमारी सभी कंपनियां ऐसा करना चाहती हैं, लेकिन वे टोकन खर्च नहीं करना चाहतीं…

हमारे पास ऐसे लोग हैं जो Google में काम करते हैं.

मैं इस बारे में जानने के लिए बहुत उत्सुक हूं.

यह बटन कैसे काम करता है?

Google से मिलने वाला बजट कितना है?

क्या आपको यह सवाल पूछना है, लुइस?

मुझे नहीं लगता कि मैं इसकी अर्थव्यवस्था के बारे में बात करने के लिए सही व्यक्ति हूं.

Google एक बहुत बड़ी कंपनी है, जिसमें कई अलग-अलग संगठन हैं.

लेकिन, यह हमारे लिए एकदम सही है, क्योंकि हम समय पर हैं.

यह आसान था.

Saved by the bell.

दोस्तों, इसे कहते हैं बेहतरीन मॉडरेटिंग.

पीआर टीम के लोग…

खैर, हमारे पैनल को धन्यवाद. साथ ही, एटीएस में आने के लिए धन्यवाद.