Vibe coding से आखिर कितना development किया जा सकता है?

 (github.com/delos-cresco)
47 पॉइंट द्वारा sungmin330 2026-01-06 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें

यह product से ज़्यादा technology और implementation side पर महसूस की गई बातों की retrospective है.

यह पूरी तरह व्यक्तिगत विचार हैं.

कृपया यह ध्यान में रखकर पढ़ें कि यह विश्वविद्यालय के चौथे वर्ष के दौरान, semester के बीच सीखते हुए बनाया गया project था!

यह project शुरू करने की वजह क्या थी

  • startup बनाने वाली mindset के साथ product development, PM/PO नज़रिए से
  • Claude Code के साथ क्या सच में full-stack MVP development संभव है, इसकी जाँच
  • stock investing में सही stocks खोजने की समस्या को हल करना
  • commercial products को सक्रिय रूप से अपनाकर उस प्रक्रिया से insights निकालना

Project timeline और अतिरिक्त जानकारी

  • planning + development: 1 महीना
  • deployment: 1 हफ्ता
  • operations: 2 महीने
  • निवेश राशि
    • Claude Code: 100USD
    • Apple developer account: 100USD
    • AWS: लगभग 220USD
    • Managed DB: लगभग 300USD
    • free tier: Datadog, Langfuse, Posthog
    • ads: 40,000 KRW
    • कुल: लगभग 1,000,000 KRW (मेरे अपने पैसे..)

Development process

Frontend

  • design tokens define किए
  • Figma में 3 core pages implement किए
  • Expo में design tokens apply किए, और Figma MCP का उपयोग करके implementation किया
  • Expo MCP का उपयोग करने की कोशिश की, लेकिन यह stable नहीं था, इसलिए output देखते हुए manually debugging किया
  • “design tokens का उपयोग करो, और दूसरे page के design concept को borrow करके…” जैसे prompt के साथ Figma wireframe के बिना नए pages बनाए

Backend

  • requirements के आधार पर API develop करने को कहा
  • frontend requirements के आधार पर ज़रूरी endpoints भी साथ में बनाने को कहा
  • generic stack Django का उपयोग करके, implementation में bottleneck के बिना Claude Code से development संभव था

AI

  • multi-agent architecture define किया और उसी के आधार पर implementation के लिए कहा
  • latest LangChain और LLMOps specs के लिए web links जोड़कर reference के तौर पर उपयोग करने को कहा
  • LLM service के prompts को LLM से generate करवाकर इस्तेमाल किया

Observability

  • ClickStack-based setup के बाद Datadog पर migrate किया
  • पूरे system के development के बाद logging और analytics लागू किए

Infra

  • शुरुआत में Pulumi इस्तेमाल करना चाहा, लेकिन Claude Code इसे अच्छी तरह नहीं कर पाया, इसलिए AWS CLI-based scripts generate करके deployment files लिखीं
  • cost की वजह से CI/CD और Dev Server नहीं बनाया

इस्तेमाल की गई technologies की list

  • service: subscription/payment, social login, dark mode
  • data: API-based data collection, CDC, ETL
  • AI: multi-agent, Text-to-SQL, Agentic RAG, SSE streaming, session management, Retry, Rate Limit
  • LLMOps: AB Test, Cloud Based Prompt Management(OTA Update), Synthetic Dataset, Evaluation

Insights

Implementation

  • करीब 1 महीने तक Claude Code के 100USD plan के साथ, मैं अकेले इस स्तर का product बना सका
  • सिर्फ design token spec define करके UI implement किया; अगर design system तक implement करके उसे Claude.md में शामिल किया होता, तो शायद frontend और तेज़ तथा stable बनता
  • design system का महत्व. यह frontend development productivity को बहुत बढ़ाता है. Figma बनाने से पहले implement करके बाद में modify करना ज़्यादा तेज़ है. वास्तव में कुछ pages implemented हैं लेकिन Figma में नहीं हैं.
  • exception cases की definition. mobile app और AI system में यह और भी महत्वपूर्ण है. system-wide timeout management, background policies, streaming recovery, simple errors जैसे happy path के बाहर के cases को plan और implement करना पड़ता है. कुछ बार Claude Code अपने आप error handling implement कर देता है, लेकिन frontend और backend को मिलाकर यह साफ़-सुथरे तरीके से solve नहीं करता. इसलिए इन हिस्सों के लिए Claude Code को अतिरिक्त निर्देश देने पड़ते हैं.
  • बड़े refactoring से बचें. शुरुआत में frontend के एक file में React और CSS code सब डाल दिया था, और उन्हें अलग करने के लिए refactoring की. नतीजतन यह असफल रहा. separation तो हुआ, लेकिन UI पहले जैसा नहीं रहा, और आखिरकार थोड़ा-थोड़ा करके अलग करना पड़ा. इसलिए development की शुरुआत से ही code architecture पर सोचना चाहिए, और component उपयोग से जुड़ी बातें prompt में जोड़नी चाहिए ताकि उनका सही उपयोग हो सके.
  • Claude.md का उपयोग. feature development के बाद, उसी content के आधार पर Claude Code से यह कहें कि Claude.md में क्या save करना चाहिए, वह जोड़ दे. जैसे-जैसे file बड़ी होती जाए, सिर्फ ज़रूरी बातें छोड़कर बाकी हटाने को कहें. readme और claude.md का ठीक से उपयोग करके LLM context को control किया जा सकता है. (skills से पहले का समय)
  • sub-agents का उपयोग नहीं किया. इनके बिना भी चीज़ें अच्छी बन रही थीं, इसलिए इस्तेमाल नहीं किया. बस Plan mode में development planning को पर्याप्त विस्तार तक ले गया, और जब लगा कि detail पर्याप्त है, तो agent को autonomously develop करने दिया.
  • packages और technologies पहले से define करके बताना बेहतर है. Claude.md, Readme, या किसी specific spec में यह साफ़ लिखना चाहिए, ताकि duplicate code न बने या अलग stack इस्तेमाल होने जैसी स्थिति से बचा जा सके (Skills?)

