00:00:00Anthropic ने अभी कुछ बहुत बड़ा किया है, उन्होंने 16 Claude एजेंट्स को आज़ाद छोड़ दिया ताकि वे बना सकें
00:00:05एक C कंपाइलर, और दो हफ़्तों तक लगातार 24/7 चलने के बाद, उन्होंने वाकई एक ऐसा कंपाइलर बना लिया जो कंपाइल कर सकता था
00:00:11Linux कर्नल को और यहाँ तक कि Doom गेम भी चला सकता था, जो बेहद प्रभावशाली है और निश्चित रूप से Opus 4 के
00:00:16पुराने वर्ज़न के साथ संभव नहीं था। लेकिन लोग इस उपलब्धि को सिर्फ 'क्लिकबेट' और
00:00:22एक आधा-सच कह रहे हैं क्योंकि Anthropic ने इस नतीजे तक पहुँचने के लिए कुछ विवादास्पद तकनीकों का इस्तेमाल किया है।
00:00:28तो, क्या Anthropic ने धोखाधड़ी की? सब्सक्राइब बटन दबाएं और चलिए पता लगाते हैं।
00:00:31हम इस वीडियो को तीन हिस्सों में बाटेंगे। पहले, हम देखेंगे कि प्रयोग कैसे सेटअप किया गया था,
00:00:37फिर हम मुख्य खोजों के बारे में बात करेंगे, जिससे मुझे लगता है कि हर डेवलपर को बहुत कुछ सीखने को मिलेगा,
00:00:42और अंत में, हम देखेंगे कि क्या नतीजे मान्य हैं, क्योंकि इस कंपाइलर को बनाने के तरीके पर मेरी कुछ अपनी राय है।
00:00:47ठीक है, यह प्रयोग निकोलस कार्लिनी द्वारा किया गया था, जो मेरी नज़र में एक बहुत ही बुद्धिमान इंसान हैं। मेरा मतलब है, चलिए देखते हैं कि उन्होंने
00:00:52इसे कैसे सेटअप किया। असल प्रोजेक्ट 'Upstream' नामक एक डायरेक्टरी में था, जिसे
00:00:5816 अलग-अलग Docker कंटेनर्स से जोड़ा गया था। मैं जानता हूँ कि यहाँ सिर्फ चार दिख रहे हैं, पर मान लेते हैं कि यहाँ 16 हैं।
00:01:03इनमें से हर Docker कंटेनर में Opus 4.6 पर चलने वाला Claude कोड का एक वर्ज़न था और
00:01:08वह Upstream रेपो को वर्कस्पेस में क्लोन करता, वर्कस्पेस में सारे बदलाव करता और फिर
00:01:15उसे वापस Upstream में पुश कर देता। यह वाकई बहुत स्मार्ट तरीका था क्योंकि हर एजेंट दूसरे एजेंट के काम को
00:01:21प्रभावित किए बिना अकेले काम कर सकता था। अब, अगर कभी 'मर्ज कॉन्फ्लिक्ट' होता, तो Claude
00:01:27उसे सुलझाने और फिर वापस Upstream में पुश करने के लिए काफी समझदार था। हर एजेंट कुछ टास्क में से चुनाव करता।
00:01:32अब, मुझे पक्का नहीं पता कि ये टास्क किसी इंसान ने बनाए थे या किसी एजेंट ने टेस्ट रन करने के आधार पर
00:01:38बनाए थे, लेकिन कुछ नाम के साथ टास्क मौजूद थे और हर एजेंट एक नया टास्क उठाता था,
00:01:44और जब भी वह नया टास्क लेता, तो वह एक नया सेशन शुरू करता था। इन एजेंट्स को लंबे समय तक चालू रखने के लिए,
00:01:50एक 'Ralph loop' का इस्तेमाल किया गया था, जिससे एजेंट टास्क पर काम करते, उसे पूरा करते, Upstream में पुश करते,
00:01:56फिर नए सेशन के साथ नया टास्क उठाते और बार-बार यही करते रहते। अब, अगर आपने 'Ralph' पर हमारा वीडियो देखा है,
00:02:02तो आप जानते होंगे कि लंबे समय तक चलने वाले एजेंट्स की कुंजी स्पष्ट रूप से परिभाषित टास्क होना है। लेकिन अगर आपके पास एक ही समय में 16 एजेंट्स चल रहे हैं,
00:02:08तो आप उन्हें एक ही टास्क चुनने से कैसे रोकते हैं? टास्क लॉक-इन के जरिए। यह कुछ ऐसे काम करता है जिसे
00:02:13लेखक ने साफ़ तौर पर नहीं बताया है, लेकिन टास्क की एक लिस्ट मौजूद होती है और एजेंट एक टास्क चुनकर उसे
00:02:19उस टास्क के नाम वाली एक टेक्स्ट फाइल देता है, फिर उस टास्क को लॉक करने के लिए एक 'कमिट' बनाता है ताकि सिर्फ वही उस पर काम कर सके
00:02:24और उसे Upstream डायरेक्टरी में पुश कर देता है। अगर कोई दूसरा एजेंट वही टास्क चुनता है
00:02:30और वैसी ही टेक्स्ट फाइल बनाता है, तो Upstream रेपो में पुश करने की कोशिश करते समय Git उसे यह कहकर रिजेक्ट कर देगा
00:02:36कि वह फाइल पहले से मौजूद है, और फिर उन्हें किसी दूसरे टास्क पर काम करना पड़ेगा। यही वह आधार है
00:02:42जिससे कार्लिनी ने Opus 4.6 द्वारा संचालित इन एजेंट्स की क्षमता का परीक्षण किया और नतीजे वाकई अद्भुत हैं।
00:02:48लेकिन इस प्रयोग को करने के बाद, उन्होंने कुछ दिलचस्प बातें खोजी हैं जिनसे मुझे लगता है
00:02:53कि हर एक डेवलपर सीख सकता है। पहली चीज़ है एक 'टेस्ट हार्नेस' या एक ऐसी स्क्रिप्ट बनाना जो
00:03:00अलग-अलग तरह के टेस्ट चलाए, क्योंकि जब निक प्रयोग कर रहे थे—हाँ, अब हम इतने करीब हैं कि मैं उन्हें निक बुला सकता हूँ—
00:03:07तो उन्होंने अनुभव किया कि जब भी किसी नए फीचर पर काम होता, Claude पुराने फीचर्स को खराब कर देता था।
00:03:12इसलिए उन्होंने SQLite, libjpg और Redis जैसे लोकप्रिय ओपन सोर्स रेपो से हाई क्वालिटी टेस्ट का एक टेस्ट हार्नेस बनाया।
00:03:17और कॉन्टेक्स्ट प्रदूषण को रोकने के लिए, उन्होंने सुनिश्चित किया कि टेस्ट हार्नेस सिर्फ वही लॉग दिखाए जो एजेंट के लिए उपयोगी हों,
00:03:23यानी मुख्य रूप से एरर लॉग, और बाकी सभी तरह के लॉग के लिए एक अलग फाइल बना दी ताकि Claude ज़रूरत पड़ने पर उन्हें देख सके।
00:03:29हालांकि, हज़ारों टेस्ट होने के कारण, एजेंट्स को पूरा टेस्ट सुइट चलाने में घंटों लग जाते, जबकि वे उस
00:03:35समय का इस्तेमाल कुछ और करने के लिए कर सकते थे। यहीं पर निक ने कुछ बहुत चालाकी वाला काम किया। उन्होंने
00:03:41अपने टेस्ट हार्नेस में एक 'fast flag' जोड़ दिया, जिसका मतलब था कि एजेंट निक द्वारा तय की गई संख्या के आधार पर
00:03:47कुल टेस्ट का केवल 1% या 10% ही चलाएगा। और अगर हर एजेंट ने 10% चलाया, तो वह कुल मिलाकर 160% टेस्ट होंगे,
00:03:52जो पर्याप्त से भी ज़्यादा है, और यह कोई बुरी बात नहीं है। यह कुछ इस तरह काम करता था कि टेस्ट,
00:03:58यानी हर एजेंट द्वारा चलाए गए विशिष्ट टेस्ट रैंडमाइज़्ड थे, लेकिन 'seed number' एक ही था, जिससे यह
00:04:05डिटरमिनिस्टिक बन गया। तो हर एजेंट के पास वही रैंडम टेस्ट होंगे और वे अकेले पूरा टेस्ट सुइट चलाने की तुलना में
00:04:13काफी तेज़ी से पूरे सुइट को कवर कर लेंगे। अगला पॉइंट भी स्मार्ट है, लेकिन थोड़ा विवादास्पद भी,
00:04:19क्योंकि इसमें मौजूदा तकनीक का इस्तेमाल करना शामिल है। अब तक, हर एजेंट कई मौजूदा ओपन सोर्स प्रोजेक्ट्स से
00:04:25यूनिट टेस्ट चला रहा था, जो 1% या 10% के टुकड़ों में बंटने पर अच्छा काम कर रहा था। लेकिन जब
00:04:31Linux कर्नल को कंपाइल करने की बारी आई, तो चूंकि ये सोर्स फाइलें व्यक्तिगत यूनिट टेस्ट नहीं हैं,
00:04:36चीज़ें थोड़ी मुश्किल हो गईं क्योंकि हर एजेंट पूरे कर्नल को कंपाइल करने की कोशिश करता, उसे वही एरर मिलता,
00:04:41और फिर वे उसे ठीक करने की कोशिश करते हुए एक-दूसरे के सुधार को ओवरराइट कर देते। तो निक ने इसका रास्ता भी यही निकाला
00:04:46कि हर एजेंट को कंपाइलेशन का एक हिस्सा चलाने दिया जाए और फिर GCC, यानी GNU
00:04:53कंपाइलर से बाकी का काम करवाया जाए। निक ने GCC को “ओरेकल” कहा क्योंकि Linux कर्नल इसके साथ
00:04:58बिल्कुल सही ढंग से कंपाइल होना चाहिए। इसलिए अगर किसी एजेंट ने Linux कर्नल के एक हिस्से को अपने खुद के कंपाइलर से कंपाइल किया,
00:05:04यानी हर एजेंट के लिए एक अलग हिस्सा, और बाकी GCC के साथ, और अगर कुछ बिगड़ा, तो वह निश्चित रूप से
00:05:09एजेंट का कंपाइलर था न कि GCC, और इसलिए एजेंट दूसरे एजेंट के बग को ठीक करने के बजाय सिर्फ उसी चीज़ को ठीक करेगा।
00:05:15अब यह विवादास्पद है क्योंकि इसमें एक मौजूदा कंपाइलर का इस्तेमाल उस काम को करने के लिए किया जा रहा है जिसे Claude को
00:05:22शून्य से (from scratch) करने के लिए कहा गया था। लेकिन हम इसके बारे में वीडियो के अंत में और बात करेंगे। अगले पॉइंट पर चलते हैं,
00:05:27जो है अपने एजेंट को 'मेमोरी' देना। चूंकि नए टास्क पर Claude के नए सेशन काम करते हैं जिनके पास
00:05:34पहले किए गए काम की लगभग कोई याददाश्त नहीं होती, इसलिए निक को 'readme' फाइल अपडेट करना और
00:05:40अलग-अलग प्रोग्रेस फाइलों में निर्देश देना उपयोगी लगा कि काम कहाँ रुका था और प्रोजेक्ट की क्या स्थिति है,
00:05:46ताकि नए सेशन के पास शुरू करने के लिए एक अच्छा आधार हो और वे उन बग्स को वापस न लाएं जिन्हें पहले ही ठीक किया जा चुका है।
00:05:51और आखिरी अधिक स्पष्ट बात यह है कि अपने एजेंट्स को अलग-अलग भूमिकाएं (roles) दें। एक ही समय में समानांतर रूप से
00:05:57एक ही कोड बेस पर कई एजेंट्स के काम करने की खूबसूरती यह है कि कोड के एक ही हिस्से पर एक साथ कई चीज़ें की जा सकती हैं।
00:06:03तो जब नया कोड नहीं लिखा जा रहा था, तब निक ने एजेंट्स को अनोखी भूमिकाएं दीं जैसे
00:06:09एक डुप्लीकेट कोड चेक करने के लिए, दूसरा कोड को जितना संभव हो उतना बेहतर बनाने (performance) का तरीका खोजने के लिए,
00:06:13और उन्होंने एक एजेंट को एक 'Rust डेवलपर' के नज़रिए से डिजाइन की आलोचना करने के लिए भी रखा, जिसे मैं उम्मीद करता हूँ कि
00:06:18उसने दूसरे एजेंट्स को यह नहीं बताया होगा कि वह एक Rust डेवलपर है। लेकिन यह प्रोजेक्ट जितना सफल रहा,
00:06:23असली सवाल यह है कि क्या Anthropic ने यह परिणाम पाने के लिए धोखाधड़ी की? खैर, एक तरह से हाँ।
00:06:29तो टास्क एक C कंपाइलर को शून्य से बनाना था और एजेंट के पास इंटरनेट का एक्सेस नहीं था, इसलिए उसने
00:06:35सारा कोड खुद ही बनाया। या फिर ऐसा नहीं है? क्योंकि उसके पास ओपन सोर्स प्रोजेक्ट्स के टेस्ट सुइट्स का एक्सेस था
00:06:40और उसके पास GCC के कंपाइल किए गए वर्ज़न का भी एक्सेस था। तो तकनीकी रूप से वह GCC कंपाइलर को बार-बार जाँच सकता था,
00:06:45उसे इनपुट देकर और आउटपुट का निरीक्षण करके, और उस जानकारी का इस्तेमाल Rust में लिखे जा रहे अपने खुद के कंपाइलर के डिजाइन को दिशा देने में कर सकता था।
00:06:51लेकिन ईमानदारी से कहूँ तो, अगर मैं भी शून्य से एक C कंपाइलर बना रहा होता, तो मैं भी यही करता।
00:06:57मैं मौजूदा कंपाइलर्स को देखता, वे कैसे लागू किए गए हैं यह समझता और अपने कंपाइलर की दिशा तय करने में उसका इस्तेमाल करता।
00:07:03अब, अगर मैं बिल्कुल नई भाषा (language) के लिए कंपाइलर बना रहा होता, तो ज़ाहिर है कि चीज़ें बहुत मुश्किल होतीं
00:07:10और शायद Claude के लिए यह देखना एक बहुत अच्छा टेस्ट होता कि क्या वह वास्तव में शून्य से कंपाइलर बनाने में सक्षम है।
00:07:16शायद निक के लिए आज़माने के लिए यह एक और विचार है, लेकिन चलिए इस प्रयोग की स्वायत्त (autonomous) प्रकृति के बारे में बात करते हैं
00:07:24चूंकि उसका भी परीक्षण किया गया था। और निष्पक्ष रूप से कहें तो, हाँ, Claude ने सारा कोड खुद ही लिखा था, लेकिन
00:07:31उसे एक इंसान से भारी मार्गदर्शन मिला था। एक इंसान ने तय किया कि कौन सा टेस्ट सुइट चलाना है। एक इंसान ने लूप शुरू किया
00:07:36और 'routes' इस्तेमाल करने का फैसला किया। एक इंसान ही वह था जिसने टेस्ट हार्नेस बनाया और एजेंट्स को विशिष्ट भूमिकाएं दीं।
00:07:41तो हालांकि यह इससे बहुत अलग है कि कोई Claude से बस कंपाइलर बनाने को कहे और उसे हमेशा के लिए चलने के लिए छोड़ दे,
00:07:47मैं यह नहीं कहूँगा कि यह कोड एक ऐसे एजेंट द्वारा लिखा गया था जो शत-प्रतिशत स्वायत्त था, क्योंकि
00:07:53अगर इसमें कोई इंसान शामिल नहीं होता, तो यह कंपाइलर कितना अच्छा होता? और एक इंसान द्वारा डिजाइन किए गए इन सभी सिस्टम्स के बावजूद,
00:07:57Claude के C कंपाइलर की कुछ मुख्य सीमाएँ थीं। उदाहरण के लिए, इसने GCC के असेंबलर और लिंकर का इस्तेमाल किया क्योंकि
00:08:04इसके द्वारा बनाया गया वर्ज़न बहुत ही दोषपूर्ण (buggy) था। इसे Linux को बूट करने के लिए GCC के 16-बिट x86 कंपाइलर की भी ज़रूरत पड़ी।
00:08:11और सबसे बढ़कर, इसका कोड बहुत कुशल नहीं था। Claude के कंपाइलर का सबसे ऑप्टिमाइज़्ड वर्ज़न
00:08:16GCC कंपाइलर के सबसे कम ऑप्टिमाइज़्ड वर्ज़न से भी कम प्रदर्शन करने वाला था। तो ऐसा लगता है कि डेवलपर्स
00:08:22अभी कहीं नहीं जा रहे हैं, या कम से कम अभी के लिए तो नहीं।
00:08:28autonomous because how good would the compiler have been if a human wasn't involved in the first place?
00:08:33And even with all the systems in place designed by a human, the Claude C compiler did have some
00:08:39key limitations. For example, it used the assembler and linker from GCC because the one it created was
00:08:46too buggy. It also needed GCC's 16-bit x86 compiler in order to boot up Linux. And to top that all off,
00:08:54the code wasn't very efficient. The most optimized version of the Claude's compiler was less
00:09:00performant than the least optimized version of the GCC compiler. So it looks like developers
00:09:05aren't going anywhere anytime soon, or at least for now.