15 पॉइंट द्वारा sharpscar 2026-03-18 | 3 टिप्पणियां | WhatsApp पर शेयर करें

समस्या

Vibe coding से प्रोजेक्ट शुरू करें तो शुरुआती कुछ घंटे किसी नई दुनिया जैसे लगते हैं। Prompt डालो तो code निकल आता है, कुछ न कुछ चलता हुआ भी दिखता है, और एक पल आता है जब लगता है, "क्या मैं सच में यह बना रहा हूँ?"

फिर error आने शुरू हो जाते हैं।

ठीक करने को कहो तो कहीं और टूट जाता है, 30 मिनट बाद AI पहले क्या कह चुका था वह भूल जाता है, 1 घंटे बाद मैं भी उलझ जाता हूँ कि अभी मैं बना क्या रहा था। अगले दिन फिर खोलो तो सब blank slate जैसा। आखिरकार वहीं के वहीं चक्कर चलते रहते हैं।

अगर कई प्रोजेक्ट एक साथ चल रहे हों तो स्थिति और खराब होती है। सोमवार को जो कर रहे थे, उसे गुरुवार को फिर से शुरू करने के लिए context शुरुआत से दोबारा सेट करना पड़ता है।

कारण

Bottleneck code में नहीं था। वह memory में था।

AI का session टूटते ही वह भूल जाता है, और मैं भी कुछ दिन बाद भूल जाता हूँ। लेकिन कोई भी चीज़ record नहीं कर रहा, इसलिए प्रोजेक्ट बार-बार initialize हो जाता है।

आज़माया गया तरीका

मैंने Obsidian को प्रोजेक्ट की long-term memory storage की तरह इस्तेमाल करना शुरू किया।

  • Obsidian — planning, design, session log, error record सब कुछ Markdown में manage करना
  • Claude Desktop + MCP — Obsidian notes को सीधे पढ़कर design पर चर्चा करने वाला "conductor" रोल
  • Claude Code + MCP — design पूरा होने के बाद काम को वास्तव में implement करने वाला "executor" रोल

Claude Desktop में context loss की समस्या मैंने 날짜_handoff.md फ़ाइल में sessions के बीच handoff लिखकर हल की। नई session खोलते समय सिर्फ यह फ़ाइल पढ़ लो, तो context तुरंत वापस आ जाता है।

मुख्य बात थी "record → design → implement → record" cycle को दोहराना।

नतीजा

पहले मैं toy project शुरू करके 3 दिन में folder delete करने का चक्र दोहराता रहता था, लेकिन इस तरीके पर आने के बाद जो प्रोजेक्ट पूरे नहीं हो पा रहे थे, वे एक-एक करके first completion → deploy → review → fix के cycle में चलने लगे। अभी मैं 10 से अधिक projects को Obsidian canvas में एक साथ manage कर रहा हूँ।

हाल ही में Claude Code में Auto Memory feature जोड़ा गया है। यह AI का AI के लिए लिखा गया memo है, जबकि ऊपर वाला तरीका इंसान का इंसान के लिए लिखा गया record है। मुझे लगता है कि दोनों एक-दूसरे को complement करते हैं।

सारांश

मैंने इस workflow को व्यवस्थित करके Wikidocs पर एक किताब के रूप में सार्वजनिक किया है। पूरा text मुफ्त है।

"Vibe coding क्यों विफल होता है — AI collaboration guidebook" https://wikidocs.net/book/19307

इसमें prologue से Ch.22 और appendix तक शामिल हैं, और feedback आप हर page के comment में छोड़ें, तो मैं तुरंत शामिल कर दूँगा। तीखी आलोचना भी स्वागत योग्य है।

3 टिप्पणियां

 
runableapp 2026-03-19

मैं Cursor इस्तेमाल करता हूँ, इसलिए मुझे ऐसी स्थिति (यानी चीज़ें भूल जाने वाली) का सामना नहीं करना पड़ा, इसलिए Claude के बारे में ऐसे मामले कभी-कभी पढ़कर अजीब लगता है। गुणवत्ता कम होने या बातों को ठीक-ठीक स्पष्ट न करने की वजह से दिक्कत हुई हो, ऐसा हुआ है, लेकिन भूल जाने वाला मामला नहीं हुआ। किसी दूसरी जगह error आने से परेशानी हुई थी, ऐसा Cursor प्रोडक्ट के शुरुआती दिनों में कुछ बार हुआ था, लेकिन अब ऐसा नहीं हुआ। क्या ऐसा इसलिए है कि मेरा प्रोजेक्ट पर्याप्त बड़ा नहीं है?

