AI codingను planners మరియు workers గా విడగొట్టాల్సిన అవసరాన్ని Cursor చెబుతోంది

శక్తివంతమైన models ఎక్కువగా typing చేయడం ఆపితే AI-assisted software development economics మారవచ్చని Cursor వాదిస్తోంది. తన upgraded agent swarm గురించి విడుదల చేసిన కొత్త వివరణలో, higher-end frontier models‌ను ప్రధానంగా planning మరియు task decomposition కోసం వాడినప్పుడు తక్కువ ఖర్చు models coding పనిలో పెద్ద భాగాన్ని విజయవంతంగా నిర్వహించాయని కంపెనీ చెబుతోంది.

ఈ దావా ఒక internal benchmark నుంచి వచ్చింది. ఇందులో Cursor తన కొత్త swarmకూ, పాత version‌కూ, source code లేకుండా, internet access లేకుండా, documentation మాత్రమే ఉపయోగించి Rust‌లో SQLite‌ని rebuild చేయమని కోరింది. కంపెనీ ప్రకారం, కొత్త swarm యొక్క ప్రతి configuration test suite‌పై 100 percent సాధించింది, అయితే పాత system merge conflicts మరియు coordination overhead‌తో ఇబ్బంది పడింది.

ఆ ఫలితం విస్తృతంగా నిజమని తేలితే, అది పరిశ్రమలో ఒక ముఖ్యమైన మార్పును సూచిస్తుంది. AI coding‌లో ప్రధాన ప్రశ్న చాలాసార్లు ఏ single model ఉత్తమ code రాస్తుందనేది. Cursor మాత్రం వేరే దృక్కోణాన్ని ముందుకు తెస్తోంది: వేర్వేరు roles, costs, context windows ఉన్న అనేక agents మధ్య పని ఎలా పంచబడుతుందో అదే మరింత ముఖ్యమైన design choice కావచ్చు.

మూల ఆలోచన parallelism కాదు, division of labor

Cursor ప్రకారం, తన తాజా swarm agents‌ను planners మరియు workers‌గా విడగొడుతుంది. Planner agents మరింత శక్తివంతమైన frontier models‌ను ఉపయోగించి ఒక goal‌ను recursively చిన్న tasks‌గా విభజిస్తాయి. Worker agents, వేగవంతమైన మరియు చౌకైన models‌ను ఉపయోగిస్తూ, ఆ tasks‌ను పూర్తి చేస్తాయి. ఈ ఏర్పాటుతో work మారుతున్న కొద్దీ మారే ఒక task tree ఏర్పడుతుందని కంపెనీ చెబుతోంది.

ఇక్కడ వాదన కేవలం ఎక్కువ agents అంటే ఎక్కువ throughput అన్నది కాదు. Cursor చెప్పే ప్రధాన అంశం swarm‌లు context-management problem‌ను పరిష్కరించడంలో సహాయపడతాయని. పెద్ద coding assignment‌పై పని చేసే single agent ఒకేసారి end goal, local implementation details, intermediate decisions అన్నింటినీ active‌గా ఉంచాలి. దీనివల్ల drift, duplication, poor handoffs‌కు అవకాశాలు పెరుగుతాయి. అందుకు విరుద్ధంగా, swarm planning‌ను execution నుంచి వేరు చేసి ప్రతి agent‌పై cognitive burden‌ను తగ్గించగలదు.

Cursor చెప్పినట్లుగా, ఇదే role separation performance‌ను మెరుగుపరిచింది. Planners code రాయలేదు, workers planning చేయలేదు. ఇది సాదాసీదాగా అనిపించవచ్చు, కానీ software-building agents గురించి ఇది ఒక architectural claim: ప్రతి model‌తో అన్నీ చేయించడానికి ప్రయత్నించడంకంటే specialization ఎక్కువ విలువైనదిగా ఉండవచ్చు.

Schema "Decomposing work keeps every agent
Cursor ప్రకారం, swarms scale కావడం parallel work వల్ల తక్కువగా, planners మరియు workers మధ్య context‌ను విడగొట్టడం వల్ల ఎక్కువగా జరుగుతుంది. | Image by Cursor

