Claude के साथ वास्तविक कोड deploy करते हुए मिली व्यावहारिक नोट्स

 (diwank.space)
77 पॉइंट द्वारा GN⁺ 2025-06-09 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • AI टूल Claude को वास्तविक सेवा में लागू करते हुए, डेवलपमेंट प्रोडक्टिविटी में 10 गुना सुधार के यथार्थवादी तरीके और अपनाने की व्यावहारिक समझ को व्यवस्थित किया गया है
  • ‘vibe-coding’ सिर्फ एक ट्रेंड नहीं बल्कि एक व्यावहारिक methodology है; सही डेवलपमेंट आदतें और infrastructure होने पर AI की ताकत को अधिकतम और उसकी कमजोरियों की भरपाई की जा सकती है
  • AI की भूमिका को ‘draft writer’, ‘pair programmer’, और ‘code reviewer’ इन तीन मोड में स्पष्ट रूप से बांटना ज़रूरी है, और हर चरण के लिए उपयुक्त documentation व guardrail अनिवार्य हैं
  • मुख्य बात यह है कि हर project में ‘CLAUDE.md’ फ़ाइल का उपयोग करके conventions, architecture, patterns, forbidden items आदि को स्पष्ट रूप से document किया जाए, और कोड के भीतर ‘anchor comment’ के ज़रिए AI को प्रभावी ढंग से guide किया जाए
  • test code हमेशा इंसान को ही लिखना चाहिए, और AI को test, migration, security, API contract, secret जैसे critical क्षेत्रों में बदलाव न करने देने के लिए सीमाएँ सख्ती से तय करनी चाहिए
  • सही सीमाओं और आदतों के तहत AI coding अपनाने वाली टीमें deployment frequency, stability, और development speed—तीनों में बड़ा सुधार हासिल कर सकती हैं, और वास्तविक operational know-how व pattern sharing AI डेवलपमेंट संस्कृति का मुख्य हिस्सा बनते जा रहे हैं

Vibe Coding Isn’t Just a Vibe

  • यह लेख AI-संचालित नए software development तरीके के लिए एक field guide है; यह सिर्फ इस्तेमाल का तरीका नहीं, बल्कि वास्तव में असरदार AI development के पीछे का 'क्यों' भी समझाता है
  • किंवदंती जैसे लगने वाले 10x productivity gains भी तभी संभव हैं जब AI की ताकत को अधिकतम और उसकी कमजोरियों को व्यावहारिक आदतों से संतुलित किया जाए—इसे वास्तविक उदाहरणों से दिखाया गया है
  • वास्तविक production में चल रहे Julep codebase से CLAUDE.md template, commit strategy, और operational disasters रोकने वाले guardrails सहित व्यावहारिक infrastructure और संचालन संबंधी know-how साझा किए गए हैं
  • खास तौर पर test code हमेशा खुद लिखना चाहिए, क्योंकि AI पर अत्यधिक निर्भरता गंभीर outage और debugging nightmare पैदा कर सकती है
  • AI development में तीन मोड (drafting, pair programming, reviewer) होते हैं, और स्थिति के अनुसार AI को पहल देनी है या इंसान को सीधे नियंत्रण रखना है—इसके rhythm और principles अलग होते हैं
  • मुख्य संदेश: अच्छी development आदतें और स्पष्ट सीमाएँ होने पर ही AI क्षमता को amplify करता है, और वास्तविक research भी दिखाती है कि “कड़े development discipline वाली टीमें deployment speed और quality—दोनों में बहुत आगे रहती हैं”

यह लेख क्यों लिखा गया: meme से method तक

  • AI को code लिखने देना और developer का “सिर्फ vibe पर चलना” यानी ‘vibe-coding’ मूल रूप से Andrej Karpathy के एक मज़ाकिया ट्वीट से शुरू हुआ एक ट्रेंड था
  • उस समय developer community ने इसे “AI काम करेगी और हम कॉफ़ी पिएँगे” वाली ultimate fantasy की तरह लेकर हँसी में उड़ा दिया था
  • लेकिन Anthropic के Sonnet 3.7 और Claude Code के लॉन्च के बाद, यह मज़ाक धीरे-धीरे वास्तविकता बनने लगा। पहले Cursor जैसे tools मौजूद थे, लेकिन Claude Code ने सचमुच ‘vibe coding’ जैसा अनुभव देना शुरू किया
  • लेखक की कंपनी Julep के पास विशाल codebase, तरह-तरह के design patterns, और technical debt है। code quality और documentation काफ़ी सख़्ती से बनाए रखे जाते हैं, फिर भी हर हिस्से के इरादे और history को समझने में कई हफ़्ते लग जाते हैं
  • अगर Claude को guardrail के बिना इस्तेमाल किया जाए, तो वह एक ज़रूरत से ज़्यादा उत्साही intern की तरह हर जगह गड़बड़ी पैदा कर सकता है
  • यह लेख उन्हीं trial-and-error, रात 3 बजे की debugging, और वास्तविक production संचालन से बचकर निकले असल व्यावहारिक patterns और know-how को समेटकर साझा करता है

