लंबे समय तक चलने वाली autonomous coding का विस्तार

 (cursor.com)
18 पॉइंट द्वारा GN⁺ 2026-01-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cursor ने यह प्रयोग किया कि क्या वह कई हफ्तों तक autonomous coding agents को parallel में चलाकर बड़े प्रोजेक्ट पूरे कर सकता है
  • शुरुआत में dynamic collaboration structure का उपयोग किया गया, लेकिन lock टकराव और काम के दोहराव से bottleneck पैदा हुआ
  • बाद में भूमिकाओं को Planner और Worker में बाँटकर parallelism और efficiency में बड़ा सुधार किया गया
  • इस संरचना के साथ शुरुआत से एक web browser implement किया गया, और सैकड़ों agents ने 10 लाख से अधिक lines of code लिखीं
  • प्रयोग के नतीजों से पता चला कि simple structure और उचित prompt design लंबे समय तक autonomous coding को scale करने की कुंजी हैं

single agent की सीमाएँ

  • मौजूदा single coding agent साधारण कामों में प्रभावी है, लेकिन जटिल प्रोजेक्ट्स में इसकी गति धीमी हो जाती है
    • कई agents को parallel में चलाना scaling की स्वाभाविक दिशा है, लेकिन task coordination कठिन है
  • शुरुआत में बिना पूर्व योजना के dynamic collaboration approach आज़माया गया
    • इसमें हर agent दूसरे agents की स्थिति देखकर खुद अगला काम तय करता था

collaboration सीखने की प्रक्रिया

  • एक ऐसी संरचना अपनाई गई जिसमें सभी agents के पास समान अधिकार थे और shared files के ज़रिये काम coordinate किया जाता था
    • हर agent दूसरे agents की स्थिति देखता, काम आवंटित करता या लेता, और अपनी स्थिति update करता
    • दोहराव रोकने के लिए lock mechanism का उपयोग किया गया
  • समस्याएँ
    1. agents लंबे समय तक lock पकड़े रखते थे या उसे release नहीं करते थे, जिससे कुल गति 20 में से केवल 2–3 के स्तर तक गिर गई
    2. lock पकड़े हुए विफल होना, या बिना lock के file बदल देना जैसी system instability की समस्याएँ सामने आईं
  • इसके बाद optimistic concurrency control पर स्विच किया गया
    • पढ़ना खुला रखा गया, लेकिन लिखना state change के समय fail होने के लिए सेट किया गया
    • यह सरल और स्थिर था, लेकिन बिना hierarchy वाली संरचना में agents ने जोखिम से बचने वाला व्यवहार दिखाया
    • वे कठिन समस्याओं से बचते रहे, केवल छोटे बदलाव दोहराते रहे, और बिना प्रगति वाला work loop बनने लगा

Planner और Worker संरचना

  • इसके बाद भूमिकाएँ अलग करने वाली hierarchical pipeline पर स्विच किया गया
    • Planners: codebase को explore करते हुए tasks बनाते हैं, और ज़रूरत पड़ने पर sub-planners भी बनाते हैं
    • Workers: केवल दिए गए task को पूरा करते हैं और completion के बाद changes push करते हैं
  • हर cycle में judge agent तय करता है कि अगला चरण आगे बढ़े या नहीं
    • इस संरचना से ज़्यादातर collaboration समस्याएँ हल हो गईं और large-scale project scalability हासिल हुई

long-running experiment

  • प्रयोग का लक्ष्य: शुरुआत से एक web browser implement करना
    • लगभग 1 हफ्ते तक चलाया गया, 1,000 files में 10 लाख से अधिक lines of code लिखी गईं
    • सैकड़ों workers ने एक ही branch पर एक साथ push किया, फिर भी conflicts न्यूनतम रहे
    • तैयार code GitHub पर सार्वजनिक किया गया
  • अतिरिक्त प्रयोग
    • Solid → React migration: 3 हफ्तों में +266K/-193K बदलाव, merge होने की संभावना की पुष्टि
    • video rendering improvement: Rust version के साथ 25 गुना speed-up, और zoom·pan·motion blur features जोड़े गए
    • संबंधित code जल्द production में लागू किया जाएगा

