ஏன் இரண்டு மூளைக் கட்டமைப்பு (two-brain architecture)?

பெரும்பாலான குறியீடு எழுதும் உதவியாளர்கள் (code-writing assistants) ஒரு ஒற்றை மாதிரியையே (single model) பயன்படுத்துகின்றன; அது எதை உருவாக்க வேண்டும் என்பதைத் தீர்மானிக்கவும் மற்றும் அதன் மூலக் குறியீட்டை (source code) எழுதவும் வேண்டியிருக்கும். நீண்ட நேரப் பயன்பாட்டின் போது, மாதிரியின் சூழல் சாளரம் (context window) நிரம்பிவிடுகிறது, இது "context drift" எனப்படும் நிலையை ஏற்படுத்துகிறது – அதாவது, அது முந்தைய முடிவுகளை மறந்துவிடுகிறது மற்றும் முரண்பட்ட அல்லது நகல் குறியீடுகளை வெளியிடுகிறது. Cursor இதை மன உழைப்பைப் பிரிப்பதன் மூலம் தீர்க்கிறது:

  • Planner agents மிகவும் சக்திவாய்ந்த மாதிரிகளில் இயங்குகின்றன (Opus 4.8 அல்லது Fable 5 என்று வரைவு குறிப்பிடுகிறது). அவை ஒரு உயர்மட்டக் கோரிக்கையை (high-level request) பணி படிநிலைகளாகப் பிரிக்கின்றன, தெளிவற்ற தன்மைகளைத் தீர்க்கின்றன மற்றும் வடிவமைப்புத் தேர்வுகளைப் பதிவு செய்கின்றன.
  • Worker agents வேகமான, அதிகத் திறன் கொண்ட மாதிரிகளில் இயங்குகின்றன (Composer 2.5). அவை திட்டமிடுபவர்களிடமிருந்து (planners) குறிப்பிட்ட பணிகளைப் பெற்று, குறியீடு துண்டுகளை (code snippets) உருவாக்குகின்றன.

"என்ன" (what) மற்றும் "எப்படி" (how) என்பதைத் தனித்தனியாக வைத்திருப்பது, ஒற்றை மாதிரி அமைப்புகளை முடக்கும் அதிகப்படியான சுமையைத் தடுக்கிறது. ஒவ்வொரு மாதிரியும் அதன் பணிக்கு ஏற்ற சூழல் அளவிற்குள் (context size) இருக்குமாறு பார்த்துக்கொள்ளப்படுவதால், வடிவமைப்பாளர்கள் ப்ராம்ப்ட்களை (prompts) சுருக்க வேண்டிய கட்டாயத்திற்குத் தள்ளும் டோக்கன் பட்ஜெட் அதிகரிப்பு தவிர்க்கப்படுகிறது.

கூட்டமைப்பை (swarm) விரிவாக்குதல்

Cursor-இன் கூட்டமைப்பின் (swarm) ஆரம்பப் பதிப்புகள் ஒரு மணி நேரத்திற்கு சுமார் ஆயிரம் கமிட்களை (commits) மேற்கொண்டன. split-brain மறுவடிவமைப்புக்குப் பிறகு, இந்த அமைப்பு ஒரு வினாடிக்குத் தோராயமாக ஆயிரம் கமிட்களை எட்டியது. அந்த வேகம் ஒரு புதிய தடையை (bottleneck) வெளிப்படுத்தியது: பதிப்பு-கட்டுப்பாட்டு கருவிகள் (version-control tools) இத்தகைய மோதல்களைக் கையாளும் வகையில் உருவாக்கப்படவில்லை. இரண்டு திட்டமிடுபவர்கள் (planners) ஒன்றோடொன்று மேலெழுந்துள்ள (overlapping) அறிவுறுத்தல்களை வழங்கும்போது, களஞ்சியத்தில் (repository) நகல் தர்க்கங்கள் (duplicated logic) உருவாகலாம் – இதைத் দলটি "split-brain errors" என்று அழைக்கிறது.