మునుపటి bottleneck intelligence మాత్రమే కాదు, coordination కూడా

Cursor తన పాత swarm‌తో చేసిన పోలిక ఆసక్తికరంగా ఉంది, ఎందుకంటే కంపెనీ raw model weakness కంటే organizational సమస్యలానే కనిపించే failure modes‌ను వివరించింది. ఒక మునుపటి browser-based swarm Gitపై గంటకు సుమారు 1,000 commits సాధించిందని, అలాగే worker agents, ఒక judge agent, conflicts‌ను పరిష్కరించే integrator‌పై ఆధారపడిందని పేర్కొంది. Cursor ప్రకారం, చివరకు integrator పరిష్కారంగా కాక bottleneck‌గా మారింది.

కంపెనీ చెబుతున్నదాని ప్రకారం, కొత్త swarm సుమారు సెకనుకు 1,000 commits స్థాయికి చేరింది, ఆ వేగంలో conventional Git workflows పనిచేయలేకపోయాయి. అందుకే agent activity కోసం Cursor తానే version control system నిర్మించాల్సి వచ్చింది. కంపెనీ వివరించినట్టుగా, ఈ వేగంలో పనిచేసే agents మానవ బృందాల్లో సాధారణంగా కనిపించని failure modes‌ను సృష్టించాయి.

అందులో ఒకటి Cursor “split-brain design” అని పిలిచింది. ఇందులో ఇద్దరు planners స్వతంత్రంగా ఒకే broad idea‌కు వచ్చారు, కానీ దాన్ని వేర్వేరు చోట్ల incompatible మార్గాల్లో అమలు చేశారు. మరొక సమస్య planners ఒకరినొకరు గమనించి, competing edits‌తో పరస్పరం block చేయడం ప్రారంభించినప్పుడు వచ్చింది. ఇవి syntax errors‌లా కాక machine labor force లోపల governance failures‌లా కనిపిస్తాయి.

Shared design records వ్యవస్థలో భాగమయ్యాయి

ఈ coordination సమస్యలను నిర్వహించడానికి, agents నిర్ణయాలను shared design documents‌లో నమోదు చేశాయని Cursor చెబుతోంది. ఆ నిర్ణయానికి సంబంధించిన code, compile timeలో తనిఖీ చేయబడే ఒక reference ద్వారా document‌కు తిరిగి అనుసంధానించబడేది. merge conflicts వచ్చినప్పుడు, ఒక neutral agent వాటిని పరిష్కరించేది. Workers పెద్ద ఫైళ్లను చిన్న modules‌గా విడగొట్టడానికి external agent‌ను కూడా flag చేయగలిగేవి.

ఈ వివరాలు ముఖ్యమైనవి, ఎందుకంటే కంపెనీ పురోగతి prompting లేదా model choice‌లో మాత్రమే కాదు, workflow infrastructure‌లో కూడా ఉందని సూచిస్తున్నాయి. Design documents memory, policy పాత్రలు పోషిస్తాయి. Neutral conflict resolver procedural backstop‌గా పనిచేస్తుంది. Compile-time references implementation‌ను rationale‌తో కలుపుతాయి. మానవ software engineering‌లో ఈ పనులు architecture docs, code review, build systems మధ్య విభజించబడి ఉంటాయి. Cursor AI collectives కోసం అలాంటి equivalent mechanisms‌ను formalize చేయడానికి ప్రయత్నిస్తోంది.

కంపెనీ behavioral assumptions‌ను కూడా మార్చిందని చెబుతోంది. Human codebasesలో వాడేందుకు trained agents core code‌ను నిర్లక్ష్యంగా తాకకుండా ఉండడం నేర్చుకున్నందున, Cursor వారికి ఈ controlled environmentలో ఉద్దేశపూర్వకంగా things break చేయడానికి అనుమతి ఇచ్చింది. ఇది ముఖ్యమైన caveat. Greenfield లేదా benchmark tasks కోసం optimized swarm production codebases‌లో అదే విధంగా ప్రవర్తించకపోవచ్చు, అక్కడ stability, compatibility, team conventions raw task completion కంటే ఎక్కువ ప్రాముఖ్యం కలిగి ఉంటాయి.