मैं इसे इस तरह करता हूँ:

  • एक मोटा-सा आइडिया, तरीका, और अगर कोई मिलती-जुलती पद्धति हो तो उसे भी लिखकर 10-20 लाइन का एक दस्तावेज़ बनाता हूँ।
  • फिर उसे पढ़कर आइडिया, architecture, testing, और plan लिखते हुए विस्तार से दस्तावेज़ बनाने को कहता हूँ। और कहता हूँ कि अगर मुझसे कुछ पूछना हो तो पूछे। (फिर वह अक्सर नंबर चुनने वाले तरीके से मुझसे सवाल पूछता है।) और फिर उस पर चर्चा करते हुए उसे पूरा करते हैं। अलग से Gemini के साथ बातचीत करके और रिसर्च करता हूँ, और उस पर भी साथ में चर्चा करता हूँ।
  • फिर तैयार दस्तावेज़ को review करते हुए दोबारा बातचीत में उसे थोड़ा-थोड़ा सुधारता हूँ, और उसके बाद उसे बनाने का निर्देश देता हूँ। बनाते समय जो हिस्से पूरे हो जाएँ, उन्हें पूरा हुआ चिह्नित करते हुए उस दस्तावेज़ को update करते हुए आगे बढ़ने को कहता हूँ। और जो चीज़ें इतनी बड़ी या जटिल हों कि उनमें समय लगे, उनके लिए Cursor rules में यह भी लिखने को कहता हूँ कि हर दिन क्या किया, उसका रिकॉर्ड किसी अलग दस्तावेज़ में रखे।

क्योंकि दस्तावेज़ प्रोजेक्ट के अंदर ही होता है, इसलिए उसे अलग से किसी खास तरह से manage करने की ज़रूरत नहीं पड़ती। और Cursor काम को लगातार जारी नहीं रखता। आप उसे चाहे अंत तक करते रहने को कहें, वह बीच में रुक ही जाता है (कहते हैं कि यह किसी अजीब loop में फँसने से बचाने वाला safety mechanism है, लेकिन इसमें मेरे पास choice नहीं होना मुझे पसंद नहीं है), और इस तरह वह बातचीत को मजबूर कर देता है। लेकिन यह मददगार भी होता है। कुछ घंटे बाद देखने पर चीज़ें बिल्कुल गलत दिशा में बन जाने की गुंजाइश कम हो जाती है।

क्योंकि सब कुछ एक ही IDE के अंदर हो जाता है, इसलिए किसी दूसरी service को जोड़ने की ज़रूरत नहीं पड़ती। Claude को मैंने API के ज़रिए सिर्फ LLM functionality के लिए इस्तेमाल किया है, इसलिए coding के मामले में बहुत लोग इसे अच्छा कहते हैं, लेकिन यह कैसा है, मुझे नहीं पता -- बस कभी-कभी जब ऐसी पोस्टें देखता हूँ कि यह चीज़ें भूल जाता है या error देता है, तो लगता है कि शायद मेरा प्रोजेक्ट छोटा होने की वजह से ऐसा नहीं हो रहा...

आख़िर में, कुल मिलाकर मैं इसे वैसे ही आगे बढ़ाता हूँ जैसे कंपनी में projects और teams को manage करते समय करते हैं - यानी लोगों के साथ काम करते समय जैसी प्रक्रिया होती है: documentation और records, बातचीत, निर्णय... यह कोई नया workflow नहीं है। इसलिए Claude के साथ किस workflow से किसी ने इसे 'पूरी तरह automatic' किया, यह जानने की मुझे बहुत जिज्ञासा है, और पूरी तरह automatic न भी हो तो बार-बार होने वाली "meetings" (इंसानों की टीम के साथ भी हम बार-बार meetings कम करने की कोशिश करते हैं) को कैसे कम किया जाए, यही मैं सोच रहा हूँ।

 
pari0130 2026-03-19

अगर आप qmd नाम की चीज़ इस्तेमाल करें, तो यह पिछली sessions को मैनेज करने के लिए एक local database संभालकर रखता है!

 
sharpscar 2026-03-19

अच्छी जानकारी के लिए धन्यवाद।