समस्याओं पर हमारी मूल पोस्ट के अनुवर्ती के रूप में, यहाँ कुछ और समस्याएँ दी गई हैं, जो हमारे अनुसार AI-प्रोग्रामिंग के अगले चरण में सबसे ज़्यादा महत्त्वपूर्ण हैं।

#अगली कार्रवाई का पूर्वानुमान

Cursor में Copilot++ शामिल है, जो Copilot का एक अधिक बुद्धिमान संस्करण है और आपके अगले संपादन का पूर्वानुमान लगाता है। क्या हम इस विचार को इसकी स्वाभाविक चरम सीमा तक ले जा सकते हैं?

कोडिंग करते समय, आप सिर्फ कम-एंट्रॉपी वाले संपादन नहीं करते। पूरे एडिटर में, आप कम-एंट्रॉपी वाले कीस्ट्रोक, क्लिक और कार्रवाइयाँ करते हैं। क्या हम कम विलंबता के साथ इनमें से हर एक का पूर्वानुमान लगाने वाला मॉडल बिल्ड कर सकते हैं?

शुरुआत में, हमने Copilot++ का विस्तार किया ताकि वह आपके अगले स्थान का पूर्वानुमान लगा सके। इसे अगले संपादन के पूर्वानुमान के साथ जोड़ दें, तो मॉडल कम-एंट्रॉपी वाले परिवर्तनों की एक शृंखला पूरी कर सकता है:

हम इस बात का पूर्वानुमान लगाने पर काम कर रहे हैं कि आप अगली किस फ़ाइल पर जाएँगे। अगला कौन-सा टर्मिनल कमांड चलाएँगे। और आपके पिछले टर्मिनल कमांड्स के आधार पर अगला संपादन क्या होगा! यानी, एक अगली कार्रवाई का पूर्वानुमान मॉडल।

इसके अलावा, मॉडल को ठीक उसी क्षण जानकारी सामने लानी चाहिए, जब आपको उसकी ज़रूरत हो — चाहे वह कोड का सही हिस्सा हो या दस्तावेज़ीकरण।

Cursor को आपकी इच्छा के विस्तार जैसा महसूस होना चाहिए। जिस क्षण आपके मन में किसी परिवर्तन का विचार आए, भाषा मॉडल को उसे तुरंत पूरा करने के लिए बस न्यूनतम आशय चाहिए।

#आशाजनक दिशाएँ

• पूरे कोडबेस में कार्रवाई के पूर्वानुमान पर बुनियादी अनुसंधान।

• ~5–13B सक्रिय पैरामीटर वाले कोड-मॉडल्स पर निरंतर प्री-ट्रेनिंग और पोस्ट-ट्रेनिंग (प्रीफिल-आधारित कम-विलंबता वाले पूर्वानुमानों के लिए)।

• Speculative Edits जैसी अतिरिक्त अनुमिति युक्तियाँ

“कार्रवाइयों” को गैर-दखल देने वाले तरीके से दिखाने के लिए चतुर UX। (आप उपयोगकर्ता को अगली कौन-सी फ़ाइल सुझाएँगे, जिस पर उसे जाना चाहिए? या वर्तमान viewport के बाहर अगला स्थान?)

#बेहतरीन संपादन

क्या हम उच्च-गुणवत्ता वाले, बड़े संपादन तैयार करने के लिए अनुमिति-समय की कंप्यूट क्षमता को बढ़ा सकते हैं? बढ़ी हुई विलंबता की भरपाई हम कैसे करें?

हो सकता है कि संपादन पृष्ठभूमि में करना पड़े। काम की एक ऐसी इकाई अलग करना, जिसे आप भरोसे के साथ बुद्धिमान मॉडल्स को सौंप सकें।

हमें ऐसे मॉडल्स की आवश्यकता होगी जिनमें एडिटर-विशिष्ट टूल उपयोग करने की मजबूत क्षमताएँ हों, पूरे कोडबेस के संदर्भ की बेहतर समझ हो, और दीर्घकालिक तर्क-क्षमता बेहतर हो।

और हम async code-generation को प्रवाह बनाए रखने वाला कैसे बना सकते हैं। यह सुनने में विरोधाभासी लगता है, लेकिन हमारा मानना है कि मॉडल क्षमताओं और UX पर सूझबूझ भरा अनुसंधान इसे संभव बना सकता है।

