00:00:00(उत्साहपूर्ण संगीत)
00:00:02- नमस्ते सबको, आप सब कैसे हैं?
00:00:23यह रोमांचक है, मैं डेक्स हूँ।
00:00:25जैसा कि उन्होंने बेहतरीन परिचय में बताया,
00:00:27मैं पिछले कुछ समय से एजेंट्स पर काम कर रहा हूँ।
00:00:29जून में एआई इंजीनियर में हमारी टॉक, 12-फैक्टर एजेंट्स,
00:00:32अब तक की सबसे बेहतरीन टॉक्स में से एक थी।
00:00:34मुझे लगता है कि टॉप आठ या ऐसा ही कुछ,
00:00:35जून में एआई इंजीनियर की सबसे अच्छी टॉक्स में से एक।
00:00:38हो सकता है मैंने कॉन्टेक्स्ट इंजीनियरिंग के बारे में कुछ कहा हो।
00:00:41मैं आज यहाँ क्यों हूँ, मैं किस बारे में बात करने आया हूँ?
00:00:44मैं जून में एआई इंजीनियर की अपनी एक पसंदीदा टॉक के
00:00:46बारे में बात करना चाहता हूँ,
00:00:47और मुझे पता है कि हम सबको कल इगोर से अपडेट मिला था,
00:00:49लेकिन उन्होंने मुझे अपनी स्लाइड्स बदलने नहीं दीं,
00:00:50इसलिए यह इस बारे में होगा कि इगोर ने जून में क्या बात की थी।
00:00:54मूल रूप से, उन्होंने सभी प्रकार की कंपनियों के
00:00:56100,000 डेवलपर्स का सर्वेक्षण किया,
00:00:58और उन्होंने पाया कि अधिकांश समय
00:01:00जब आप सॉफ्टवेयर इंजीनियरिंग के लिए एआई का उपयोग करते हैं,
00:01:01तो आप बहुत सारा दोबारा काम और कोड-बेस में बदलाव कर रहे होते हैं।
00:01:04और यह जटिल कार्यों, ब्राउनफील्ड कोड बेस के
00:01:07लिए वास्तव में अच्छी तरह से काम नहीं करता है।
00:01:08और आप चार्ट में देख सकते हैं, मूल रूप से,
00:01:10आप बहुत अधिक शिप कर रहे हैं,
00:01:11लेकिन इसमें से बहुत कुछ बस पिछले हफ्ते शिप किए गए
00:01:14खराब काम (slop) को सुधारना मात्र है।
00:01:15तो, और दूसरा पहलू यह था कि
00:01:18अगर आप ग्रीनफील्ड, छोटा वर्सेल डैशबोर्ड,
00:01:21ऐसा कुछ कर रहे हैं, तो यह बहुत अच्छा काम करेगा।
00:01:25लेकिन अगर आप 10 साल पुराने जावा कोड बेस में जाने वाले हैं,
00:01:28तो शायद उतना अच्छा न हो।
00:01:29और यह मेरे अनुभव से मेल खाता था।
00:01:30व्यक्तिगत रूप से, और कई संस्थापकों
00:01:32और बेहतरीन इंजीनियरों से बात करने पर - बहुत अधिक खराब काम,
00:01:35टेक डेब्ट फैक्ट्रीज़, यह हमारे कोड बेस के लिए काम नहीं करने वाला है।
00:01:37शायद किसी दिन, जब मॉडल्स बेहतर हो जाएंगे।
00:01:40लेकिन कॉन्टेक्स्ट इंजीनियरिंग इसी बारे में है।
00:01:42हम आज के मॉडल्स से अधिक से अधिक कैसे लाभ उठा सकते हैं?
00:01:44हम अपनी कॉन्टेक्स्ट विंडो को कैसे मैनेज करते हैं?
00:01:46तो हमने अगस्त में इस बारे में बात की थी।
00:01:48मुझे कुछ स्वीकार करना है।
00:01:49जब मैंने पहली बार क्लाउड कोड का उपयोग किया, तो मैं प्रभावित नहीं हुआ।
00:01:53यह ऐसा था, ठीक है, यह थोड़ा बेहतर है,
00:01:54मैं समझ गया, मुझे इसका यूएक्स (UX) पसंद है।
00:01:56लेकिन तब से, हमने एक टीम के रूप में कुछ ऐसा पता लगाया
00:01:59कि हम वास्तव में
00:02:01दो से तीन गुना अधिक थ्रूपुट प्राप्त करने में सक्षम थे।
00:02:02और हम इतना अधिक शिप कर रहे थे कि हमारे पास
00:02:06सहयोग करने के तरीके को बदलने के अलावा कोई विकल्प नहीं था।
00:02:07हमने सॉफ्टवेयर बनाने के अपने पूरे तरीके को बदल दिया।
00:02:11यह तीन लोगों की टीम थी, इसमें आठ हफ्ते लगे,
00:02:12यह वाकई बहुत कठिन था।
00:02:14लेकिन अब जब हमने इसे सुलझा लिया है, तो हम कभी पीछे नहीं हटेंगे।
00:02:16यह वही "नो स्लॉप" वाली बात है।
00:02:18मुझे लगता है कि हम इससे कहीं पहुँच पाए हैं।
00:02:20सितंबर में हैकर न्यूज़ पर यह बहुत वायरल हुआ था।
00:02:23हमारे पास हजारों लोग हैं जिन्होंने गिटहब (GitHub) पर जाकर
00:02:25हमारा "रिसर्च प्लान इम्प्लीमेंट" प्रॉम्प्ट सिस्टम अपनाया है।
00:02:28तो यहाँ जो लक्ष्य हैं, जिन्हें हमने एक तरह से हासिल किया है,
00:02:31हमें ऐसे एआई की जरूरत है जो ब्राउनफील्ड कोड बेस में अच्छी तरह काम कर सके।
00:02:35जो जटिल समस्याओं को हल कर सके।
00:02:38कोई स्लॉप नहीं, ठीक है, अब और खराब काम नहीं।
00:02:40और हमें मानसिक तालमेल बनाए रखना था।
00:02:42मैं एक मिनट में इसके बारे में
00:02:43थोड़ी और बात करूँगा कि इसका क्या मतलब है।
00:02:44और निश्चित रूप से, हम हर चीज के साथ,
00:02:46अधिक से अधिक टोकन खर्च करना चाहते हैं।
00:02:47हम एआई को सार्थक रूप से क्या सौंप सकते हैं,
00:02:50वह वास्तव में बहुत महत्वपूर्ण है।
00:02:52अत्यधिक प्रभावशाली।
00:02:53तो यह कोडिंग एजेंट्स के लिए उन्नत कॉन्टेक्स्ट इंजीनियरिंग है।
00:02:56मैं इसे इस तरह से फ्रेम करना शुरू करूँगा।
00:02:58कोडिंग एजेंट का उपयोग करने का सबसे नौसिखिया तरीका
00:03:01उससे कुछ मांगना है और फिर उसे बताना है कि वह गलत क्यों है
00:03:03और उसे फिर से निर्देशित करना और पूछते रहना,
00:03:05जब तक कि आपका कॉन्टेक्स्ट खत्म न हो जाए या आप हार न मान लें या रोने न लगें।
00:03:09हम इस बारे में थोड़े और समझदार हो सकते हैं।
00:03:11ज्यादातर लोग अपनी एआई खोज की शुरुआत में ही
00:03:13यह जान जाते हैं कि शायद यह बेहतर होगा
00:03:17कि अगर आप कोई बातचीत शुरू करते हैं और आप भटक जाते हैं,
00:03:21तो आप बस एक नई कॉन्टेक्स्ट विंडो शुरू करें।
00:03:24आप कहें, ठीक है, हम उस रास्ते पर चले गए थे।
00:03:25चलिए फिर से शुरू करते हैं।
00:03:26वही प्रॉम्प्ट, वही काम।
00:03:27लेकिन इस बार, हम इस रास्ते पर चलेंगे।
00:03:29और वहां मत जाना क्योंकि वह काम नहीं करता।
00:03:31तो आपको कैसे पता चलेगा कि कब फिर से शुरू करने का समय है?
00:03:34अगर आप यह देखते हैं,
00:03:37(दर्शक हंसते हुए)
00:03:39तो शायद फिर से शुरू करने का समय आ गया है, है ना?
00:03:41जब आप क्लाउड को बताते हैं कि वह गड़बड़ कर रहा है, तो वह यही कहता है।
00:03:45तो हम इस बारे में और भी समझदार हो सकते हैं।
00:03:47हम वह कर सकते हैं जिसे मैं "जानबूझकर संपीड़न" (intentional compaction) कहता हूँ।
00:03:50और यह मूल रूप से है कि आप सही रास्ते पर हैं या नहीं,
00:03:53आप अपनी मौजूदा कॉन्टेक्स्ट विंडो ले सकते हैं
00:03:56और एजेंट से इसे मार्कडाउन फ़ाइल में कंप्रेस करने के लिए कह सकते हैं।
00:03:59आप इसकी समीक्षा कर सकते हैं, इसे टैग कर सकते हैं।
00:04:00और फिर जब नया एजेंट शुरू होता है,
00:04:02तो वह सीधे काम पर लग जाता है, उसे वह सब
00:04:04खोजबीन और कोड-बेस को समझने और
00:04:05पुरानी बातों को पकड़ने की ज़रूरत नहीं होती।
00:04:07कंपैक्शन में क्या जाता है?
00:04:09सवाल यह है कि आपकी कॉन्टेक्स्ट विंडो में
00:04:11कौन सी चीजें जगह लेती हैं?
00:04:13तो यह फ़ाइलों की तलाश कर रहा है, कोड फ्लो को समझ रहा है,
00:04:17फ़ाइलों को एडिट कर रहा है, यह टेस्ट और बिल्ड आउटपुट है।
00:04:20और अगर आपके पास कोई ऐसा MCP है जो आपकी कॉन्टेक्स्ट विंडो में
00:04:22JSON और ढेर सारी UUIDs डाल रहा है,
00:04:25तो भगवान ही आपका भला करे।
00:04:26तो हमें क्या कंपैक्ट करना चाहिए?
00:04:28मैं यहाँ विवरणों पर और बात करूँगा,
00:04:30लेकिन यह एक बहुत अच्छा संपीड़न है।
00:04:31यह बिल्कुल वही है जिस पर हम काम कर रहे हैं,
00:04:33सटीक फ़ाइलें और लाइन नंबर
00:04:34जो उस समस्या के लिए मायने रखते हैं जिसे हम हल कर रहे हैं।
00:04:37हम कॉन्टेक्स्ट को लेकर इतने जुनूनी क्यों हैं?
00:04:39क्योंकि इसके लिए यूट्यूब पर एलएलएम (LLMs) का काफी मज़ाक उड़ाया गया था।
00:04:42वे शुद्ध फलन (pure functions) नहीं हैं क्योंकि वे अनिश्चित (nondeterministic) हैं,
00:04:45लेकिन वे स्टेटलेस (stateless) हैं।
00:04:46और एलएलएम से बेहतर प्रदर्शन पाने का एकमात्र तरीका
00:04:49बेहतर टोकन डालना है
00:04:51और फिर आपको बेहतर टोकन मिलते हैं।
00:04:52और इसलिए हर लूप के साथ,
00:04:53क्लाउड अगला टूल चुन रहा है
00:04:55या कोई भी कोडिंग एजेंट अगला टूल चुन रहा है।
00:04:56और वहां सैकड़ों सही अगले कदम हो सकते हैं
00:04:58और सैकड़ों गलत अगले कदम।
00:05:00लेकिन इसके बाद क्या आने वाला है, इसे प्रभावित करने वाली एकमात्र चीज़
00:05:03वही है जो अब तक की बातचीत में है।
00:05:05इसलिए हम इस कॉन्टेक्स्ट विंडो को सटीकता, पूर्णता, आकार
00:05:07और थोड़े प्रक्षेपवक्र (trajectory) के लिए ऑप्टिमाइज़ करेंगे।
00:05:10और प्रक्षेपवक्र वाला हिस्सा दिलचस्प है
00:05:11क्योंकि बहुत से लोग कहते हैं,
00:05:12ठीक है, मैंने एजेंट को कुछ करने के लिए कहा
00:05:13और उसने कुछ गलत किया।
00:05:16तो मैंने उसे सुधारा और उस पर चिल्लाया
00:05:17और फिर उसने फिर से कुछ गलत किया।
00:05:18और फिर मैंने उस पर चिल्लाया।
00:05:20और फिर एलएलएम इस बातचीत को देख रहा है,
00:05:21कहता है, ठीक है, बढ़िया, मैंने कुछ गलत किया
00:05:23और इंसान मुझ पर चिल्लाया
00:05:24और मैंने कुछ गलत किया और इंसान मुझ पर चिल्लाया।
00:05:25तो इस बातचीत में अगला सबसे संभावित टोकन यह है
00:05:26कि बेहतर होगा कि मैं कुछ गलत करूँ
00:05:29ताकि इंसान मुझ पर फिर से चिल्ला सके।
00:05:31इसलिए अपने प्रक्षेपवक्र के प्रति सचेत रहें।
00:05:33अगर आप इसे उल्टा करें,
00:05:35तो सबसे बुरी चीज गलत जानकारी होना है,
00:05:36फिर जानकारी का न होना, और फिर बस बहुत अधिक शोर।
00:05:39अगर आपको समीकरण पसंद हैं, तो यहाँ एक सरल समीकरण है
00:05:42अगर आप इसे इस तरह से सोचना चाहते हैं।
00:05:44जेफ हंटली ने कोडिंग एजेंट्स पर काफी शोध किया है।
00:05:47उन्होंने इसे बहुत अच्छी तरह से समझाया।
00:05:51बस आप जितना अधिक कॉन्टेक्स्ट विंडो का उपयोग करेंगे,
00:05:51आपको उतने ही खराब परिणाम मिलेंगे।
00:05:53यह एक अवधारणा की ओर ले जाता है।
00:05:55मैं एक बहुत ही शैक्षणिक अवधारणा की बात कर रहा हूँ जिसे "डम्ब ज़ोन" (dumb zone) कहा जाता है।
00:05:56तो आपके पास अपनी कॉन्टेक्स्ट विंडो है।
00:05:59आपके पास लगभग 168,000 टोकन हैं।
00:06:01कुछ आउटपुट और संपीड़न के लिए आरक्षित हैं।
00:06:03यह मॉडल के अनुसार अलग-अलग होता है,
00:06:05लेकिन हम यहाँ उदाहरण के रूप में क्लाउड कोड का उपयोग करते हैं।
00:06:07लगभग 40% की रेखा वह जगह है जहाँ आप अपने काम के आधार पर
00:06:09कुछ घटते प्रतिफल (diminishing returns) देखना शुरू करेंगे।
00:06:10यदि आपके कोडिंग एजेंट्स में बहुत अधिक MCPs हैं,
00:06:14तो आप अपना सारा काम डम्ब ज़ोन में कर रहे हैं
00:06:17और आपको कभी अच्छे परिणाम नहीं मिलेंगे।
00:06:18लोगों ने इस बारे में बात की है।
00:06:21मैं उस बारे में बात नहीं करूँगा।
00:06:21आपका अनुभव अलग हो सकता है।
00:06:2240% इस बात पर निर्भर करता है कि कार्य कितना जटिल है,
00:06:23लेकिन यह एक तरह का अच्छा दिशानिर्देश है।
00:06:26तो वापस कंपैक्शन पर आते हैं, या जैसा कि मैं अब से इसे कहूँगा,
00:06:28चतुराई से डम्ब ज़ोन से बचना।
00:06:31हम सब-एजेंट्स का उपयोग कर सकते हैं।
00:06:33यदि आपके पास एक फ्रंट-एंड सब-एजेंट और एक बैक-एंड सब-एजेंट
00:06:37और एक QA सब-एजेंट और एक डेटा साइंटिस्ट सब-एजेंट है, तो कृपया रुक जाइए।
00:06:39सब-एजेंट्स भूमिकाओं को मानवीय रूप देने के लिए नहीं हैं।
00:06:44वे कॉन्टेक्स्ट को नियंत्रित करने के लिए हैं।
00:06:47और इसलिए आप क्या कर सकते हैं कि यदि आप एक बड़े कोड बेस में
00:06:49यह ढूंढना चाहते हैं कि कोई चीज़ कैसे काम करती है,
00:06:51तो आप कोडिंग एजेंट को ऐसा करने के लिए निर्देशित कर सकते हैं
00:06:53यदि वह सब-एजेंट्स को सपोर्ट करता है,
00:06:55या आप अपना खुद का सब-एजेंट सिस्टम बना सकते हैं,
00:06:56लेकिन मूल रूप से आप कहते हैं, अरे, जाओ ढूंढो कि यह कैसे काम करता है।
00:06:58और वह एक नई कॉन्टेक्स्ट विंडो बना सकता है
00:07:00जो वह सारी पढ़ाई और खोजबीन करने
00:07:03चीजों को खोजने और पूरी फ़ाइलों को पढ़ने
00:07:05और कोड बेस को समझने का काम करेगी,
00:07:07और फिर बस एक बहुत ही संक्षिप्त संदेश
00:07:09पैरेंट एजेंट को वापस भेजेगी कि,
00:07:13अरे, जो फ़ाइल तुम्हें चाहिए वो यहाँ है।
00:07:14पैरेंट एजेंट उस एक फ़ाइल को पढ़ सकता है और सीधे काम पर लग सकता है।
00:07:17और इसलिए यह वास्तव में शक्तिशाली है।
00:07:20यदि आप इनका सही ढंग से उपयोग करते हैं,
00:07:22तो आप इस तरह की अच्छी प्रतिक्रियाएँ प्राप्त कर सकते हैं,
00:07:23और फिर आप अपने कॉन्टेक्स्ट को बहुत अच्छी तरह से प्रबंधित कर सकते हैं।
00:07:25सब-एजेंट्स से भी बेहतर क्या काम करता है
00:07:29या सब-एजेंट्स के ऊपर एक लेयर है
00:07:30या सब-एजेंट्स के ऊपर एक लेयर की तरह,
00:07:32एक वर्कफ्लो है जिसे मैं 'फ्रीक्वेंट इंटेंशनल कॉम्पेक्शन' कहता हूँ।
00:07:35हम थोड़ी देर में रिसर्च, प्लान और इम्प्लीमेंट के बारे में बात करेंगे,
00:07:37लेकिन मुद्दा यह है कि आप लगातार
00:07:39अपने कॉन्टेक्स्ट विंडो को छोटा रख रहे हैं।
00:07:41आप अपना पूरा वर्कफ्लो कॉन्टेक्स्ट मैनेजमेंट के इर्द-गिर्द बना रहे हैं
00:07:45तो इसके तीन चरण हैं: रिसर्च, प्लान और इम्प्लीमेंट,
00:07:48और हम पूरे समय 'स्मार्ट ज़ोन' में रहने की कोशिश करेंगे।
00:07:51तो रिसर्च का मतलब है यह समझना
00:07:53कि सिस्टम कैसे काम करता है, सही फाइल ढूंढना,
00:07:55और निष्पक्ष बने रहना।
00:07:56रिसर्च करने के लिए आप इस प्रॉम्प्ट का उपयोग कर सकते हैं।
00:07:58यहाँ एक रिसर्च प्रॉम्प्ट का आउटपुट दिया गया है।
00:08:00ये सभी ओपन सोर्स हैं।
00:08:01आप इन्हें लेकर खुद इस्तेमाल कर सकते हैं।
00:08:04प्लानिंग में, आप सटीक स्टेप्स की रूपरेखा तैयार करेंगे।
00:08:06आप इसमें फाइल के नाम और कोड की लाइनें शामिल करेंगे।
00:08:08आप इस बारे में बहुत स्पष्ट होंगे कि हम हर बदलाव के बाद
00:08:10चीजों का परीक्षण कैसे करेंगे।
00:08:11यहाँ एक अच्छा प्लानिंग प्रॉम्प्ट दिया गया है।
00:08:12यहाँ हमारी योजनाओं में से एक है।
00:08:13इसमें वास्तविक कोड स्निपेट्स मौजूद हैं।
00:08:16और फिर हम इसे इम्प्लीमेंट (लागू) करेंगे।
00:08:17और अगर आपने इनमें से कोई प्लान पढ़ा है,
00:08:17तो आप आसानी से समझ सकते हैं कि दुनिया का सबसे साधारण मॉडल भी
00:08:20शायद इसमें गलती नहीं करेगा।
00:08:23तो हम बस आगे बढ़ते हैं और प्लान को रन करते हैं
00:08:24और कॉन्टेक्स्ट को कम रखते हैं।
00:08:26प्लानिंग प्रॉम्प्ट के तौर पर, जैसा कि मैंने कहा,
00:08:27यह इस प्रक्रिया का सबसे कम रोमांचक हिस्सा है।
00:08:30मैं इसे व्यवहार में लाना चाहता था।
00:08:31तो हमारे लिए काम करते हुए, मैं अपने दोस्त वैभव के साथ एक पॉडकास्ट करता हूँ
00:08:34जो बाउंड्री ML (Boundary ML) नाम की कंपनी के CEO हैं।
00:08:37और मैंने कहा, "सुनो, मैं तुम्हारे प्रोग्रामिंग लैंग्वेज के
00:08:393,00,000 लाइनों वाले रस्ट (Rust) कोड बेस में
00:08:41एक ही बार में फिक्स करने की कोशिश करूँगा।"
00:08:42और पूरा एपिसोड इसी में चला जाता है।
00:08:45यह लगभग डेढ़ घंटे का है।
00:08:46मैं अभी इसके बारे में विस्तार से बात नहीं करूँगा,
00:08:47लेकिन हमने काफी रिसर्च की
00:08:48और फिर उन्हें फेंक दिया क्योंकि वे खराब थे।
00:08:49फिर हमने बिना रिसर्च के और रिसर्च के साथ प्लान बनाए
00:08:51और सभी परिणामों की तुलना की।
00:08:53मज़ा आया।
00:08:54वह सोमवार की रात थी।
00:08:55मंगलवार की सुबह तक, हम शो पर थे
00:08:57और CTO ने उस PR (पुल रिक्वेस्ट) को देख लिया था
00:08:59पर उन्हें नहीं पता था कि मैं यह पॉडकास्ट के लिए एक मज़ाक के रूप में कर रहा था।
00:09:03और उन्होंने कहा, "हाँ, यह अच्छा लग रहा है।
00:09:04हम इसे अगले रिलीज़ में शामिल कर लेंगे।"
00:09:05वह थोड़े उलझन में थे।
00:09:08यहाँ वह प्लान है।
00:09:09पर जो भी हो, हाँ, पुष्टि हो गई।
00:09:12यह पुराने कोड बेस में काम करता है और कोई फालतू कचरा नहीं है।
00:09:14लेकिन मैं देखना चाहता था कि क्या हम जटिल समस्याओं को हल कर सकते हैं।
00:09:17तो वैभव को अब भी थोड़ा संदेह था।
00:09:19मैं बैठा, हम एक शनिवार को लगभग सात घंटे तक बैठे
00:09:21और हमने BAML को 35,000 लाइनों का कोड भेज दिया।
00:09:24उनमें से एक PR लगभग एक हफ्ते बाद मर्ज हो गया।
00:09:26मैं यह कहूँगा कि इसमें से कुछ कोड जनरेशन था।
00:09:28आप अपना बिहेवियर अपडेट करते हैं,
00:09:29सभी गोल्डन फाइल्स अपडेट हो जाती हैं और बाकी सब,
00:09:31लेकिन हमने उस दिन बहुत सारा कोड भेजा।
00:09:33उनका अनुमान है कि सात घंटों में लगभग एक से दो हफ्ते का काम हुआ।
00:09:36तो बढ़िया है, हम जटिल समस्याओं को हल कर सकते हैं।
00:09:40इसकी कुछ सीमाएँ भी हैं।
00:09:41मैं अपने दोस्त ब्लेक के साथ बैठा।
00:09:42हमने 'Parquet Java' से हडूप (Hadoop) की डिपेंडेंसी हटाने की कोशिश की।
00:09:46अगर आप जानते हैं कि Parquet Java क्या है,
00:09:47तो मुझे आपके साथ जो भी हुआ उसके लिए खेद है
00:09:50जिसने आपको करियर के इस मोड़ पर पहुँचा दिया।
00:09:53वह सफल नहीं रहा।
00:09:55यहाँ वो प्लान और रिसर्च हैं।
00:09:57एक बिंदु पर, हमने सब कुछ छोड़ दिया
00:09:58और हम वापस व्हाइटबोर्ड पर आ गए।
00:10:00एक बार जब हमने यह सीख लिया था
00:10:01कि कमियाँ कहाँ-कहाँ हैं,
00:10:03तो हम वापस लौट आए कि, ठीक है,
00:10:05यह वास्तव में एक साथ कैसे फिट होगा?
00:10:06और यह मुझे एक बहुत ही दिलचस्प बात पर ले आता है
00:10:09जिसके बारे में जेक बाद में बात करेंगे।
00:10:11सोचने का काम बाहर आउटसोर्स न करें।
00:10:13AI सोचने की जगह नहीं ले सकता।
00:10:14यह केवल उस सोच को बढ़ावा दे सकता है जो आपने की है
00:10:17या आपकी सोच की कमी को और भी साफ़ कर सकता है।
00:10:19तो लोग पूछते हैं, तो डेक्स,
00:10:21यह स्पेक-ड्रिवेन डेवलपमेंट (spec-driven development) है, है ना?
00:10:23नहीं, स्पेक-ड्रिवेन डेवलपमेंट अब बेमानी हो चुका है।
00:10:27विचार नहीं, बल्कि यह मुहावरा।
00:10:30यह अच्छी तरह से परिभाषित नहीं है।
00:10:33यह थॉटवर्क्स (ThoughtWorks) की ब्रिगेटा हैं।
00:10:35और बहुत से लोग सिर्फ 'स्पेक' कहते हैं
00:10:37और उनका मतलब एक विस्तृत प्रॉम्प्ट से होता है।
00:10:39क्या किसी को यह तस्वीर याद है?
00:10:41क्या कोई जानता है कि यह कहाँ से है?
00:10:43ठीक है, यह काफी पुरानी बात है।
00:10:44एजेंट्स का दौर कभी नहीं आएगा
00:10:46क्योंकि इसमें 'सिमेंटिक डिफ्यूजन' (अर्थ का धुंधलापन) है।
00:10:47मार्टिन फाउलर ने 2006 में यह कहा था।
00:10:49हम एक अच्छी परिभाषा के साथ एक अच्छा शब्द लाते हैं
00:10:52और फिर हर कोई उत्साहित हो जाता है
00:10:53और 100 अलग-अलग लोगों के लिए इसके 100 अलग मतलब निकलने लगते हैं
00:10:56और अंत में वह शब्द बेकार हो जाता है।
00:10:59हमारे पास एक व्यक्ति के रूप में एजेंट था, एक माइक्रोसर्विस के रूप में,
00:11:02एक चैटबॉट के रूप में, और एक वर्कफ्लो के रूप में एजेंट था।
00:11:05और साइमन, तुम्हारा धन्यवाद।
00:11:06हम वापस शुरुआत पर आ गए हैं।
00:11:07एजेंट बस एक लूप में चलने वाले टूल्स हैं।
00:11:09यही स्पेक-ड्रिवेन देव (spec-driven dev) के साथ हो रहा है।
00:11:11पहले इस टॉक की शुरुआत में मेरे पास शॉन की स्लाइड थी,
00:11:15लेकिन उसकी वजह से बहुत से लोगों का ध्यान
00:11:15गलत चीजों पर केंद्रित होने लगा।
00:11:17उनका यह कहना कि कोड को भूल जाओ, अब यह असेंबली की तरह है
00:11:19और आप बस मार्कडाउन पर ध्यान दें।
00:11:21यह विचार बहुत अच्छा है, लेकिन लोग कहते हैं स्पेक-ड्रिवेन देव
00:11:24मतलब एक बेहतर प्रॉम्प्ट या प्रोडक्ट रिक्वायरमेंट्स डॉक्यूमेंट लिखना है।
00:11:26कभी-कभी इसका मतलब सत्यापन योग्य फीडबैक लूप्स
00:11:28और बैक प्रेशर का उपयोग करना होता है।
00:11:30शायद यह कोड को असेंबली की तरह समझना है,
00:11:32जैसा कि शॉन ने हमें सिखाया था।
00:11:34लेकिन बहुत से लोगों के लिए यह कोडिंग के दौरान
00:11:36बस बहुत सारी मार्कडाउन फाइलों का उपयोग करना है।
00:11:37या मेरा पसंदीदा, जो मुझे पिछले हफ्ते ही मिला,
00:11:39कि स्पेक एक ओपन सोर्स लाइब्रेरी का डॉक्यूमेंटेशन है।
00:11:43तो यह खत्म हो गया।
00:11:44स्पेक-ड्रिवेन देव अब सिर्फ एक बढ़ा-चढ़ाकर कही गई बेकार बात है।
00:11:48इसका अर्थ पूरी तरह से फैल चुका है।
00:11:49तो मैं उन चार चीजों के बारे में बात करना चाहता था
00:11:52जो वास्तव में आज काम करती हैं, वो व्यवहारिक कदम
00:11:55जो हमने आंतरिक रूप से और कई उपयोगकर्ताओं के साथ काम करते हुए पाए हैं।
00:11:59हम रिसर्च करते हैं, हम समझते हैं कि सिस्टम कैसे काम करता है।
00:12:02आपको "मेमेंटो" फिल्म याद है?
00:12:03कॉन्टेक्स्ट इंजीनियरिंग पर यह सबसे बेहतरीन फिल्म है,
00:12:05जैसा कि पीटर कहते हैं।
00:12:07यह आदमी सोकर उठता है, उसे कुछ याद नहीं रहता,
00:12:09उसे यह जानने के लिए अपने शरीर के टैटू पढ़ने पड़ते हैं कि वह कौन है
00:12:11और वह क्या कर रहा है।
00:12:12अगर आप अपने एजेंट्स को सही जानकारी नहीं देंगे, तो वे मनगढ़ंत बातें बनाएंगे।
00:12:17तो यह आपकी टीम है, आप में से अधिकांश के लिए यह बहुत सरल है।
00:12:19आप में से ज्यादातर के पास इससे कहीं बड़े संगठन हैं।
00:12:19लेकिन मान लीजिए कि आप यहाँ कुछ काम करना चाहते हैं।
00:12:21एक चीज जो आप कर सकते हैं वह यह है कि
00:12:23आप हर रिपॉजिटरी में 'ऑनबोर्डिंग' डाल सकते हैं।
00:12:26आप उसमें काफी सारा कॉन्टेक्स्ट डाल देते हैं।
00:12:27यहाँ रिपो है, और यह ऐसे काम करता है।
00:12:28यह कोड बेस के सभी कॉन्टेक्स्ट का एक संक्षिप्त रूप है
00:12:29जिसे एजेंट काम शुरू करने से पहले
00:12:32पहले से देख सकता है।
00:12:34यह चुनौतीपूर्ण है क्योंकि कभी-कभी यह बहुत लंबा हो जाता है।
00:12:36जैसे-जैसे आपका कोड बेस बड़ा होता जाता है,
00:12:39आपको या तो इसे और लंबा करना पड़ता है
00:12:41या फिर कुछ जानकारियों को छोड़ना पड़ता है।
00:12:43और इसलिए जैसे-जैसे आप इसे पढ़ रहे होते हैं,
00:12:45आप इस विशाल 50 लाख लाइनों वाले मोनो रिपो का
00:12:48कॉन्टेक्स्ट पढ़ेंगे,
00:12:49और आप अपनी सारी सोचने की क्षमता (स्मार्ट ज़ोन)
00:12:52सिर्फ यह समझने में लगा देंगे कि यह कैसे काम करता है।
00:12:53फिर आप किसी भी टूल को सही से इस्तेमाल नहीं कर पाएंगे।
00:12:55तो आप इसे अलग-अलग हिस्सों में बाँट सकते हैं।
00:12:57आप 'प्रोग्रेसिव डिस्क्लोज़र' (क्रमिक खुलासा) के बारे में बात कर सकते हैं।
00:13:02आप इसे विभाजित कर सकते हैं, है ना?
00:13:04आप बस हर रिपो की रूट (root) में एक फाइल रख सकते हैं
00:13:05और फिर हर स्तर पर आपके पास अतिरिक्त कॉन्टेक्स्ट होता है
00:13:08इस आधार पर कि यदि आप यहाँ काम कर रहे हैं,
00:13:11तो आपको यह जानने की जरूरत है।
00:13:13हम स्वयं फाइलों का डॉक्यूमेंटेशन नहीं करते
00:13:15क्योंकि वे ही परम सत्य (source of truth) हैं।
00:13:17लेकिन फिर जैसे-जैसे आपका एजेंट काम करता है,
00:13:18आप रूट कॉन्टेक्स्ट को लेते हैं
00:13:19और फिर आप सब-कॉन्टेक्स्ट को लेते हैं।
00:13:21हम किसी खास टूल की बात नहीं करेंगे,
00:13:22आप इसके लिए CloudMD या Hoax का उपयोग कर सकते हैं।
00:13:23लेकिन फिर भी आपके पास स्मार्ट ज़ोन में काफी जगह बचती है
00:13:24क्योंकि आप केवल वही जानकारी ले रहे हैं जिसकी आपको जरूरत है।
00:13:26इसके साथ समस्या यह है कि यह पुराना पड़ जाता है।
00:13:28और इसलिए हर बार जब आप कोई नया फीचर शिप करते हैं,
00:13:31तो आपको इस आंतरिक डॉक्यूमेंटेशन के बड़े हिस्सों को
00:13:33कैश करना, मान्य करना और फिर से बनाना पड़ता है।
00:13:35और आप बहुत सारे AI का उपयोग कर सकते हैं
00:13:38और इसे अपडेट करने को अपनी प्रक्रिया का हिस्सा बना सकते हैं।
00:13:42क्यों न मैं एक सवाल पूछूँ?
00:13:43वास्तविक कोड, फंक्शन के नाम,
00:13:46कमेंट्स और डॉक्यूमेंटेशन के बीच,
00:13:48क्या कोई अंदाजा लगाना चाहता है कि इस चार्ट के y-एक्सिस पर क्या है?
00:13:50- स्लॉप (Slop)। - स्लॉप।
00:13:51यह वास्तव में झूठ की वह मात्रा है जो आपको
00:13:57अपने कोड बेस के किसी भी हिस्से में मिल सकती है।
00:13:58तो आप इसे अपडेट करने को अपनी प्रक्रिया का हिस्सा बना सकते हैं,
00:14:01लेकिन आपको शायद ऐसा नहीं करना चाहिए क्योंकि आप शायद करेंगे नहीं।
00:14:03हम जिसे पसंद करते हैं वह है 'ऑन-डिमांड कंप्रेस्ड कॉन्टेक्स्ट'।
00:14:06तो अगर मैं ऐसा फीचर बना रहा हूँ जो SCM प्रोवाइडर्स,
00:14:08JIRA और लीनियर (linear) से संबंधित है,
00:14:11तो मैं इसे बस थोड़ा सा निर्देश दूँगा।
00:14:14मैं कहूँगा, 'देखो, हम यहाँ कोड बेस के
00:14:15इस हिस्से में काम कर रहे हैं'।
00:14:17और एक अच्छा रिसर्च प्रॉम्प्ट या स्लैश कमांड
00:14:18कोड बेस के उन खास हिस्सों को समझने के लिए
00:14:21कई सब-एजेंट्स को काम पर लगा सकता है,
00:14:24और फिर एक रिसर्च डॉक्यूमेंट तैयार कर सकता है
00:14:27जो कोड पर आधारित बिल्कुल सटीक जानकारी हो।
00:14:30कोडबेस के माध्यम से और फिर एक रिसर्च डॉक्यूमेंट तैयार कर सकता है
00:14:33जो कि वास्तव में सच का एक स्नैपशॉट है
00:14:35स्वयं कोड के आधार पर, कोडबेस के वे हिस्से जो मायने रखते हैं।
00:14:39हम सत्य को संक्षिप्त (कंप्रेस) कर रहे हैं।
00:14:41योजना बनाना ही असली ताकत (लेवरेज) है।
00:14:43योजना बनाना इरादे के संक्षिप्तीकरण के बारे में है।
00:14:45और योजना में, हम सटीक चरणों की रूपरेखा तैयार करेंगे।
00:14:48आइए अपनी रिसर्च और अपनी PRD या अपनी बग टिकट को लें
00:14:50या जो कुछ भी वह है।
00:14:52हम एक योजना बनाते हैं और एक प्लान फ़ाइल तैयार करते हैं।
00:14:54तो हम इसे फिर से छोटा कर रहे हैं।
00:14:55और मैं रुककर मानसिक तालमेल (मेंटल अलाइनमेंट) के बारे में बात करना चाहता हूँ।
00:14:58क्या कोई जानता है कि कोड रिव्यू किस लिए होता है?
00:15:00मानसिक तालमेल, मानसिक तालमेल।
00:15:05यह सुनिश्चित करने के बारे में है कि चीजें सही हैं और बहुत कुछ।
00:15:08लेकिन सबसे महत्वपूर्ण बात यह है कि हम टीम में हर किसी को
00:15:10एक ही धरातल पर कैसे रखें
00:15:11कि कोडबेस कैसे बदल रहा है और क्यों?
00:15:14और मैं हर हफ्ते Golang की एक हजार लाइनें पढ़ सकता हूँ।
00:15:17क्षमा करें, मैं एक हजार नहीं पढ़ सकता।
00:15:18यह कठिन है, मैं कर सकता हूँ।
00:15:19पर मैं नहीं चाहता।
00:15:20और जैसे-जैसे हमारी टीम बढ़ती है, सारा कोड रिव्यू होता है।
00:15:23हम कोड को बिना पढ़े नहीं छोड़ते।
00:15:24लेकिन मैं, टीम के एक तकनीकी लीडर के रूप में,
00:15:27योजनाओं (प्लान्स) को पढ़ सकता हूँ और अपडेट रह सकता हूँ।
00:15:29और मेरे लिए इतना ही काफी है।
00:15:30मैं कुछ समस्याओं को जल्दी पकड़ सकता हूँ
00:15:32और मैं इस बात की समझ बनाए रखता हूँ कि सिस्टम कैसे विकसित हो रहा है।
00:15:35मिचेल की एक बहुत अच्छी पोस्ट थी
00:15:36कि कैसे वह अपने AMP थ्रेड्स को
00:15:38अपने पुल रिक्वेस्ट्स पर डाल रहे हैं ताकि आप न केवल यह देख सकें कि,
00:15:41हे, यहाँ GitHub में हरे रंग की टेक्स्ट की एक दीवार है,
00:15:43बल्कि यहाँ सटीक चरण हैं, यहाँ प्रॉम्प्ट्स हैं,
00:15:44और हे, मैंने अंत में बिल्ड चलाया और यह पास हो गया।
00:15:46यह रिव्यूअर को एक ऐसी यात्रा पर ले जाता है
00:15:49जैसा कि एक GitHub PR कभी नहीं कर सकता।
00:15:51और जैसे-जैसे आप दो से तीन गुना
00:15:52ज़्यादा कोड शिप कर रहे हैं,
00:15:54तो यह आपकी ज़िम्मेदारी है कि आप अपनी टीम को
00:15:57एक ही धरातल पर रखने के तरीके खोजें और उन्हें दिखाएं कि मैंने ये कदम उठाए
00:16:00और हमने इसका मैन्युअल रूप से परीक्षण कैसे किया।
00:16:01आपका लक्ष्य लेवरेज है, इसलिए आप उच्च स्तर का भरोसा चाहते हैं
00:16:04कि मॉडल वास्तव में सही काम करेगा।
00:16:06मैं सिर्फ इस योजना को पढ़कर यह नहीं जान सकता कि वास्तव में
00:16:08क्या होने वाला है और कोड में क्या बदलाव होने वाले हैं।
00:16:11इसलिए हमने समय के साथ बदलाव किए हैं ताकि हमारी योजनाओं में
00:16:14बदलने वाले कोड के वास्तविक स्निपेट्स शामिल हों।
00:16:17तो आपका लक्ष्य लेवरेज है।
00:16:18आप इरादे का संक्षिप्तीकरण चाहते हैं
00:16:19और आप विश्वसनीय निष्पादन चाहते हैं।
00:16:22और जैसा कि, मुझे नहीं पता, मेरा बैकग्राउंड फिजिक्स का है।
00:16:23हमें चोटियों और वक्रों (peaks and curves) के केंद्र से रेखाएं खींचना पसंद है।
00:16:28जैसे-जैसे आपकी योजनाएँ लंबी होती जाती हैं, विश्वसनीयता बढ़ती है,
00:16:30पठनीयता कम हो जाती है।
00:16:31आपके, आपकी टीम और आपके कोडबेस के लिए एक 'स्वीट स्पॉट' है,
00:16:33आपको उसे खोजने की कोशिश करनी चाहिए।
00:16:35क्योंकि जब हम रिसर्च और योजनाओं का रिव्यू करते हैं,
00:16:37यदि वे अच्छे हैं, तो हम मानसिक तालमेल बिठा सकते हैं।
00:16:40सोचने का काम आउटसोर्स न करें।
00:16:42मैंने यह पहले भी कहा है, यह कोई जादू नहीं है।
00:16:44कोई परफेक्ट प्रॉम्प्ट नहीं होता।
00:16:46यदि आप योजना नहीं पढ़ते हैं, तो यह काम नहीं करेगा।
00:16:50इसलिए हमने अपनी पूरी प्रक्रिया आपके इर्द-गिर्द बनाई है, जहाँ आप निर्माता (builder),
00:16:53एजेंट के साथ लगातार संवाद में रहते हैं,
00:16:55और योजनाओं को बनते ही पढ़ते हैं।
00:16:56और फिर यदि आपको पीयर रिव्यू की आवश्यकता है,
00:16:58तो आप इसे किसी को भेज सकते हैं और कह सकते हैं,
00:16:58हे, क्या यह योजना सही लग रही है?
00:17:00क्या यह सही दृष्टिकोण है?
00:17:00क्या इन चीजों को देखने का यह सही क्रम है?
00:17:03जेक ने फिर से एक बहुत अच्छा ब्लॉग पोस्ट लिखा कि
00:17:05रिसर्च-प्लान-इम्प्लीमेंट को जो चीज़ मूल्यवान बनाती है
00:17:07वह है आप, यानी 'ह्यूमन इन द लूप', जो यह सुनिश्चित करता है कि यह सही है।
00:17:11तो अगर आप इस बातचीत से एक चीज़ सीखकर जाते हैं,
00:17:14तो वह यह होनी चाहिए कि कोड की एक खराब लाइन, एक खराब लाइन ही होती है।
00:17:17और योजना का एक खराब हिस्सा 100 खराब कोड लाइनों के बराबर हो सकता है।
00:17:22और रिसर्च की एक खराब लाइन, जैसे सिस्टम कैसे काम करता है
00:17:25और चीजें कहाँ हैं, इस बारे में गलतफहमी,
00:17:27तो आपका पूरा काम बिगड़ जाएगा।
00:17:29आप मॉडल को गलत दिशा में भेज रहे होंगे।
00:17:31और इसलिए जब हम आंतरिक रूप से और यूजर्स के साथ काम कर रहे होते हैं,
00:17:34तो हम लगातार मानवीय प्रयास और ध्यान को
00:17:36इस पाइपलाइन के उच्चतम लेवरेज वाले हिस्सों में ले जाने की कोशिश कर रहे हैं।
00:17:39सोचने का काम आउटसोर्स न करें।
00:17:41उन टूल्स से सावधान रहें जो सिर्फ आपको अच्छा महसूस कराने के लिए
00:17:43ढेर सारी मार्कडाउन फाइलें उगलते रहते हैं।
00:17:45मैं यहाँ किसी का नाम नहीं लूँगा।
00:17:47कभी-कभी यह सब ज़रूरत से ज़्यादा होता है।
00:17:49और जिस तरह से मैं इसके बारे में सोचना पसंद करता हूँ वह यह है कि,
00:17:51हाँ, आपको हमेशा पूरी रिसर्च-प्लान-इम्प्लीमेंट की ज़रूरत नहीं होती।
00:17:54कभी आपको ज़्यादा की ज़रूरत होती है, कभी कम की।
00:17:56अगर आप किसी बटन का रंग बदल रहे हैं,
00:17:57तो बस एजेंट से बात करें और उसे बताएं कि क्या करना है।
00:18:00यदि आप एक साधारण योजना बना रहे हैं और यह एक छोटी सुविधा है,
00:18:04यदि आप कई रिपॉजिटरी में मध्यम स्तर की सुविधाएँ बना रहे हैं,
00:18:07तो एक रिसर्च करें, फिर एक योजना बनाएं।
00:18:09मूल रूप से, आप जितनी कठिन समस्या हल कर सकते हैं,
00:18:10उसकी सीमा उतनी ही बढ़ती जाती है, जितना अधिक आप यह कॉन्टेक्स्ट इंजीनियरिंग
00:18:13और कॉम्पैक्शन करने के लिए तैयार होते हैं।
00:18:15और इसलिए यदि आप शीर्ष दाएं कोने (top right corner) में हैं,
00:18:18तो आपको शायद ज़्यादा करना होगा।
00:18:19बहुत से लोग मुझसे पूछते हैं, मुझे कैसे पता चलेगा
00:18:21कि कितनी कॉन्टेक्स्ट इंजीनियरिंग का उपयोग करना है?
00:18:23इसमें अभ्यास (reps) लगता है।
00:18:24आप गलतियाँ करेंगे, आपको बार-बार
00:18:26गलतियाँ करनी होंगी।
00:18:27कभी-कभी आप बहुत ज़्यादा करेंगे, कभी-कभी बहुत कम।
00:18:29एक टूल चुनें और उसका अभ्यास करें।
00:18:32मैं क्लॉड और कोडेक्स और इन सभी विभिन्न टूल्स के बीच
00:18:35मिन-मैक्सिंग (हर चीज़ का थोड़ा-थोड़ा उपयोग) करने के खिलाफ सलाह देता हूँ।
00:18:36वैसे मैं परिवर्णी शब्दों (acronyms) का बहुत बड़ा शौकीन नहीं हूँ।
00:18:40हमने कहा कि स्पेक-संचालित देव (spec-driven dev) पुराना हो चुका है।
00:18:42मुझे नहीं लगता कि रिसर्च-प्लान-इम्प्लीमेंट ही हमेशा स्टेप्स रहेंगे।
00:18:44महत्वपूर्ण हिस्सा कॉम्पैक्शन, कॉन्टेक्स्ट इंजीनियरिंग
00:18:47और स्मार्ट ज़ोन में बने रहना है।
00:18:48लेकिन लोग इसे RPI कह रहे हैं
00:18:50और मैं इसमें कुछ नहीं कर सकता।
00:18:52तो बस सावधान रहें, कोई भी परफेक्ट प्रॉम्प्ट नहीं है,
00:18:55कोई रामबाण इलाज नहीं है।
00:18:56अगर आप वास्तव में कोई बहुत प्रचलित (hype-y) शब्द चाहते हैं,
00:18:58तो आप इसे 'हार्नेस इंजीनियरिंग' कह सकते हैं,
00:19:00जो कॉन्टेक्स्ट इंजीनियरिंग का हिस्सा है
00:19:01और यह इस बारे में है कि आप इंटीग्रेशन पॉइंट्स के साथ कैसे जुड़ते हैं
00:19:03चाहे वह Codex, Claude, Cursor या कुछ भी हो,
00:19:05और आप अपने कोडबेस को कैसे कस्टमाइज़ करते हैं।
00:19:07तो आगे क्या है?
00:19:11मुझे लगता है कि कोडिंग एजेंट वाली चीजें वास्तव में
00:19:12आम बात (commoditized) होने वाली हैं।
00:19:13लोग इसे करना सीखेंगे और इसमें बेहतर होंगे।
00:19:15और कठिन हिस्सा यह होगा कि आप अपनी टीम
00:19:17और SDLC में अपने वर्कफ़्लो को एक ऐसी दुनिया में कैसे ढालते हैं
00:19:21जहाँ आपका 99% कोड AI द्वारा शिप किया जाता है।
00:19:24और अगर आप इसे समझ नहीं पाते हैं, तो आप मुसीबत में हैं।
00:19:26क्योंकि एक तरह की दूरी बढ़ रही है
00:19:27जहाँ स्टाफ इंजीनियर्स AI नहीं अपनाते
00:19:29क्योंकि यह उन्हें उतना तेज़ नहीं बनाता
00:19:31और फिर जूनियर और मिड-लेवल इंजीनियर्स इसका बहुत उपयोग करते हैं
00:19:33क्योंकि यह उनके कौशल की कमियों को भरता है
00:19:35और फिर यह कुछ घटिया कोड (slop) भी पैदा करता है
00:19:36और फिर सीनियर इंजीनियर्स इससे और भी ज़्यादा नफरत करते हैं
00:19:38क्योंकि वे उस घटिया कोड की सफाई कर रहे होते हैं,
00:19:40जिसे पिछले हफ्ते Cursor द्वारा शिप किया गया था।
00:19:42यह AI की गलती नहीं है,
00:19:44यह मिड-लेवल इंजीनियर की गलती नहीं है।
00:19:46सांस्कृतिक परिवर्तन (Cultural change) बहुत कठिन है
00:19:48और इसे सफल होने के लिए शीर्ष नेतृत्व से आना होगा।
00:19:50तो अगर आप अपनी कंपनी के तकनीकी लीडर हैं,
00:19:52तो एक टूल चुनें और उसका अभ्यास करें।
00:19:54अगर आप मदद करना चाहते हैं, तो हम नियुक्तियाँ (hiring) कर रहे हैं,
00:19:56हम एक एजेंटिक IDE बना रहे हैं ताकि हर आकार की टीमों को
00:19:5999% AI-जनरेटेड कोड की यात्रा में तेज़ी लाने में मदद मिल सके।
00:20:03अगर आप हमारे साथ काम करना चाहते हैं तो हमें खुशी होगी।
00:20:06हमारी वेबसाइट पर जाएँ, हमें ईमेल भेजें,
00:20:08या हॉलवे में मुझसे आकर मिलें।
00:20:09आपकी ऊर्जा के लिए आप सभी का बहुत-बहुत धन्यवाद।
00:20:11(दर्शक तालियाँ बजाते हैं)
00:20:13(उत्साही इलेक्ट्रॉनिक संगीत)