15 पॉइंट द्वारा GN⁺ 2026-02-09 | 14 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM-आधारित code generation tools का बार-बार उपयोग करने के बाद, लेखक ने खुद कोड लिखते समय मिलने वाला flow और आनंद फिर से खोजा
  • कोड लिखना सिर्फ़ एक उत्पादकता वाली गतिविधि नहीं, बल्कि problem space को समझने और सोच को परिष्कृत करने की प्रक्रिया है, और auto-generation इसमें बाधा डालता है
  • ऐसे कोड की शुद्धता जाँचना जिसे आपने खुद नहीं लिखा है कठिन होता है, और संदर्भ को भीतर तक समझना केवल खुद लिखते समय ही संभव होता है
  • LLM का सीमित उपयोग करके संदर्भ को मैन्युअली देना और उसे केवल आंशिक code edits तथा test generation के लिए इस्तेमाल करना, सोच पर अपनी पकड़ बनाए रखने में मदद करता है
  • यह लेख उत्पादकता से अधिक सोच की गहराई और खुशी को प्राथमिकता देता है, और ज़ोर देता है कि अगर कोई tool सोच में बाधा डालता है तो उससे सावधान रहना चाहिए

LLM code generation के उपयोग का अनुभव और उससे पैदा हुई शंका

  • लेखक ने कई बार claude-code इस्तेमाल किया, लेकिन हर बार उदासी और निष्क्रियता महसूस की और अंततः उसे हटा दिया
    • auto-generated code “ठीक-ठाक दिखता” था, लेकिन इससे अपने काम के अर्थ का एहसास कम हो जाता था
    • हर बार tool का उपयोग बंद करने पर लेखक ने फिर से coding का आनंद पाया
  • coding सिर्फ़ implementation नहीं, बल्कि problem space को explore करने और असफलताओं से सीखने की प्रक्रिया है
    • किसी API को सच में समझने के लिए उसे खुद इस्तेमाल करना पड़ता है; सिर्फ documentation पढ़ना काफ़ी नहीं
    • कोड लिखने की क्रिया खुद सोच को ठोस रूप देने का साधन है

सोच और शुद्धता का संबंध

> "अगर आप लिखे बिना सिर्फ़ सोचते हैं, तो आप केवल यह भ्रम पालते हैं कि आप सोच रहे हैं।" - Leslie Lamport

  • ऐसे कोड की शुद्धता जाँचना जिसे आपने खुद नहीं लिखा है, कहीं ज़्यादा कठिन है
  • खुद लिखने की प्रक्रिया में समस्या का संदर्भ भीतर तक बैठ जाता है, और यह code quality को समझने के लिए ज़रूरी है
  • LLM पर निर्भर रहने से यह प्रक्रिया छूट जाती है, जिससे problem domain की समझ कमज़ोर पड़ती है

‘Vibe coding’ की लत और उसके दुष्प्रभाव

  • LLM code generation में तुरंत dopamine reward देने वाली लत जैसी विशेषता होती है
    • यह भ्रम पैदा होता है कि “बस prompt थोड़ा और बदल दूँ तो सही हो जाएगा”
  • यह तरीका सोच की जड़ता बढ़ाता है, दिमाग़ को निष्क्रिय बनाता है, और साधारण कामों के लिए भी LLM पर निर्भरता बढ़ा देता है
    • उदाहरण के तौर पर, एक साधारण find-and-replace काम भी LLM को देने पर ज़्यादा समय लगा
  • चाहे generated code कितना भी अधिक हो, अंततः review और समझने की ज़िम्मेदारी इंसान की ही रहती है, और यही उल्टा bottleneck बन सकता है

tools किस तरह सोच को आकार देते हैं

  • “tools तटस्थ नहीं होते” इस दृष्टिकोण से, जो tool सोच में बाधा डाले, वह बुरा tool है
    • knowledge workers की मुख्य क्षमता गहराई से सोचने की क्षमता है, और जो तकनीक इसे बाधित करे उससे सावधान रहना चाहिए
  • फिर भी, लेखक LLM को पूरी तरह नकारने के बजाय, इसे इरादतन और सीमित तरीके से इस्तेमाल करता है
    • ज़रूरी files कॉपी करके संदर्भ दिया जाता है, और इसका उपयोग केवल code के कुछ हिस्सों में बदलाव या test लिखने के लिए किया जाता है
    • इससे generated बदलावों का दायरा छोटा रहता है, और codebase की समग्र संरचना को खुद समझा जा सकता है
    • यह निष्क्रिय generation नहीं बल्कि ‘thoughtful generation’ में बदल जाता है, जिससे दिमाग़ की सक्रियता और flow state बनाए रखना संभव होता है