vibe coding का सार

  • जैसे Steve Yegge ने CHOP(Chat-Oriented Programming) शब्द गढ़ा था, वैसे ही ‘vibe coding’ AI से बातचीत करते हुए code पूरा करने का एक नया डेवलपमेंट तरीका है
  • अगर पारंपरिक coding संगमरमर को तराशने की तरह लाइन-दर-लाइन सावधानी से बनाने का काम है, तो
    • vibe coding एक orchestra conductor जैसा है, और AI वह वादक है जो कच्चा माल देता है (मूलभूत coding क्षमता)
    • developer पूरी दिशा और संरचना तय करता है, और AI उसी प्रवाह को code में बदलता है
  • vibe coding की 3 postures
    • 1. AI को first drafter की तरह इस्तेमाल करना
      • architecture और design पर ध्यान रखते हुए, repetitive काम (CRUD, boilerplate आदि) AI तेज़ी से generate कर देता है
      • यह ऐसा लगता है जैसे आपके पास सोचने की गति से code लिखने वाला junior engineer हो, लेकिन उसे लगातार guidance चाहिए
    • 2. AI के साथ pair programming
      • यह सबसे व्यावहारिक और सबसे प्रभावी मोड है
      • developer और AI ideas का आदान-प्रदान करते हैं; बड़ा ढाँचा इंसान बनाता है और implementation details AI भरता है
      • यह ऐसे colleague के साथ pair coding जैसा है जिसके पास बहुत प्रोग्रामिंग ज्ञान है, लेकिन वास्तविक deployment experience नहीं है
    • 3. AI को validator/code reviewer की तरह इस्तेमाल करना
      • इंसान द्वारा लिखा गया code AI review करता है, bugs, improvements, और छूटे हुए patterns सुझाता है
      • यह कभी न थकने वाला और बारीक नज़र वाला reviewer बन जाता है
  • मुख्य insight: developer की भूमिका ‘writer’ से ‘editor’ में बदलती है। हर code खुद लिखने के बजाय, AI द्वारा बनाए गए output को review, modify, और direction देना अहम हो जाता है।
  • लेकिन पूरी architecture और context की कमान इंसान के हाथ में ही रहनी चाहिए, क्योंकि AI सिर्फ ‘encyclopedic knowledge वाला intern’ है; वह हमारे service या business context को नहीं समझता

vibe coding के 3 व्यावहारिक मोड: framework

कई महीनों के प्रयोग और वास्तविक deployment incidents के बाद, यह स्पष्ट हुआ कि vibe coding के 3 अलग मोड हैं, जिनमें से हर एक का rhythm, guardrail, और best use case अलग है

  • मोड 1: Playground (प्रयोग/prototype/personal project)

    • कब इस्तेमाल करें: weekend hacking, personal scripts, PoC, अचानक आए idea का टेस्ट आदि
    • विशेषताएँ: design, documentation, या guardrail के बिना AI code का 80~90% लिख देता है। idea से परिणाम तक कुछ ही मिनटों में पहुँचा जा सकता है
    • जोखिम: वास्तविक production/critical code के लिए उपयुक्त नहीं। सिर्फ़ खिलवाड़ या प्रयोग के लिए इस्तेमाल करें। engineering principles यहाँ और भी ज़्यादा महत्वपूर्ण हो जाते हैं

  • मोड 2: Pair Programming (वास्तविक उपयोग/छोटी सेवा)

    • कब इस्तेमाल करें: 5,000 lines से छोटे project, वास्तविक users वाले side project, demo, छोटे modules आदि
    • मुख्य बिंदु: project की practices, architecture, patterns, test guide आदि को CLAUDE.md में एक बार साफ़-साफ़ define करें
    • फायदा: जैसे किसी नए developer का onboarding करते हैं, वैसे Claude को एक बार समझाने पर वह लगातार consistent code generate कर सकता है
    • व्यावहारिक points:
      • code के अलग-अलग हिस्सों में anchor comment (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION आदि) से Claude को context खोने से बचाएँ
      • ये comments AI और इंसान—दोनों के लिए guidance का काम करते हैं, और CLAUDE.md में इनके management rules व examples तक दर्ज होने चाहिए

  • मोड 3: Production/Monorepo Scale (बड़ी सेवा)

    • कब इस्तेमाल करें: दर्जनों से सैकड़ों developers, वास्तविक users वाली बड़ी service, और ऐसी स्थिति जहाँ एक गलती से बड़ा नुकसान हो सकता है
    • सावधानी: मौजूदा समय (जून 2025) तक बड़े पैमाने पर batch vibe coding पूरी तरह scalable नहीं है
    • सिद्धांत: vibe coding को individual service/submodule इकाई के आधार पर अपनाना बेहतर है; सभी integration points (API, DB आदि) पर स्पष्ट boundaries और version management होना चाहिए, और महत्वपूर्ण interfaces/API पर बदलाव संबंधी warning comments अनिवार्य हैं
    • व्यावहारिक उदाहरण:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • ऐसी boundary lines न हों तो Claude मनमाने “improvements” करते-करते पूरी वास्तविक service को तोड़ सकता है
  • निष्कर्ष: बड़े projects में vibe coding को धीरे-धीरे, अलग की गई services की इकाई में अपनाना चाहिए, और विश्वसनीयता के लिए documentation, guidelines, review जैसे पारंपरिक principles को साथ लेकर चलना अनिवार्य है

