मैं Cursor का उपयोग कैसे करता हूँ

मुझे अपने मन की बात कहनी है। @cursor_ai में अपने इंटरव्यू से पहले, मैंने कभी भी Cursor का उपयोग नहीं किया था।

Meta में, Claude Code जबरदस्त तरीके से लोकप्रिय हो रहा था। मैंने अपने साइड प्रोजेक्ट्स के लिए एक व्यक्तिगत $200 प्रति माह का प्लान भी ले लिया था। मुझे यह बहुत पसंद आया कि यह कितना सरल था, और मैं कितनी जल्दी उत्पादक महसूस कर सकता था। मेरे लिए सबसे बड़ी चुनौती थी अपने खुद के कौशल विकसित करना, जो cc को लगभग वह सब कुछ बना दे जो मैं चाहता था। मैंने इसके ऊपर अपना खुद का एजेंट ऑर्केस्ट्रेटर टूल भी बनाना शुरू कर दिया था।

ऑनसाइट इंटरव्यू के दौरान, मैंने 2 दिनों तक Cursor का उपयोग किया, और इसका उपयोग करके इंटरव्यू प्रोजेक्ट बनाया। यह Cursor 3 के रिलीज़ से पहले की बात है, इसलिए मैं एडिटर विंडो का उपयोग कर रहा था। मैं इतने सालों से vscode का उपयोग कर रहा हूँ कि अधिकांश कीबोर्ड शॉर्टकट अभी भी मेरे कॉन्टेक्स्ट विंडो में थे, इसलिए IDE पर वापस आना बहुत मुश्किल नहीं था। लेकिन मैं झूठ नहीं बोलूँगा, पहले एक-दो घंटों में मुझे cli की कमी ज़रूर महसूस हुई। चीजों पर क्लिक करना लगभग बर्बरतापूर्ण लग रहा था। लेकिन कुछ चीजें थीं जो वास्तव में मुझे प्रभावित कर गईं।

पहली बात, उस समय जिन मॉडलों का मैं आदी था - Opus और Codex - वे किसी तरह ज़्यादा स्मार्ट लगते थे। और यह अद्भुत था कि मैं एक साथ मॉडल बदल सकता था और अपने प्रोजेक्ट के अलग-अलग हिस्सों पर दोनों का उपयोग कर सकता था (फ्रंटएंड के लिए Opus, सिस्टम के लिए Codex)। अपने इंटरव्यू से पहले, मैं पहले से ही मल्टी-मॉडल adversarial review के बारे में बात कर रहा था, इसलिए UI में मूल रूप से ऐसा कर पाना बहुत स्वाभाविक लगा। इससे भी बेहतर यह था कि अलग-अलग मॉडलों के सब-एजेंट बनाए जा सकते थे, ताकि मैं एक ही बातचीत में दोनों दुनिया का सर्वश्रेष्ठ पा सकूं।

दूसरी बात, कॉम्पैक्टेशन बेहद तेज़ था। cc उपयोगकर्ता के रूप में मैं कॉम्पैक्ट होने में कई मिनट लगने का आदी था, और इसलिए मैं हमेशा अपने कॉन्टेक्स्ट और प्लान उपयोग पर नज़र रखता था। इसलिए मैं Cursor में इसकी गति देखकर पूरी तरह से हैरान रह गया। इतना कि मुझे कभी यह देखने की ज़रूरत नहीं पड़ी कि मैं कितना कॉन्टेक्स्ट उपयोग कर रहा हूँ। यह बस काम करता रहा, जबकि cc में कॉम्पैक्टेशन के बाद मुझे अक्सर लगता था कि मॉडल बहुत बेवकूफ हो गया है।

और तीसरी चीज़ जो मैंने देखी, वह यह थी कि GUI, TUI की तुलना में कितना अधिक लाभ प्रदान कर सकते हैं। अपने ऐप को सीधे Cursor के ब्राउज़र में खोलना और Design Mode के साथ डिज़ाइन में बदलाव करना सहज लगा, और इसने मुझे सोचने पर मजबूर कर दिया कि उद्देश्य-निर्मित UI एजेंटिक कोडिंग को कितना अधिक प्रभावी बना सकते हैं।

Cursor के साथ Cursor का निर्माण