Liniendiagramm der kumulierten Merge-Konflikte ab dem ersten Konflikt; v1 erreicht nach 120 Minuten fast 70.000 Konflikte mit steigender Kurve, v2 bleibt flach unter tausend.
పాత version conflict rate తగ్గకుండా వేగంగా పెరుగుతూనే ఉంది. | Image by Cursor

ఈ ఫలితం Cursor కంటే ఎందుకు పెద్దది

Cursor నివేదికలో అత్యంత బలమైన implication ఆర్థికపరమైనదే. High-end models‌ను ప్రధానంగా planning‌కు పరిమితం చేసి, lower-cost models ఎక్కువ implementation పనిని చేయగలిగితే advanced coding automation యొక్క cost structure మారుతుంది. Frontier-model usage మరింత selective అవుతుంది, తద్వారా teams ప్రతి దశకూ frontier-model prices చెల్లించకుండా agentic work‌ను scale చేయగలవు.

Software companies single assistants కంటే agent fleets‌తో ప్రయోగాలు చేస్తున్న ఈ సమయంలో ఇది ప్రాముఖ్యం పొందుతోంది. వాణిజ్య ప్రశ్న ఇక AI code రాయగలదా లేదా అన్నదానికే పరిమితం కాదు, అది coordination మరియు error recoveryతో, దీర్ఘకాల వినియోగానికి సరిపడేంత తక్కువ ధరకు అది చేయగలదా అన్నదీ. Cursor యొక్క planner-worker structure ఈ రెండో ప్రశ్నకు స్పష్టమైన సమాధానం ఇవ్వడానికి చేసిన ప్రయత్నం.

జాగ్రత్త అవసరమయ్యే కారణాలు కూడా ఉన్నాయి. Report చేసిన benchmark internal, task-bounded, highly specific. Documentation నుండి Rust‌లో SQLite rebuild చేయడం కఠినమైన పరీక్షే, కానీ messy enterprise systems‌ను maintain చేయడం, incomplete product requirements‌ను అర్థం చేసుకోవడం లేదా నిజమైన organizational constraints‌ను దాటుకుని పని చేయడం వేరే విషయం. కాబట్టి కంపెనీ దావాలు settled industry conclusion కంటే emerging pattern గురించి ఎక్కువ చెబుతున్నాయి.

అయితే కూడా, పెద్ద సంకేతాన్ని విస్మరించడం కష్టం. Cursor ఒక future‌ను వివరిస్తోంది, అందులో ప్రధాన innovation single ever-larger coding model కాదు, differentiated roles ఉన్న models యొక్క managed ecosystem. Planning, execution, conflict resolution, refactoring, design-memory functions‌ను వేర్వేరు agents‌కు కేటాయించి speed, cost లేదా reasoning depth కోసం tune చేయవచ్చు.

ఆ model విస్తరిస్తే, developers AI tools‌ను ఎలా అంచనా వేస్తారో మారిపోవచ్చు. ప్రధాన metric ఇక ఒక model completions quality మాత్రమే కాదు. అది orchestration quality అవుతుంది: ఒక system work‌ను ఎంత బాగా విభజిస్తుంది, context‌ను ఎలా కాపాడుతుంది, collisions‌ను ఎలా పరిష్కరిస్తుంది, మరియు expensive reasoning‌ను అత్యధిక value ఇచ్చే చోట మాత్రమే ఎలా కేటాయిస్తుంది.

Cursor ఫలితాలు ప్రతి environment‌లో ఎక్కువ coding‌కు cheaper models సరిపోతాయని నిరూపించవు. కానీ అవి ఒక narrower, మరియు ప్రభావవంతమైన, దావాను మద్దతు ఇస్తాయి: frontier models‌ను అంతా చేయడానికి కాక పని plan చేయడానికి ఉపయోగించినప్పుడు, lower-cost agents అనేక teams ప్రస్తుతం అనుకునేదానికంటే చాలా ఎక్కువ implementation load‌ను మోయగలవు.

ఈ వ్యాసం The Decoder నివేదికపై ఆధారపడింది. మూల వ్యాసాన్ని చదవండి.

Originally published on the-decoder.com