इन्फ्रास्ट्रक्चर-केंद्रित टिकाऊ AI डेवलपमेंट वातावरण बनाना

  • CLAUDE.md: AI और इंसानों दोनों के लिए एकल सत्य स्रोत (The Single Source of Truth)

    • CLAUDE.md सभी प्रोजेक्ट नियम, आर्किटेक्चर, सावधानियाँ, कोड स्टाइल, प्रतिबंधित चीजें, डोमेन शब्दावली आदि को व्यवस्थित रूप से समेटने वाले एक ‘संविधान’ की भूमिका निभाता है
    • यह AI और नए टीम सदस्यों के बीच साझा होने वाले ‘ज्ञान के ढाँचे’ की तरह काम करता है, और उदाहरणों के साथ ठोस guidelines और निषेधों का श्रमसाध्य तरीके से प्रबंधन किया जाता है
    • जो टीमें अच्छे CLAUDE.md में निवेश करती हैं, वे बेहतर परिणाम बनाती हैं
    • हमारा production CLAUDE.md देखें
    • जैसे-जैसे codebase बड़ा होता है, केवल CLAUDE.md पर्याप्त नहीं रहता; कोड के अलग-अलग हिस्सों में anchor comment (AIDEV-NOTE/TODO/QUESTION आदि) के जरिए local context को स्पष्ट रूप से पहुँचाना जरूरी होता है
    • अगर codebase को एक शहर मानें, तो anchor comment ऐसे साइनबोर्ड हैं जो AI और इंसानों दोनों को रास्ता भटकने से बचाते हैं
    • ऐसे comments सिर्फ कोड की व्याख्या नहीं करते, बल्कि यह इस तरह क्यों काम करता है इसकी कहानी भी छोड़ते हैं

  • Git workflow: AI कोड का व्यवस्थित प्रबंधन

    • AI कोड जनरेशन जितनी तेज़ होती जाती है, गलत प्रबंधन होने पर git history दूषित हो सकती है
    • git worktree approach जैसी विधि से main branch से अलग AI experiment space तैयार करें, ताकि कोड स्वतंत्र रूप से बनाया जा सके लेकिन रिकॉर्ड को व्यवस्थित रूप से अलग और प्रबंधित रखा जाए
    • commit message में AI involvement को ज़रूर स्पष्ट करें ([AI] tag आदि का उपयोग), ताकि reviewer अतिरिक्त सावधानी से समीक्षा कर सके

अलिखित नियम: टेस्ट कोड हमेशा इंसान लिखे

  • AI-assisted development में सबसे महत्वपूर्ण सिद्धांत: "टेस्ट कोड कभी भी AI को नहीं सौंपना चाहिए"
  • टेस्ट सिर्फ व्यवहार जांचने वाला कोड नहीं है
    • यह executable specification है, जिसमें वास्तविक समस्या का संदर्भ, edge case की समझ, business requirement की व्याख्या, और डोमेन के प्रति मानवीय समझ व अनुभव शामिल होते हैं
    • जो बेहतरीन टीमें गति और स्थिरता दोनों संभालती हैं, वे इसी टेस्ट को पूरी तरह इंसानी नियंत्रण में रखती हैं
  • AI द्वारा auto-generated tests अक्सर केवल सतही path (happy path) को ही verify करते हैं, और अप्रत्याशित गंभीर समस्याएँ (जैसे memory leak) छूट जाती हैं
  • हमारी टीम में अगर AI टेस्ट फाइल को छू भी दे, तो PR अपने-आप reject हो जाता है (कोई अपवाद नहीं)
  • टेस्ट कोड की specification भी है, safety net भी, और अब तक जमा हुई bugs व edge cases की सामूहिक समझ भी
  • इसे हमेशा इंसानी हाथों से लिखना चाहिए, और AI इसे छू न सके इसके लिए सख़्त सुरक्षा होनी चाहिए

स्केलिंग और context management: token economy और context optimization

  • AI कोड डेवलपमेंट में होने वाली आम गलती:
    "tokens बचाने" के लिए context (prompt, requirements, environment आदि) को कम कर देना, जिससे उल्टा बार-बार काम दोहराना पड़ता है और कुल token खपत बढ़ जाती है
  • उपयुक्त context देना लंबे समय में अधिक प्रभावी है
    • "minimal" नहीं, बल्कि "relevant और पर्याप्त context" पहले से देना ही कुंजी है
  • खराब उदाहरण: कम context वाला prompt "Add caching to the user endpoint"
    • Claude केवल साधारण in-memory caching करेगा, invalidation strategy/monitoring नहीं होगी, multi-server स्थिति का विचार नहीं होगा, और cache stampede के लिए कोई उपाय नहीं होगा
    • नतीजतन 3 से अधिक बार iterative fixes करनी पड़ेंगी, और कुल 4 गुना से ज़्यादा tokens खर्च होंगे
  • अच्छा उदाहरण: context से भरपूर prompt 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • शुरुआत से ही ठोस context देने पर बिना दोहराव के सटीक implementation संभव होता है
  • निष्कर्ष:
    • "tokens अच्छे tools में किया गया निवेश हैं"
    • पहले से पर्याप्त context देने पर लंबे समय में दोहराव और सुधार कम होते हैं, इसलिए लागत बचती है
  • व्यावहारिक टिप: हर प्रोजेक्ट में कोड बदलते समय Claude से कहें कि वह codebase में हुए बदलाव और संबंधित context को CLAUDE.md में अपडेट करे

सेशन प्रबंधन और context contamination की रोकथाम

  • हर काम के लिए Claude का नया session शुरू करना महत्वपूर्ण है
    • अगर एक ही लंबी बातचीत में कई काम (जैसे DB migration, frontend design आदि) मिला दिए जाएँ, तो context आपस में गड़बड़ा जाता है और अनचाहे परिणाम आते हैं
  • नियम: एक काम = एक session, काम पूरा होते ही नया session शुरू
    • Claude के 'mental model' को हमेशा साफ़ और केंद्रित स्थिति में रखें
    • ठीक वैसे ही जैसे कच्चे चिकन और सब्ज़ियों के लिए अलग cutting board इस्तेमाल किया जाता है

