AI coding ने उजागर किया डेवलपर्स का दुख और विभाजन

• AI coding tools के प्रसार ने डेवलपर्स के बीच हमेशा मौजूद लेकिन न दिखने वाले प्रेरणा के अंतर को सतह पर ला दिया है
• code लिखने की शिल्पकारी से मिलने वाली संतुष्टि खोने का दुख और code के इर्द-गिर्द के ecosystem और career environment में बदलाव का दुख, दोनों अलग तरह की हानि की भावना हैं
• 1980 के दशक से programming कर रहे एक डेवलपर के नज़रिए से, AI coding, C64 BASIC से assembly, और function से system design तक जाती abstraction की स्वाभाविक निरंतरता है
• दशकों तक code पढ़ने और review करने का अनुभव, AI द्वारा बनाए गए code की quality को परखने वाली समझ और निर्णय क्षमता के रूप में अब भी वैध है
• आप किस तरह का दुख महसूस कर रहे हैं, इसे पहचानना सबसे अहम है; शिल्पकारी हानि और संदर्भगत हानि के लिए अलग-अलग प्रतिक्रिया तरीकों की ज़रूरत होती है

---

शोक की शुरुआत

• James Randall 1980 के दशक में 7 साल की उम्र से programming शुरू करने वाले डेवलपर हैं, और वे कहते हैं कि खोज की भावना तथा जिद के सहारे किसी चीज़ को समझ लेने का अनुभव "compressed" हो गया है
  • यह पूरी तरह गायब नहीं हुआ है, लेकिन compression की प्रक्रिया में कुछ खो गया है
• Nolan Lawson ने "We Mourn Our Craft" शीर्षक वाले लेख में इस हानि को और सीधे शब्दों में व्यक्त किया
  • हाथ से code गढ़ने का एहसास, रात 2 बजे debugger से bug पकड़ने का अनुभव, और "यह मैंने बनाया" कहने का गर्व—इन सबकी याद आएगी
• ये भावनाएँ वास्तविक हानि से जुड़ी सच्ची भावनाएँ हैं, लेकिन पढ़ते हुए लगातार यह लगा कि वे अलग-अलग चीज़ों का शोक मना रहे हैं

विभाजन की असली प्रकृति

• AI coding डेवलपर्स के बीच हमेशा मौजूद लेकिन कम दिखाई देने वाले विभाजन को उजागर कर रही है
• AI से पहले दोनों पक्ष एक ही तरीके से काम करते थे: वही editor, वही language, वही pull request workflow
  • शिल्प-केंद्रित डेवलपर और परिणाम-केंद्रित डेवलपर साथ बैठकर वही product ship करते थे, इसलिए उनमें फर्क करना मुश्किल था
  • काम की प्रेरणा दिखाई नहीं देती थी, क्योंकि process एक जैसी थी
• अब एक चौराहा आ गया है: machine को code लिखने देना और क्या बनाना है यह निर्देशित करना, या खुद हाथ से code लिखना
  • इसी चुनाव के क्षण में programming शुरू करने का मूल कारण पहली बार साफ़ दिखाई देता है
• university के दिनों में mathematics और computer science की classes में भी यही विभाजन था: कुछ लोग proof और theorem को ही पसंद करते थे, और कुछ की रुचि केवल जब उनका उपयोग application में होता था तभी जागती थी

मेरा दुख अलग था

• पिछले 18~24 महीनों में मैंने सचमुच दुख और अनुकूलन का दौर झेला
• मुझे डर था कि मैं नए tools को समझ नहीं पाऊँगा, लेकिन वास्तव में मैं उन्हें समझ पाया
• मुझे चिंता थी कि AI द्वारा बनाए गए code की quality परखने की क्षमता खो दूँगा, लेकिन दशकों तक code पढ़ने और review करने का अनुभव वाष्पित नहीं हुआ
  • जब कुछ गलत होता है तो मैं अब भी उसे पहचान सकता हूँ, और नज़र की पैनी समझ वैसी ही बनी हुई है
