समानांतर Claude टीम के साथ C compiler बनाना

• 16 Claude agents ने समानांतर सहयोग से Rust-आधारित C compiler पूरा किया, जो Linux 6.9 kernel को build कर सकने के स्तर तक पहुँचा
• लगभग 2,000 sessions और 20,000 डॉलर की लागत में 100,000 lines के स्तर का code बनाया गया, और x86·ARM·RISC-V architectures का support जोड़ा गया
• agents ने automatic loop harness के जरिए मानव हस्तक्षेप के बिना लगातार काम किया, और testing·parallelization·role division संरचना से दक्षता बढ़ाई
• परिणाम में GCC compatibility और उच्च test pass rate दिखा, लेकिन 16-bit x86 code generation·linker·optimization quality जैसे हिस्से अभी अधूरे हैं
• यह प्रयोग autonomous LLM team की सीमाओं और संभावनाओं को परखने का उदाहरण है, और आगे fully autonomous development environment की safety और quality management को मुख्य चुनौती के रूप में सामने लाता है

---

एजेंट टीम-आधारित C compiler प्रोजेक्ट का अवलोकन

• कई Claude instances ने समानांतर सहयोग से एक codebase विकसित करने का प्रयोग किया
  • मानव के real-time हस्तक्षेप के बिना स्वायत्त रूप से code लिखना·test करना·fix करना बार-बार दोहराया गया
• लक्ष्य था Rust में लिखा गया C compiler पूरा करना और उससे Linux kernel को सीधे build करना
• कुल 16 agents, लगभग 2,000 sessions, और 20 करोड़ input tokens·14 करोड़ output tokens का उपयोग हुआ
• परिणामस्वरूप 100,000 lines के स्तर का compiler बना, जो Linux 6.9 kernel और प्रमुख open source projects (QEMU, FFmpeg, SQLite, Redis आदि) को build कर सकता है

लंबे समय तक चलने वाले execution के लिए Claude harness की डिजाइन

• पहले Claude Code को मानव input चाहिए होता था, लेकिन infinite loop structure वाले automatic execution harness से स्वायत्त प्रगति संभव हुई
  • हर task पूरा होने के बाद तुरंत अगला task करने वाली automatic repeat structure
  • काम के दौरान Claude ने गलती से pkill -9 bash चलाकर खुद को बंद भी कर दिया था
• parallel execution structure में Docker containers और Git synchronization का उपयोग किया गया
  • हर agent /workspace में काम करने के बाद /upstream पर push करता था
  • text file-आधारित lock से task conflicts रोके गए
  • merge conflicts भी Claude ने खुद हल किए

समानांतर Claude संचालन का तरीका

• parallel execution का लाभ simultaneous debugging और role specialization में मिला
  • कुछ agents code लिखते थे, जबकि कुछ documentation·quality management·performance optimization संभालते थे
• कोई communication layer या central coordinator नहीं था; हर agent स्वायत्त रूप से अगला task चुनता था
• Git history में हर agent के task lock records और progress documents दर्ज रहे

Claude टीम programming से मिली सीख

high-quality testing का महत्व

• Claude दिए गए tests के आधार पर स्वायत्त रूप से काम करता है, इसलिए verifier की accuracy सबसे अहम है
  • false positive होने पर development गलत दिशा में जा सकता है
• continuous integration (CI) pipeline बनाकर यह सुनिश्चित किया गया कि मौजूदा features टूटें नहीं
• quality बनाए रखने के लिए open source build scripts और compiler test suites का उपयोग किया गया

Claude के नजरिए से environment design

• हर agent context के बिना नए container से शुरू करता था, इसलिए progress documentation अनिवार्य थी
  • README और progress files को लगातार update करने के निर्देश दिए गए
• context pollution की रोकथाम: logs को न्यूनतम रखा गया और errors को ERROR keyword से पहचानने योग्य बनाया गया
• time awareness की कमी की भरपाई के लिए --fast option के साथ 1–10% sample tests चलाए गए

