రెండు మెదడుల ఆర్కిటెక్చర్ ఎందుకు?
చాలా కోడ్-రైటింగ్ అసిస్టెంట్లు ఒకే మోడల్ను ఉపయోగిస్తాయి, అది ఏమి నిర్మించాలో నిర్ణయించడమే కాకుండా (and) సోర్స్ కోడ్ను కూడా రాయాల్సి ఉంటుంది. సుదీర్ఘమైన సెషన్ల సమయంలో, ఆ మోడల్ యొక్క కాంటెక్స్ట్ విండో నిండిపోతుంది, దీనివల్ల "context drift" జరుగుతుంది – అంటే అది మునుపటి నిర్ణయాలను మర్చిపోయి, పరస్పర విరుద్ధమైన లేదా డూప్లికేట్ కోడ్ను ఇస్తుంది. Cursor ఈ మానసిక శ్రమను విభజించడం ద్వారా దీనిని పరిష్కరిస్తుంది:
- Planner agents అత్యంత శక్తివంతమైన మోడళ్లపై నడుస్తాయి (డ్రాఫ్ట్లో Opus 4.8 లేదా Fable 5 అని పేర్కొనబడింది). ఇవి ఒక ఉన్నత స్థాయి అభ్యర్థనను టాస్క్ హైరార్కీగా విభజిస్తాయి, అస్పష్టతలను తొలగిస్తాయి మరియు డిజైన్ ఎంపికలను రికార్డ్ చేస్తాయి.
- Worker agents వేగవంతమైన, అధిక త్రూపుట్ (high-throughput) కలిగిన మోడళ్లపై (Composer 2.5) నడుస్తాయి. ఇవి ప్లానర్ల నుండి నిర్దిష్ట పనులను తీసుకుని కోడ్ స్నిప్పెట్లను రూపొందిస్తాయి.
"ఏమిటి" (what) మరియు "ఎలా" (how) అనే అంశాలను వేరుగా ఉంచడం వల్ల సింగిల్-మోడల్ సిస్టమ్స్ను నిలిపివేసే ఓవర్లోడ్ను నిరోధించవచ్చు. ప్రతి మోడల్ దాని పాత్రకు సరిపోయే కాంటెక్స్ట్ పరిమాణంలోనే ఉంటుంది, దీనివల్ల డిజైనర్లు ప్రాంప్ట్లను తగ్గించాల్సి వచ్చేలా చేసే టోకెన్-బడ్జెట్ సమస్యను నివారించవచ్చు.
స్వార్మ్ (swarm) స్కేలింగ్
Cursor యొక్క స్వార్మ్ ప్రారంభ వెర్షన్లు గంటకు సుమారు వెయ్యి కమిట్లను (commits) చేసేవి. స్ప్లిట్-బ్రెయిన్ రీడిజైన్ తర్వాత, సిస్టమ్ సెకనుకు సుమారు వెయ్యి కమిట్ల వేగాన్ని అందుకుంది. ఆ వేగం ఒక కొత్త అడ్డంకిని (bottleneck) బయటపెట్టింది: వెర్షన్-కంట్రోల్ టూల్స్ అంతటి పోటీని తట్టుకునేలా రూపొందించబడలేదు. ఇద్దరు ప్లానర్లు ఒకే రకమైన (overlapping) సూచనలను ఇచ్చినప్పుడు, రిపోజిటరీలో డూప్లికేట్ లాజిక్ వచ్చే అవకాశం ఉంది – ఈ సమస్యను టీమ్ "split-brain errors" అని పిలుస్తుంది.
Cursor మూడు రక్షణ చర్యలతో ఈ గందరగోళాన్ని అదుపు చేసింది:
- Shared design documents – ప్రతి ప్లానర్ తన నిర్ణయాలను జనరేట్ చేయబడిన కోడ్కు అనుసంధానించబడిన ఒక సెంట్రల్ డాక్యుమెంట్కు రాస్తుంది. వర్కర్లు ఆ లింక్లను అనుసరిస్తారు, తద్వారా అదే డిజైన్ మరెక్కడో మళ్ళీ సృష్టించబడదు.
- Multi-angle reviews – మూడు ఏజెంట్లు పని యొక్క వేర్వేరు భాగాలను (పూర్తి ట్రాన్స్క్రిప్ట్, కేవలం అవుట్పుట్, లేదా కేవలం కోడ్ మాత్రమే) తనిఖీ చేస్తాయి. ఈ క్రాస్-చెకింగ్ వల్ల సింగిల్ వ్యూలో గుర్తించలేని అసంగతాలను (inconsistencies) పట్టుకోవచ్చు.
- Self-maintained field guides – ఏజెంట్లు ఆశ్చర్యపరిచే అంశాలు మరియు లోపాల (pitfalls) గురించి ఒక "knowledge folder"ను నిర్వహిస్తాయి. కొత్త వర్కర్ ప్రారంభమైనప్పుడు, తెలిసిన తప్పులను మళ్ళీ చేయకుండా ఉండటానికి అది ఆ ఫోల్డర్ను సంప్రదిస్తుంది, ఇది స్వార్మ్ అంతటా షార్ట్-టర్మ్ మెమరీని అందిస్తుంది.
ఈ చర్యలు మార్పుల ప్రవాహం ఉన్నప్పటికీ కోడ్బేస్ను సమగ్రంగా (coherent) ఉంచుతాయి.
ముఖ్యమైన బెంచ్మార్క్లు (Benchmarks)
Cursor తన హైబ్రిడ్ స్వార్మ్ను పరీక్షించడానికి మొత్తం SQLite మాన్యువల్ను (835 పేజీల Rust ఇంప్లిమెంటేషన్) మళ్ళీ నిర్మించింది – ఇది ఖచ్చితత్వం మరియు పరిమాణం రెండింటినీ పరీక్షించే పని. ఫలితాలు స్పష్టంగా ఉన్నాయి:
- Accuracy – హైబ్రిడ్ కాన్ఫిగరేషన్ (planner + Composer workers) 100% ఖచ్చితత్వాన్ని సాధించింది, ఇది అత్యంత అధునాతన మోడల్ (GPT-5.5) యొక్క సోలో రన్ను కూడా స్థిరంగా అధిగమించింది.
- Code size – పాత మోనోలిథిక్ స్వార్మ్ నుండి వచ్చిన 64,305 లైన్ల కోడ్తో పోలిస్తే, హైబ్రిడ్ స్వార్మ్ 9,908 లైన్ల ఇంజిన్ కోడ్ను మాత్రమే ఉత్పత్తి చేసింది.
- Cost – సోలో GPT-5.5 ఇన్స్టెన్స్ను నడపడానికి సుమారు $10,565 ఖర్చయింది. హైబ్రిడ్ విధానం వర్కర్ ఫ్లీట్ కోసం కేవలం $411 మాత్రమే ఖర్చు చేసింది.
ఈ ఖర్చు వ్యత్యాసానికి కారణం Composer 2.5. ఇది ఫ్లాగ్షిప్ మోడళ్లకు సమానమైన పనితీరును అందిస్తూనే, తక్కువ ధరకే (per-million-token price లో చాలా తక్కువ భాగం) లభిస్తుందని డ్రాఫ్ట్ వివరిస్తుంది. ఎక్కువ టోకెన్ వినియోగాన్ని ఈ చౌకైన మోడల్కు మళ్లించడం ద్వారా, స్వార్మ్ నాణ్యతను తగ్గించకుండా మొత్తం ఖర్చును తక్కువగా ఉంచుతుంది.
ముగింపు (Bottom line)
- శక్తివంతమైన ప్లానర్ను చౌకైన ఎగ్జిక్యూటర్తో జత చేయడం వల్ల వేగం, కోడ్ కాంపాక్ట్నెస్ మరియు ఖర్చులో గణనీయమైన (orders-of-magnitude) లాభాలు లభిస్తాయి.
- ఈ డిజైన్ "ఏమిటి" (what) అనే అంశాన్ని ఫ్రాంటియర్ మోడళ్లకు మరియు "ఎలా" (how) అనే అంశాన్ని స్పెషలిస్ట్ మోడళ్లకు కేటాయించడం ద్వారా కాంటెక్స్ట్ డ్రిఫ్ట్ను నివారిస్తుంది.
- ఆపరేషనల్ ఓవర్హెడ్ మరియు ఇన్ఫ్రాస్ట్రక్చర్ అవసరాలు విస్తృతమైన వినియోగానికి అతిపెద్ద అడ్డంకులుగా ఉన్నాయి.