• मुझे डर था कि puzzle सुलझाने का आनंद खत्म हो जाएगा, लेकिन वास्तव में मैं बस एक स्तर ऊपर गया हूँ
  • C64 पर byte सजाने से लेकर function लिखने और फिर system design तक का career, हर बदलाव में यही पैटर्न दिखाता रहा है
  • अब puzzle architecture, configuration, और assistant को निर्देशित करने के क्षेत्र में खिसक गया है
• ज़्यादातर डर वास्तविकता से टकराकर टिक नहीं पाए, लेकिन कुछ दुख अब भी बाकी हैं

जो दुख अब भी बाकी है

• HTML को हाथ से लिखने का नहीं, बल्कि open web ecosystem के लिए दुख है
  • AI का commons पर training करना, और लोगों के internet अनुभव को आकार देने वाली ताकतों का और अधिक केंद्रीकरण, यही असली हानि है
  • यह समस्या व्यक्तिगत productivity बढ़ने से भी गायब नहीं होती
• career landscape में बदलाव का दुख
  • 30 साल से अधिक समय तक किया गया web development अब पहले जैसा hot field नहीं रहा
  • mobile app ने उसका एक हिस्सा ले लिया, और AI engineering अब प्रमुख स्थान पर है
  • मुझे लगता है कि मैं इस बदलाव में सफलतापूर्वक आगे बढ़ रहा हूँ, लेकिन बेचैनी असली है और अभी खत्म नहीं हुई
• इस दुख का सार यह है: code लिखने की क्रिया खुद याद नहीं आ रही
  • दुख इस बात का है कि code के आसपास की दुनिया बदल रही है
  • Randall और Lawson का दुख शिल्पकला स्वयं के लिए है, जबकि इस लेख का दुख संदर्भ और कारणों के लिए है

कोई भी पक्ष गलत नहीं है

• Kevin Lawver ने Lawson के जवाब में लिखे लेख में अतीत से चिपके रहने के बजाय शिल्पकला और जुनून को नई दिशा देने की बात कही
• इसे सिर्फ nostalgia बनाम pragmatism के रूप में देखने से आगे बढ़कर, अपने भीतर के दुख की किस्म को पहचानना व्यावहारिक रूप से अधिक उपयोगी है
• अगर आप शिल्पकारी हानि का शोक मना रहे हैं, तो "बस adapt कर लो" जैसा कहना पर्याप्त नहीं होगा
  • संभव है कि आपको वह संतुष्टि कहीं और ढूँढ़नी पड़े, या यह स्वीकार करना पड़े कि काम का एहसास बदल जाएगा
  • अब तक शिल्पकला से livelihood मिलना अपने आप में किस्मत थी
• अगर आप संदर्भगत हानि का शोक मना रहे हैं, तो अधिक क्रियाशील प्रतिक्रिया संभव है
  • नए tools सीखना, अपने पसंदीदा web के लिए काम करना—चाहे वह small web ही क्यों न हो—और दुखी रहते हुए भी अनुकूलित होना संभव है
• Nolan Lawson के शब्दों में: "मैं न इस नई दुनिया का जश्न मनाता हूँ, न उसका विरोध करता हूँ। सूरज उगता और डूबता है, और मैं असहाय होकर उसकी कक्षा में घूमता हूँ; मेरा विरोध उसे रोक नहीं सकता"
  • लेकिन दुख और डर के बीच भी थोड़ी-सी उत्सुकता महसूस होना एक ईमानदार स्वीकारोक्ति है

computer से काम कराना

• 1980 के दशक में programming शुरू करने के बाद से मैंने जो भी language सीखी, वह हमेशा उद्देश्य हासिल करने का साधन रही
  • computer से अपनी चाही हुई चीज़ करवाने का एक नया तरीका
