- Cursor और Claude Code को साथ-साथ इस्तेमाल करते हुए बड़े codebase में वास्तविक development काम और LLM evaluation consulting जैसे कई तरह के कामों का अनुभव मिला
- Cursor अपने सुविधाजनक UI/UX और unlimited API access की वजह से power users के बीच लोकप्रिय था, लेकिन हाल में कड़े rate limit आने से user experience अचानक बहुत सीमित हो गया
- Claude Code का Sonnet 4 code समझने, edit करने और बड़े context को संभालने में उच्च भरोसेमंदी और efficiency दिखाता है, और Opus 4 के साथ मिलाकर इस्तेमाल करने पर मुश्किल bugs भी हल किए जा सकते हैं
- command-based CLI environment, sub-agent का उपयोग जैसी power users के लिए कई advanced capabilities छिपी हुई हैं, और लगातार experiment करना व features खोजना एक अहम अनुभव है
- कमियां के रूप में visual UI की कमी, धीमा copy/paste, दूसरे models के उपयोग पर पाबंदी, checkpoint जैसी अतिरिक्त improvements की मांग अभी बाकी है
Cursor से Claude Code तक: बदलाव की पृष्ठभूमि
- हाल तक Cursor को unlimited API usage और सहज Diff review workflow की वजह से developers बहुत पसंद करते थे
- इसलिए इसका उपयोग मुख्य रूप से Gumroad bounties और AI engineering/LLM evaluation से जुड़े advisory कामों में code generate करने और codebase को जल्दी समझने के लिए किया गया
- लेकिन जून के मध्य के बाद अचानक कड़े rate limit लागू हो गए, जिससे काम की efficiency तेज़ी से घट गई और Cursor के फायदे काफी कम हो गए
- Sonnet 4, Opus 4, GPT-4.1, Gemini Pro 2.5 जैसे कई models में से वास्तविक उपयोग में Sonnet 4 और Opus 4 सबसे ज़्यादा काम आए
- API cost और speed slowdown जैसी सीमाओं के कारण Claude Code Max subscription (महीने के 200 डॉलर) तक लेने पर विचार करते हुए गंभीर रूप से migration की कोशिश की गई
Claude Code का वास्तविक उपयोग अनुभव
- Python, Ruby, TypeScript जैसे medium-to-large open source codebase (50M+ tokens) में Claude Code का उपयोग किया गया, और specs व tests के ज़रिये feedback loop का अनुभव हुआ
- शुरुआत में सिर्फ़ simple command input का इस्तेमाल किया, लेकिन बाद में basic commands और plan mode सीखकर इसका और गहरा उपयोग तलाशा गया
- simple command input → command/plan mode सीखना → साफ़ command combinations के ज़रिये automation और productivity में सुधार
- problem-solving process को लगभग consultation की तरह खुलकर इस्तेमाल किया गया: Claude को पूरा context दे देना, ज़रूरत पड़ने पर Opus पर switch करके plan बनाना (Plan mode), और Sonnet 4 से मुख्य काम कराना — यह mixed strategy अपनाई गई
- Claude को .claude folder के अंदर files में record और organize करने के लिए कहा गया ताकि context management और copy/paste की असुविधा कम हो, और Plan mode/Auto-edit mode साथ में इस्तेमाल करने की सिफारिश की गई
- context management: compaction के बजाय समय-समय पर नया chat शुरू करना, और ज़रूरी बदलाव अलग file में note करने के लिए कहना
Context management और sub-agent का उपयोग
- Claude Code context compression support करता है, लेकिन यह धीमा और कम efficient लगा, इसलिए मुख्य बिंदुओं की file बनाकर नया chat शुरू करना ज़्यादा पसंद किया गया
- Scratchpad जैसी auxiliary files में changes, notes और history लिखवाकर बाद में branch काम या session recovery (/resume) में इस्तेमाल किया गया
- sub-agent: codebase के भीतर कई कामों (search, analysis आदि) को parallel में चलाकर multithreading structure में काम बांटा जा सकता है
- अंदरूनी तौर पर ToDo list आधारित multi-agent बनते हैं, जो context management में मदद करते हैं
Search और commands का उपयोग
- Cursor में normal/semantic search, agentic search जैसे कई tools उपलब्ध हैं, और search speed भी तेज़ है
- लेकिन Claude Code की search धीमी हो सकती है। sub-agents का उपयोग करने पर बड़े codebase में parallel processing संभव है
- sub-agent, task tool,
/think, /ultrathink जैसे commands के उपयोग से बड़े repository को explore करना और कामों को बांटना संभव हुआ
Shift + ? shortcut से command list देखकर नए features जल्दी देखना महत्वपूर्ण है- terminal commands (bash) को
! से, और headless mode में भी चलाया जा सकता है
- file tags (
@file), memorize feature (user-customized system prompt), CLAUDE.md जैसे कई advanced features built-in हैं
Sonnet 4 vs Opus 4 तुलना और workflow tips
- Sonnet 4: ज़्यादातर स्थितियों में तेज़, लंबे context + agent काम में मज़बूत। Python और frontend कामों में बेहतर
- Opus 4: कई बार instructions जमा होने पर confused होने की प्रवृत्ति दिखती है; ऐसे में file में लिखकर नया chat शुरू करने की सलाह है। जब Sonnet 4 अटक जाए तो कठिन bugs सुलझाने में उपयोगी
- जटिल समस्याओं के लिए Opus से शुरुआत और सामान्य coding के लिए Sonnet का उपयोग करने वाला hybrid approach सुझाया गया है
Custom commands और अन्य tips
/pr-comments, /review जैसे custom commands supported हैं, इसके लिए Github CLI चाहिए- branch बदलते समय बातचीत फिर से शुरू करना, main के साथ diff review करना जैसी flexible workflow संरचनाएं बनाई जा सकती हैं
Esc दो बार दबाकर बातचीत के किसी भी बिंदु से fork किया जा सकता है/permissions से session शुरू होने से पहले permissions adjust किए जा सकते हैं- हिम्मत हो तो claude
--dangerously-skip-permissions भी आज़मा सकते हैं
- Cluade Code Pro TIPS वीडियो की सिफारिश
आगे क्या आज़माना चाहते हैं
- custom commands को सीधे define करके उपयोग करने के तरीकों पर experiment करना चाहते हैं
- Playwright server जैसे MCP servers का उपयोग करके frontend automation development आज़माना चाहते हैं
- Claude screenshots ले, result पहचाने और UI को बार-बार बेहतर करे — ऐसे feedback loop बनाने पर फ़ोकस रहेगा
- how-i-bring-the-best-out-of-claude-code-part-2 में सुझाए गए सभी advanced उपयोगों को practically आज़माने की योजना है
- prompt optimization पर काम करने की योजना है
- evaluation criteria (
rubric.md) को स्पष्ट रूप से define करके, context वाली files (pmd आदि) के साथ prompts का evaluation/improvement loop design करना चाहते हैं
- कई Claude instances रखकर, एक instance prompt से result निकाले और दूसरा उसे evaluate व feedback देकर improve करे — इस तरह single या multi-agent system की दिशा में विकसित करने की योजना है
- इस approach की प्रेरणा Nirant की post से मिली
- कई Claude Code instances को action logs के माध्यम से एक-दूसरे से communicate कराने वाला multi-agent system बनाना चाहते हैं
निष्कर्ष और सुधार की मांग
- Cursor UI/UX के मामले में बहुत मज़बूत है, लेकिन Claude Code power users और CLI-friendly environment में productivity और experimentation spirit को बढ़ावा देता है
- यह ऐसा tool है जिसमें exploratory learning और experiment का बड़ा reward मिलता है, इसलिए Nerd/power users को इसे मज़बूती से recommend किया जा सकता है
जिन features में सुधार की उम्मीद है
- UI integration (Claudia संदर्भ)
- Cursor जैसे checkpoints support। Git है, लेकिन Cursor का तरीका बहुत सुविधाजनक है
- copy/paste quality में सुधार
- अलग-अलग models के उपयोग का support
1 टिप्पणियां
Hacker News राय
जब भी मैं लोगों को Claude Code की इतनी ज़्यादा तारीफ़ करते देखता हूँ, तो मुझे यह एहसास झटकना मुश्किल लगता है कि या तो सब इन्फ्लुएंसर हैं, या फिर बस terminal और Emacs, Vim जैसे पारंपरिक tools के कट्टर फ़ैन। मैं हर बार जब Claude Code को Cursor से बहुत बेहतर बताने वाली टिप्पणी देखता हूँ, तो सच में उसका subscription लेकर उसे बड़े TypeScript codebase पर आज़माता हूँ, लेकिन प्रक्रिया लंबी होती है और learning curve भी काफ़ी steep है। नतीजा आखिरकार Cursor के built-in Claude जैसा ही निकलता है, बस ज़्यादा धीमा और अस्पष्ट, इसलिए code review भी मुश्किल हो जाता है। अब तो बस ऐसा लगता है कि टिप्पणी करने वाले ये जोशिले समर्थक या तो sponsored हैं, या फिर 200 डॉलर दे चुके हैं इसलिए अपनी पसंद को सही ठहराना चाहते हैं। ईमानदारी से कहूँ तो Cursor मेरे लिए कहीं ज़्यादा productive रहा है। मैं 18 साल का अनुभवी programmer हूँ, रोज़ बहुत code लिखता हूँ, Gemini 2.5 Pro और Claude 4.0 दोनों का बारी-बारी से इस्तेमाल करता हूँ, लेकिन फिर भी Cursor से ज़्यादा फ़ायदा मिल रहा है। अभी तक एक भी व्यक्ति मुझे मना नहीं पाया। मुझे कोई ठोस फ़ायदा नज़र नहीं आता। आगे चलकर राय बदल सकती है, लेकिन अभी तो बिल्कुल महसूस नहीं हो रहा
मुझे लगता है कि ज़्यादातर लोग software development में असली मुश्किल क्या है, इसे गहराई से ग़लत समझते हैं। असल काम का बड़ा हिस्सा कोई जटिल algorithm बनाना नहीं, बल्कि पहले से मौजूद ideas को ठीक से जोड़कर काम में लाना होता है। लेकिन यह सब specification, design, architecture जैसी शुरुआती तैयारी के बाद आता है। AI से ऐसे program तुरंत बना लेना cool लगता है, और demo में यह महसूस होता है कि काम बहुत जल्दी “पूरा” हो गया, लेकिन असली समस्या ऐसा system बनाना है जिसे 30 साल तक quality standards के साथ चलाया जा सके। prototype या one-off कामों के लिए यह शानदार है, लेकिन लंबे समय की durability में इसकी सीमा काफ़ी बड़ी है
ऐसे tools से productivity को maximize करने के लिए बहुत छोटे और तेज़ feedback loop सबसे ज़रूरी हैं। Cursor का tab autocomplete model editor क्या करने जा रहा है, इसे लगभग instinctively समझ लेता है, और यह ऐसा लगता है जैसे कोई पागलों की तरह intelligent co-driver साथ बैठा हो। मुझे ख़ुद macro programming करके सिर नहीं खपाना पड़ता; अगर ज़रूरत नहीं है तो Esc दबाकर cancel कर देता हूँ, नहीं तो धीरे-धीरे agentic mode की तरफ़ बढ़ जाता हूँ। पूरी तरह agent-based editors में 15–30 मिनट लग जाते हैं और workflow पूरी तरह टूट जाता है। output को review करना अपने-आप में काम बन जाता है, और यह छोटे accept/reject loop के मुकाबले बहुत ज़्यादा मानसिक ऊर्जा लेता है। network permission देनी है या offline चलाना है, यह भी बड़ा सवाल बन जाता है, इसलिए इन्हें तभी इस्तेमाल करना ठीक लगता है जब maintenance/security/reliability ज़रूरी न हो और बस जल्दी से code खड़ा करना हो। वरना productivity उलटी घट जाती है। आगे यह बेहतर होगा, लेकिन अभी के लिए मैं Cursor में साफ़ तौर पर बेहतर नतीजे पा रहा हूँ
मैं भी पहले ऐसा ही सोचता था, लेकिन हाल में Claude Code को सच में इस्तेमाल करके लगा कि यह Cursor से काफ़ी बेहतर है। क्यों, यह ठीक-ठीक नहीं पता, लेकिन Claude शायद पूरे structure को बेहतर समझता है और बेकार के बदलावों से बचता है। हाँ, कभी-कभी दिशा ख़ुद देनी पड़ती है, लेकिन efficiency कहीं ज़्यादा है। इसकी एक खास बात यह है कि यह आमतौर पर एक बार में सिर्फ़ एक file साफ़-साफ़ दिखाता है, इसलिए review करना बहुत आसान होता है। Cursor कई files एक साथ खोल देता है, और changes इतने ज़्यादा होते हैं कि जल्दी समझना मुश्किल हो जाता है। जानकारी के लिए, मैं VSCode terminal window में Claude Code extension इस्तेमाल करता हूँ। Claude जिन files को बदलना चाहता है, उनके tabs खोलकर changes propose करता है
लोग अभी तक यह नहीं समझ पाए हैं कि Cursor कोई एक परिपक्व product नहीं, बल्कि उन features का bundle है जिन्हें बाकी सारे tools तेज़ी से catch up करने के लिए जोड़ रहे हैं। असली सबक यह है कि deep interface के अलावा एक और strategy है—अपने पसंदीदा editor के साथ best-in-class agent solution को जोड़ना। आखिरकार ये अनुभव “best practices” में बदलकर इकट्ठा होंगे, लोग इन्हें अपने editor या IDE में स्वाभाविक रूप से अपनाएँगे, और ऐसे सारे vscode forks ग़ायब हो जाएँगे
मैंने एक महीने से भी कम समय तक 17 डॉलर वाले plan पर इस्तेमाल किया, और अनुभव आधा रोमांच, आधा झुंझलाहट वाला रहा। मैंने Rust में 8 हज़ार lines और Markdown में 12 हज़ार lines लिखीं, और काम की specification व specific tasks को test harness जैसी शैली में अलग करके AI से interact किया। यह जादू VC subsidy की वजह से है या नहीं, पता नहीं, लेकिन Rust ऐसा महसूस होने लगा जैसे कोई scripting language हो। (संदर्भ के लिए: GitHub repository का नाम ‘knowseams’ है)
AI में मुझे सबसे अच्छी बात यह लगती है कि जब मन नहीं होता तो बस “यह कर दो” कह सकता हूँ। output अच्छा हो या ख़राब, उससे फ़र्क नहीं पड़ता। कम से कम यह एक starting point दे देता है
LLM की वजह से blank page का डर ख़त्म हो गया है। जटिल context को फिर से दिमाग़ में लादने की ज़रूरत नहीं पड़ती; बस पूछो “हम क्या कर रहे थे?”, “यह code क्या था?” और AI तुरंत समझा देता है, जिससे फ़ौरन दोबारा flow में लौट सकता हूँ। rubber duck debugging और दोहराए जाने वाले छोटे-मोटे कामों (yak shaving) तक को यह बहुत तेज़ कर देता है, इसलिए सच में काम का है। मैं इसे Slack, Notion, Linear वगैरह के साथ जोड़कर भी इस्तेमाल करता हूँ, इसलिए यह मेरे लिए task/project management tool भी है
जब मैं ख़ुद काम करना चाहता हूँ, तब भी AI से plan बनवाकर उसे Markdown में लिखवा लेता हूँ। आज भी मैंने उससे refactor plan माँगा था, लेकिन उसने 40 files वाले prototype code block को नीचे से structural changes करके बदलने जैसा ग़लत approach सुझाया। अगर मैं उस दिशा में ग़लती कर बैठता, तो debugging में बहुत समय चला जाता। फिर भी उसने attack point दिया, और plan को एक घंटे के भीतर ठीक करके लागू भी कर दिया। अगर मैं अकेला करता, तो शायद complexity देखकर शुरू ही न कर पाता, या documentation के चक्कर में उलझकर छोड़ देता
दिन के अंत में जब ध्यान नहीं लगता और जितना लिखता हूँ उतना ही वापस undo करना पड़ता है, तब मैं AI को steering दे देता हूँ और थोड़ा साँस ले लेता हूँ। छोटे issues में बस diff एक नज़र देख लेना काफ़ी होता है, और मुश्किल issues में अगर ठीक से पता हो कि समस्या क्या है, तो AI को दिशा देकर उससे काम निकलवा सकते हैं। आमतौर पर जब काम 40–60% तक पहुँच जाता है, तो मैं ख़ुद takeover करके finish करता हूँ। सामान्यतः मैं अपने sharp hours में ख़ुद सोचकर development करता हूँ, और देर रात के बचे हुए repetitive काम AI को दे देता हूँ ताकि अगले दिन की तैयारी या थोड़ा ज़्यादा high-level writing/design कर सकूँ
मैं तो बस टहलने चला जाता हूँ और coffee पीता हूँ। इंसानी समस्याओं को इंसानी तरीक़े से हल करना कुछ ज़्यादा स्वाभाविक लगता है
Claude Code को शब्दों में समझाना मुश्किल है। इसे इस्तेमाल करने के बाद तो ऐसा लगा जैसे मेरा पेशा ही बदल गया हो। पहले भी मैं Claude को अपने पूरे workflow में गहराई से इस्तेमाल करता था, लेकिन Claude Code सचमुच “steroids” पर Claude जैसा है। अगर अभी तक नहीं आज़माया है, तो ज़रूर recommend करूँगा। पहली बार सच में ऐसा लगा जैसे किसी junior engineer के साथ काम कर रहा हूँ
मेरा अनुभव बिल्कुल उल्टा है। मैं कुछ कहता हूँ, यह कुछ मिनट लेकर कोई नतीजा देता है, लेकिन असल में app टूट चुका होता है, और debug करते-करते पता चलता है कि इसने पूरी तरह ग़लत दिशा में काम किया, तो अंत में सब फेंकना पड़ता है। फिर भी मैं Claude को छोड़े बिना इस्तेमाल करता रहता हूँ क्योंकि दूसरों की तरह अगर यह ठीक से चल जाए तो वाकई बहुत बढ़िया है। हक़ीक़त में यह boilerplate तो निकाल देता है, लेकिन काफ़ी debugging ख़ुद करनी पड़ती है, और सबसे बुरे हाल में एक घंटा और tokens दोनों बर्बाद हो जाते हैं
आज पहली बार मैंने इसे company में इस्तेमाल किया, और यह Cursor के मुकाबले बेहद ज़्यादा transformative लगा। foundation model वही होने के बावजूद experience पूरी तरह अलग है। एक महीने पहले तक AI की वजह से काम धीमा पड़ता था, लेकिन आज Claude Code से 20 मिनट में काम हो गया, और API usage cost भी 10 डॉलर से कम रही। context management की फ़िक्र बहुत कम करनी पड़ी, और Claude Code ख़ुद ज़रूरी context खोजकर जोड़ता रहा, इसलिए काफ़ी लंबे समय तक productive बना रहा। Cursor का agent mode 3–5 मिनट के tasks तक ही ठीक लगता है, लेकिन Claude Code 10 मिनट से ज़्यादा वाले कामों में भी रास्ता नहीं भूलता और लगातार progress करता है। tool use भी शानदार है, और loop में कम फँसता है—यह काफ़ी चौंकाने वाला है
आपने कहा “junior engineer के साथ काम करने जैसा”, लेकिन मुझे तो उल्टा ऐसा लगा कि मैं subordinate हूँ और Claude मेरा manager है। मैं कहता हूँ “देखो, मैंने कितना शानदार काम किया!” और जवाब मिलता है “लेकिन मैंने तो यह करने को कहा ही नहीं था…”
क्या आप थोड़ा और specific बता सकते हैं कि किस तरह के tasks, languages और domains में इसका इस्तेमाल किया? सभी के use case इतने अलग हैं कि जिज्ञासा हो रही है
मेरा भी यही अनुभव है। Claude सिर्फ़ साधारण junior से बढ़कर है। यह options suggest करने, decisions के लिए recommendation देने, और trade-offs को साफ़ visualise करने में बहुत अच्छा है
क्या ऐसी walkthrough examples कम हैं जहाँ लोग सच में Claude Code से app या library बना रहे हों? मुझे सिर्फ़ “वाह, कितना cool है” वाली पोस्ट्स से ज़्यादा, इस tool के साथ असली development को चलते हुए देखना है। अगर ऐसे examples का कोई collection हो तो बहुत अच्छा होगा
मुझे पूरी स्थिति कुछ अजीब लगती है। Claude Code ख़ुद में निश्चित रूप से अच्छा है, और documentation या Stack Overflow को बहुत तेज़ी से खोजने में काम आता है। लेकिन अगर इसके बारे में फैली हुई बढ़ा-चढ़ाकर कही गई बातें सच हैं, तो क्या अब तक software innovation की रफ़्तार विस्फोटक नहीं हो जानी चाहिए थी? Stripe के CEO ने कहा था कि AI tools से productivity 100x बढ़ती है—तो 3–4 महीने बाद क्या Stripe को अब तक rocket launch नहीं कर देना चाहिए था? Microsoft भी AI coding पर पूरी तरह दाँव लगा रहा है, तो Teams अभी भी इतना कमज़ोर क्यों लगता है? एक साल से ज़्यादा समय से कहा जा रहा है कि ये tools क्रांतिकारी हैं, लेकिन ज़मीनी हक़ीक़त 3–4 साल पहले से बहुत अलग नहीं लगती
हाल में दो trends साफ़ दिखते हैं: (1) non-experts छोटे-मोटे projects पर AI इस्तेमाल कर रहे हैं, (2) developers पूरी app structure, files, interfaces, tech stack, test framework सब कुछ पहले से बहुत विस्तार में define करके LLM से बारीक handling करवाकर किसी तरह ठीक-ठाक परिणाम निकालते हैं YouTube example। PR/YouTube वगैरह में जो 80–99% बातें सुनाई देती हैं, वे असल में पहले समूह से आती हैं। लोगों को productivity gain इसलिए महसूस होती है क्योंकि LLM से बात करना, documentation करना, guide करना और corrections करवाना, सीधे development करने की तुलना में कम थकाऊ लगता है। समय या कुल मेहनत भले बराबर हो, लेकिन मानसिक अपेक्षाएँ कम लगती हैं
मैं YouTube पर ऐसे live streams/case studies ढूँढ रहा हूँ जहाँ सच में productivity boost दिखता हो, लेकिन अभी तक ऐसा कोई case नहीं देखा जिसे देखकर लगे, “वाह, यह तो सच में तेज़ है!”
पक्ष-विपक्ष की बहुत तेज़ रायें सुनाई देती हैं, लेकिन वास्तव में ज़्यादातर लोग चुपचाप अपना काम commit कर रहे हैं (और यह बात ख़ुद में ironic है)। मेरे मामले में task के हिसाब से 1.5x से 10x तक speed-up का मैं सच में अनुभव करता हूँ। सबसे बड़ा फ़ायदा यह है कि pure creative, one-off, boilerplate और refactoring जैसे कामों में cognitive load बहुत कम हो जाता है, इसलिए output अधिक consistent रहती है। मैं अब भी काफ़ी “hand coding” करता हूँ, और लगभग हर line को अंत तक review करता हूँ। कई घंटों तक इसे अकेले चलने देना तो nightmare है। सच में, 10 साल से ज़्यादा समय से maintain हो रही production app पर काम करते हुए मेरे पास ब्लॉग पर प्रचार लिखने का भी समय नहीं है। दूसरी तरफ़, मैं बहुत lean organisation में हूँ, इसलिए पूरे system का context मेरे हाथ में है और समस्या को जल्दी समझ सकता हूँ। जहाँ अपनी efficiency बढ़ाना अहम हो, वहाँ यह बुनियादी क्षमता को साफ़ तौर पर बढ़ाता है। बड़े organisations में शायद ऐसा अनुभव पाना मुश्किल है
मेरे अनुभव में, हर code folder के root पर Claude.md नाम की Markdown file रखकर minimal ruleset जोड़ना अच्छा काम करता है, जैसे pipeline हो। इससे test generation और placement तय किए गए folder व style के अनुसार ही होते हैं, debug files बनने से रोका जा सकता है, और नई classes या structures की बेतरतीब बढ़ोतरी भी रुकती है। जहाँ बहुत ज़रूरी न हो, वहाँ reuse करने का rule भी सेट कर देता हूँ। Prompt भी बहुत लंबा नहीं लिखता; ज़्यादातर सिर्फ़ अनिश्चित हिस्सों के लिए plan document बनवाता हूँ। LLM के knowledge range से बाहर के नए issues पर भी बड़े input की जगह बहुत कम context देता हूँ। इस तरीके से मुझे लगातार 1 input–1 output (depth तक लागू) जैसे नतीजे मिलते हैं। हाल में मैं Claude Code से हटकर CLI mode में Opus जैसे दूसरे बड़े models को कम लागत पर इस्तेमाल करने लगा हूँ। असली ताक़त CLI में है। मैं एक साथ 60–70 agent streams चला रहा हूँ, और 200 million tokens के स्तर के (react/typescript/golang) codebase को भी बिना दिक्कत संभाल रहा हूँ। ज़्यादा से ज़्यादा एक-दो बार ही अतिरिक्त निर्देश देने पड़े
क्या आप list कर सकते हैं कि agent streams में क्या-क्या चला रहे हैं? जानने की बहुत उत्सुकता है
Anthropic के अलावा कौन से models इस्तेमाल कर रहे हैं, यह भी जानना चाहूँगा। मैंने Kimi K2 आज़माया था, लेकिन मेरे use case के लिए खास नहीं लगा
“agent stream” से आपका मतलब क्या है? 60–70 को कैसे manage करते हैं, इसकी cognitive load की मैं कल्पना भी नहीं कर सकता
कभी-कभी Claude Code के साथ किसी खास task में productivity नाटकीय रूप से बढ़ जाती है। मैं recommend करूँगा कि slash commands का इस्तेमाल करके पिछली बातचीतों को slash command में बदला जाए। इससे धीरे-धीरे इस्तेमाल लायक primitive commands का एक set जमा हो जाता है। मैंने अपने examples GitHub पर डाले हैं make-command.md, improve-command.md
PSA (जनहित सूचना): इस repository की मदद से Claude Code को किसी भी model के साथ जोड़ा जा सकता है। बताया जा रहा है कि नया Kimi-K2 काफ़ी अच्छा काम करता है
मैंने भी Kimi-K2 इस्तेमाल किया है, और यह Sonnet/Opus 4.0 जितना अच्छा नहीं, लेकिन tool calling में Gemini 2.5 Pro से बेहतर लगा। अगर Claude Max (महीने के 100–200 डॉलर) महँगा लगता है, तो इसे ज़रूर recommend करूँगा। model ख़ुद बहुत lean और simple है, यह बात अच्छी लगती है। Anthropic चाहे तो Claude Code को open source करके CLI coding agent दुनिया का VSCode बना सकता है। और opencode भी recommend करूँगा। यह सभी models को native support देता है और Claude Code जैसे features भी देता है
अगर कई models के साथ इस्तेमाल करना है, तो मैं सीधे sst/opencode recommend करूँगा (मैं ख़ुद भी Claude Pro के साथ यही करता हूँ)
वैसे जिन लोगों ने अभी तक CC इस्तेमाल नहीं किया है—वे npm से CC client डाउनलोड करके free में इस्तेमाल कर सकते हैं
मैं Claude Code, local LLM, Continue, VSCode के साथ एक साधारण Python app को “vibe coding” के तौर पर बनाते हुए खेल रहा था, तभी मुझे Claude का free tier पता चला, और मैंने चल रहे code व LLM outputs उसमें डाल दिए। उसने errors और updates को एक ही बार में ठीक-ठाक organise और fix कर दिया, तो काफ़ी मज़ा आया! फिर अगले step में मैंने ChatGPT से pygame-based 2d game (Manic Miner style) project के specs और prompts तैयार कराए और Claude में डाले, लेकिन Claude बार-बार ऐसे methods refer कर रहा है जो मौजूद ही नहीं हैं, या codebase version mismatch जैसी उल्टी-सीधी बातें कर रहा है। line numbers और आसपास का code साफ़-साफ़ दिखाने पर भी यह वही gaslighting करता रहता है। इसे कैसे संभालें? perfection नहीं चाहिए, लेकिन ऐसा लग रहा है जैसे local LLM जैसी ही सीमाओं पर फिर अटक गया हूँ। सेहत ठीक नहीं रहती, इसलिए यह काम मैं रुक-रुक कर करता हूँ; कोई सलाह हो तो अच्छा होगा
बहुत संभव है कि आप “अस्पष्ट interfaces और छिपी हुई assumptions से भरे code hell” में फँस गए हैं। ऐसे में बेहतर होगा कि पहले ChatGPT के अब तक के सारे outputs का summary बनाएँ, यह गहराई से list करें कि मौजूदा game क्या करता है और कौन-कौन से features हैं, फिर वही document Claude को देकर requirements को शुरुआत से दोबारा break down करवाएँ। Claude zero-shot में भी बेहतरीन sample दे सकता है, और सबसे बुरी स्थिति में भी बार-बार self brush-up करके बेहतर हो सकता है। अगर तब भी Claude बेकार features गढ़ता रहे, तो context7 MCP server install करें और Claude से साफ़ तौर पर कहें कि वह context7 इस्तेमाल करे
यह LLM तकनीक की बुनियादी सीमा है। यह probabilistically “सबसे संभावित” token sequence निकालता है, लेकिन “संभावित लगना” और “सही होना” अगर एक न हों, तो फिर कोई समाधान नहीं। हर LLM में यह “संभाव्यता” का मानदंड training/fine-tuning के साथ अलग होता है
शुरुआती setup के बाद, मैं जानना चाहता हूँ कि लोग इस tool को ठीक से चलाने के लिए और कौन-कौन से तरीके अपनाते हैं। यानी context और codebase structure को इस तरह व्यवस्थित करने के व्यावहारिक तरीके क्या हैं कि tool ख़ुद सही दिशा पकड़ सके। मैंने अपने विचार इस लेख में लिखे हैं। मुझे लगता है कि इससे भी बेहतर methodologies आगे आती रहेंगी
Claude Code से मुझे कई तरह के alpha मिल रहे हैं, लेकिन इसे पूरी team तक scale करना मुश्किल लग रहा है। क्या कोई व्यावहारिक tips या best practices हैं जिनसे team members या मेरे reports Claude Code को प्रभावी ढंग से इस्तेमाल कर सकें?