AI system

  • ReAct धीमा है. UX बहुत खराब है. multi-agent को parallel में चलाने के बावजूद यह बहुत धीमा है.
  • UX. slow responses को संभालने के लिए multi-agent steps दिखाने वाला UX, streaming, animation, dynamic Markdown rendering वगैरह जोड़ा. लेकिन अगर response आने में 1 मिनट लग जाए, तो फिर इसका मतलब ही क्या है?… (B2C app)
  • cloud-based prompt और tool schema management. यह अच्छा है कि इसे online environment में लागू किया जा सकता है. अब यह लगभग अनिवार्य लगता है, और Langfuse बहुत पसंद आया.
  • Text-to-SQL में prompt के अंदर schema डालना पड़ता है. इस समय context बहुत ज़्यादा consume होता है. शायद fine-tuning या RAG से इसे हल किया जा सकता है.
  • evaluation और iteration. user personas के हिसाब से Synthetic Dataset बनाया, और LLM-as-a-Judge से evaluation किया. इसे automate करना चाहता हूँ, लेकिन अकेले करने पर development resources फिर भी कम पड़ते हैं.
  • evaluation metrics और rubric: यह उम्मीद से ज़्यादा पेचीदा है. मुझे लगता है कि generic metrics DAU और MAU जैसी चीज़ें हैं. लेकिन इन metrics से useful insights नहीं निकलते. case-by-case basis पर metrics define करके low-quality cases को अलग करना, उन्हें solve करना और iteration करना ज़रूरी है. अंततः एक ऐसे system की ज़रूरत है जो custom metrics अच्छी तरह बनाने में मदद करे. (multi-turn का क्या?)
  • OpenAI tier सोच से ज़्यादा restrictive है. उस tier में अच्छे models को production में इस्तेमाल नहीं किया जा सकता.

Infrastructure

  • AWS महँगा है, Managed DB महँगा है. अच्छे हैं, लेकिन अब पछतावा होता है
  • ClickHouse बहुत महँगा है, लेकिन अच्छा है. Managed इस्तेमाल करने से सुविधा रहती है. खासकर CDC तक एक साथ. (तेज़ होने से क्या फ़ायदा, जब LLM ही धीमा हो)
  • Qdrant, Redis Cloud भी बुरे नहीं हैं. setup में कम समय लगता है, और cost भी कम है.
  • Datadog. बहुत अच्छा है. बस महँगा होने वाला है, इसलिए सिर्फ free tier इस्तेमाल किया. खासकर errors को अलग से इकट्ठा करके notify करने वाला feature बहुत अच्छा है. ECS में agent को sidecar के रूप में जोड़कर इस्तेमाल किया.

Service

  • payment और subscription. Toss Pay इस्तेमाल करने पर विचार किया था, लेकिन किया नहीं. पहले तो annual fee होनी चाहिए, और React Native docs भी नहीं हैं, इसलिए SDK अच्छा नहीं लगा. काफी निराशा हुई. नतीजतन NICE Payments चुना. इसमें annual fee नहीं है और development server भी है, इसलिए reasonably आसानी से development हो गया.
  • Apple payment. NICE Payments इस्तेमाल किया, लेकिन इसमें समस्या है. Apple की payment policies काफ़ी सख्त हैं. iOS development के दौरान Apple policy से जुड़े issues आए, और इन्हें documents तथा UI दोनों स्तर पर solve करना पड़ा. शायद Apple का in-app payment system ही इस्तेमाल करना ज़्यादा सुकूनदायक होगा.
  • payment और subscription (auto-payment) अलग चीज़ें हैं. auto-payment implement करने के लिए scheduling infrastructure चाहिए, और card key store करने की security पर भी ध्यान देना पड़ता है. आखिरकार implement तो कर लिया, लेकिन यह सोच से ज़्यादा मुश्किल था. Stripe को इस्तेमाल करके देखने का मन हुआ.
  • push notifications. Expo में इसे आसानी से setup किया जा सकता है. आखिरकार messages भेजने के लिए back office चाहिए, लेकिन मुझे लगता है कि यह एक essential feature है.

विचार

  • software design patterns और architecture का महत्व और बढ़ने वाला है.
  • अच्छा होगा अगर coding agents के साथ toy projects से आगे बढ़कर असली results बनाने में लोगों की रुचि बढ़े.
  • over-specification से बचें. लेकिन नौकरी पाने के लिए over-spec भी जानना ज़रूरी नहीं है क्या? अगली बार शायद एक ही instance पर docker-compose से सब खत्म करना बेहतर होगा… (supabase के साथ?)
  • one-person startup का युग लगभग आ चुका है. लेकिन पैसे कमाना और कुछ बना लेना, ये दोनों अलग बातें हैं.
  • अकेले काम करना मज़ेदार नहीं है
  • Linear भी Jira की जगह इस्तेमाल करने के लिए ठीक है. पहली बार इस्तेमाल कर रहा था, इसलिए tickets को hierarchy के हिसाब से group करके देखने का सही तरीका समझ नहीं आया.

परिणाम

  • server cost वहन न कर पाने की वजह से project बंद कर दिया गया.
  • balance -100

संदर्भ

4p~ में अतिरिक्त सामग्री है.

https://figma.com/deck/wsGLEmFYOUPUheWBl1t23K/…

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.