हम हफ्तों तक कोडिंग एजेंट्स को स्वायत्त रूप से चलाने के प्रयोग कर रहे हैं।

हमारा लक्ष्य यह समझना है कि उन प्रोजेक्ट्स के लिए, जिन्हें पूरा करने में आमतौर पर मानव टीमों को महीनों लगते हैं, हम एजेंटिक कोडिंग की अत्याधुनिक सीमा को कितनी दूर तक ले जा सकते हैं।

इस पोस्ट में हम बताते हैं कि एक ही प्रोजेक्ट पर सैकड़ों समवर्ती एजेंट्स चलाने, उनके काम का समन्वय करने, और उन्हें दस लाख से ज़्यादा पंक्तियों का कोड तथा खरबों टोकन लिखते देखने से हमने क्या सीखा।

#एकल एजेंट की सीमाएँ

आज के एजेंट केंद्रित कार्यों के लिए अच्छा काम करते हैं, लेकिन जटिल प्रोजेक्ट्स के लिए धीमे पड़ जाते हैं। स्वाभाविक अगला चरण कई एजेंट्स को समानांतर में चलाना है, लेकिन उनका समन्वय कैसे किया जाए, यह तय करना चुनौतीपूर्ण है।

हमारा पहला विचार यह था कि पहले से योजना बनाना बहुत कठोर साबित होगा। बड़े प्रोजेक्ट में आगे का पाथ अस्पष्ट होता है, और काम का सही बँटवारा शुरुआत में स्पष्ट नहीं होता। हमने गतिशील समन्वय से शुरुआत की, जहाँ एजेंट यह तय करते हैं कि उन्हें क्या करना है, इस आधार पर कि दूसरे वर्तमान में क्या कर रहे हैं।

#समन्वय करना सीखना

हमारे शुरुआती तरीके में सभी एजेंटों को बराबर दर्जा दिया गया था और उन्हें एक साझा फ़ाइल के ज़रिए आपस में समन्वय करने दिया गया था। हर एजेंट देखता था कि दूसरे क्या कर रहे हैं, कोई कार्य अपने नाम कर लेता था, और अपनी स्थिति अपडेट करता था। दो एजेंट एक ही कार्य न उठा लें, इसके लिए हमने एक लॉकिंग तंत्र का उपयोग किया।

यह कई दिलचस्प तरीकों से विफल हुआ:

1. एजेंट बहुत लंबे समय तक लॉक अपने पास रखते थे, या उन्हें छोड़ना ही भूल जाते थे। लॉकिंग सही तरह काम भी करती थी, तब भी वह एक बाधा बन जाती थी। बीस एजेंटों की रफ़्तार घटकर प्रभावी रूप से सिर्फ़ दो या तीन के थ्रूपुट जितनी रह जाती थी, और ज़्यादातर समय इंतज़ार में निकलता था।

2. सिस्टम काफ़ी नाज़ुक था: एजेंट लॉक पकड़े हुए ही विफल हो सकते थे, ऐसे लॉक लेने की कोशिश कर सकते थे जो उनके पास पहले से हों, या बिना लॉक लिए ही समन्वय फ़ाइल को अपडेट कर सकते थे।

हमने लॉक की जगह optimistic concurrency control आज़माया। एजेंट स्थिति को स्वतंत्र रूप से पढ़ सकते थे, लेकिन अगर उनकी पिछली रीड के बाद स्थिति बदल गई होती, तो लिखना विफल हो जाता। यह तरीका ज़्यादा सरल और मज़बूत था, लेकिन फिर भी कुछ गहरी समस्याएँ बनी रहीं।

जब कोई पदानुक्रम नहीं था, तो एजेंट जोखिम लेने से कतराने लगे। वे कठिन कार्यों से बचते थे और उनकी जगह छोटे, सुरक्षित परिवर्तन करते थे। कोई भी एजेंट कठिन समस्याओं या शुरू से अंत तक के implementation की ज़िम्मेदारी नहीं लेता था। नतीजा यह हुआ कि काम लंबे समय तक बिना किसी प्रगति के घूमता रहता था।

#योजनाकार और वर्कर