मुख्य सीख

  • अरबों tokens लगाने के बाद यह पाया गया कि सिस्टम पूरी तरह efficient नहीं है, लेकिन उम्मीद से बेहतर परिणाम मिले
  • model selection लंबे autonomous काम का मुख्य तत्व है
    • GPT-5.2 ने focus बनाए रखने, निर्देशों का पालन करने और सटीक implementation में बेहतर प्रदर्शन किया
    • Opus 4.5 में जल्दी समाप्त हो जाने की प्रवृत्ति दिखी
    • GPT-5.2 planner की भूमिका में GPT-5.1-codex से अधिक उपयुक्त रहा
    • इसलिए हर भूमिका के लिए सबसे उपयुक्त model चुना गया
  • complexity हटाने से performance में सुधार हुआ
    • quality integrator की भूमिका उल्टा bottleneck बन गई
    • workers अपने स्तर पर conflicts सुलझा सकते थे
  • simple structure सबसे प्रभावी साबित हुई
    • distributed systems theory या organization design models केवल आंशिक रूप से ही उपयोगी रहे
    • संरचना बहुत कम हो तो conflict और duplication बढ़ते हैं, बहुत अधिक हो तो fragility बढ़ती है
  • prompt design का system behavior पर निर्णायक प्रभाव पड़ा
    • लंबे समय तक focus बनाए रखने, pathological behavior रोकने और collaboration बढ़ाने में इसकी केंद्रीय भूमिका रही

आगे की चुनौतियाँ

  • multi-agent coordination अब भी कठिन समस्या है
    • planners को इस तरह बेहतर बनाना होगा कि task पूरा होते ही वे अपने आप अगला चरण plan करें
    • कुछ agents बहुत लंबे समय तक चलते रहे, इसलिए periodic restart की ज़रूरत पड़ी
  • लेकिन मुख्य सवाल, यानी “क्या agents की संख्या बढ़ाकर autonomous coding को scale किया जा सकता है?”, इस पर
    • यह पुष्टि हुई कि सैकड़ों agents कई हफ्तों तक सहयोग करके वास्तविक प्रगति कर सकते हैं
  • यह तकनीक आगे चलकर Cursor की agent features में शामिल की जाएगी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-16