parallelization की सीमाएँ और समाधान

• जब independent tests अधिक हों तो parallelization आसान होती है, लेकिन Linux kernel build एक बड़ा single task होने के कारण conflicts पैदा हुए
• समाधान के तौर पर GCC को reference compiler oracle की तरह इस्तेमाल किया गया
  • कुछ files GCC से, और बाकी Claude compiler से build की गईं
  • failure होने पर problematic files को सीमित करते हुए parallel debugging संभव हुई
  • बाद में delta debugging से interdependent errors पकड़ी गईं

agents की role specialization

• duplicate code हटाना, performance सुधारना, efficient code generation, Rust structure सुधारना, documentation आदि जैसे विशेषीकृत role division अपनाए गए
• parallelization और specialization को मिलाकर बड़े codebase के management की दक्षता बढ़ाई गई

Opus 4.6 model का performance evaluation

• Opus 4.5 तक बड़े projects build नहीं हो पाते थे; Opus 4.6 में पहली बार व्यावहारिक स्तर हासिल हुआ
• clean-room implementation के रूप में internet access के बिना केवल Rust standard library का उपयोग किया गया
• GCC torture test suite में 99% pass rate, और Doom चलाने में सफलता मिली
• सीमाएँ:
  • 16-bit x86 code generation संभव नहीं, इसलिए boot stage में GCC को बुलाना पड़ता है
  • assembler·linker अधूरे हैं, और कुछ bugs मौजूद हैं
  • generated code की efficiency कम है, और GCC optimization बंद होने की स्थिति से भी कम प्रभावी है
  • Rust code quality ठीक-ठाक है, लेकिन expert level की नहीं

autonomous agent team की सीमाएँ और संभावनाएँ

• यह प्रोजेक्ट LLM autonomous collaboration की limits मापने के लिए एक benchmark है
• पूरी तरह autonomous development में quality assurance·security risks शामिल हैं
  • केवल tests pass होने को पूर्णता मान लेने का जोखिम है
• मानव verification के बिना code deploy करने को लेकर चिंता जताई गई
• फिर भी, यह साबित हुआ कि autonomous agent teams जटिल projects पूरे कर सकती हैं
• आगे model development के साथ safe autonomous development strategies को अनिवार्य कार्य माना गया है

आगे की दिशा

• language models का विकास IDE autocomplete → function completion → pair programming → autonomous project execution की दिशा में बढ़ रहा है
• Agent teams पूरी तरह autonomous development की संभावना दिखाती हैं
• तेज तकनीकी प्रगति पर आश्चर्य के साथ-साथ नए ethics·safety frameworks की जरूरत पर जोर दिया गया
• उम्मीद है कि सकारात्मक उपयोग नकारात्मक जोखिमों की भरपाई करेगा, लेकिन नए development paradigm के लिए तैयारी जरूरी है

[mammal]

यह कोई C में बना compiler प्रोजेक्ट नहीं है, बल्कि सिर्फ Rust standard library से बना प्रोजेक्ट है, इसलिए यह आलोचना कि gcc/clang C code उसके training data में था, मुझे कुछ हद तक goalpost shifting लगती है। फिर भी, यह प्रभावशाली है।

[GN⁺]

Hacker News की राय

• मैंने Google में लगभग 10 साल तक Clang से Linux kernel build करने पर काम किया है। यह प्रोजेक्ट(clangbuiltlinux.github.io) कहता है कि LLM ने वही काम 2,000 sessions और $20,000 के API खर्च में कर दिखाया। यह सच में boot भी हो गया, यह सुनकर हैरानी होती है। हालांकि, जनरेट किए गए कोड की efficiency कम है, और यह GCC के बिना optimization वाले version से भी कम efficient बताया गया है। फिर भी यह सचमुच शानदार प्रोजेक्ट है

  • शानदार तो है, लेकिन हो सकता है कि यह किसी और का homework नकल करने का नतीजा हो
  • कहा गया है कि Opus 16-bit x86 code generator लागू नहीं कर पाया, इसलिए boot चरण में GCC को बुलाने वाला जुगाड़ इस्तेमाल किया गया। इसलिए क्या यह सच में boot हुआ, इस पर सवाल है
  • यह कुछ ऐसा लगता है जैसे Ken Thompson का “Trusting Trust” दौर फिर लौट रहा हो। AI जल्द compiler के अंदर खुद को ही बिठा सकता है
  • अगर $20,000 लगे, तो उस पैसे में थोड़े समय के लिए 8 senior developers रखे जा सकते थे। लगता है marketing cost बहुत ज़्यादा थी, और असली revenue model साफ़ नहीं है

