59 पॉइंट द्वारा GN⁺ 2025-08-25 | 12 टिप्पणियां | WhatsApp पर शेयर करें
  • AI टूल Claude Code सिर्फ एक साधारण code generator नहीं है, बल्कि ऐसा productivity tool है जो सहकर्मी को काम सौंपने जैसा अनुभव देता है
  • यह दोहराव वाले implementation के बजाय system design, product thinking, communication जैसी मानवीय क्षमताओं पर ध्यान केंद्रित करने के लिए माहौल देता है
  • parallel work, multi-step debugging, और GitHub integration के ज़रिए कम लोगों की टीम भी बड़ी development team स्तर का output दे सकती है
  • हालांकि, ज़रूरत से ज़्यादा tests लिखना या साधारण काम को ज़रूरत से ज़्यादा करना जैसी सीमाएँ और व्यवहारगत विशेषताएँ मौजूद हैं, जिन्हें उपयोगकर्ता को संभालना होगा
  • नतीजतन, यह डेवलपर की भूमिका को implementer से conductor की ओर ले जाता है और junior developer training, senior productivity, तथा non-developer द्वारा project execution तक व्यापक संभावनाएँ खोलता है

AI द्वारा लिखा गया code और डेवलपर की बदलती भूमिका

  • पिछले दो महीनों में लिखा गया सारा code इंसान ने नहीं, बल्कि Claude Code ने सीधे लिखा है
    • उपयोगकर्ता implementation के बजाय architecture design और desired outcome तय करने पर ध्यान देता है
    • बार-बार होने वाली और बारीक typing धीरे-धीरे अनावश्यक होती जा रही है
  • इस प्रक्रिया में डेवलपर का मूल्य product planning, systems thinking, aesthetic judgment की ओर शिफ्ट हो रहा है

multi-step debugging क्षमता

  • queue job failure की समस्या में Claude Code ने external library के हज़ारों lines of code का विश्लेषण कर कारण खोज निकाला
    • development environment और production environment में queue name mismatch की समस्या हल की
  • यह ऐसा उदाहरण है जिसमें सामान्य डेवलपर को कई घंटे या कई दिन लगने वाली समस्या कम समय में हल हो गई

orchestra conductor की तरह काम करना

  • कई Claude Code instances को parallel चलाकर एक साथ कई features develop किए जा सकते हैं
    • हर काम अलग git worktree में होता है, जिससे conflicts नहीं होते
  • डेवलपर खुद code लिखने के बजाय काम को निर्देशित और review करने वाले manager की भूमिका निभाता है
  • इससे थकान या focus कम होने पर भी काम प्रभावी ढंग से आगे बढ़ सकता है

रोज़मर्रा के उपयोग और कम friction

  • Cursor, Copilot जैसे IDE-आधारित tools से अलग, Claude Code किसी एक खास environment से बंधा नहीं है
  • यह CLI, git, tmux जैसे मौजूदा developer workflow के साथ सहज रूप से जुड़ता है
  • मुख्य commands:
    • /issues → GitHub issue बनाना
    • /work → issue-आधारित development और PR बनाना
    • /review → PR review और सुधार
  • इससे research, implementation, review process में friction कम हो जाता है

सीमाएँ और इसकी कार्यशैली

  • कभी-कभी यह tests बहुत ज़्यादा लिख देता है या साधारण काम को अनावश्यक रूप से जटिल बना देता है
  • अगर यह गलत दिशा में बढ़े, तो इसे तुरंत रोका जा सकता है
  • इसकी खास बात यह है कि यह repetitive style fixes जैसे वे काम भी खुशी से करता है जिन्हें डेवलपर टालना चाहते हैं

junior developers और learning

  • junior developers, Claude Code को ऐसे mentor की तरह इस्तेमाल कर सकते हैं जिससे लगातार सवाल पूछे जा सकें
    • "मेरे PR में क्या समस्याएँ हैं?"
    • "Python और Ruby के approach में क्या अंतर है?"
    • "हर language में कौन-सी pitfalls और सावधानियाँ हैं?"
  • इससे growth की speed और वास्तविक काम में योगदान, दोनों काफ़ी बढ़ जाते हैं

वास्तविक workflow उदाहरण

  • सुबह 9 बजे: bug report को Claude Code को देना → reproduce करना और GitHub issue अपने-आप बनाना
  • 9:20 बजे: 4 tabs में अलग-अलग काम parallel करना (bug fix, PR review, changelog लिखना, background task की जाँच)
  • 10 से 11 बजे: हर PR अपने-आप बनना, जिसमें documentation और error handling शामिल हो
  • 11:30 बजे: इंसान final review करके UX और code style को ठीक करे
  • 11:45 बजे: customer feedback का विश्लेषण कर उसे अपने-आप issues में बदलना

