Cursor के SQLite Rust प्रयोग से हम क्या सीख सकते हैं

하이라이트

• Cursor टीम ने 835 पेजों के SQLite डॉक्यूमेंटेशन का उपयोग करके AI एजेंट स्वॉर्म्स के ज़रिए Rust में mini SQLite का पुननिर्माण किया।

• GPT 5.5 द्वारा संचालित एजेंट स्वॉर्म की कुल लागत लगभग $10,000 आई, जबकि Opus 4.8 (प्लानर) और Composer 2.5 (वर्कर) के संयोजन ने समान गुणवत्ता वाले परिणाम मात्र $1,300 में हासिल किए।

• सैकड़ों समवर्ती एजेंटों के उच्च थ्रूपुट को संभालने के लिए Cursor टीम ने Git को छोड़कर लगभग 1000 कमिट प्रति सेकंड की गति वाला एक नया कस्टम वर्ज़न कंट्रोल सिस्टम बनाया।

• वर्कर एजेंट अक्सर मर्ज कॉन्फ्लिक्ट्स में दूसरों के कोड को ओवरराइड कर देते हैं, जिसे हल करने के लिए एक तटस्थ तीसरा एजेंट मध्यस्थ के रूप में काम करता है।

• अत्यधिक बढ़ी हुई मेगा-फ़ाइलों की समस्या से निपटने के लिए वर्कर एजेंट फूली हुई फ़ाइलों को फ्लैग करते हैं और एक बाहरी एजेंट उन्हें छोटे मॉड्यूल्स में विभाजित करता है।

타임라인

1. 00:00 - 02:19

   प्रयोग का उद्देश्य और SQLite का चयन

   Cursor टीम का मुख्य लक्ष्य यह पता लगाना था कि क्या पूरी तरह से एजेंटों के एक सिस्टम के ज़रिए सिर्फ़ आधिकारिक डॉक्यूमेंट्स से एक जटिल सॉफ़्टवेयर तैयार किया जा सकता है। इसके लिए उन्होंने 835 पेजों के विस्तृत स्पेसिफिकेशन और क्वेरी व्यवहार को परखने वाले SQLogic टेस्ट सूट का उपयोग किया। यह परिणामी mini SQLite उत्पादन-तैयार (production-ready) डेटाबेस नहीं है, बल्कि एजेंट इंजीनियरिंग का एक परीक्षण है।

   • यह प्रयोग Rust या SQLite के बारे में नहीं, बल्कि एजेंट स्वॉर्म्स और AI ऑर्केस्ट्रेशन की क्षमता का परीक्षण करने के बारे में है।
   • SQLite के 835 पेजों के मानव-केंद्रित डॉक्यूमेंटेशन का उपयोग एजेंटों के लिए एक विस्तृत विनिर्देश (specification) के रूप में किया गया।
   • एजेंटों द्वारा बनाए गए कोड की सटीकता जांचने के लिए SQLogic टेस्ट सेट का उपयोग किया गया।
2. 02:19 - 07:22

   मॉडल संयोजन और लागत दक्षता

   प्रयोग में पाया गया कि प्रत्येक कार्य के लिए उच्चतम स्तर की बुद्धिमत्ता (frontier intelligence) की आवश्यकता नहीं होती। यदि संदर्भ और कार्य विवरण स्पष्ट हैं, तो प्लानिंग का काम अधिक सक्षम मॉडल (जैसे Opus 4.8) को सौंपा जा सकता है, जबकि कोड कार्यान्वयन का काम तेज़ और सस्ते मॉडलों (जैसे Composer 2.5) से कराया जा सकता है। इससे लागत में लगभग 87% की कमी आई।

   • प्लानर, वर्कर और रिव्यूअर एजेंटों की बहु-स्तरीय संरचना का उपयोग करके काम को विभाजित किया गया।
   • प्लानर और वर्कर दोनों में GPT 5.5 का उपयोग करने पर प्रयोग की कुल लागत $10,000 रही।
   • Opus 4.8 को प्लानर और Composer 2.5 को वर्कर बनाने पर समान टेस्ट पास दर मात्र $1,300 की लागत में प्राप्त हुई।