• यह Cursor browser project से कहीं ज़्यादा वास्तविक दृष्टिकोण है। इसे clean-room implementation कहा गया है, क्योंकि इंटरनेट access के बिना सिर्फ Rust standard library का इस्तेमाल किया गया। कहा गया है कि 100,000 lines का compiler Linux 6.9, QEMU, FFmpeg, SQLite, Postgres और Redis तक build कर सकता है।
  Opus 4.5 पहली बार बड़े tests pass कर पाया, और यह नतीजा उसकी सीमाओं को लगभग पूरी तरह इस्तेमाल करता दिखता है।
  कई पाबंदियों के बावजूद, यह प्रभावशाली प्रयोग लगता है

  • “clean-room implementation” कहना थोड़ा बढ़ा-चढ़ाकर लगता है। मॉडल ने पहले ही पूरे इंटरनेट के C compilers पर training ली है, इसलिए यह शब्द जोड़ने की खास ज़रूरत नहीं थी
  • सिर्फ मौजूदा स्तर देखकर ऐसे नतीजों का मूल्यांकन करना अफ़सोसजनक है। पिछले कुछ महीनों की प्रगति की रफ़्तार देखें, तो एक साल बाद की स्थिति कल्पना से परे हो सकती है
  • असल में इसे clean-room से ज़्यादा, training के दौरान compress हुए ज्ञान को LLM द्वारा test-based तरीके से बाहर निकालने जैसा कहना ठीक होगा
  • यह मॉडल वैसे भी GCC या Clang code पर trained होगा, इसलिए असली code similarity कितनी है, यह जानने की जिज्ञासा है
  • मेरे हिसाब से यह बड़ा कारनामा तो है, लेकिन वास्तविक user के नज़रिए से कम दिलचस्प है। LLVM में नया ISA जोड़ना, या नई language के लिए compiler बनाना, शायद ज़्यादा मायने रखेगा

• शुरुआत में मेरी प्रतिक्रिया “वाह, कमाल है” वाली थी, लेकिन फिर मेरा विचार बदल गया। C compiler बहुत सख्त specification वाला software है, इसलिए LLM के लिए इसे संभालना अपेक्षाकृत आसान है।
  लेकिन हम जो ज़्यादातर काम करते हैं, उनमें requirements धुंधली होती हैं और लक्ष्य लगातार बदलते रहते हैं। ऐसे क्षेत्रों में यह कितना अच्छा चलेगा, यह देखना दिलचस्प होगा

  • “C compiler स्पष्ट है” यह बात सुनकर हँसी आती है। “unspecified behavior” कितनी ज़्यादा है
  • code generation का tests के हिसाब से ढलना, ML model fitting जैसा है। इंसानों को अभी भी tests design और verify करने पड़ते हैं

• यह उम्मीद करना कि नतीजा पूरी तरह perfect होना चाहिए, अजीब लगता है। जो संभव हुआ है, वही चौंकाने वाला है। ऐसे प्रयास शायद अगले Opus या Sonnet की training में शामिल होंगे, और हो सकता है कि किसी दिन ऐसा model आए जो खुद efficient compiler बना ले

  • मैं भी यही सोचता हूँ। “मुद्दा यह नहीं कि कुत्ता कितना अच्छा नाचता है, बल्कि यह कि वह नाच रहा है, यही चौंकाने वाली बात है”
  • आजकल generative AI के प्रति नाराज़गी इतनी बढ़ गई है कि ज़रा सी कमी पर भी उसे ‘AI कचरा’ कह दिया जाता है। यह अफ़सोसजनक है, क्योंकि यह तो बस एक demo और proof of concept है

