दोन-मेंदू आर्किटेक्चरची गरज का आहे?

बहुतेक कोड-लेखन सहाय्यक (code-writing assistants) एकाच मॉडेलचा वापर करतात ज्याला काय तयार करायचे आहे आणि त्याचा सोर्स कोड काय असेल हे दोन्ही ठरवावे लागते. लांब सत्रांमध्ये (long sessions), मॉडेलची कॉन्टेक्स्ट विंडो (context window) भरून जाते, ज्यामुळे "कॉन्टेक्स्ट ड्रिफ्ट" (context drift) होतो – मॉडेल पूर्वीचे निर्णय विसरते आणि परस्परविरोधी किंवा पुनरावृत्ती झालेला कोड देते. Cursor हे मानसिक श्रम विभागून हे सोडवते:

  • Planner agents सर्वात शक्तिशाली मॉडेल्सवर चालतात (मसुद्यात Opus 4.8 किंवा Fable 5 चा उल्लेख आहे). ते उच्च-स्तरीय विनंतीचे कामाच्या श्रेणीमध्ये (task hierarchy) विभाजन करतात, संदिग्धता दूर करतात आणि डिझाइनचे निर्णय नोंदवतात.
  • Worker agents जलद आणि उच्च-थ्रूपुट (high-throughput) मॉडेल्सवर (Composer 2.5) चालतात. ते प्लॅनर्सकडून ठोस कामे घेतात आणि कोड स्निपेट्स (code snippets) तयार करतात.

"काय" (what) आणि "कसे" (how) वेगळे ठेवल्यामुळे सिंगल-मॉडेल सिस्टममध्ये येणारा ओव्हरलोड थांबतो. प्रत्येक मॉडेल त्याच्या भूमिकेनुसार योग्य कॉन्टेक्स्ट आकारात राहते, ज्यामुळे टोकन-बजेटचा (token-budget) अतिवापर टाळता येतो आणि डिझाइनर्सना प्रॉम्प्ट्स कापून (truncate) घ्यावे लागत नाहीत.

स्वॉर्मचे स्केलिंग (Scaling the swarm)

Cursor च्या स्वॉर्मच्या सुरुवातीच्या आवृत्त्या ताशी सुमारे एक हजार कमिट्स (commits) करत होत्या. स्प्लिट-ब्रेन रिडिझाइननंतर ही सिस्टीम साधारणपणे प्रति सेकंद एक हजार कमिट्सपर्यंत पोहोचली. या वेगामुळे एक नवीन अडथळा (bottleneck) समोर आला: व्हर्जन-कंट्रोल टूल्स अशा प्रकारच्या संघर्षासाठी (contention) बनवलेली नव्हती. जेव्हा दोन प्लॅनर्सने एकमेकांशी साधर्म्य असणारे निर्देश दिले, तेव्हा रिपॉझिटरीमध्ये लॉजिकची पुनरावृत्ती होऊ शकत होती – या समस्येला टीम "स्प्लिट-ब्रेन एरर्स" (split-brain errors) असे म्हणते.

Cursor ने तीन सुरक्षा उपायांनी हा गोंधळ नियंत्रित केला:

  1. Shared design documents – प्रत्येक प्लॅनर आपले निर्णय एका मध्यवर्ती दस्तऐवजात (central document) लिहितो जो जनरेट केलेल्या कोडशी लिंक केलेला असतो. वर्कर्स त्या लिंक्सचे अनुसरण करतात, जेणेकरून तोच डिझाइन पुन्हा इतरत्र तयार होणार नाही.
  2. Multi-angle reviews – तीन एजंट्स कामाचा प्रत्येक भाग वेगळ्या दृष्टीकोनातून तपासतात (पूर्ण ट्रान्सक्रिप्ट, फक्त आउटपुट, किंवा फक्त कोड). ही क्रॉस-चेकिंग पद्धत अशा विसंगती पकडते ज्या एका दृष्टीकोनातून सुटू शकल्या असत्या.
  3. Self-maintained field guides – एजंट्स आश्चर्यकारक निष्कर्ष आणि चुकांची एक "नॉलेज फोल्डर" (knowledge folder) ठेवतात. जेव्हा एखादा नवीन वर्कर सुरू होतो, तेव्हा तो ज्ञात चुका टाळण्यासाठी त्या फोल्डरचा सल्ला घेतो, ज्यामुळे स्वॉर्ममध्ये अल्पकालीन स्मृती (short-term memory) मिळते.

हे उपाय कोडबेसमध्ये बदल मोठ्या प्रमाणात होत असतानाही सुसंगतता राखतात.

महत्त्वाचे बेंचमार्क्स (Benchmarks)

Cursor ने संपूर्ण SQLite मॅन्युअल – ८३५ पानांची Rust अंमलबजावणी (implementation) – पुन्हा तयार करून हायब्रिड स्वॉर्मची चाचणी घेतली, ही अशी कार्य होती जी अचूकता (correctness) आणि आकार (size) या दोन्हीची परीक्षा घेते. निकाल धक्कादायक होते:

  • Accuracy – हायब्रिड कॉन्फिगरेशनने (planner + Composer workers) १००% अचूकता प्राप्त केली, ज्याने सर्वात प्रगत मॉडेलच्या (GPT-5.5) सिंगल रनला सातत्याने मागे टाकले.
  • Code size – हायब्रिड स्वॉर्मने ९,९०८ ओळींचा इंजिन कोड तयार केला, तर जुन्या, मोनोलिथिक (monolithic) स्वॉर्मने ६४,३०५ ओळी तयार केल्या होत्या.
  • Cost – सिंगल GPT-5.5 इन्स्टन्स चालवण्याचा खर्च सुमारे $१०,५६५ आला. हायब्रिड दृष्टिकोनामध्ये वर्कर फ्लीटवर फक्त $४११ खर्च झाले.

खर्चातील हा फरक Composer 2.5 मुळे आहे, ज्याचे वर्णन मसुद्यात असे केले आहे की ते फ्लॅगशिप मॉडेल्सच्या तुलनेत कामगिरी देते, परंतु प्रति-मिलियन-टोकन किंमत खूपच कमी आहे. बहुतेक टोकन वापर या स्वस्त मॉडेलकडे वळवून, स्वॉर्म गुणवत्तेशी तडजोड न करता एकूण खर्च कमी ठेवतो.

सारांश (Bottom line)

  • शक्तिशाली प्लॅनरची स्वस्त एक्झिक्युटरसोबत (executor) जोडणी केल्यामुळे वेग, कोडची संक्षिप्तता आणि खर्चात कित्येक पटीने वाढ होते.
  • हे डिझाइन "काय" (what) हे फ्रंटियर मॉडेल्सना आणि "कसे" (how) हे स्पेशालिस्ट मॉडेल्सना नियुक्त करून कॉन्टेक्स्ट ड्रिफ्ट दूर करते.
  • ऑपरेशनल ओव्हरहेड (operational overhead) आणि इन्फ्रास्ट्रक्चरची मागणी हे व्यापक वापरासाठी अजूनही सर्वात मोठे अडथळे आहेत.