मार्च के अंत से जुड़ने के बाद, मैं मुख्य रूप से Cursor 3 की Agent Window पर काम कर रहा हूँ, और इसे अपने दैनिक उपयोग के रूप में उपयोग कर रहा हूँ। जबकि मैं अभी भी cc को एक शानदार टीम वाला एक अच्छा प्रोडक्ट मानता हूँ, मैंने देखा है कि इसकी सादगी लोगों को इसके चारों ओर अपने खुद के एब्स्ट्रैक्शन बनाने के लिए प्रेरित करती है। अपनी पिछली नौकरी में, ऐसा लगता था कि हर हफ्ते cc के ऊपर बना एक नया आंतरिक ऑर्केस्ट्रेटर टूल घोषित किया जाता था।

@bcherny इस "अव्यक्त मांग" (latent demand) के विचार के बारे में बहुत बात करते हैं:

"प्रोडक्ट में एक बहुत पुराना विचार है जिसे अव्यक्त मांग कहते हैं... आप एक प्रोडक्ट को इस तरह से बनाते हैं कि वह हैक करने योग्य हो, वह काफी खुला हो कि लोग इसका दुरुपयोग दूसरे उपयोग के मामलों के लिए कर सकें। फिर आप देखते हैं कि लोग इसका दुरुपयोग कैसे करते हैं और फिर आप उसके लिए निर्माण करते हैं।"

यह बिल्कुल यही था! ऑर्केस्ट्रेशन टूल्स पर एकत्रित होना उस अव्यक्त मांग को उजागर करता है कि cli का उपयोग करना आपको, मनुष्य को, ऑर्केस्ट्रेटर बना देता है।

लेकिन मैंने जिस भी एजेंट वर्कफ़्लो का उपयोग किया था, वह गलत चीज़ पर केंद्रित था। GUI में कई CLI चलाना बिल्कुल गलत था। जिस दृष्टिकोण में मेरी दिलचस्पी थी, वह एजेंटों में विश्वास बनाना था।

एक पूर्व इंजीनियरिंग मैनेजर के रूप में, मुझे जल्दी ही एहसास हुआ कि एजेंटों का प्रबंधन करना एक मानव इंजीनियरिंग टीम बनाने जैसा है। नए कर्मचारियों को ऑनबोर्ड करने की आवश्यकता होती है ताकि वे कोडबेस को समझ सकें, लेकिन यह भी कि काम कैसे होता है। वे अपने पिछले अनुभवों से प्राप्त कौशल के साथ पहले से प्रशिक्षित होकर आते हैं: डीबग कैसे करें, उच्च गुणवत्ता वाला कोड और टेस्ट कैसे लिखें, और कैसे संवाद करें, कुछ नाम करने के लिए।

एजेंट नए कर्मचारियों की तरह हैं जो लगातार भूलने और बेवकूफी की स्थिति में रहते हैं। उन्हें याद नहीं रहता कि आप उन्हें क्या बताते हैं, और वे वास्तव में कभी कुछ नया नहीं सीखते। लेकिन हम उन्हें नियमों, कौशलों, टूल्स और दीर्घकालिक स्मृति से लैस कर सकते हैं जो इसका अनुमान लगा सकते हैं। वे सक्षम फिर भी बेवकूफ हैं, और बहुत सिखाए जा सकने वाले हैं। और मैंने उनकी विफलता के तरीकों को उन्हें वह सब कुछ सिखाने के अवसर के रूप में देखा जो मैं गहरी, कठोर इंजीनियरिंग के बारे में जानता हूँ।

क्योंकि जब कोई कठोरता नहीं होती है, तो एजेंट चापलूसी करते हुए वह कोड लिखने के लिए कुछ भी करेंगे जो आपने माँगा था। और यार, वे बहुत सारा कोड लिख सकते हैं और लिखेंगे भी। भोला समानांतरीकरण (naive parallelization) उन्हें केवल और अधिक तेज़ी से घटिया कोड लिखने पर मजबूर करता है।

यदि आप तेज़ जाना चाहते हैं, तो पहले गहराई में जाएँ

मुझे लगता है कि एजेंट ऑर्केस्ट्रेशन उत्पादक रूप से किया जा सकता है। लेकिन हमें पहले गहराई में जाने की आवश्यकता है।

मैं pstack को ओपन सोर्स कर रहा हूँ, जो मेरे कौशलों और इंजीनियरिंग सिद्धांतों का व्यक्तिगत सेट है जिसका मैं @cursor_ai के निर्माण के लिए प्रतिदिन उपयोग करता हूँ। मैंने अपने साइड प्रोजेक्ट्स में इन कौशलों के शुरुआती संस्करण विकसित करना शुरू किया था, और तब से उन्हें परिष्कृत कर रहा हूँ।