3. 07:22 - 10:48

   1000 कमिट प्रति सेकंड के लिए नया वर्ज़न कंट्रोल

   सैकड़ों समवर्ती एजेंटों द्वारा उत्पन्न कोड की मात्रा पारंपरिक वर्ज़न कंट्रोल टूल्स के मोटे लॉक (coarse locks) को जाम कर देती है। Git इंसानी डेवलपर्स के लिए सही है, लेकिन प्रति सेकंड 1000 कमिट उत्पन्न करने वाले स्वॉर्म्स के लिए अनुपयुक्त है। Cursor टीम ने एक नया कस्टमाइज्ड वर्ज़न कंट्रोल बनाया जो थ्रूपुट और एजेंट-आधारित टकराव समाधान दोनों को संभालता है।

   • पारंपरिक Git और Cargo उच्च समवर्ती (high concurrency) के कारण इतने बड़े एजेंट स्वॉर्म के साथ काम करने में असमर्थ हैं।
   • पुराने ब्राउज़र स्वॉर्म ने 1000 कमिट प्रति घंटे का शिखर छुआ था, जबकि नया सिस्टम 1000 कमिट प्रति सेकंड तक पहुँचता है।
   • अत्यधिक थ्रूपुट और तुरंत टकराव (conflicts) की पहचान के लिए शुरुआत से एक नया वर्ज़न कंट्रोल सिस्टम बनाया गया।
4. 10:48 - 18:32

   स्वॉर्म में टकराव, विवाद और समाधान

   जब कई प्लानर और वर्कर एक ही कोडबेस पर काम करते हैं, तो वे अक्सर एक ही कॉन्सेप्ट को अलग-अलग तरीकों से लागू करते हैं या एक-दूसरे के बदलावों को मिटा देते हैं। वर्कर एजेंट अपने स्वयं के कार्य संदर्भ के कारण पक्षपाती होते हैं और अन्य एजेंटों के बदलावों का सम्मान नहीं करते। ताज़ा context window वाले समर्पित मध्यस्थ और रिव्यूअर एजेंटों को लाकर इन टकरावों को निष्पक्षता से हल किया गया।

   • स्प्लिट-ब्रेन डिज़ाइन की समस्या को दूर करने के लिए प्रॉम्प्टिंग के माध्यम से प्लानर्स के अधिकार क्षेत्र स्पष्ट किए गए।
   • प्लानेर्स के बीच विवाद सुलझाने के लिए एक रिकॉन्साइलर एजेंट साझा डिज़ाइन डॉक्यूमेंट्स को मिलाता है।
   • वर्कर एजेंटों द्वारा एक-दूसरे के कोड को ओवरराइड करने से रोकने के लिए एक तटस्थ तीसरा एजेंट मर्ज कॉन्फ्लिक्ट्स हल करता है।
5. 18:32 - 27:27

   मेगा-फ़ाइलें, कोड की जड़ता और स्टैक्ड रिव्यू सिस्टम

   एजेंटों का कोई समग्र आर्किटेक्चरल विज़न न होने के कारण फ़ाइलें अत्यधिक बड़ी (मेगा-फ़ाइलें) हो जाती हैं। इसके अलावा, मॉडल फाइन-ट्यूनिंग के कारण एजेंट पुराने कोड को हटाने के बजाय नया कोड जोड़ते रहते हैं। इसे ठीक करने के लिए ब्रेकिंग रिफ़ैक्टरिंग की अनुमति दी गई। अंत में, विभिन्न फोकस (सुरक्षा, परफ़ॉर्मेंस, स्टाइल) वाले रिव्यूअर एजेंटों के संयोजन (Stacked Review System) ने कोड में गलतियों को बड़े पैमाने पर जमा होने से रोका।

   • फ़ाइलों के अत्यधिक बड़े होने पर वर्कर उन्हें फ्लैग करते हैं और एक समर्पित एजेंट उन्हें छोटे मॉड्यूल्स में तोड़ता है।
   • एजेंटों की कोर कोड न बदलने की प्रवृत्ति को दूर करने के लिए स्पष्ट रूप से ब्रेकिंग बदलावों की अनुमति दी गई।
   • विभिन्न दृष्टिकोणों (लेंस) वाले कई रिव्यूअर एजेंट मिलकर कोड गुणवत्ता सुनिश्चित करते हैं।
6. 27:27 - 32:17

   साझा मेमोरी और सॉफ़्टवेयर इंजीनियरिंग का भविष्य

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

   • एजेंटों ने साझा संदर्भ और सीख दर्ज करने के लिए एक 'फील्ड गाइड' डॉक्यूमेंट तैयार किया।
   • शुरुआती 80% कोड बनाना आसान है, लेकिन 100% प्रोडक्शन-रेडी सॉफ़्टवेयर बनाने में समय लगता है।
   • भविष्य का सॉफ़्टवेयर विकास एजेंट प्रणालियों के आर्किटेक्चर और विशिष्टताओं (specs) को डिज़ाइन करने पर केंद्रित होगा।