निष्कर्ष और किसके लिए उपयुक्त

  • दो लोगों की टीम हर महीने $400 खर्च करके बड़ी टीम स्तर का output हासिल कर रही है
  • किनके लिए उपयुक्त:
    • वे senior developers जो implementation के बजाय strategy और quality पर ध्यान देना चाहते हैं
    • वे team leads जो ज़्यादा परिणाम चाहते हैं
    • non-developer founders और शुरुआती developers
  • शुरुआत महीने के $20 subscription से की जा सकती है, और असली projects Claude Code को सौंपकर देखना learning curve घटाने की कुंजी है
  • coding का भविष्य खुद implementation करने के बजाय नतीजों को निर्देशित करने और delegation की ओर बढ़ रहा है

12 टिप्पणियां

 
kaydash 2025-08-27

इंसान तो लड़ते हैं, लेकिन प्रोग्राम नहीं लड़ते और ज़्यादा तार्किक होते हैं..

 
bluekai17 2025-08-27

मुझे लगता है कि सिर्फ worktree का सही इस्तेमाल भी काफी अच्छा है।

 
bhjun 2025-08-25

ऐसा करने के लिए तो Pro बिल्कुल भी काफी नहीं होगा।
मैं एक non-developer के तौर पर iOS ऐप बना रहा हूँ, और Pro में limit बहुत जल्दी आ जाती है।
हर बार 2 घंटे भी पूरे नहीं होते और काम खत्म हो जाता है.

दूसरी तरफ, लगता है कि limit तक पहुंचना ही काम खत्म करने का सही समय भी है...
(आज के लिए यहीं तक,,, ऐसा सा फील lol)

 
bluekai17 2025-08-27

अगर $100 वाला इस्तेमाल करें तो फिर भी काफ़ी आराम रहता है। मैं non-developer तो नहीं हूँ, लेकिन app development पहली बार कर रहा था, इसलिए मैंने इसे एक महीने तक इस्तेमाल करके देखा। अभी तक मैंने लगभग $566.93 खर्च किए थे।

 
fanotify 2025-08-26

सुबह 2~3 घंटे इस्तेमाल किया तो लंच से पहले ही limit लग गई (Pro user)
कहा जा रहा है कि 3 बजे से reset होगा, लेकिन Max नहीं है तो लगता है पूरे दिन इस्तेमाल नहीं कर पाएंगे (हालांकि Max में भी limit तक पहुंचना इतना मुश्किल नहीं होगा, ऐसा लगता है)

 
neodasida 2025-08-25

लगता है जैसे 2 घंटे का ऑटोमैटिक पोमोडोरो हो, हाहा

 
click 2025-08-25

$20 वाले pro plan में, जिस तरीके की सब लोग सलाह देते हैं—पहले plan mode में उसे detail plan बनाने के लिए analyze कराना और फिर edit mode में जाना—सिर्फ़ ऐसे चलाने पर भी जल्दी limit तक पहुंच जाता है.
कोड quality वाकई बेहतर हो जाती है, लेकिन ऐसा लगता है कि शुरुआत से ही सीधे edit mode में शुरू करने की तुलना में token खपत कम-से-कम तीन गुना तेज़ है.

 
hanay 2025-08-25

फ़्री प्लान में इसका इस्तेमाल नहीं किया जा सकता, सही?

 
bluekai17 2025-08-27

अगर 100 डॉलर वाला इस्तेमाल करें, तो शायद किसी तरह कवर हो जाएगा।

 
helio 2025-08-25

$20 में भी यह वैसे करना मुश्किल है। अगर आप इस तरह लिखना चाहते हैं कि "पिछले दो महीनों में लिखा गया सारा कोड किसी इंसान ने नहीं, बल्कि Claude Code ने सीधे लिखा है",
तो क्या पहले $200 खर्च नहीं करने पड़ेंगे, और limit लगने पर फिर से $200 और खर्च करने पड़ेंगे?

 
muroa96 2025-08-26

मैं भी 100 डॉलर वाला इस्तेमाल कर रहा हूँ। कोड लिखने से पहले मैं Plan को Opus मॉडल पर तैयार करता हूँ, और असली coding के लिए Sonnet का इस्तेमाल करता हूँ। पिछले करीब दो महीनों में लगभग सारा कोड (कम से कम कई हज़ार lines) Claude Code ने सीधे लिखा है, और limit लगने की नौबत लगभग कभी नहीं आई। जब गलती से Opus से कोड लिखवाया हो, उसे छोड़ दें तो ऐसा लगभग कभी नहीं हुआ।
फ़िलहाल मैं हाल ही में आए Opus Plan Mode का इस्तेमाल कर रहा हूँ, और इसे इस्तेमाल करने के बाद से Approaching limit की चेतावनी भी लगभग दिखाई नहीं देती।

 
progdesigner 2025-08-25

मैं पहले से ही बिल्कुल इसी तरह काम कर रहा हूँ~
अगर कम्युनिटी में वोट कराया जाए
तो लगता है कि 80-90% लोग इसी दिशा में बदल रहे हैं