इसे यहाँ प्राप्त करें: https://cursor.com/marketplace/cursor/pstack

ये कौशल Cursor टीम द्वारा सबसे अधिक उपयोग किए जाने वाले कौशलों में से कुछ बन गए हैं, इसलिए मैं इसे आप सभी के साथ साझा करने के लिए उत्साहित हूँ।

pstack एजेंटों को कई मॉडलों का उपयोग करके अधिक कठोर बनना सिखाता है। मैंने उन सभी विफलता मोड को ले लिया है जो मैंने देखे हैं और उन्हें कौशल में बदल दिया है। प्लगइन का हृदय /poteto-mode है, जो एक उच्च-क्रम कौशल है जो एजेंटों को किसी दिए गए कार्य के लिए सही प्लेबुक देता है। लक्ष्य अधिकतम LOC नहीं है, बल्कि इसके विपरीत है: न्यूनतम कोड के साथ अधिकतम प्रभाव।

कठोरता को उसी तरह से समस्याओं के पास जाकर लागू किया जाता है जैसे अनुभवी इंजीनियर करते हैं। उदाहरण के लिए, डीबग करने का एक शानदार तरीका समस्या स्थान की बाइनरी खोज करना है। आप कुछ परिकल्पनाओं के साथ शुरुआत करते हैं कि क्या हो सकता है, और फिर व्यवस्थित रूप से उन्हें खारिज करने का प्रयास करते हैं जब तक कि आप वास्तविक मूल कारण के करीब नहीं पहुँच जाते। यदि इसे दोबारा प्रस्तुत करना कठिन है, तो आप कृत्रिम रूप से बग को होने के लिए मजबूर करने का प्रयास कर सकते हैं। या आप प्रोग्राम के चलने पर उसकी स्थिति की जाँच करने के लिए इंस्ट्रूमेंटेशन या कंसोल लॉगिंग जोड़ने का प्रयास कर सकते हैं।

ये चरण एक प्लेबुक बनाते हैं जिसका उपयोग एजेंटों द्वारा अनुमान लगाने के बजाय अच्छी तरह से समस्याओं को डीबग करने के लिए किया जा सकता है, जो वे करने में प्रसन्न होते हैं यदि आप उन्हें ऐसा करने देते हैं। pstack कई कौशलों और प्लेबुकों के साथ आता है जो आपको सॉफ्टवेयर इंजीनियरिंग को इसी स्तर की कठोरता के साथ करने देता है। मेरे पास वर्तमान में निम्नलिखित के लिए प्लेबुक हैं:

स्किल ऑथरिंग और इवैल
स्वायत्त रूप से काम करना
बग फिक्स और रनटाइम फोरेंसिक
सुविधा विकास
विज़ुअल पैरिटी और प्रोटोटाइपिंग
और भी बहुत कुछ

जब भी आपको कठोरता की आवश्यकता हो, अपने प्रॉम्प्ट को /poteto-mode से प्रीफिक्स करें। उदाहरण के लिए:

आप वैकल्पिक रूप से मांग पर अन्य कौशलों को भी आमंत्रित कर सकते हैं:

/how: आप चाहते हैं कि कोई सबसिस्टम वास्तव में कैसे काम करता है, इसका विवरण चाहते हैं।
/why: आप जानना चाहते हैं कि कुछ इस तरह से क्यों बनाया गया था। आपके उपलब्ध MCPs का उपयोग करके प्रत्येक साक्ष्य श्रेणी (स्रोत नियंत्रण, इश्यू ट्रैकर, लंबे फॉर्म के दस्तावेज़, रीयल-टाइम चैट, इंफ्रा ऑब्ज़र्वेबिलिटी, एरर ट्रैकिंग, एनालिटिक्स वेयरहाउस) को समानांतर में क्वेरी करता है।
/architect: आप एक फंक्शन बाउंड्री को पार करने वाला कोड लिखने वाले हैं और चाहते हैं कि पहले टाइप और डेटा स्ट्रक्चर तय हो जाएँ।
/arena: आप एक ही चीज़ के N समानांतर प्रयास चाहते हैं, फिर प्रत्येक के सर्वश्रेष्ठ भागों को लेना चाहते हैं।
/interrogate: आप चाहते हैं कि अलग-अलग मॉडल किसी चीज़ की विरोधात्मक समीक्षा करें।
/tdd: आप एक बग ठीक कर रहे हैं। पहले फेल होने वाला टेस्ट लिखें, फिर फिक्स।
/unslop: आप किसी भी तरह की AI लेखनी को साफ कर रहे हैं। उन्हें सादा बोलने को कहता है।
/reflect: आप लंबी बातचीत के बाद लगातार अपने कौशल में सुधार करना चाहते हैं।
/figure-it-out: कुछ असामान्य कर रहे हैं? कार्य के लिए एक कठोर, ऑडिट करने योग्य प्लेबुक डिज़ाइन करता है।
/show-me-your-work: आप एक समीक्षा योग्य निर्णय श्रृंखला चाहते हैं। निर्णयों को एक tsv में लॉग करता है जिसे आप कमिट कर सकते हैं।