#काल्पनिक छद्म-कोड

उपयोगकर्ता ऐसा छद्म-कोड लिखेंगे जो वांछित परिवर्तन का वर्णन करता है। फिर हम Cursor पर भरोसा कर सकते हैं कि वह उस छद्म-कोड को पृष्ठभूमि में पूरे परिवर्तन में बदल दे।

#बहु-फ़ाइल संपादन

Cmd-k पहले से ही शानदार है, लेकिन यदि आप अपने पूरे कोडबेस में एक सामान्य संपादन करने के लिए कह सकें तो? खासकर, ऐसा जो कई फ़ाइलों में सटीक रूप से लागू हो?

#आशाजनक दिशाएँ

• अनुमिति-समय कंप्यूट को स्केल करना। हमें पता है कि रिवार्ड मॉडल और rejection sampling तेज़ और आसान सुधार दिखाएँगे, लेकिन हम इससे कितनी आगे तक जा सकते हैं?

• बेहतर तर्क मॉडल (gpt-5, claude-4, gemini 2.0)

• किसी उपयोगकर्ता के कार्यस्थान के लिए कई language-server/file-system प्रतियां चलाना। इसके लिए मॉडल द्वारा टूल का उपयोग और रनटाइम परिवेशों को दूरस्थ रूप से पुनर्निर्मित करना आवश्यक होगा।

• एजेंट trajectories पर मॉडल के प्रदर्शन का प्रशिक्षण/सुधार

• in-flow async संपादनों के लिए महत्वपूर्ण UX प्रयोग

#सर्वोत्तम संदर्भ

दस्तावेज़ीकरण के लाखों टोकन, स्रोत कोड के करोड़ों टोकन, कमिट इतिहास के और भी करोड़ों टोकन हो सकते हैं—ये सभी संभावित रूप से एक ही क्वेरी को सुलझाने के लिए उपयोगी हो सकते हैं।

यह तो आपके UI के पिक्सेल, उत्पादन और localhost के लॉग्स, Slack के संदेश वगैरह की बात भी नहीं है...

हमारा मानना है कि सर्वश्रेष्ठ कोडिंग सिस्टम इस सारी जानकारी को समाहित करने के लिए पुनर्प्राप्ति, recurrence, और long-context attention के मिश्रण का उपयोग करेंगे।

हम सिस्टम्स पर ज़ोर देते हैं क्योंकि निकट भविष्य में यह मॉडल्स और इंफ्रा का एक ensemble हो सकता है, जो मिलकर कोडिंग के लिए एक अनंत संदर्भ इंजन बनाते हैं। लंबे समय में, हम उम्मीद करते हैं कि यह आर्किटेक्चर में ही अंतर्निहित होगा।

हम विशेष रूप से पुनर्प्राप्ति के भविष्य के बारे में रचनात्मक ढंग से सोचने को लेकर उत्साहित हैं। एम्बेडिंग्स से आगे बढ़ते हुए, एक महंगे अनुक्रमण चरण और एक सस्ते querying चरण (corpus के आकार के सापेक्ष sublinear) जैसी मूलभूत संरचना को देखते हुए, सर्वश्रेष्ठ प्रदर्शन कितना संभव है?

शायद यह transformer memory as a differentiable search index के किसी रूपांतर जैसा दिखे। संभव है कि यह पूरी तरह कुछ और ही हो। यह अनुसंधान की एक ऐसी दिशा है, जिस पर अभी कम काम हुआ है।

#मल्टी-हॉप संदर्भ

मेरे कोडबेस में, मैं दो स्ट्रिंग्स के बीच एक डिफ निकालना चाहता हूँ। एम्बेडिंग्स के जरिए, मुझे यह चंक मिलता है:

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

मूल प्रश्न का उत्तर देने के लिए, मुझे यह तय करना होगा कि एक string से ITextModel कैसे बनाएँ। यह ऐसा प्रश्न है जिसे सुलझाने के लिए दो hops की आवश्यकता होती है।

किसी कोडबेस में सबसे कठिन प्रश्नों और queries के लिए कई hops आवश्यक होते हैं। साधारण पुनर्प्राप्ति केवल एक hop के लिए ही काम करती है।

#आशाजनक दिशाएँ

