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

 (cursor.com)
18 पॉइंट द्वारा GN⁺ 2026-01-16 | अभी कोई टिप्पणी नहीं है. | 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 में शामिल की जाएगी

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.