खुशी और उत्पादकता के बीच संतुलन

  • ज़िंदगी छोटी है, इसलिए खुशी को प्राथमिकता देनी चाहिए
    • पूरे feature को auto-generate करने से उत्पादकता बढ़ सकती है, लेकिन अगर उससे अस्तित्वगत बेचैनी और उदासी पैदा होती है, तो लंबे समय में वह अलाभकारी है
  • लेखक मानता है कि आप उसकी भावनाओं से सहमत भी हो सकते हैं और नहीं भी,
    “अलग तरह से चुनने से मत डरिए”

14 टिप्पणियां

 
nimgnos 2026-02-09

कैलकुलेटर होते हुए भी कुछ लोग हाथ से हिसाब करना या मानसिक गणना करना पसंद करते हैं।

 
su79eu7k 2026-02-09

जब मैं बहुत ज़्यादा जटिलता वाले और business logic के लिए core हिस्सों को खुद हाथ से लिखकर उन पर गहराई से सोचता हूँ, और फिर उस प्रक्रिया को AI engineers तक पहुँचाता हूँ, तो मुझे सावधानी से ऐसा लगता है कि शायद यह productivity में मददगार हो सकता है। गणितज्ञ भी calculator जैसे tools का इस्तेमाल करते हैं, लेकिन जब वे core ideas पर सोचते हैं तो बहुत नोट्स भी बनाते हैं, है न।

 
naruchingu 2026-02-10

आज ऐसी दुनिया है जहाँ मोबाइल से बस एक शॉट में फोटो ली जा सकती है, लेकिन फिर भी कोई कई घंटों तक चित्र बना सकता है। मुझे लगता है कि यह सिर्फ़ प्रक्रिया और दिशा का अंतर है, सही या गलत का सवाल नहीं।

 
wkdehf555 2026-02-09

लेकिन यह तो बस इतना ही लगता है कि वे कंपनियों जिस दिशा का पीछा कर रही हैं, उससे सीधे टकराने की बात कर रहे हैं..

 
dolsangodkimchi 2026-02-09

व्यक्तिगत खुशी और संतुष्टि के आदर्श का सम्मान करता हूँ, लेकिन श्रम देकर उसके बदले पैसे पाने वाले पेशे के नज़रिए से यह एक अनुचित mindset लगता है.

 
foriequal0 2026-02-09

अगर कोई दीर्घकालिक metrics को नज़रअंदाज़ करके सिर्फ़ अल्पकालिक metrics का ही पीछा कर रहा हो, तो भले ही उसका आपसे कोई संबंध न हो, फिर भी गुजरते हुए मन में यह कहने का मन करेगा, "ऐसे नहीं करते, tsk tsk"।
लेकिन अगर वह programmer खुद को ऐसा व्यक्ति मानता हो जो कंपनी के साथ सुख-दुख बाँटते हुए बड़ा योगदान दे रहा है और कंपनी में महत्वपूर्ण भूमिका निभा रहा है, तो उसके मन में ऐसा विचार और कितना ज़्यादा आएगा।

 
geeksk553 2026-02-09

असल में, जो डेवलपर सच में बहुत अच्छे होते हैं और जिनके पास असली स्किल होती है, वे vibe coding का आनंद लेते हैं...

यह मेरी बात नहीं है (जैसे Linus Torvalds या Robert Martin)

 
dieafterwork 2026-02-10

मैंने तो इसे सिर्फ Python scripts में ही इस्तेमाल किया था। यह कहना शायद मुश्किल है कि मुझे इसमें सचमुच मज़ा आता था।

 
cocofather 2026-02-10

