पहला प्रयास 95% बेकार: Claude Code के साथ एक Staff Engineer की यात्रा

 (sanity.io)
24 पॉइंट द्वारा GN⁺ 2025-09-03 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • एक Staff Engineer ने Claude Code का उपयोग करते हुए AI के साथ डेवलपमेंट वर्कफ़्लो पर 6 हफ्तों तक किए गए प्रयोग का अनुभव साझा किया
  • AI को ‘सीख न सकने वाले जूनियर डेवलपर’ के रूप में देखने की सोच सफल इंटीग्रेशन की कुंजी है
  • पहला प्रयास अक्सर 95% विफल होता है, लेकिन दोहराव की प्रक्रिया से यह धीरे-धीरे उपयोगी कोड में निखरता है
  • प्रोजेक्ट-विशिष्ट context file (Claude.md) और MCP-आधारित tool integration के जरिए AI के context की कमी की समस्या को हल किया गया
  • डेवलपर की भूमिका कोड लिखने से हटकर समस्या समाधान और architecture design की ओर शिफ्ट होती है, और यही AI उपयोग के दौर का नया productivity pattern है

पृष्ठभूमि और दृष्टिकोण

  • लेखक पहले सारा कोड खुद लिखते थे, लेकिन अब 80% कोड AI लिखता है और वे architecture, review, और multi-threaded development management पर ध्यान देते हैं
  • यह लेख 'AI नवाचार लाएगा' जैसी अतिआशावादी बात नहीं करता, बल्कि वास्तविक production development workflow में AI को integrate करते समय होने वाली उलझन और व्यावहारिक पद्धति साझा करता है
  • AI को ‘सीख न सकने वाला जूनियर डेवलपर’ मानकर चलना उसके सफल उपयोग की कुंजी है

डेवलपमेंट paradigm में बदलाव की प्रक्रिया

  • शुरुआती 5 सालों तक किताबों और SDK docs के सहारे डेवलपमेंट का तरीका बना रहा
  • उसके बाद 12 सालों तक search (google) आधारित सामूहिक ज्ञान के उपयोग की ओर बदलाव हुआ
  • पिछले 18 महीनों में Cursor के जरिए AI-assisted coding का प्रयोग किया गया
  • और हाल के 6 हफ्तों में Claude Code के जरिए व्यापक AI delegation से तेज़ बदलाव का अनुभव हुआ
  • Claude Code के साथ अनुकूलन में कुछ ही घंटों में productivity का असर महसूस होने लगा

वास्तविक AI-आधारित production workflow

  • production में जाने वाले कोड पर काम करते समय AI का उपयोग मुख्यतः "सोचने" के लिए किया जाता है
  • एक ही बार में परफ़ेक्ट कोड बन पाना संभव नहीं है। एक engineer के रूप में असली काम समस्या का सर्वोत्तम समाधान ढूँढ़ना है
    • पहला प्रयास (95% विफल): AI system context बनाता है और डेवलपर समस्या को परिभाषित करता है, लेकिन कोड लगभग पूरी तरह गलत होता है
    • दूसरा प्रयास (50% विफल): context की समझ बेहतर होती है और approach अधिक ठोस बनती है, फिर भी आधा परिणाम बेकार रहता है
    • तीसरा प्रयास (उपयोगी कोड): दोहराव और review के बाद वास्तव में इस्तेमाल लायक base code मिलता है, जिसे आगे सुधारा जा सकता है
  • यह प्रक्रिया विफलता नहीं, बल्कि जानबूझकर किया गया प्रयोग और iterative optimization process है

context की समस्या और समाधान

  • AI सेशनों के बीच memory बनाए नहीं रख सकता, इसलिए हर बार वही बातें दोहरानी पड़ती हैं
  • इसके समाधान के रूप में Claude.md file में architecture decisions, patterns, और documentation links दर्ज किए जाते हैं
  • MCP integration के जरिए Linear, Notion, GitHub, codebase, और database से जोड़कर context अपने-आप उपलब्ध कराया जाता है
    • Linear से ticket context दिया जाता है
    • Notion या Canvas से documents तक पहुँच मिलती है
    • non-production database से data structure की जाँच की जाती है
    • GitHub पर पुराने PRs की background information का उपयोग होता है