• कहा गया है कि यह प्रोजेक्ट Linux kernel, QEMU, FFmpeg, Redis और Doom तक build कर सकता है। यह सचमुच हैरान करने वाला है।
  लेकिन ऐसे agent systems test किए जा सकने वाले क्षेत्रों में तो अच्छा काम करते हैं, जबकि business decision-making जैसे context-आधारित क्षेत्रों में उनकी सीमाएँ हैं

  • जिस मॉडल ने पहले ही पूरे इंटरनेट पर training ली है, उसके लिए “clean-room implementation” जैसी अवधारणा का कोई अर्थ है भी या नहीं, इस पर शक है
  • अगला चरण यह है कि AI वास्तविक business context को समझे और संभाले। उदाहरण के लिए Vending-Bench जैसे benchmarks देखें, तो वह दिन दूर नहीं लगता जब AI product manager user interviews, experiments और roadmap proposals तक अपने आप करने लगेगा

• प्रोजेक्ट शानदार है, लेकिन “clean-room” का ज़िक्र छोड़ देना बेहतर होता। यह copyright वाले code पर trained model है, इसलिए बात लगभग उलटी है

  • लेकिन इंसान भी मौजूदा codebase से सीखकर, उसी ज्ञान के आधार पर clean-room implementation करते हैं
  • जैसे इंसान कंपनी में सीखी बातों को दूसरी जगह फिर इस्तेमाल करते हैं, वैसे ही LLM भी trained data को रूपांतरित तरीके से फिर गढ़ता है। अगर सीधी copying नहीं है, तो मामला अलग है

• GitHub issue के मुताबिक, समस्या include path छूट जाने की थी। compiler खुद ठीक है

  • शायद बस glibc-devel जैसा package गायब था
  • लेख बहुत लंबा था और उसमें ठोस आधार कम था। लगा कि उसने मुख्य बात ही मिस कर दी
  • AI भविष्य है
  • यह सचमुच चौंकाने वाला नतीजा है

• मैं चाहता हूँ कि सभी prompts और agent structure सार्वजनिक किए जाएँ। सीखने के लिए यह शानदार होगा, लेकिन इसे दोहराने के लिए खुद $20,000 खर्च करना भारी पड़ता है

  • आजकल सिर्फ नतीजे देखने और प्रक्रिया में दिलचस्पी न लेने का माहौल थोड़ा अफ़सोसजनक है

• यह Cursor blog के working version जैसा लगता है। असल में Linux kernel build करने का सबूत कहीं ज़्यादा भरोसेमंद है

  • मूल रूप से तो April Fools के लिए एक हल्की-फुल्की language बनानी थी, लेकिन अब इस स्तर के नतीजे देखकर हैरानी होती है। फिर भी इसे आज़माते रहने का इरादा है

• यह “पिरामिड बना सकते हैं, लेकिन कैथेड्रल नहीं” वाली तरह का approach है (संबंधित लेख).
  इसमें भारी computing resources झोंककर किसी तरह functionality लागू की गई है, और $20,000 को यूँ ही जला देने जैसा कहना ग़लत नहीं होगा।
  घातीय computing से रैखिक नतीजा पाना अर्थपूर्ण तो है, लेकिन लंबे समय में यह अक्षम दिशा लगती है

  • $20,000 API pricing के हिसाब से है, subscription के हिसाब से देखें तो शायद Max plan के 5–6 subscriptions जितना होगा
  • फिर भी वह तो FAANG engineer की 2 हफ्ते की cost भर है। इंसान 2 हफ्तों में compiler नहीं बना सकता, इसलिए demo के तौर पर इसकी काफ़ी value है