हमारा अगला तरीका भूमिकाओं को अलग करना था। एक ऐसे सपाट ढांचे के बजाय, जहाँ हर एजेंट सब कुछ करता है, हमने अलग-अलग जिम्मेदारियों वाली एक पाइपलाइन बनाई।

• योजनाकार लगातार कोडबेस को खोजते हैं और कार्य बनाते हैं। वे विशिष्ट क्षेत्रों के लिए उप-योजनाकार स्पॉन कर सकते हैं, जिससे योजना बनाना खुद ही समानांतर और पुनरावर्ती हो जाता है।

• वर्कर कार्य उठाते हैं और उन्हें पूरा करने पर पूरी तरह ध्यान केंद्रित करते हैं। वे दूसरे वर्कर के साथ समन्वय नहीं करते और न ही बड़ी तस्वीर की चिंता करते हैं। वे बस अपने असाइन किए गए कार्य पर तब तक लगे रहते हैं, जब तक वह पूरा नहीं हो जाता, और फिर अपने परिवर्तन पुश कर देते हैं।

हर चक्र के अंत में, एक निर्णायक एजेंट तय करता था कि आगे जारी रखना है या नहीं, और फिर अगला दौर नए सिरे से शुरू होता था। इससे हमारी ज़्यादातर समन्वय समस्याएँ हल हो गईं और हम बहुत बड़े प्रोजेक्ट्स तक स्केल कर सके, बिना किसी एक एजेंट के संकीर्ण दृष्टि का शिकार हुए।

#हफ्तों तक चलना

इस सिस्टम का परीक्षण करने के लिए, हमने इसे एक महत्वाकांक्षी लक्ष्य दिया: शुरुआत से एक वेब ब्राउज़र बनाना। एजेंट लगभग एक हफ्ते तक चलते रहे और उन्होंने 1,000 फ़ाइलों में 10 लाख से ज़्यादा पंक्तियों का कोड लिखा। आप GitHub पर स्रोत कोड देख सकते हैं।

कोडबेस इतना बड़ा होने के बावजूद, नए एजेंट अब भी इसे समझ सकते हैं और सार्थक प्रगति कर सकते हैं। सैकड़ों वर्कर एक साथ चलते हैं और बहुत कम टकराव के साथ उसी ब्रांच पर पुश करते हैं।

हालाँकि यह एक साधारण स्क्रीनशॉट जैसा लग सकता है, शुरुआत से एक ब्राउज़र बनाना बेहद कठिन है।

एक और प्रयोग Cursor कोडबेस में Solid से React का इन-प्लेस माइग्रेशन करना था। इसमें +266K/-193K संपादन के साथ तीन हफ्तों से ज़्यादा समय लगा। इसे अब भी सावधानीपूर्वक समीक्षा की आवश्यकता है, लेकिन यह हमारे CI और शुरुआती जाँचों को पास कर रहा था।

एक और प्रयोग एक आगामी उत्पाद को बेहतर बनाना था। एक लंबे समय तक चलने वाले एजेंट ने Rust के एक कुशल संस्करण के साथ वीडियो रेंडरिंग को 25 गुना तेज़ कर दिया। उसने कर्सर का अनुसरण करते हुए, स्वाभाविक स्प्रिंग ट्रांज़िशन और मोशन ब्लर के साथ स्मूद ज़ूम और पैन का समर्थन भी जोड़ा। यह कोड मर्ज किया जा चुका है और जल्द ही उत्पादन में होगा।

हमारे पास कुछ और दिलचस्प उदाहरण हैं जो अभी भी चल रहे हैं:

• Java LSP: 7.4K कमिट, 550K LoC
• Windows 7 emulator: 14.6K कमिट, 1.2M LoC
• Excel: 12K कमिट, 1.6M LoC

#हमने क्या सीखा

हमने इन एजेंट्स पर एक ही लक्ष्य की दिशा में ट्रिलियनों टोकन लगाए हैं। सिस्टम पूरी तरह कुशल नहीं है, लेकिन यह हमारी अपेक्षा से कहीं अधिक प्रभावी है।