• AI coding उसी निरंतरता का ताज़ा चरण है; कोई विच्छेद नहीं, बल्कि सीढ़ी की अगली पायदान
• लेकिन यह सीढ़ी खुद भी बदल रही है, और जिस इमारत पर यह टिकी है वह भी बदल रही है, इसलिए यह ठीक-ठीक कहना मुश्किल है कि हम कहाँ जा रहे हैं
• एक बात निश्चित है: किसी सोची-समझी चीज़ के सचमुच काम करने के क्षण की संतुष्टि 40 साल से अधिक समय में नहीं बदली
  • वहाँ तक पहुँचने के लिए code का रास्ता बदल गया है, लेकिन उसके काम करने का वह क्षण वही है

[github88]

काफ़ी ज़्यादा हंगामा मचा रहे हैं।

[ahwjdekf]

मुझे लगता है कि web programming जैसी चीज़ें AI कर दे, यह बहुत अच्छी बात है।

[brilliant08]

लगता है दूसरी programming में कोई उच्चतर मूल्य होता है।

[onetoday]

कभी-कभी मुझे लगता है कि HN की औसत उम्र काफ़ी ज़्यादा है और वहाँ ऐसे लोग हैं जो किसी तरह पीछे छूट रहे हैं।
इसलिए मैं ऐसी नकारात्मक पोस्टें (आलोचनात्मक नहीं) पढ़े बिना ही आगे बढ़ जाता हूँ।

वैसे, कभी-कभी खुद कोडिंग करने का मज़ा याद आता है,
और लगता है कि शायद वेब साइड में होने की वजह से यह थोड़ा ज़्यादा संभव है,
लेकिन मुझे कोड टाइप किए हुए 3 महीने से ज़्यादा हो चुके हैं।

सबसे बढ़कर, इस तरह डेवलप करना इतना मज़ेदार है कि बचपन की तरह मैं स्वेच्छा से देर रात तक काम भी काफ़ी करने लगा हूँ।

[snisper]

अगर AI की वजह से इतनी दिक्कत है, तो बस उसका इस्तेमाल न करें, है न?

[savvykang]

मुझे जिज्ञासा है कि जब RAD tools आए थे, तब लोगों की प्रतिक्रिया कैसी रही होगी।

[GN⁺]

Hacker News की राय

• मुझे लगता है कि लेख बात को पूरी तरह गलत समझ रहा है। ‘craft’ टाइप डेवलपर भी नतीजों पर ध्यान देते हैं, लेकिन वे ऐसे नतीजे चाहते हैं जो लंबे समय तक टिकें और स्केल हो सकें
  एक अच्छे प्रोग्रामर का लक्ष्य खुद को बेकार बना देना होता है। कभी ऐसा दौर था जब लोग assembly में cycles गिनते थे और bits पैक करते थे, लेकिन फिर compiler का इस्तेमाल स्वाभाविक हो गया। कभी CRUD ऐप हाथ से बनाए जाते थे, लेकिन अब framework वह काम कर देता है। memory management, type system, high-level language, no-code/low-code systems — ये सब प्रगति का हिस्सा हैं। आखिरकार programming का मकसद ही यह है कि कंप्यूटर वह काम कर दें जो हमें खुद न करना पड़े
  असली विभाजन, मेरे हिसाब से, उन लोगों के बीच सोच का फर्क है जो software को ऐसी चीज़ मानते हैं जिसे सुधारा और समझा जा सकता है, और उन लोगों के बीच जो इसे किसी और द्वारा बनाई गई अगम्य रुकावट मानते हैं
  • मुझे यह नज़रिया पसंद आया। सिस्टम्स के साथ लंबे समय तक काम करने पर हर detail मायने रखने लगती है। अंदाज़ा होने लगता है कि एक चीज़ बदलने से पूरे सिस्टम पर क्या असर पड़ेगा। लेकिन AI युग के software में मुझे डर है कि क्या इस तरह की समझ नामुमकिन हो जाएगी। बहुत सारा code अपने-आप generate होगा, इसलिए पूरे सिस्टम को समझना मुश्किल हो सकता है। अगर आखिरकार बदलना ही कठिन हो जाए, तो शायद AI से उसे फिर से बनवा लेना ज़्यादा तर्कसंगत लगे। इसलिए modularity और भी ज़्यादा अहम हो सकती है
  • मैं लगभग पूरी तरह सहमत हूँ, लेकिन आख़िरी वाक्य को छोड़कर। वह intelligence की समस्या कम, और इस बात की समस्या ज़्यादा है कि दूसरी श्रेणी के लोग अक्सर सचमुच कमज़ोर स्तर के होते हैं
  • मैं सोच रहा हूँ कि क्या यह भेद Pirsig के ‘classical vs romantic’ भेद जैसा है। पहले वाले structure और principles को समझना चाहते हैं, जबकि दूसरे लोग बाहरी रूप, एहसास और उपयोगिता को ज़्यादा महत्व देते हैं
  • “अच्छे प्रोग्रामर खुद को बेकार बना देते हैं” — यह बात पहले अक्सर सुनने को मिलती थी, लेकिन अब लगभग गायब लगती है