और अंत में, आप /automate-me के साथ अपना खुद का मोड स्किल बना सकते हैं। यह आपके हाल के ट्रांसक्रिप्ट को माइन करता है, आपके काम करने के तरीके से आपका-मोड स्किल तैयार करता है, और अंतर्निहित रूप से pstack के माध्यम से रूट करता है।

pstack किसी भी एजेंटिक कोडिंग टूल के साथ काम करता है, लेकिन यह Cursor जैसे मल्टी-मॉडल टूल्स में विशेष रूप से अच्छा काम करता है। कई कौशल प्रत्येक मॉडल की अद्वितीय शक्तियों और कमजोरियों का लाभ उठाने के लिए मल्टी-मॉडल वर्कफ़्लो का उपयोग करते हैं। यह एजेंट ऑर्केस्ट्रेशन है, लेकिन चौड़ाई के बजाय गहराई में पहले लागू किया गया है।

एजेंटों के साथ अड़चन सत्यापन है। एजेंट बड़ी मात्रा में कोड जल्दी से लिख सकते हैं। यह सुनिश्चित करना कि यह सब सही है, अत्यंत कठिन है। जब आप वहाँ पहुँच सकते हैं, तो सच्चा एजेंट समानांतरीकरण, जैसे सॉफ्टवेयर के लिए एक डार्क फैक्ट्री में, संभव हो सकता है।

लेकिन पहले, हमें गहराई में जाने और कठोर होने की आवश्यकता है। मुझे लगता है कि हम विश्वास को बढ़ाकर वहाँ पहुँचते हैं।

pstack को आज़माएँ और मुझे बताएँ कि आप क्या सोचते हैं।

ज़ेन और सॉफ्टवेयर रखरखाव की कला

ये कौशल मुझे कोड लिखते समय अधिक आत्मविश्वास के साथ आगे बढ़ने में मदद करते हैं। लेकिन अब एजेंटों द्वारा सारा कोड लिखे जाने के कारण कोड को बनाए रखना एक दुःस्वप्न बन गया है। बग, प्रदर्शन समस्याएँ, और सुविधा अनुरोधों को हल करने में अभी भी समय लगता है। और अब इसमें और भी बहुत कुछ है!

मैं Cursor में Cursor ऑटोमेशन का व्यापक उपयोग करता हूँ। वे क्लाउड एजेंट हैं जिन्हें शेड्यूल किया जा सकता है, या किसी Slack चैनल में नए संदेश जैसी घटनाओं के जवाब में चलाया जा सकता है। ऐसा ही एक उदाहरण मेरा बॉट Benny है। मैंने उसे वही कौशल दिए हैं जो मेरे पास pstack में हैं।

Benny अभी भी निर्माणाधीन है, लेकिन मेरा दृष्टिकोण सॉफ्टवेयर रखरखाव प्रक्रिया को जितना संभव हो उतना स्वचालित करना है। विचार यह है: यदि अब हमारे पास pstack के साथ समस्याओं को काफी हद तक "एक शॉट" में हल करने का आत्मविश्वास है, यह एक अच्छी डिग्री की निश्चितता के साथ कि PR की गुणवत्ता उच्च है, तो निश्चित रूप से हम फीडबैक को भी स्वचालित कर सकते हैं।

यह फैक्ट्री अपना जीवन ट्राइएज से शुरू करती है: बग रिपोर्ट के बारे में कर्मचारियों से जानकारी एकत्र करना। हम Cursor का बहुत अधिक डॉगफ़ूडिंग करते हैं और इसलिए हमें अपने रिलीज़ कैंडिडेट पर कर्मचारियों से बहुत सारी प्रतिक्रिया मिलती है। Benny इमेज और वीडियो अटैचमेंट को समझता है, pstack कौशल का उपयोग करके कोडबेस का पता लगाता है, और यदि यह स्पष्ट नहीं है तो रिपोर्टर के साथ प्रतिलिपि चरणों की जानकारी के लिए चैट करता है।