समानांतर Claude instances का संचालन और मुख्य रणनीतियाँ

  • कई Claude instances को parallel चलाते हुए इसे ऐसे संभाला जाता है जैसे ‘हर दिन memory खो देने वाली छोटी dev team’ को manage किया जा रहा हो
  • एक ही problem area पर parallelization न करना, सभी कामों को Linear जैसे project management tools में दर्ज करना, और मानव द्वारा सीधे बदले गए कोड को साफ़-साफ़ चिह्नित करना जैसी रणनीतियाँ बनाई गईं
  • सिर्फ कोड लिखने में नहीं, code review में भी AI का सक्रिय उपयोग होता है: test omissions, साफ़ bugs, और improvements जल्दी पकड़कर दोहराव वाले काम कम किए जाते हैं
  • कंपनी (Sanity) की policy के अनुसार, AI-जनित कोड की अंतिम गुणवत्ता की ज़िम्मेदारी engineer पर ही रहती है
  • AI और इंसान के कोड में फर्क न कर पाने वाले माहौल में भावनात्मक लगाव कम होता है और ज़्यादा आलोचनात्मक व वस्तुनिष्ठ code review संभव हो जाता है

3-स्तरीय code review process

  • कोड लिखना काम का एक हिस्सा है, लेकिन code review भी उतना ही महत्वपूर्ण है
  • पहला review: Claude की शुरुआती जाँच
    • test coverage में कमी और साफ़ bugs का पता लगाना
    • सुधार के सुझाव देकर साथियों के review समय की बचत
  • दूसरा review: मेरा review
    • maintainability, architecture, business logic, और integration की जाँच
    • AI-जनित कोड होने पर भी engineer की अंतिम ज़िम्मेदारी बनी रहती है
  • तीसरा review: टीम का सामान्य review
    • टीम को यह नहीं बताया जाता कि कौन-सा हिस्सा AI ने लिखा है। एक ही quality standard लागू होता है
    • भावनात्मक लगाव के बिना वस्तुनिष्ठ review संभव होता है
  • AI द्वारा लिखे गए कोड के प्रति भावनात्मक लगाव कम होने से अधिक वस्तुनिष्ठ review संभव होता है

Slack-triggered agent और work automation पर प्रयोग

  • Cursor के साथ Slack-integrated agent का pilot किया गया: सरल business logic बदलावों में सफलता मिली, लेकिन जटिल CSS layout में असफल रहा
  • अभी के समय में private NPM packages के लिए support नहीं, unsigned commits, और official tracking को bypass करने जैसी सीमाएँ मौजूद हैं
  • फिर भी, भविष्य में agent के रात भर simple repetitive tickets निपटाने की संभावना को लेकर उत्साह है

लागत और ROI

  • Claude Code के उपयोग की लागत कंपनी के लिए engineer पर किया जाने वाला काफ़ी बड़ा खर्च है
  • लेकिन इस निवेश से productivity gains मिले
    • feature release speed में 2~3 गुना सुधार
    • कई development threads को एक साथ manage करना संभव
    • repetitive और boilerplate code हाथ से लिखने की ज़रूरत कम
  • AI adoption के शुरुआती दौर में senior engineers के लिए प्रति माह $1000~1500 का budget चाहिए हो सकता है, और कौशल बढ़ने के साथ cost efficiency बेहतर होने की उम्मीद है

AI-assisted development की लगातार बनी रहने वाली समस्याएँ और सीमाएँ

  • learning problem: AI अपनी गलतियों से सीख नहीं पाता, इसलिए वही गलतफ़हमियाँ दोहराता है; समाधान है बेहतर documentation और ज़्यादा स्पष्ट निर्देश
  • trust problem: AI गलत कोड भी पूरे आत्मविश्वास से दे सकता है, इसलिए verification अनिवार्य है; खासकर जटिल state management, performance, और security वाले हिस्सों में अतिरिक्त सावधानी चाहिए
  • context limit problem: बड़े codebase AI की context window से बाहर चले जाते हैं, इसलिए समस्याओं को छोटे हिस्सों में बाँटना और साफ़ context देना ज़रूरी है