• असली विभाजन उन लोगों के बीच है जो मानते हैं कि तकनीकी प्रगति अपने-आप में अच्छी चीज़ है, और उन लोगों के बीच जो जानते हैं कि इतिहास में productivity बढ़ने से काम के घंटे कम नहीं हुए
  8 घंटे का कार्यदिवस तकनीक से नहीं, राजनीतिक संघर्ष से आया था
  • असली विभाजन पूंजी के मालिकों और मज़दूरों के बीच है। पूंजीपति मज़दूरों की पैदावार का एक हिस्सा विरासत में मिले कागज़ के टुकड़ों के दम पर खा जाते हैं
  • यह दिलचस्प है कि ऐसी चर्चा Hacker News पर ज़्यादा दिखने लगी है। अगर AI डेवलपर्स की जगह लेने लगे, तो हो सकता है कि समझदार और प्रेरित लोग राजनीतिक रूप से जागरूक हो जाएँ। इतिहास में जब कंपनियाँ बहुत बड़ी हो जाती हैं, तो अंततः उनके साथ राज्यों जैसा व्यवहार होने लगता है
  • बहुत ज़्यादा अतिवादी दावे हो रहे हैं। आखिरकार असली विभाजन विज्ञान-तकनीक का समर्थन करने वाले और उससे नफ़रत करने वाले लोगों के बीच है
• अब यह सिर्फ़ mechanical keyboard पर टाइप करना पसंद करने वाले लोगों की बात नहीं रह गई। असली फर्क उन लोगों में है जिन्हें सिस्टम को समझना और नए बनाना पसंद है, और उन लोगों में जो वह काम दूसरों पर छोड़कर सिर्फ़ नतीजा लेना चाहते हैं
  हालाँकि, अगर वह “दूसरा” इंसान हो, तो mentoring या माहौल बनाकर उस श्रेय को साझा किया जा सकता है
  • यह मज़ेदार है कि “असली विभाजन” हमेशा ‘मैं, जो बौद्धिक या नैतिक रूप से श्रेष्ठ हूँ’ बनाम ‘वे, जो घटिया हैं’ वाली कहानी में बदल जाता है
  • मुझे सिस्टम समझना और नए बनाना पसंद है, और साथ ही AI को दोहराए जाने वाले काम सौंपना भी अच्छा लगता है। तो क्या मेरे जैसे लोग होने ही नहीं चाहिए? मैं सहमत नहीं हूँ
  • डेवलपर्स के दो प्रकार होते हैं। Type A security, testing और CI तक बड़ी बारीकी से संभालता है, लेकिन user के नज़रिए से कभी-कभी बोझिल हो सकता है। Type B testing या deployment में कमज़ोर हो सकता है, लेकिन user experience को प्राथमिकता देता है। दोनों की ज़रूरत है। बस AI शायद पहले Type A के क्षेत्र को replace करेगा
  • यह कुछ “Claude, ज़रा यह वजन उठा दो” जैसा लगता है
  • हर व्यक्ति को मज़ा अलग जगह से मिलता है। मुझे puzzle सुलझाने की प्रक्रिया पसंद है। योजना से ज़्यादा तुरंत सूझे हल मुझे आनंद देते हैं