Cursor மூன்று பாதுகாப்பு வழிமுறைகள் மூலம் இந்த குழப்பத்தைக் கட்டுப்படுத்தியது:

  1. Shared design documents – ஒவ்வொரு திட்டமிடுபவரும் தனது முடிவுகளை உருவாக்கப்பட்ட குறியீட்டுடன் இணைக்கப்பட்ட ஒரு மைய ஆவணத்தில் எழுதுகிறார்கள். பணியாளர்கள் (Workers) அந்த இணைப்புகளைப் பின்பற்றுவதால், அதே வடிவமைப்பு வேறு எங்கேயும் மீண்டும் உருவாக்கப்படுவதில்லை.
  2. Multi-angle reviews – மூன்று முகவர்கள் (agents) வேலையின் வெவ்வேறு பகுதிகளை ஆய்வு செய்கிறார்கள் (முழுப் பதிவு, வெளியீடு மட்டும், அல்லது குறியீடு மட்டும்). இந்த குறுக்குச் சரிபார்ப்பு, ஒரு ஒற்றைப் பார்வையில் விடுபடக்கூடிய முரண்பாடுகளைக் கண்டறிகிறது.
  3. Self-maintained field guides – முகவர்கள் ஆச்சரியமான கண்டுபிடிப்புகள் மற்றும் சிக்கல்கள் குறித்த ஒரு "அறிவுத் தொகுப்பை" (knowledge folder) பராமரிக்கின்றன. ஒரு புதிய பணியாளர் தொடங்கும் போது, தெரிந்த தவறுகளைத் தவிர்க்க அவர் அந்தத் தொகுப்பைத் தொடர்பு கொள்கிறார், இது கூட்டமைப்பிற்குள் குறுகிய கால நினைவகத்தை (short-term memory) வழங்குகிறது.

இந்த நடவடிக்கைகள் மாற்றங்களின் பெருமளவிற்கும் மத்தியிலும் குறியீட்டுத் தொகுப்பை (codebase) சீராக வைத்திருக்க உதவுகின்றன.

முக்கியமான அளவீடுகள் (Benchmarks)

Cursor தனது கலப்பு கூட்டமைப்பை (hybrid swarm) முழு SQLite கையேட்டையும் மீண்டும் உருவாக்குவதன் மூலம் சோதித்தது – இது 835 பக்கங்களைக் கொண்ட ஒரு Rust செயலாக்கம் (implementation) ஆகும் – இது துல்லியம் மற்றும் அளவு ஆகிய இரண்டையும் சோதிக்கும் ஒரு பணியாகும். அதன் முடிவுகள் வியக்கத்தக்கவை:

  • Accuracy – கலப்பு கட்டமைப்பு (planner + Composer workers) 100% துல்லியத்தை எட்டியது, இது குறிப்பிடப்பட்ட மிகவும் மேம்பட்ட மாதிரியின் (GPT-5.5) ஒற்றை இயக்கத்தை விடத் தொடர்ச்சியாகச் சிறந்து விளங்கியது.
  • Code size – பழைய, ஒற்றைத்தன்மை கொண்ட (monolithic) கூட்டமைப்பிலிருந்து 64,305 வரிகள் வந்த நிலையில், கலப்பு கூட்டமைப்பானது 9,908 வரிகள் கொண்ட என்ஜின் குறியீட்டை உருவாக்கியது.
  • Cost – ஒரு தனி GPT-5.5 மாதிரியை இயக்குவதற்கு சுமார் $10,565 செலவானது. கலப்பு அணுகுமுறை பணியாளர் குழுவிற்கு (worker fleet) வெறும் $411 மட்டுமே செலவிட்டது.

இந்தச் செலவு வேறுபாட்டிற்கு Composer 2.5 காரணமாகும்; இது முதன்மை மாதிரிகளுக்கு (flagship models) இணையான செயல்திறனை வழங்கும் அதே வேளையில், ஒரு மில்லியன் டோக்கன்களுக்கான விலையில் ஒரு சிறு பகுதியை மட்டுமே வசூலிப்பதாக வரைவு விவரிக்கிறது. பெரும்பாலான டோக்கன் நுகர்வை இந்த மலிவான மாதிரிக்கு மாற்றுவதன் மூலம், தரம் குறையாமல் கூட்டமைப்பானது ஒட்டுமொத்தச் செலவைக் குறைவாக வைத்திருக்கிறது.

சுருக்கம் (Bottom line)

  • ஒரு சக்திவாய்ந்த திட்டமிடுபவரை (planner) மலிவான நிறைவேற்றுபவருடன் (executor) இணைப்பது வேகம், குறியீட்டின் சுருக்கம் மற்றும் செலவு ஆகியவற்றில் பன்மடங்கு முன்னேற்றத்தைத் தருகிறது.
  • இந்த வடிவமைப்பு "என்ன" என்பதை முன்னணி மாதிரிகளுக்கும் (frontier models), "எப்படி" என்பதை நிபுணத்துவ மாதிரிகளுக்கும் (specialist models) ஒதுக்குவதன் மூலம் context drift-ஐத் தவிர்க்கிறது.
  • செயல்பாட்டுச் சுமை (Operational overhead) மற்றும் உள்கட்டமைப்புத் தேவைகள் ஆகியவை பரவலான பயன்பாட்டிற்கு இன்னும் மிகப்பெரிய தடைகளாக உள்ளன.