कोड से समस्या की ओर भावनात्मक बदलाव

  • कोड के प्रति आसक्ति छोड़कर problem-solving केंद्रित सोच की ओर बदलाव
  • गलत कोड को जल्दी हटाना, ज़्यादा वस्तुनिष्ठ review, और refactoring का कम बोझ => सकारात्मक बदलाव
  • अगर इससे बेहतर AI tools आते हैं, तो उन्हें तुरंत अपनाने की इच्छा है
  • मूल बात ‘कोड’ नहीं, बल्कि जिस समस्या को हल करना है उसकी उपयोगिता है

engineer के नज़रिए से AI adoption पर सलाह

  • 1. कई AI solutions पर प्रयोग की छूट दें: टीम को अलग-अलग tools खुद इस्तेमाल करके व्यावहारिक क्षमता बढ़ाने दें
  • 2. दोहराव वाले और सरल कामों से AI लागू करें: तेज़ असर मिलने की संभावना ज़्यादा है
  • 3. trial-and-error के लिए budget रखें: पहले महीने की अव्यवस्था स्वीकार करनी होगी
  • 4. review process को फिर से डिज़ाइन करें: AI code की प्रकृति के अनुरूप जाँच मजबूत करें
  • 5. पूरी documentation करें: अच्छा context productivity को कई गुना बढ़ाता है
  • नए AI workflow के अनुकूल होने वाले engineers यह समझेंगे कि उनके toolbox में एक नई तेज़ धार वाली छुरी आ गई है
  • AI workflow अपनाने वाले engineers कई AI agents को orchestrate करते हुए architecture, review, और जटिल problem-solving पर केंद्रित नई भूमिका की ओर विकसित होंगे

आपका अगला कदम

  • एक छोटा लेकिन अच्छी तरह परिभाषित feature चुनें,
  • AI को उस feature को implement करने के तीन मौके दें,
  • और परिणामों को ऐसे review करें जैसे आप किसी नए डेवलपर को mentor कर रहे हों
  • बस इतना ही। किसी बड़े बदलाव या process overhaul की ज़रूरत नहीं है
  • सिर्फ एक feature, तीन प्रयास, और ईमानदार review काफ़ी है
  • भविष्य AI द्वारा डेवलपर्स को replace करने का नहीं है
    • बल्कि डेवलपर्स के ज़्यादा तेज़ी से काम करने, बेहतर solutions बनाने, और सर्वश्रेष्ठ tools का उपयोग करने का है

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

5 टिप्पणियां

 
helio 2025-09-05

"अगर प्रक्रिया इतनी जटिल है, तो लगता है कि खुद ही सीधे code लिख लेना बेहतर है"
 
skageektp 2025-09-05

टीम के सदस्यों से काम करवाने के बजाय खुद ही सारा काम निपटा देने वाले टीम लीड का अंदाज़ हाहाहा
 
greenbhj 2025-09-05

ऐसा लग सकता है, लेकिन बिल्कुल भी ऐसा नहीं है.
पिछले 6 महीनों में छोटे और बड़े पैमाने पर बार-बार प्रयोग किए हैं.
 
iolothebard 2025-09-05

कोई छोटा लेकिन अच्छी तरह परिभाषित फीचर चुनें,
AI को उस फीचर को इम्प्लीमेंट करने के तीन मौके दें,
और नतीजों की समीक्षा ऐसे करें जैसे आप किसी शुरुआती डेवलपर को मेंटर कर रहे हों
अगर वह मेरे बिना यह कर सकता है तो यह “फ़ायदा” है… लेकिन अगर मुझे होना ही पड़े… तो फिर बस मैं ही करूँ, वही “फ़ायदा” है।
 