• कोडबेस के लिए विशेषीकृत/सुधारित एम्बेडिंग्स और री-रैंकर्स।

• मल्टी-हॉप एम्बेडर्स का प्रशिक्षण। किसी क्वेरी और अब तक मिले प्रासंगिक कोड को देखते हुए, यह तय करना कि आगे कोड के किस हिस्से पर हॉप करना है।

• चतुर प्रीफ़िक्स-कैशिंग और संभवतः कस्टम एटेंशन मास्क, जो कोडबेस के लिए बेहतर अनुकूल हों।

• कोडबेस-स्तरीय पुनर्प्राप्ति पर नया अनुसंधान।

• किसी मॉडल को उसके वेट्स में एक कोडबेस सीखने के लिए प्रशिक्षित करना, कुछ वैसे ही जैसे ट्रांसफ़ॉर्मर्स को खोज इंडेक्स की तरह इस्तेमाल किया जाता है।

#बग पहचान और डीबगिंग

मौजूदा बग-पहचान प्रणालियों को कैलिब्रेशन और कोडबेस की पर्याप्त समझ, दोनों में दिक्कत होती है।

मॉडल्स इतने सक्षम हैं कि वे बग्स की सही पहचान कर सकें, लेकिन उनमें false positives की समस्या रहती है। सबसे पेचीदा बग्स की पहचान के लिए कोडबेस की गहरी समझ चाहिए। और जो कोड पहली नज़र में बगयुक्त लगता है, वह व्यापक संदर्भ देखने पर सही भी हो सकता है।

यह एक रूप में ऐसे सामने आ सकता है: भाषा मॉडल्स का इस्तेमाल करके कोड समीक्षा का कहीं बेहतर अनुभव।

#AI समीक्षा में बग्स का पता लगाना

“AI समीक्षा” का लाभ यह है कि उपयोगकर्ता false positives को अधिक आसानी से स्वीकार कर लेता है, क्योंकि वही समीक्षा का अनुरोध कर रहा होता है। इसकी कमी यह है कि इसके लिए उपयोगकर्ता के व्यवहार में बदलाव करना पड़ता है।

#AI linting

बग पहचान का सर्वश्रेष्ठ रूप एक ऐसा हमेशा चालू रहने वाला linter है, जो पृष्ठभूमि में आपके बग्स को पकड़ लेता है। इसके लिए AI-review से सस्ता और तेज़ मॉडल होना चाहिए, क्योंकि हम इसे हर मिनट कई बार चलाएँगे। इसे false-positive की कम दर के लिए ट्यून किया हुआ भी होना चाहिए।

#अधिक स्मार्ट डीबगिंग

शायद बग पहचान से भी अधिक प्रभावशाली बात कठिन समस्याओं की डीबगिंग है।

हमें LLM-आधारित स्थिर विश्लेषण से आगे बढ़ना होगा। उदाहरण के लिए, हमने cursor/debug पैकेज बनाया है। जब इसे आपके कोड में इंजेक्ट किया जाता है, तो यह रनटाइम जानकारी को ट्रैक करता है।

पृष्ठभूमि में, हम इसका उपयोग अतिरिक्त वेरिएबल स्टेट्स को ट्रैक करने के लिए भी कर सकते हैं (यह print-debugging जैसा है, जिसमें प्रासंगिक आउटपुट Cursor के संदर्भ में पाइप किए जाते हैं)।

#आशाजनक दिशाएँ

• कैलिब्रेशन में सुधार के लिए चतुर डेटासेट क्यूरेशन (संभवतः सिंथेटिक डेटा) और अत्याधुनिक कोड मॉडल्स पर RL।

• अन्य इंटरफ़ेस (ब्राउज़र या गैर-एकीकृत टर्मिनल) से प्रासंगिक जानकारी ट्रैक करना।

• डीबगर-विशिष्ट टूल उपयोग और चेन में अत्याधुनिक मॉडल के प्रदर्शन में सुधार।

• असीमित संदर्भ और कोडबेस की लगभग पूर्ण समझ।

• प्रोग्राम की स्थिति से जुड़ी सभी उपयोगी जानकारी ट्रैक करने के लिए हमारी cursor/debug लाइब्रेरी के दायरे का विस्तार।

अगर इनमें से किसी भी समस्या पर काम करने में आपकी रुचि है, तो कृपया hiring@cursor.com पर संपर्क करें