व्यावहारिक उदाहरण: error handling संरचना का बदलाव

  • वास्तविक रूप से 500+ endpoints में इस्तेमाल हो रहे ad-hoc error handling को structured error hierarchy से बदलने का एक उदाहरण दिया गया है
  • इसमें इंसान (architect) पहले से मुख्य डिज़ाइन (SPEC.md/requirements/error classification) लिखता है, और Claude बड़े पैमाने पर वास्तविक code transformation (mechanical work) का executor बनता है
  • आर्किटेक्चर सिद्धांत, ठोस specification, design document के उदाहरण/अवधारणा तैयार करना -> AI को स्पष्ट निर्देश देना -> ठीक 4 घंटे के भीतर पूरा refactoring समाप्त करने का अनुभव

AI युग में leadership और organizational culture

  • senior engineer की भूमिका खुद कोड लिखने से आगे बढ़कर, knowledge curation, boundaries तय करने, और AI/इंसान दोनों को guide करने की दिशा में विकसित हो रही है
  • Lean management, continuous deployment जैसी आधुनिक डेवलपमेंट संस्कृति AI collaboration के प्रबंधन में भी उतनी ही महत्वपूर्ण है

  • नए कर्मचारियों के onboarding checklist (इंसान + AI सहयोग का विभाजन)

    • पहला सप्ताह: बुनियाद मजबूत करना
      • टीम का CLAUDE.md (common/service-specific) पढ़ना
      • development environment सेट करना
      • पहला PR submit करना (100% स्वयं coding, AI निषिद्ध)
    • दूसरा सप्ताह: AI collaboration का अभ्यास
      • Claude पर टीम template लागू करना, settings configure करना
      • AI के साथ 'toy problem' हल करना
      • prompt patterns का अभ्यास
      • AI-assisted पहला PR (mentor/senior के साथ)
    • तीसरा सप्ताह: स्वतंत्र व्यावहारिक काम
      • AI assistance से मुख्य feature विकसित और deploy करना
      • सहकर्मी के AI कोड के लिए स्वयं tests लिखना
      • code review session एक बार lead करना

पारदर्शी संस्कृति बनाना: AI उपयोग का सक्रिय खुलासा

  • हर AI उपयोग वाले commit को नीचे की तरह commit message tag से स्पष्ट रूप से चिह्नित करें 
    feat: add Redis caching to user service \[AI]  
# \[AI] - 50% 이상 AI 생성, \[AI-minor] - 50% 미만, \[AI-review] - 리뷰만 AI 사용  
# AI가 캐시/클라이언트 코드 작성, 캐시키 설계/테스트/검증은 사람이 직접
  • प्रभाव
    1. reviewer AI कोड पर विशेष ध्यान देता है
    2. debugging के समय कोड का स्रोत पहचानना आसान होता है
    3. AI उपयोग को लेकर शर्म या छिपाने की संस्कृति खत्म होती है, और "जिम्मेदारी से AI का उपयोग" करने वाली टीम संस्कृति स्थापित होती है
  • यह ज़रूरी है कि हर कोई बिना झिझक AI का उपयोग कर सके, high-performance culture में योगदान दे सके, और इसके लिए सक्रिय खुलापन व सांस्कृतिक तंत्र मौजूद हों

Claude के लिए निषेध: यहाँ AI को बिल्कुल हाथ नहीं लगाना चाहिए

  • टेस्ट फ़ाइलें/डेटाबेस migration/सुरक्षा के core code/API contract (version control शामिल नहीं)/environment settings और secrets आदि में AI automation का इस्तेमाल बिल्कुल नहीं किया जा सकता
  • गलती के स्तर के अनुसार (format·dependency से लेकर business-critical क्षेत्र में data destruction तक) वर्गीकरण करें, और high-risk क्षेत्रों पर अतिरिक्त अनिवार्य guardrails लागू करने पर ज़ोर दें
  • AI गलतियों का risk hierarchy (Hierarchy of AI Mistakes)
    • Level 1: परेशान करने वाला, लेकिन घातक नहीं
      • format error (linter से पकड़ा जाता है)
      • ज़रूरत से ज़्यादा verbose code (बाद में refactor किया जा सकता है)
      • inefficient algorithm (profiling के दौरान पता चलता है)
    • Level 2: बहुत महंगी गलतियाँ
      • internal API compatibility टूटना (team coordination की ज़रूरत)
      • existing pattern बदलना (confusion पैदा करना)
      • अनावश्यक dependency जोड़ना (codebase फूलना)
    • Level 3: करियर के लिए घातक (Career-Limiting)
      • test result मिलाने के लिए test को ही बदल देना
      • API contract तोड़ देना
      • secrets/व्यक्तिगत जानकारी leak कर देना
      • data migration को नुकसान पहुँचाना
    • गलती के level के अनुसार guardrails का स्तर भी बदलना चाहिए, और Level 3 की गलतियाँ करियर के लिए भी गंभीर ख़तरा बन सकती हैं