• AI से पहले दोनों तरह के लोग वही काम करते थे — वही editor, वही language, वही PR workflow। फर्क सिर्फ़ प्रेरणा का था। इसलिए कुछ लोगों को AI द्वारा code लिख देना पसंद आता है, और कुछ लोग दुखी हैं कि वही हिस्सा गायब हो रहा है जिसे वे सबसे ज़्यादा enjoy करते थे
  Kellan का लेख “Code has always been the easy part” भी इसी बात से जुड़ा है। हमारी पीढ़ी web से मिलने वाली agency की भावना की आदी होकर tech में आई थी
  • असली फर्क quality standards का है। कुछ लोग variable नाम तय करने में भी घंटों लगा देते हैं, और कुछ सोचते हैं “चल रहा है, बस काफ़ी है।” दोनों की अपनी कीमत है। लेकिन models जिस रफ़्तार से आगे बढ़ रहे हैं, उसमें पिछले साल के मानक से फैसला नहीं करना चाहिए। default output औसत होता है, लेकिन सही तरीके से इस्तेमाल करो तो कहीं बेहतर quality मिल सकती है
  • क्या Perl programming सौंदर्य की दृष्टि से आनंददायक नहीं थी? मुझे तो Perl संभालना गर्व की बात लगता था। मुश्किल से पढ़ी जाने वाली language पर महारत का आनंद अलग था
  • Perl में सचमुच आकर्षण था। unless जैसी syntax flow को स्वाभाविक ढंग से व्यक्त करने देती थी। लेकिन उसका विकास रुक गया, और लोगों ने उसे अलग-अलग तरीकों से बढ़ाया, जिससे नाज़ुक codebase बन गए
  • मुझे coding खुद में मज़ेदार नहीं लगती, लेकिन समस्या हल होने पर मिलने वाली संतुष्टि बहुत बड़ी होती है। लगता है कि इस तरह की सोच दिमाग़ की लचक बनाए रखती है
  • यह कोई binary बात नहीं है। मैं दोनों श्रेणियों का मिश्रण हूँ। AI मेरे काम की coding कर देता है, इसलिए घर पर मुझे पारंपरिक coding का आनंद लेने की फुर्सत मिल जाती है
• मैं परिणाम-केंद्रित हूँ। मैं नतीजे की quality को महत्वपूर्ण मानता हूँ। coding की प्रक्रिया से ज़्यादा मेरा जुनून तैयार product की गुणवत्ता को लेकर है। लेकिन आजकल के apps 15 साल पहले की तुलना में धीमे हैं और उनमें bugs ज़्यादा हैं। Claude app में भी कभी-कभी ऐसे buttons दिखते हैं जिन पर click ही नहीं होता
  AI coding productivity शायद सिर्फ़ 10% बढ़ाती है। असली bottleneck क्या बनाना है, यह समझने और दूसरों को मनाने की प्रक्रिया है। coding तो बस उसे समझने का एक साधन है
  • मैं भी AI का इस्तेमाल code लिखने से ज़्यादा जानकारी इकट्ठा करने और उसकी पुष्टि करने में करता हूँ। कई LLMs को reviewer बनाकर एक-दूसरे की आलोचना करवाता हूँ। जटिल business logic से निपटने में यह बहुत मददगार है। AI edge cases खोजने में भी उपयोगी है
  • मैं सहमत हूँ कि coding bottleneck नहीं है। AI 10x productivity देगा, यह बात समझ से परे है। मैं पहले से ही coding में तेज़ हूँ, इसलिए AI मुझे बहुत मदद नहीं देता। उल्टा अब quality से ज़्यादा speed पर ज़ोर डाला जाता है। टीम के लोग AI से हज़ारों lines निकलवा रहे हैं, और code quality तेज़ी से गिर रही है
  • लगता है आप code quality और product quality को मिला रहे हैं। ज़्यादातर समस्याएँ business decisions से पैदा होती हैं
  • अगर “सिर्फ़ नतीजा” ही मायने रखता है, तो फिर खुद करने के बजाय outsourcing क्यों नहीं कर देते — यह सवाल भी पूछा जा सकता है