बेहद लंबे समय तक चलने वाले कार्यों के लिए सही मॉडल चुनना बहुत महत्वपूर्ण है। हमने पाया कि GPT-5.2 मॉडल लंबे स्वायत्त काम में कहीं बेहतर हैं: निर्देशों का पालन करना, फोकस बनाए रखना, भटकाव से बचना, और चीज़ों को सटीक व पूरी तरह लागू करना।

Opus 4.5 में सुविधाजनक होने पर जल्दी रुक जाने और शॉर्टकट्स अपनाने की प्रवृत्ति होती है, जिससे वह जल्दी नियंत्रण वापस दे देता है। हमने यह भी पाया कि अलग-अलग मॉडल अलग-अलग भूमिकाओं में बेहतर होते हैं। GPT-5.2, GPT-5.1-Codex की तुलना में बेहतर योजनाकार है, भले ही बाद वाला खास तौर पर कोडिंग के लिए प्रशिक्षित है। अब हम एक ही सार्वभौमिक मॉडल के बजाय हर भूमिका के लिए सबसे उपयुक्त मॉडल का उपयोग करते हैं।

हमारे कई सुधार जटिलता जोड़ने से नहीं, बल्कि उसे हटाने से आए। शुरुआत में हमने गुणवत्ता नियंत्रण और टकराव सुलझाने के लिए एक integrator भूमिका बनाई थी, लेकिन पाया कि उसने जितनी समस्याएँ सुलझाईं, उससे अधिक अवरोध पैदा किए। वर्कर पहले से ही टकराव खुद संभालने में सक्षम थे।

सबसे अच्छा सिस्टम अक्सर आपकी अपेक्षा से अधिक सरल होता है। शुरुआत में हमने वितरित कंप्यूटिंग और संगठनात्मक डिज़ाइन से प्रेरित सिस्टमों को मॉडल करने की कोशिश की। हालांकि, वे सभी एजेंट्स के लिए काम नहीं करते।

संरचना की सही मात्रा कहीं बीच में होती है। बहुत कम संरचना होने पर एजेंट्स आपस में टकराते हैं, काम दोहराते हैं, और भटक जाते हैं। बहुत अधिक संरचना नाज़ुकता पैदा करती है।

सिस्टम के व्यवहार का एक आश्चर्यजनक रूप से बड़ा हिस्सा इस बात पर निर्भर करता है कि हम एजेंट्स को कैसे प्रॉम्प्ट करते हैं। उन्हें अच्छी तरह समन्वय करने, समस्याग्रस्त व्यवहारों से बचाने, और लंबे समय तक फोकस बनाए रखने के लिए व्यापक प्रयोग करने पड़े। हॉर्नेस और मॉडल महत्वपूर्ण हैं, लेकिन प्रॉम्प्ट्स उससे भी अधिक महत्वपूर्ण हैं।

#आगे क्या है

बहु-एजेंट समन्वय अब भी एक कठिन समस्या है। हमारी मौजूदा प्रणाली काम करती है, लेकिन हम अभी भी इष्टतम स्थिति से काफी दूर हैं। योजनाकारों को अपने कार्य पूरे होते ही अगले चरण की योजना बनाने के लिए सक्रिय हो जाना चाहिए। एजेंट कभी-कभी जरूरत से कहीं ज़्यादा देर तक चलते रहते हैं। भटकाव और संकीर्ण दृष्टि से निपटने के लिए हमें अब भी समय-समय पर नए सिरे से शुरुआत करनी पड़ती है।

लेकिन मूल प्रश्न—क्या हम किसी समस्या पर अधिक एजेंट लगाकर स्वायत्त कोडिंग को स्केल कर सकते हैं—का जवाब हमारी उम्मीद से ज़्यादा आशाजनक निकला है। सैकड़ों एजेंट एक ही कोडबेस पर हफ्तों तक साथ मिलकर काम कर सकते हैं और महत्वाकांक्षी प्रोजेक्ट्स पर वास्तविक प्रगति कर सकते हैं।

हम यहाँ जो तकनीकें विकसित कर रहे हैं, वे आगे चलकर Cursor की एजेंट क्षमताओं को आकार देंगी। अगर आप AI-सहायित सॉफ्टवेयर विकास की सबसे कठिन समस्याओं पर काम करने में रुचि रखते हैं, तो हमें hiring@cursor.com पर लिखें।