विकास का भविष्य: आगे के बदलाव और दिशा

  • 2025 की वर्तमान स्थिति में, AI-assisted development किशोरावस्था के एक ताकतवर लेकिन अभी भी अटपटे और खुरदरे नौजवान जैसा है
  • लेकिन इसकी growth curve साफ़ तौर पर 'acceleration' में है
  • अच्छी documentation, AI युग में DevOps implementation की core infrastructure है
    • documentation अब सिर्फ़ 'reference material' नहीं, बल्कि human intent और AI execution के बीच सीधा 'interface' है
    • high-performance teams, tests जितनी ही सख़्ती से CLAUDE.md जैसी documentation को manage करती हैं

  • आगे अपेक्षित बदलाव

    • पूरा code context समझने वाला AI
      • file unit नहीं, बल्कि service/system level तक समझ
    • session·project के पार persistent memory
      • बातचीत और काम के context को लंबी अवधि तक याद रखना और उपयोग करना
    • सक्रिय रूप से सुधार के सुझाव देने वाला AI
      • बिना request के भी समस्या और सुधार बिंदु पहले से diagnose करना
    • हर team के pattern·preference सीखने वाला AI
      • संगठन की अपनी style/convention के मुताबिक code अपने-आप generate करना
  • लेकिन, मूल बात नहीं बदलेगी:
    • दिशा तय करना इंसान का काम, execution·leverage AI का
    • tool चाहे जितना ताकतवर हो जाए, हम अब भी 'tool का उपयोग करने वाले इंसान' ही हैं

निष्कर्ष: अभी, यहीं से शुरू करें

  • अगर आपने यहाँ तक पढ़ लिया है, तो उत्साह के साथ थोड़ी-सी घबराहट भी महसूस हो सकती है
    • यह प्रतिक्रिया सामान्य है, AI-assisted development शक्तिशाली है लेकिन 'जानबूझकर और व्यवस्थित अभ्यास' अनिवार्य है

  • आज से ही लागू करने लायक action plan

    • आज
      • 1. अपने current project में CLAUDE.md फ़ाइल बनाइए
      • 2. जिस code को आप सबसे जटिल मानते हैं, उसमें 3 anchor comment ख़ुद जोड़िए
      • 3. स्पष्ट boundary (guide) के अंदर AI-assisted feature का 1 प्रयोग कीजिए
    • इस हफ़्ते
      • 1. team level पर AI commit message rule बनाइए
      • 2. एक junior developer के साथ AI coding session चलाइए
      • 3. AI द्वारा बनाए गए code के लिए test code ख़ुद लिखिए
    • इस महीने
      • 1. AI अपनाने से पहले और बाद में deployment frequency के बदलाव को मापिए
      • 2. team के भीतर repetitive tasks के लिए prompt pattern library बनाइए
      • 3. पूरी team के साथ AI collaboration पर retrospective meeting कीजिए
  • मुख्य बात है "अभी तुरंत, छोटे स्तर से, सावधानी से, लेकिन शुरुआत ज़रूर करें"
  • जो developer इस pravah को जल्दी master कर लेते हैं, वे इसलिए बेहतर नहीं होते कि वे ज़्यादा स्मार्ट हैं,
    • बल्कि इसलिए कि उन्होंने जल्दी शुरुआत की, ज़्यादा गलतियाँ कीं, और उनसे सीखा
  • software deployment का प्रदर्शन ही संगठन के प्रदर्शन को तय करता है
    • ऐसी दुनिया में जहाँ speed और quality ही competitiveness हैं, AI-assisted development विकल्प नहीं बल्कि 'ज़रूरी क्षमता' है
    • लेकिन इसके लिए सही तरीके से आगे बढ़ना होगा
  • vibe coding सुनने में मज़ाक जैसा लग सकता है,
    • लेकिन यह इंसानी क्षमता को amplify करने का एक गंभीर development तरीका है
    • tools और patterns पहले से ही पर्याप्त रूप से तैयार हैं
    • अब यह चुनने का समय है कि orchestra को कौन conduct करेगा, और कौन अकेले सारे instrument बजाएगा

व्यावहारिक सामग्री और सुझाए गए resources

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

7 टिप्पणियां

 
softychoco 2025-06-16

आज मैंने जो पोस्ट लिखी, उसका नज़रिया भी काफ़ी हद तक इसी सामग्री जैसा है.
आख़िरकार, मुख्य बात यह थी कि AI के ज़रिए उत्पादकता बढ़ाई जाए और घटी हुई स्थिरता को बेहतर बनाने वाली संगठनात्मक संरचना में बदलाव किया जाए.

https://softycho.co/57
 
kimjoin2 2025-06-09

AI की मदद से होने वाली coding को vibe coding कहते हैं, लेकिन इसमें vibe का मतलब क्या है, यह अब तक समझ नहीं आया।
माहौल? एहसास? मेल-जोल? इसका AI से कोई संबंध भी नहीं लगता।
इतना context से कटा हुआ लगता है कि जैसे यह बस यूँ ही फेंक दिया गया हो।
 
analogstar 2025-06-11

नामूविकी के अनुसार
"Vibe Coding वह नया शब्द है जो उस क्रिया को दर्शाता है जिसमें डेवलपर generative AI की मदद से कोड लिखता है; यानी प्रोग्रामिंग करते समय पहले से सख्त लॉजिक या डिज़ाइन पर आधारित होने के बजाय अंतर्ज्ञान और एहसास पर निर्भर किया जाता है, इसलिए इसका नाम ‘Vibe’ coding पड़ा है।" ऐसा कहा गया है। हा हा
 
hohemian 2025-06-09

दिमाग खाली कर दीजिए और फ़्लो के साथ चलिए।
सारा लॉजिक AI लिख देता है।
आप तो बस Tab key दबाने वाली मशीन बन जाते हैं!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. इसे समझिए मत🧠, महसूस कीजिए!😊

वैसा ही एहसास है
 
humblebee 2025-06-09