Hacker News टिप्पणियाँ

  • मैं Steve Yegge की पोस्ट Welcome to Gas Town से जुड़े काम पर काम कर रहा हूँ, इसलिए इसे दिलचस्पी से देखा

  • हाल ही में मैंने साझा की गई LLM predictions पोस्ट में कहा था कि 2029 तक AI-assisted coding से browser बनना चौंकाने वाली बात नहीं रहेगा, और Cursor का यह प्रोजेक्ट दूसरी कोशिश है
    एक और उदाहरण इस Reddit पोस्ट में देखा जा सकता है

    • अगर implementation समझदारी से हो, तो शायद GitHub के Chromium source को लेकर अनावश्यक फीचर हटाकर सिर्फ बाहरी रूप बदलने जैसा काम किया जाएगा
    • 2029 तक तो हमें मानक इतना ऊपर ले जाना चाहिए कि AI द्वारा pelican के लिए browser बनाने पर चुटकुले बनने लगें
    • मैंने Reddit वाले उदाहरण का कोड लगभग 5 मिनट देखा, और text layout calculation तथा bidi (bidirectional text) हैंडलिंग बहुत खराब थी। standards को ध्यान में न रखने वाले “browser” को सचमुच browser कहना मुश्किल है
    • प्रभावशाली तो है, लेकिन यह सवाल उठता है कि open source browser code कहीं मॉडल के training data में शामिल तो नहीं था
    • यह जिज्ञासा है कि उन्होंने कहा भविष्यवाणी गलत निकली, फिर एक हफ्ते बाद उसी podcast में आकर नई भविष्यवाणी क्यों की

  • मैंने repository के tests खुद चलाए, और वे errors और warnings से भरे थे, CI भी काफी समय से fail हो रहा था। ऐसी स्थिति में इसे “successful example” कहना ठीक है या नहीं, समझ नहीं आता। पूरी तरह autonomous coding की बजाय human-centered assistive approach ज्यादा व्यावहारिक लगती है

    • codebase सैकड़ों-हजारों छोटे files में बंटा हुआ था, इसलिए structure समझना लगभग असंभव था। README भी कमजोर था और dependencies की कोई व्याख्या नहीं थी। AI द्वारा बना कोड है, लेकिन maintenance किसी दुःस्वप्न जैसा है
    • लगता है लेखक ने भी fully autonomous coding को गंभीर productization से अधिक LLM limitations के प्रयोग की तरह देखा। अभी यह उस चरण में है जहाँ छोटे projects में ही “अकेले ठीक-ठाक कोड” निकल पा रहा है
    • CI-failing PR को वैसे ही merge कर देना, इस पर यह मज़ाक बनता है कि शायद इसने human-level quality हासिल कर ली
    • “slow” से उनका मतलब क्या है, यह स्पष्ट नहीं है। GPU speed? इंसान से धीमा? अंततः यह AI bubble को फुलाने वाली पोस्ट जैसी लगी

  • यह जिज्ञासा है कि उस PR को अब तक merge क्यों नहीं किया गया। AI agent swarm द्वारा लंबे समय में जटिल software पूरा करने वाला भविष्य आकर्षक है, लेकिन मौजूदा उदाहरण बहुत कमजोर है। इंसानों के साथ collaboration कहाँ होता है, यह ज्यादा अहम है

    • मेरे अनुभव में agents converge नहीं करते, बल्कि धीरे-धीरे और भी बिखरा हुआ code monster बना देते हैं
    • एक भी काम करने वाला साधारण project सार्वजनिक न करना investors को लुभाने वाले bait जैसा लगता है। AI boom dot-com bubble जैसा लगता है, बस इस बार कमाई पर ज्यादा फोकस है
    • browser, Excel, या Windows 7 जैसे उदाहरण training data में आंशिक रूप से रहे होंगे, लेकिन उससे पूरी नकल संभव नहीं है
    • code इतना विशाल और समस्याओं से भरा था कि review करना ही असंभव था। आखिर में YOLO-style merge ही एकमात्र रास्ता बचता है
    • मेरी दिलचस्पी convergence condition में है। code बढ़े या घटे, अहम यह है कि वह किसी optimal state पर स्थिर हो सके

  • यह अफसोसजनक है कि उन्होंने कठिनाई को चरणबद्ध तरीके से बढ़ाते हुए प्रयोग नहीं किया। React CRUD → Paint clone → file manager → browser क्रम में धीरे-धीरे विस्तार करते, तो प्रगति के चरण अधिक साफ दिखते

  • मैंने भी इसी तरह के तरीके से tjs बनाया है। यह दुनिया का सबसे तेज़ और सटीक JSON Schema Validator है, और git subtree का उपयोग करने वाला planner/delegate pattern प्रभावी रहा। जिन software systems में standards और tests अच्छी तरह परिभाषित हों, उन्हें AI agents तेज़ी से rewrite और optimize कर सकते हैं
    संबंधित commands spawn-perf-agents.md में देखे जा सकते हैं

  • browser को scratch से बनाना बहुत कठिन है, लेकिन पोस्ट में दी गई बातों में विस्तृत विश्लेषण की कमी थी। अगर बात सिर्फ “compile हो जाता है” तक सीमित है, तो उसका महत्व कम है। असली कसौटी यह है कि क्या अगला बदलाव स्थिरता से merge किया जा सकता है

    • agent coding का न्यूनतम मानक “compile success” → “सही तरीके से run” → “edge cases संभालना” होना चाहिए। इंसानों से कम bugs वाला system अगर 1 साल से अधिक स्थिर चले, तभी उस पर भरोसा किया जा सकता है
    • वास्तविकता में तो CI भी fail हो रहा है, इसलिए “compile हो जाता है” वाला दावा भी संदिग्ध है

  • ब्लॉग के अनुसार इसमें trillions of tokens इस्तेमाल हुए, और OpenAI API pricing से हिसाब लगाएँ तो लागत कई करोड़ डॉलर के स्तर की बनती है। इतनी रकम में शायद सीधे browser team को donation देना बेहतर होता

  • मैंने खुद build करके देखा, और 100 से अधिक compile errors आए। अधिकांश commits में CI fail था, और असल में यह कई open source libraries को जोड़कर बनाया गया था।
    quickjs, wgpu, winit, egui, html parser जैसे मौजूदा components को ज्यों का त्यों लिया गया था, लेकिन CEO ने इसे “custom JS VM” कहा, जिससे गलतफहमी पैदा होती है
    फिर भी, AI ने इस तरह का integration autonomously कर लिया, यह प्रभावशाली है

    • इस्तेमाल किए गए components Rust-आधारित browser blitz से बहुत मिलते-जुलते हैं, इसलिए training data में शामिल होने की संभावना है
    • “यह चलता है या नहीं, उससे फर्क नहीं पड़ता; screenshot लो और investors को दिखाओ” जैसी startup-शैली की चुटकी भी आई
    • आँकड़ों के अनुसार लगभग 60,000 workflow runs में से सिर्फ लगभग 1,000 ही सफल हुए। व्यावहारिक रूप से यह असत्यापित code का ढेर लगता है
    • अंत में “सब लोग अपना-अपना custom Cursor बनाएँ” वाले मज़ाक के साथ बात खत्म हुई

  • code बहुत नाज़ुक और अस्थिर लगा। उदाहरण के लिए render_placeholder function सिर्फ frame buffer भरने वाले अस्थायी code जैसा दिखता है।
    जिज्ञासा है कि यह code वास्तव में क्या भूमिका निभाता है, और हर test पर token/time cost कितनी आती है

    • tag attributes निकालने का तरीका भी इस हिस्से की तरह कुछ अजीब लगा
    • लेकिन अगर Cursor इसे अपने-आप ठीक कर सकता है, तो ऐसी नाज़ुकता भी लंबे समय में dependency बढ़ाने की रणनीति हो सकती है