Linus Torvalds पर लेख खोजकर देखा तो लगता है कि उन्होंने इसे शौक के तौर पर इस्तेमाल किया था, और Linux development में अभी तक इसका इस्तेमाल नहीं किया है।

 
GN⁺ 2026-02-09
Hacker News की राय
  • कोडिंग की तुलना बढ़ईगिरी से की गई है। मशीनें फर्नीचर बना सकती हैं, फिर भी कुछ लोग आज भी हाथ से बनाते हैं। हाथ से कोड लिखना भी उसी तरह आनंद के लिए किया जा सकता है, लेकिन आगे चलकर पेशे के रूप में यह कठिन हो सकता है

    • यह तुलना पूरी तरह सही नहीं लगती। इलेक्ट्रिक आरी इंसान-नेतृत्व वाली centaur technology है, लेकिन GenAI इसके उलट इंसान-सहायक reverse-centaur technology है। इलेक्ट्रिक आरी इंसान की जगह नहीं लेती, लेकिन AI टीम का आधा हिस्सा कम कर सकती है
    • बढ़ईगिरी में एक ही उत्पाद बार-बार बनाया जाता है, लेकिन कोड दोहराया नहीं जाता। ज़्यादातर प्रोजेक्ट्स में bottleneck requirements जुटाने या design में होता है, इसलिए हाथ से कोडिंग और AI कोडिंग के बीच productivity का फ़र्क सीमित है
    • पूछा गया कि natural language→code बदलाव क्या high-level language→assembly बदलाव जैसा है। Brooks की ‘essential complexity’ गायब हो रही है, और standardized patterns की वजह से AI अस्पष्ट इरादों को executable code में बदलने वाले दौर में पहुँच रही है। अंततः experts की value बढ़ेगी, लेकिन standard engineers की demand घटेगी
    • यह सवाल उठाया गया: “अगर हम अब पेशेवर रूप से हाथ से कोड भी न लिख सकें, तो हमें वेतन किस बात का मिलेगा?” क्या हम सिर्फ ग्राहक-सामना करने वाले लोग या LLM prompt writer बनकर रह जाएंगे?
    • अगर हाथ से कोडिंग को अब मूल्यवान नहीं माना जाएगा, तो यह दुखद होगा। यह अब भी आनंददायक है, लेकिन मूल्य में गिरावट चुभती है
  • मैं लंबे समय में सबसे तेज़ और सबसे अच्छे नतीजे देने वाला तरीका चुनता हूँ। अभी neovim और हाथ से कोडिंग वही भूमिका निभाते हैं। खुद टाइप करते हुए प्रोजेक्ट को गहराई से समझना लंबे समय में फ़ीचर तेज़ी से देने में मदद करता है। जो काम सीखने में मदद नहीं करते, उन्हें मैं LLM को दे देता हूँ, लेकिन ऐसे काम काफ़ी हैं इसलिए LLM का उपयोग भी बहुत होता है

    • “गहरी समझ लंबे समय में गति बढ़ाती है” — यह नज़रिया प्रभावशाली लगा
    • मैं भी इसी तरह काम करता हूँ। टीम से कहता हूँ कि 6 महीने नहीं, 2 साल बाद के लिए optimize करना चाहिए
    • जहाँ सीखने का मौका है, वही काम मैं खुद करता हूँ; बाकी को जितना हो सके automate करना चाहता हूँ
    • कई agents इस्तेमाल करने पर context switching बहुत बढ़ जाता है, और उल्टा पूरा संदर्भ खोने जैसा लगता है
  • vibecoding की समस्या यह है कि “अच्छा लग रहा है” वाली भावना असली परिणामों को धुंधला कर देती है

    • कुछ लोगों को ही यह अच्छा लगता होगा; मुझे तो समस्या और कोड की गहरी समझ में आनंद मिलता है
    • “vibe doc पढ़ना” अच्छा है, लेकिन vibe coding में कोड बहुत verbose और over-abstracted हो जाता है, समझना मुश्किल होता है, और उस पर अपना नाम लगाने में हिचक होती है
    • योजना बनाने के बाद भी आखिर में फिर से शुरुआत से करना पड़ता है — यह निराशाजनक है
    • यह पहचानना कठिन है कि productivity सच में बढ़ी है या सिर्फ ऐसा महसूस हो रहा है
    • Windows Copilot के साथ प्रयोग किया, लेकिन वह धीमा था और quality भी कम थी, इसलिए कोई आनंद नहीं मिला
  • एक व्यंग्यात्मक सवाल उठाया गया: “क्या खुश होने से code output 200 गुना बढ़ जाता है?”

  • AI की value साफ़ है। उदाहरण के लिए, 300-column DB table को Rust struct में बदलते समय, 15 शब्दों के prompt से 900 lines का code बना दिया। ऐसे repetitive कामों में AI बेहतरीन है। लेकिन मैं सब कुछ उसे नहीं सौंपना चाहता। मैं इसे सिर्फ जितना उपयोग सुखद लगे उतना ही इस्तेमाल करता हूँ

    • ऐसा तरीका खराब schema या design को सुधारने से रोक सकता है
    • Python में code generation script लिखना बेहतर लग सकता है। AI कभी-कभी field names को हल्का बदल देती है, इसलिए reliability की समस्या है
    • इंसान के कॉफ़ी पीते हुए कोड लिखने में लगने वाली energy cost AI से कहीं ज़्यादा है
    • AI का उपयोग dopamine addiction जैसा महसूस होता है
  • मुख्य सवाल है: “जब LLM मेरे लिए code लिख रही हो, तब मैं क्या करूँ?” LLM को पूरी तरह छोड़ा नहीं जा सकता; साथ खड़े होकर देखभाल करनी पड़ती है। junior developers बढ़ते हैं, लेकिन LLM सीखती नहीं। इसलिए mentoring का संतोष गायब-सा लगता है

    • मैं एक साथ कई agents चलाकर feature development, bug fixing, और docs update करता हूँ। काम अब भी बहुत है, यह doomscrolling नहीं है
  • जिज्ञासा है कि आजकल developer hiring कैसे बदल गई है। क्या LLM का उपयोग allowed है, या अब भी हाथ से कोड लिखने की अपेक्षा की जाती है?

    • बड़ी कंपनियों में बदलाव अभी धीमा है। legal ownership issues की वजह से वे AI-generated code इस्तेमाल करने में हिचकती हैं
    • आगे चलकर हाथ से कोडिंग और AI कोडिंग दोनों की मांग होगी। hiring हमेशा की तरह बस एक और gate जोड़ देगी
    • mid-sized companies hiring रोक रही हैं या सिर्फ AI इस्तेमाल करने वाले developers को रख रही हैं। बड़ी कंपनियाँ अब भी Leetcode और system design पूछती हैं
    • ज़्यादातर कंपनियाँ अभी तक LLM cheating की सीमा को ठीक से समझ नहीं पाई हैं
  • मैं LLM आने से पहले ही model-driven development (MDD) के ज़रिए vibecoding जैसी गति से development कर रहा था। data model ही application है, और LLM उसके ऊपर procedures बस थोड़ा तेज़ लिख देती है। data model की दिशा अब भी मैं ही तय करता हूँ

  • AI coding को तीन हिस्सों में बाँटा जा सकता है

    1. ऑनलाइन पहले से मौजूद code की खोज
    2. पूरी तरह नया code, जहाँ AI सिर्फ typing assistant है
    3. repetitive और boilerplate-heavy code generation — यह framework की विफलता है
    • AI जिन कामों में अच्छी है, वे शायद वही काम हों जो हमें करना ही नहीं चाहिए। असली चुनौती उस भाषा को खोजना है जो हमारी इच्छित चीज़ों को सुंदर ढंग से व्यक्त कर सके
    • frameworks आगे नहीं बढ़ पाए, और LLM हर समस्या को हथौड़ा समझने वाला औज़ार बन गई है
  • आधुनिक समाज button क्लिक करके dopamine पाने वाली संरचना में बदलता जा रहा है। इसलिए सब कुछ बिखरा हुआ महसूस होता है

    • यह कटाक्ष किया गया कि slot machine अब ultimate UX बन चुकी है
 
redline2151 2026-02-09

आजकल बार-बार ऐसी पोस्टें आ रही हैं जिनमें लोग बस खुद को तसल्ली देकर पीछे छूटते डेवलपर होने को सही ठहराते हैं। वैसे भी ज़माने के बहाव को रोका नहीं जा सकता।

 
cjm01115 2026-02-09

यह तो हद से ज़्यादा हो गया है।

 
geeksk553 2026-02-09

मैं भी इस राय से सहमत हूँ कि भले ही कोई व्यक्ति हाथ से कोड लिखने पर अड़ा रहे, फिर भी जब तक वह अकेले बिज़नेस नहीं कर रहा है
उसे बदला जाना तय है, लेकिन लगता है कि उसे यह बात पता नहीं है।

 
hmmhmmhm 2026-02-09

अरे, ये तो कुछ ज़्यादा ही harsh है T_T