GN⁺ 2025-09-03
Hacker News टिप्पणियाँ

  • यह महसूस हुआ कि एजेंट की संज्ञानात्मक सीमाओं को ध्यान में रखकर निर्देश देना महत्वपूर्ण है; उदाहरण के लिए, बड़े बदलाव एक साथ न माँगें, पहले योजना बनवाएँ, फिर छोटे-छोटे चरणों में काम करवाएँ और हर चरण को टेस्ट करते हुए आगे बढ़ें। जटिल चरणों में समस्या और समाधान को विज़ुअलाइज़ करने वाला कोड लिखवाना भी उपयोगी है। अगर किसी चरण में विफलता हो, तो कोड में logging जोड़ें, logs सहेजें, टेस्ट चलाएँ और logs देखकर कारण समझने की प्रक्रिया को बार-बार दोहराना प्रभावी रहता है। अगर मौजूदा कोड की डिज़ाइन शैली के आधार पर मॉडल को यह समझाया जाए कि बदलाव कहाँ करने हैं, तो AI पूरे सिस्टम को एक ही फ़ाइल में ठूँसने से बच सकता है। मैंने कई लोगों के ऐसे टिप्स साझा करने वाले ब्लॉग देखे हैं; अभी भी यह परफेक्ट नहीं है, लेकिन कम से कम 95% तक बेकार नतीजे आने जैसा अनुभव नहीं रहा

    • मैं ये सब पहले से आज़मा रहा हूँ, फिर भी ज़्यादातर बार बेकार कोड ही निकलता है। जब कभी कुछ ठीक से चलता भी है, तब भी उसे उपयोगी बनाने के लिए अंत में मुझे खुद हाथ लगाना पड़ता है। सच है कि कभी-कभी यह बहुत अच्छा काम करता है और तब काफ़ी उत्साह होता है, लेकिन व्यक्तिगत रूप से मुझे दक्षता में कोई बड़ा सुधार महसूस नहीं हुआ
    • बड़े पैमाने के जटिल कामों में, "अभी तुरंत कोड मत लिखो। मैं हर चरण विस्तार से समझाऊँगा" जैसे निर्देश प्रभावी लगते हैं। उदाहरण के लिए, input पढ़ना, candidate बनाना, candidate scoring, priority और sorting, output data structure बनाना, DB में save करना—इस तरह चरणबद्ध रूपरेखा दी जा सकती है। Claude इन चरणों को TODO list और docs में व्यवस्थित कर देता है, जिससे बाद में उसी बिंदु से काम फिर शुरू करना आसान हो जाता है। वास्तव में, एक घंटा काम करने के बाद रुककर अगर उससे कहा जाए, “जो stage पूरे हो गए हैं उनका code generate करो और comments छोड़ दो ताकि अगली बार वहीं से जारी रखें,” तो लगातार काम करना आसान हो जाता है
    • कई LLM/एजेंट लंबे समय तक इस्तेमाल करने पर भी उपयोगी नतीजे निकालना अब भी कठिन है। बेकार output से बचने के लिए, खुद काम करने से भी ज़्यादा ऊर्जा prompt लिखने में लगानी पड़ती है, और prompt की wording या tone, या कोई अनचाही association न बन जाए, इस पर इतना ध्यान देना पड़ता है कि बेवजह बेचैनी होती है। अच्छा होगा अगर किसी अलग frontend framework की तरह LLM prompts को manage करने वाला कोई tool हो, जो सामान्य prompt संरचनाओं को व्यवस्थित करे या best practices को default रूप में लागू करे, ताकि code में कुछ ढूँढते समय, नई feature design करते समय या tests लिखते समय सोचने का बोझ कम हो
    • अगर प्रक्रिया इतनी जटिल है, तो फिर लगता है कि कोड खुद लिखना ही बेहतर है
    • व्यक्तिगत प्रोजेक्ट्स में AI और vibe coding आज़माने पर लगा कि test-driven development का तरीका vibe coding के साथ काफ़ी अच्छी तरह मेल खाता है। समस्या को छोटे, testable units में बाँटें, पहले AI से unit tests लिखवाएँ, फिर असली code implement करवाने का तरीका मैं सुझाऊँगा

  • अब समय आ गया है कि ऐसे लेख सिर्फ साधारण refactoring या React boilerplate की बात न करें, बल्कि वास्तव में ऐसे ठोस task examples शामिल करें जहाँ "एजेंट distributed processing कर रहा हो"। कहा जा रहा है कि Sanity में लंबे समय से माँगी गई कुछ features हैं और एजेंट उन पर काफ़ी काम parallelize कर रहा है। लेकिन "कोड का 80% ऐसे junior developer ने लिखा जिसने कुछ सीखा ही नहीं" जैसी बातें मानना मुश्किल है

    • मेरे हिसाब से "कुछ न सीखने वाला junior developer" वाला वर्णन ग़लत है। Claude ज़्यादा से ज़्यादा उस बहुत पढ़े-लिखे senior जैसा है जिसके पास असली field experience नहीं है और जो सिर्फ साहित्य/दस्तावेज़ों में लिखे सही जवाब जानता है। encyclopedic knowledge शानदार है, लेकिन व्यावहारिक समझ कम है। हाल में Claude के साथ commercial codebase बनाते समय देखा कि ज़्यादातर input 'कोड का स्वाद' और सफलता की परिभाषा पर केंद्रित होता है, और code खुद लगभग disposable होता है
    • AI-generated code इतना बढ़ रहा है, फिर भी open source में unresolved issues अब भी जमा हैं; यह काफ़ी विडंबनापूर्ण है
    • अगर AI को दिए गए वास्तविक कामों के उदाहरण और उनके नतीजे दिखाए जाएँ, तो बढ़ा-चढ़ाकर बनाई गई उम्मीदों पर सवाल उठाने का मौका मिलेगा। लेकिन ज़मीनी examples के बिना बस Claude Code की महानता वाली बातें ही बार-बार सामने आ रही हैं
    • जब किसी sales-जैसे engineer की technical blog post में "lessons" की जगह "learnings" जैसे शब्द दिखते हैं, तो लगता है कि यह उस रास्ते के उलट है जिस पर मैं चला हूँ—जैसे-जैसे developer career आगे बढ़ा, मैं Google search पर कम निर्भर हुआ और सिर्फ docs पर ज़्यादा ध्यान देने लगा

  • लेखक ने productivity बढ़ने की बात तो कही, लेकिन आमतौर पर बताई जाने वाली सीमाओं का भी वही ज़िक्र किया, इसलिए व्यावहारिक रूप से लगा कि इसमें कोई खास नई बात नहीं थी। मुझे पूरा यक़ीन है कि कोई भी core feature development Claude Code को पूरी तरह नहीं सौंपेगा

    • मुझे लगता है कि Anthropic की ओर से एक लेख है जो व्यवहार्य दिशा—खासकर prototyping-केंद्रित उपयोग—पर काफ़ी यथार्थवादी दृष्टिकोण देता है https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf

  • boilerplate से बचना developer का काम है, और वही भविष्य के अपने लिए सुविधा देने वाला abstraction भी होता है। अगर AI से boilerplate generate कराया जाए, तो बाद में जब हर instance को अलग-अलग बदलना पड़े, तब उल्टा असुविधा बढ़ जाती है, और अगर जगह-जगह बिखरा boilerplate code असंगत हो जाए तो समस्या और बड़ी हो जाती है

    • frameworks और tools में पहले से ही अधिकतर boilerplate generators मौजूद हैं, तो फिर AI पर tokens और लागत खर्च करके यह काम कराने में कितना बड़ा मूल्य है, इस पर संदेह होता है

  • दिलचस्प बात यह है कि यह व्यक्ति AI से बुनियादी implementation शुरू करता है, जबकि मैं इसका उल्टा करता हूँ—मैं आधारभूत ढाँचा पहले खुद बनाता हूँ। तभी मैं structure और working principles को सही तरह समझ पाता हूँ; उसके बाद AI को सिर्फ दोहराव वाले boilerplate काम सौंपता हूँ। AI नकल करके लिखने में अच्छा है, लेकिन architecture design में बहुत कमज़ोर है

    • LLM maintainable architecture की planning में बहुत कमज़ोर हैं। code के विकसित होने के साथ वे structure को refactor नहीं कर पाते, और context समझने की सीमा यहाँ एक बड़ी रुकावट हो सकती है

  • जब base salary पहले से ही महँगी है, तब उसके ऊपर हर महीने $1,000 से $1,500 अतिरिक्त खर्च करके उन छोटे-मोटे मुद्दों पर निवेश करने की बात, जहाँ productivity बढ़ेगी भी या नहीं यह निश्चित नहीं, संदेहास्पद लगती है। कम से कम मेरे बॉस को तो यह पसंद नहीं आएगा

    • hardware कंपनियाँ हर साल ऐसे कई EDA tool licenses खरीदती हैं जो developer salaries से भी महँगे होते हैं। अगर productivity सचमुच स्पष्ट रूप से बढ़ती है, तो $1,000 कोई बड़ी रकम नहीं है
    • अगर developers की salary इतनी महँगी है, तो निवेश न करना ही उल्टा अव्यावहारिक होगा। अगर महीने के $1k-$1.5k से productivity निश्चित रूप से बढ़ाई जा सकती है, तो हिचकिचाना ही अक्षम्यता है। इस नज़रिए से सिर्फ AI की लागत को अलग से देखना बहुत सरलीकृत दृष्टिकोण है। अगर AI की मदद से developers की संख्या घटाई जा सकती है, तो वह भी वास्तविक लागत-बचत है
    • मैं खुद IntelliJ Pro AI पर महीने के $20 भी मुश्किल से खर्च करता हूँ, इसलिए मुझे शक हुआ कि Claude सच में इतना महँगा है या नहीं; खोजने पर लगा कि हाँ, ऐसा हो सकता है। फिर भी हक़ीक़त यह है कि कहीं न कहीं किसी budget में AI subscription cost जुड़ ही रही है, और जैसे कंपनियाँ पहले से high-performance internet की लागत चुकाती हैं, वैसे ही AI की लागत भी अब एक बुनियादी खर्च बनती जा रही है
    • और यह भी याद रखना चाहिए कि यह pricing वास्तव में subsidy-आधारित है
    • आगे कंपनियाँ कैसे बदलेंगी, यह देखना दिलचस्प होगा। एक बात साफ़ है: आख़िरकार मुद्दा यह होगा कि developers को किन मानकों पर आंका जाएगा। क्या AI के उपयोग से performance review या layoffs जैसी चीज़ों में नुकसान उठाना पड़ेगा, और कोई यह कैसे साबित करेगा कि उपलब्धि का असली श्रेय उसी को है, न कि LLM को—यह महत्वपूर्ण प्रश्न है

  • लेख में बताए गए MCP(Multi-Channel Processor) उपयोग का तरीका ठीक से समझ नहीं आया। Claude Code तो shell में curl या gh जैसी चीज़ों के ज़रिए लगभग सभी third-party services को कॉल कर सकता है, लेकिन MCP इस्तेमाल करने पर उल्टा समस्या हो सकती है (उदाहरण: linear MCP server issue बहुत लंबा होने पर उसे काट देता है, जबकि direct API call में ऐसी सीमा नहीं होती)। लगता है शायद मैं कुछ मिस कर रहा हूँ

  • Anthropic ने Boris Cherny(Claude Code के निर्माता) के साथ एक इंटरव्यू पोस्ट किया है, जिसमें Claude Code के agent coding के भविष्य और उसके उपयोग के तरीकों पर विचार साझा किए गए हैं https://youtu.be/iF9iV4xponk

  • "$1000-1500/महीना budget" वाली बात देखकर लगा कि शायद वे सिर्फ API key का इस्तेमाल कर रहे हैं और claude MAX जैसे monthly plan के बारे में नहीं जानते। अगर बिना सोचे-समझे queries दोहराते न रहें, तो $100-$200/महीना काफ़ी होना चाहिए

    • $1k-$1.5k बहुत ज़्यादा लगता है। 20x Max plan भी $200/महीना में काफ़ी usage कवर कर देता है, और usage हर 5 घंटे में reset हो जाती है। इसके बावजूद अगर कोई रोज़ limit पार कर रहा है, तो हो सकता है उस स्तर पर token-based billing और भी महँगी पड़ने लगे

  • अगर Claude या किसी और एजेंट का इस्तेमाल करने वाले हैं, तो logging ज़रूर करने की ज़ोरदार सिफारिश है। पूरा log file AI में डालने पर समस्या को व्यवस्थित करके जवाब पाने या अगले चरण तक पहुँचने की संभावना बढ़ जाती है। logging सचमुच सब कुछ है