• मुझे हाथ से HTML लिखे जाने वाले web की याद आती है। यह दुखद है कि वह DIY web ecosystem, जिसे लोग खुद बनाते थे, अब कंपनियों के मालिकाना AI tools से replace हो रहा है। अभी हम बीच के चरण में हैं, लेकिन open web का पतन तेज़ हो रहा है
• generative AI का उपयोग craftsmanship की निरंतरता में भी किया जा सकता है। open source code लाकर “यह ऐसे क्यों काम करता है?” पूछते हुए समझ-आधारित विकास किया जा सकता है
  • puzzle सुलझाने का मज़ा खत्म नहीं हुआ है, बस एक स्तर ऊपर खिसक गया है। अब पूरे सिस्टम की संरचना और उसके कारणों को डिज़ाइन करना ही कारीगर का क्षेत्र है
  • बेशक उसका नतीजा upstream में contribute भी करना चाहिए
  • सच कहें तो यह सब पहले search engines से भी किया जा सकता था
• तीनों scenarios बुरे हैं। ① कमज़ोर AI → महामंदी 2.0, ② उम्मीद के मुताबिक AI → कुछ गिने-चुने अति-धनवानों का एकाधिकार, ③ बेहद शक्तिशाली AI → मानव जाति का विनाश। आदर्श AI की मात्रा शून्य है
  फिर भी प्रतिरोध करने की कोशिश करनी चाहिए
  • मैं भी पहले ऐसा ही सोचता था, लेकिन अब AI boom के बाद की व्यावहारिक सीमाएँ देखकर लगता है कि बाज़ार जल्द ही खुद को सुधार लेगा। अभी की स्थिति AOL दौर के ज़्यादा क़रीब लगती है
  • असली intelligence सिर्फ़ text को tool calls में बदलना नहीं है, उसमें planning, criticism और creative problem solving भी शामिल होना चाहिए
  • असल में scenario 1 और 2 दोनों में फ़ायदा उन्हीं लोगों को मिलता है। 3 तो लोगों का ध्यान भटकाने के लिए खड़ी की गई कल्पना है
• startups में लंबे समय तक काम करने के बाद मैंने ‘craftsmanship’ वाली सोच छोड़ दी। उसकी जगह अब यह समझ आ गई है कि AI code review का न होना या बहुत बड़े PRs कितने ख़तरनाक होते हैं। यह craftsmanship नहीं, बल्कि accuracy और technical debt के प्रबंधन का सवाल है
  • समस्या ‘नतीजों पर ध्यान देने वाले’ लोग नहीं, बल्कि श्रेय लेने और काम से बचने वाले लोग हैं। उनका code टूट भी जाए तो वे तब तक किसी और project पर जा चुके होते हैं
  • मेरे अनुभव में ‘craftsmanship बनाम results’ से ज़्यादा महत्वपूर्ण है पूरी इमारत को सही ढंग से बनाने की समझ। AI अगर subcontractor की तरह कुछ हिस्से संभाले तो ठीक है, लेकिन अभी हालत यह है कि पूरा काम ही outsource कर दिया जाता है, इसलिए नतीजा बिखरा हुआ आता है
• डेवलपर्स दो तरह के होते हैं। एक वे जो coding से इतना प्यार करते हैं कि manager नहीं बनते, और दूसरे वे जो मौका मिलते ही manager बन जाते हैं। AI का फ़ायदा दूसरी श्रेणी को ज़्यादा मिलता है
  • जो लोग इंसानों के साथ अच्छे हैं, उन्हें manager बनना चाहिए। और एक तीसरी श्रेणी भी है — वे लोग जिन्हें system design पसंद है और implementation दूसरों को सौंपना पसंद है