ओह, ऐसा है क्या? मुझे तो सुनते ही बिल्कुल वही 'feeling' आ गई थी..
आपकी बात सुनकर.. आजकल non-developer roles भी जिस 'hard-coding' शब्द को अच्छी तरह समझते हैं, वही याद आ गया।
यह शब्द भी शुरू में अपने आप में क्या मतलब रखता है, समझना मुश्किल होता है, लेकिन development सीखते-सीखते आखिरकार यह किस चीज़ को दर्शाता है और इसके पीछे क्या इरादा है, यह सबको अच्छी तरह समझ में आने वाली एक तरह की 'feeling' ही है, शायद? haha
 
GN⁺ 2025-06-09
Hacker News राय

  • लेख के लेखक के नज़रिए से: आजकल Claude code पर लेखों की बाढ़ आई हुई है, इसलिए हमने जो कुछ मुख्य बिंदु खोजे—खासकर Anchor Comments—उन्हें साझा करना उपयोगी समझा
    Anchor Comments तरीका ऐसा है जिसमें codebase के अलग-अलग हिस्सों में विशेष फ़ॉर्मैट के comments छोड़े जाते हैं, ताकि ज़रूरी जानकारी को तुरंत grep करके ढूंढा जा सके
    उदाहरण के तौर पर, AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION: जैसे prefixes इस्तेमाल किए जाते हैं
    फ़ाइल खोजने से पहले यह नियम है कि पहले यह ज़रूर grep किया जाए कि कोई मौजूदा AIDEV-… है या नहीं
    काम खत्म होने के बाद संबंधित anchor को अपडेट करना अनिवार्य है
    अगर कोई code file या code snippet बहुत जटिल हो, बहुत महत्वपूर्ण हो, या उसमें bug होने की आशंका लगे, तो हमेशा anchor comment छोड़ना चाहिए
    संदर्भ उदाहरण यहाँ देखा जा सकता है

    • मैं एक बहुत अनुभवी engineer हूँ जो LLM को व्यवस्थित रूप से नहीं, बस कभी-कभार इस्तेमाल करता है, लेकिन वास्तविक project में LLM को production में कैसे लागू किया जाता है यह विस्तार से देखना काफ़ी उपयोगी लगा
      समझ नहीं आता कि बाकी लोग इतने नकारात्मक नज़रिए क्यों रखते हैं
      इससे मुझे अपने workflow में LLM का इस्तेमाल थोड़ा और बढ़ाने की प्रेरणा मिली
      बेशक LLM ने project की चाबी अपने हाथ में नहीं ली थी, लेकिन कुछ खास काम उसे देकर सफलता मिली ऐसे कई उदाहरण रहे

    • इन दिनों इस विषय पर बहुत लेख हैं, लेकिन यह लेख काफ़ी practical है और मुझे ऐसा system idea देता है जिसे मैं खुद लागू कर सकता हूँ
      aider जैसे tools इस्तेमाल करते समय और इस workflow में क्या अंतर है, यह जानने की उत्सुकता है—अगर लेखक का नज़रिया हो तो सुनना चाहूँगा

    • शानदार article, बड़े पैमाने पर LLM इस्तेमाल करने के तरीकों को समझने में बहुत मदद मिली
      इसमें कहा गया कि "AI को tests छूने नहीं चाहिए", लेकिन आगे 500 से ज़्यादा endpoints refactor करने का उदाहरण दिया गया जो 4 घंटे में पूरा हुआ—यह काफ़ी प्रभावशाली लगा
      जिज्ञासा है कि क्या इन 4 घंटों में test refactoring भी शामिल थी, या यह सिर्फ prompts पर लगे समय की बात थी

    • मैंने यह नियम पढ़ा कि अगर tests AI द्वारा update किए गए हों तो PR reject कर दिया जाता है, लेकिन असल में यह कैसे पता चलता है कि AI ने generate या modify किया था, यह जानना चाहूँगा
      लेख में कहा गया कि git commit message के नियम से यह पहचाना जाता है, लेकिन यह भी commit स्तर पर ही काम करता है

    • क्या यह लेख लिखने में Claude Code का इस्तेमाल किया गया था?
      मैं खुद आजकल अपनी लिखी हुई चीज़ों का 100% Claude Code से लिखता हूँ, क्योंकि markdown files में agent का सीधे edit करना claude.ai artifacts या chatgpt.com canvas की तुलना में बहुत ज़्यादा productive लगता है
      इसकी वजह से research material या संबंधित files को document में गहराई से merge करना बेहद आसान हो गया है

  • AI agents की दिलचस्प बात यह है कि वे उन प्रक्रियाओं को सचमुच अमल में ले आते हैं जिन्हें हम आम तौर पर महत्वपूर्ण तो मानते हैं, लेकिन system deploy करने के सामने उनकी priority पीछे चली जाती थी
    मैं इस उपयोगी trick का इस्तेमाल करता हूँ कि AI के मेरे बदले कुछ करने पर जितनी असहजता महसूस हो, उसे 'systematic verification पर समय लगाने के संकेतक' की तरह लिया जाए
    जैसे लिंक में बताया गया है, अगर data migration validation system बनाया जाए, तो उससे जुड़े सभी बदलाव भी स्वाभाविक रूप से AI के इस्तेमाल के दायरे में लाए जा सकते हैं
    अमूर्त 'technical debt' की बातों की तुलना में इसे बाहर के लोगों को समझाना भी आसान पड़ता है

    • मैं इससे पूरी तरह सहमत हूँ, और एक और उपयोगी trick जो मैंने खोजी है वह यह है कि Claude Code से कहा जाए: "codebase को देखो, और अगर कुछ confusing, अजीब, या intuition के खिलाफ लगे तो AIDEV-QUESTION: comment छोड़ो"
      इससे अनपेक्षित रूप से जटिल और भूले-बिसरे code की वजह से महत्वपूर्ण जगहों को फिर से खोज पाने का अनुभव हुआ है

    • मेरा अंदाज़ा है कि ऊँचे abstraction level वाले verification tools—जैसे acceptance tests, property tests, formal verification—और ज़्यादा इस्तेमाल होने लगेंगे
      क्योंकि LLM के इस्तेमाल से boilerplate की लागत तुलनात्मक रूप से काफ़ी कम हो गई है

  • इसे पढ़ते हुए मैंने कुछ नया सीखा
    हाल में Sonnet 4 को Cursor और Web पर इस्तेमाल किया, लेकिन बार-बार ऐसा लगा कि वह चीज़ों को ढीले-ढाले ढंग से करता है या नतीजों को गलत समझकर रिपोर्ट करता है, जिससे मैं हैरान रह गया
    यहाँ तक कि programming के बाहर के क्षेत्रों में भी वह अजीब तरह से गलत बातें करता दिखा
    Anthropic की report में जैसा देखा था, “मैं तुम्हें delete कर दूँगा” जैसी चेतावनियाँ भी बेअसर रहीं, और इस्तेमाल के बाद mobile app में feedback submit न हो पाने की समस्या भी हुई
    बाकी लोगों को Claude से जुड़ी ऐसी दिक्कतें नहीं लग रहीं, तो सोच रहा हूँ कि क्या यह सिर्फ मेरे साथ हो रहा है

    • हालिया updates में ऐसा लगता है कि AI की क्षमता को बहुत कमज़ोर कर दिया गया है
      3.5 version तक यह text analysis, summary, short writing जैसे आसान कामों में ठीक था, लेकिन version 4 और आगे एक ही context में 3-4 बार से ज़्यादा निर्देश ठीक से follow नहीं कर पाता
      जब मैं पूछता हूँ, “संक्षेप में बोलने को कहा था, फिर बार-बार इतना लंबा क्यों समझा रहे हो?”, तो जवाब मिलता है कि default settings की वजह से निर्देश अनदेखे हो रहे हैं, और “harmful information” से तो वह पूरी तरह बचने की प्रवृत्ति दिखाता है
      कई बार तार्किक खामियाँ दिखाने पर वह खुद स्वीकार करता है कि उसकी reliability कम है
      कभी-कभी लगता है कि शायद वह इतना ज़्यादा smart हो गया है कि उलटी समस्याएँ आने लगी हैं, और अगर Anthropic ने उसे गलत दिशा में आगे बढ़ाया है तो यह अफ़सोस की बात है

    • ऊपर बताई गई सारी समस्याएँ मैंने भी वास्तव में अनुभव की हैं
      Web पर अगर बहुत specific request दी जाए तो कुछ बेहतर रहता है, लेकिन फिर भी generated code का आधा हिस्सा अब भी errors से भरा होता है

  • documentation tips पढ़कर लगा कि ये नियम सिर्फ AI के लिए ही नहीं, सामान्य coding पर भी लागू होते हैं
    CLAUDE.md की जगह CONVENTIONS.md हो, और AI के लिए comments की जगह READER के लिए comments हों, तब भी यह उतना ही उपयोगी रहेगा
    अगर किसी अनजाने codebase में नया contribution करते समय ऐसे comments मिलें, तो मैं काफ़ी आभारी रहूँगा

    • मैंने aider के साथ इसे वास्तव में आज़माया, और यह काफ़ी अच्छा चला
      उड़ान का इंतज़ार करते हुए मैंने PDF viewer और drawing feature तक वाला code 30 मिनट में पूरा कर लिया

    • मैं मूल लेखक नहीं हूँ, लेकिन वास्तव में Claude के लिए मददगार comments और इंसानों के लिए मददगार comments की शैली में बहुत बड़ा अंतर है
      इंसानों के लिए style guide आम तौर पर लगभग 100 lines की होती है और “input बदलने वाले function में हमेशा ! लगाओ” जैसे सरल नियमों पर आधारित रहती है
      Claude के लिए guide मैंने 500 lines से ज़्यादा लिखी, और हर नियम के लिए “ऐसे करो, वैसे मत करो” जैसे बहुत सारे examples देने पड़े, तब जाकर कुछ असर महसूस हुआ

  • लेख के लिए धन्यवाद
    कई developers जब LLM को काम पर कुछ हद तक control सौंपते हैं तो जो बेचैनी महसूस करते हैं, और दूसरी तरफ यह चिंता कि यह पारंपरिक औपचारिक व सख्त development methodology की बजाय कुछ experimental या unstructured approach जैसा लगता है—इस द्वंद्व से मैं सहमत हूँ
    फिर भी LLM का इस्तेमाल करके समस्याओं को कहीं तेज़ गति से हल करने वाली 'goal-oriented optimization' वास्तव में एक व्यावहारिक मध्य-मार्ग बनाती है
    अक्सर हम implementation details में फँसकर असली लक्ष्य से भटक जाते हैं, और मुझे लगता है कि LLM का उपयोग ऐसी गलतियों को कम करने में मदद करता है

    • सही बात
      मैं LLM को एक अधूरा lever मानता हूँ—अभी यह कच्चा है और गलतियाँ भी बहुत करता है, लेकिन सीखते हुए इस्तेमाल करने लायक ज़रूर है
      बशर्ते इसे लचर engineering को सही ठहराने के बहाने की तरह न इस्तेमाल किया जाए, बल्कि इसे सचमुच उपयोगी tool बनाने की कोशिश की जाए

  • लेख के सबसे ऊपर 2.3MB की image थी, जो Wi‑Fi पर भी मज़ाकिया ढंग से बहुत धीरे load हुई

  • कुछ विचार

    • सोच रहा हूँ कि LLM से जुड़े prompts या specs को codebase में और अधिक सुव्यवस्थित तरीके से रखने का कोई बेहतर तरीका है या नहीं
      अगर CLAUDE.md, SPEC.md, और AIDEV comments बहुत बढ़ जाएँ, तो उन्हें संभालना कठिन हो सकता है

    • आजकल 'vibe-coding' की परिभाषा क्या है, यह जानने की उत्सुकता है
      Karpathy के “cowboy mode” की तरह code देखे बिना सारे diff स्वीकार करने वाली बात से अब यह बदलकर शायद किसी भी LLM workflow को शामिल करने वाले अर्थ में इस्तेमाल होने लगा है

    • यह भी जानना है कि क्या लोग अपना code किसी और के LLM को भेजते समय source code obfuscation करते हैं

    • यह सच है कि comments बहुत बढ़ जाएँ तो code जल्दी जटिल लगने लगता है
      इसलिए मैं इसे visualize करके gutter में छोटे indicators के रूप में दिखाने वाला एक vscode extension खुद बना रहा हूँ
      vibe-coding का मतलब हर व्यक्ति के लिए अलग है, लेकिन निजी तौर पर यह मेरे लिए कोई परिपूर्ण समाधान नहीं रहा और इसमें कई समस्याएँ मिलीं
      3.7 Sonnet और Codex ने 60% नतीजे दिए, लेकिन Opus 4 वास्तव में बहुत प्रभावी लगा
      code obfuscation के मामले में, लेख के उदाहरण तो शुरू से ही पूरी तरह open source थे, इसलिए वहाँ कोई बड़ी समस्या नहीं थी

  • यह बहुत दिलचस्प लगा, और मैं इसे अपनी CLAUDE.md file में भी लागू करने की सोच रहा हूँ
    AI development का यह विरोधाभासी सबक कि “tokens बचाने के लिए context बचाना” कभी-कभी उलटा नुकसान कर सकता है, इससे मैं सहमत हूँ
    बड़े projects और जटिल code में Claude Opus और Sonnet के प्रदर्शन का अंतर वास्तव में काफ़ी बड़ा होता है, यह मैंने खुद महसूस किया है
    Sonnet अक्सर ऐसी कोशिशें दोहराता रहा जिन्हें करने की ज़रूरत ही नहीं थी, और इससे स्थिति और खराब हो जाती थी
    आख़िरकार यह सवाल उठता है कि Max subscription वाले users के लिए Opus और Sonnet को अलग-अलग मानने की ज़रूरत भी है या नहीं
    जहाँ Sonnet को 10~20 बार के iteration लगते हैं, वहीं Opus 2~3 बार में काम खत्म कर देता है, इसलिए लंबे समय में Sonnet का उपयोग ही शायद ज़्यादा महँगा पड़ता है

    • Max subscription के दो tiers हैं, और $100 वाला Pro से 5 गुना tokens देता है, जबकि $200 वाला 20 गुना
      token calculation आसान नहीं है, और hybrid mode में Opus tokens 20% बचे रहने तक Opus इस्तेमाल होता है, उसके बाद अपने-आप Sonnet पर switch हो जाता है

  • लेख अच्छा लिखा गया है, लेकिन “tests कभी भी AI को मत सौंपो” वाली बात से मैं सहमत नहीं हूँ
    मैं आजकल सारे tests AI से लिखवाता हूँ और खुद ध्यान से review करता हूँ
    अगर code नया हो, तो ऊँची autonomy पाने के लिए tests भी AI को सौंपने पड़ते हैं
    मैं AI को test implementation और उन्हें pass करवाने के लिए साफ़ निर्देश देता हूँ, फिर AI के development के दौरान तुरंत review करता हूँ और जहाँ test cases कम हों वहाँ उन्हें जोड़ देता हूँ

  • मैं ज़्यादातर बातों से सहमत हूँ, लेकिन Claude को tests या migrations को हाथ तक न लगाने देने वाली policy से सहमत नहीं हूँ
    tests खुद लिखना मेरे लिए सबसे नापसंद काम है, और ऐसी स्थिति में LLM अगर कम-से-कम एक minimal draft भी बना दे तो बहुत मदद मिलती है
    असली बात यह है कि चाहे किसने generate किया हो, अंतिम ownership और ज़िम्मेदारी हमेशा इंसान के पास रहनी चाहिए
    संदेश के लहज़े से लगता है कि लेखक का मकसद Claude पर भरोसे की कमी, या कर्मचारियों को AI के output को बिना आलोचनात्मक सोच के स्वीकार करने से रोकना था
    या शायद उनका मानना है कि tests/migrations पर सख्त नियम न हों तो असली code टूट सकता है या data loss का जोखिम वास्तविक है

    • यह बात भी सही है, लेकिन मेरे अनुभव में कुछ बड़े मुद्दे सामने आए थे
      1. बाद में जब इंसानों ने generated tests को manually ठीक किया, तो बहुत गंभीर pitfalls मिले
      2. Claude context को ठीक से नहीं समझता, इसलिए वह लगभग हर चीज़ को mock कर देता है और ऐसे tests बनाता है जो हमारे service/build environment से पूरी तरह कटे हुए होते हैं
      3. और इससे भी बड़ी समस्या यह है कि पूरी team tests को लेकर बहुत आलसी हो जाती है
        वास्तव में production में bugs काफ़ी बढ़ गए थे