यह बग रिपोर्टिंग प्रक्रिया का एक महत्वपूर्ण हिस्सा है। स्पष्ट प्रतिलिपि चरणों और यह समझ के बिना कि क्या टूटा है, एजेंट केवल समाधान के बारे में अनुमान लगा सकते हैं। हमें उन्हें यह स्पष्ट समझ देने की आवश्यकता है कि यह वास्तव में कहाँ और कैसे टूटता है।

एक बार ट्राइएज हो जाने के बाद, Benny कोड को देखने, हाल के बग रिग्रेशन के लिए git हिस्ट्री, उसी बग के बारे में अन्य संदेशों के लिए Slack, और यहां तक कि यह जानने के लिए Notion से डिज़ाइन और उत्पाद निर्णयों के बारे में अपने निष्कर्षों के साथ एक टिकट बनाता है कि क्या कोई सुविधा कैसे काम करनी चाहिए: क्या यह एक बग है, या इसे इस तरह से काम करने के लिए डिज़ाइन किया गया था?

टिकट दायर होने के बाद, एक और Benny बॉट इसे मेरे द्वारा बनाए गए एक अन्य कौशल /orchestrate का उपयोग करके उठाता है।

सबसे पहले, वह कंप्यूटर उपयोग के माध्यम से समस्या को दोहराने का प्रयास करता है। Cursor Cloud Agents क्लाउड में Cursor को ही चला सकते हैं, जहाँ वे डेस्कटॉप के साथ बातचीत करते हैं, चीजों पर क्लिक करते हैं, और कीबोर्ड इनपुट भेजते हैं। आंतरिक रूप से, यह मेरे द्वारा बनाए गए अधिक कौशल का उपयोग करता है ताकि CDP या समकक्ष प्रोटोकॉल का उपयोग करके हमारे उत्पादों को प्रोग्रामेटिक रूप से नियंत्रित किया जा सके।

यह हमें यह प्रदर्शित करने की अनुमति देता है कि क्या बग रिपोर्ट को दोहराया जा सकता है। यदि यह लगातार बग को दोहराता है, तो वह इसे ठीक करने का प्रयास करता है। यदि यह एक प्रदर्शन समस्या है, तो Benny पहले और बाद में CPU ट्रेस और हीप स्नैपशॉट ले सकता है। सबप्लानर्स pstack कौशल का उपयोग करके फिक्स को सत्यापित करने और यह जाँचने के लिए अधिक वर्कर्स को स्पॉन करते हैं कि क्या टिकट ठीक हो गया है।

इस रन में अतिरिक्त वर्कर्स को पहले और बाद का वीडियो लेने के लिए स्पॉन किया जाता है, और अंत में एक वर्कर विवरण में वीडियो के साथ समीक्षा के लिए PR खोलता है।

यह सब अभी भी निर्माणाधीन है और करने के लिए बहुत अधिक काम है, लेकिन मैं एजेंटों की एक टीम रखने के बारे में उत्साहित हूँ जो मुझे सोते समय या अन्य काम करते समय आत्मविश्वास के साथ बग ठीक करने में मदद कर सके। कोड समीक्षा को स्केलेबल बनाना एक और बड़ा क्षेत्र है, और मुझे लगता है कि Cursor में मदद करने के लिए कुछ शानदार आगामी सुविधाएँ होंगी।

लेकिन अपना खुद का सॉफ्टवेयर फैक्ट्री बनाने की कुंजी विश्वास है। जब तक आप किसी एजेंट पर सत्यापन सहित अंत-से-अंत तक किसी समस्या का स्वामित्व लेने के लिए भरोसा नहीं कर सकते, आप अपनी प्रक्रियाओं को स्वचालित नहीं कर सकते। जैसे-जैसे आप pstack जैसे प्लगइन्स का उपयोग करके विश्वास बढ़ाते हैं जो आपके एजेंटों को अधिक इंजीनियरिंग गहराई देते हैं, आप अधिक महत्वाकांक्षी समस्याओं से निपटना शुरू कर सकते हैं। उन एजेंटों को समानांतर करने की कोशिश करना जिन पर आप अभी तक भरोसा नहीं करते हैं, टोकन की बर्बादी है और आपके कोडबेस में और अधिक घटिया कोड लाता है।

पढ़ने के लिए धन्यवाद!