प्रोग्रामर पहचान का संकट
(hojberg.xyz)- प्रोग्रामर की पहचान हाल में AI और LLM tools के आने से खतरे में है
- प्रोग्रामिंग संस्कृति की शुरुआत 1950 के दशक में MIT की hacker ethics से हुई थी, जहाँ कोड लिखने की प्रक्रिया को ही एक गहरी craft माना जाता था, और सूक्ष्म logic तथा problem solving में डूबना इसकी मुख्य value रही है
- लेकिन आज AI industry और LLM tools developers को सिर्फ़ specification लिखने वाले या operator में बदलना चाहते हैं, और सीधे कोड लिखने के बजाय natural language में निर्देश देने वाली "vibe-coding" शैली थोप रहे हैं
- LLM से बना code non-deterministic और inaccurate होता है, और developer द्वारा खुद code पढ़ने-लिखने की प्रक्रिया से मिलने वाली गहरी समझ और immersion को हटाकर codebase से उसका संबंध तोड़ देता है
- कंपनियाँ productivity बढ़ाने के नाम पर tool usage थोप रही हैं, और team collaboration व mentoring culture को AI के साथ interaction से बदलकर developers के बीच मानवीय जुड़ाव को कमज़ोर कर रही हैं
- प्रोग्रामिंग को केवल output नहीं बल्कि सोच और समझ की प्रक्रिया मानने वाला उसका मूल मूल्य खोता जा रहा है, और developers को अपनी skill, आनंद और पेशेवर पहचान बचाने के लिए इस बदलाव का विरोध करना चाहिए
प्रोग्रामर का सार और परंपरा
-
कोड लिखना केवल काम नहीं, बल्कि developer की पहचान का हिस्सा है; editor एक workshop भी है और एक पवित्र जगह भी, जहाँ skill निखरती है और व्यक्ति flow state में प्रवेश करता है
- Vim जैसे tools के ज़रिए सोच और code के बीच बिना रुकावट काम किया जाता है, और एक ऐसी अमूर्त दुनिया बनाई जाती है जो वास्तविक दुनिया को प्रभावित करती है
- puzzle सुलझाने की प्रक्रिया खुद पूरी तस्वीर से ज़्यादा महत्वपूर्ण होती है, और उँगलियों से buffer तक skill के प्रवाह में समय का अहसास खो जाता है
-
1950 के दशक के उत्तरार्ध में MIT में नई प्रोग्रामिंग संस्कृति पैदा हुई, जहाँ प्रयोगधर्मी और anti-establishment स्वभाव वाले hackers Flexowriter और TX-0 computer का उपयोग करते हुए perfect program का पीछा कर रहे थे
- "The Right Thing" की अवधारणा के इर्द-गिर्द elegant और concise code लिखना लक्ष्य था
- Tech Model Railroad Club के सदस्य machine language में डूबे रहते थे, digital magic सीखते थे, और जो ज्ञान पाते थे उसे दूसरे छात्रों के साथ साझा करने की संस्कृति बनाते थे
-
Building 26 की computing crucible में coding skill तपकर निखरी, और लगभग 70 साल पहले स्थापित यह संस्कृति आज भी developers के मन और machines में जीवित है
- शुरुआती hackers की विरासत एक गहरी और शारीरिक skill के रूप में बची हुई है, और इसी पर एक जुनूनी industry खड़ी की गई
- developers आज भी उसी विस्मय, उपलब्धि और puzzle सुलझाने की elegance से प्रेरित होते हैं
-
लेकिन प्रोग्रामर की पहचान बनाने वाले ये मुख्य मूल्य अब खतरे में हैं, और जो भविष्य कभी उजला और स्पष्ट दिखता था, वह अब अशुभ अँधेरे, धोखे और अनिश्चितता से ढक गया है
AI industry द्वारा नई पहचान थोपना
-
अरबों डॉलर की AI industry, Hacker News community, और LinkedIn पर LLM समर्थक दावा कर रहे हैं कि software development का भविष्य अब programming जैसा नहीं दिखता, और जो एक साल पहले meme जैसा लगता था, वह "vibe-coding" अब mainstream बनता जा रहा है
- developers से अपेक्षा की जा रही है कि वे code के बजाय Markdown में specification लिखें, और codebase के कोनों में भटकने, puzzle सुलझाने और रहस्य खोजने वाली गहरी immersion व skill की गहराई गायब हो रही है
- इसके बजाय, जब agents developers की तरफ़ से सोचते हैं, तब developers को बिखरे हुए cognition और context switching को स्वीकार करना पड़ता है; creative problem solving मशीन को दे दी जाती है और developer सिर्फ़ operator रह जाता है
-
कुछ developers इस बदलाव और "Specification Engineering" नाम की नई पहचान का स्वागत कर रहे हैं, और operator बनकर Steve Jobs की तरह "orchestra conduct" करने के विचार से उत्साहित हैं
- यह सवाल उठता है कि अगर coding में इतनी कम रुचि है तो वे programmer क्यों बने; शायद उन्होंने Woz और Jobs को ही गड़बड़ा दिया
- Prompt, Context, Specification "Engineering" programmers के लिए किसी उज्ज्वल और समृद्ध career का वादा करता नहीं दिखता
-
इसका मतलब है skill, mastery और labor के मूल्य में गिरावट, जहाँ developer की अनोखी abstract thinking क्षमता ऐसे क्षेत्र में धकेली जा रही है जहाँ उसकी ज़रूरत कम है, और जो जगह पहले से product managers और designers ने घेर रखी है
कंपनियों के भीतर बदलती power dynamics
-
जब कंपनियों के भीतर यह नई पहचान थोपी जा रही है, तो power dynamics बदल रही हैं; productivity को गलत जगह बढ़ाने की उन्मादी कोशिश में developers को लगातार अधिक ठोस तरीक़े से LLM इस्तेमाल करने के लिए मजबूर किया जा रहा है
- अनुकूलन न करो तो बाहर कर दिए जाओ, या फिर ऐसा product इस्तेमाल करो जो तुम्हारी अपनी बेकारता की घोषणा करता है, नहीं तो इस्तीफ़ा दो
- पहले शायद ही कभी management ने developer के tools को इतनी विस्तार से निर्देशित किया था
-
developers ने chef या carpenter की तरह अपने tools को curate और sharpen करने में हमेशा गर्व महसूस किया है; editor settings, dotfiles और dev environment को अपने सोचने के ढंग के अनुरूप personal बनाना इसका हिस्सा रहा है
- skill के हिस्से के रूप में toolset को personal बनाने के प्रति समर्पण रहा है, इसलिए रोज़मर्रा के काम से लगभग कटा हुआ management जब इसका आदेश देता है तो वह दख़ल जैसा लगता है
- दशकों तक corporate माहौल में अपेक्षाकृत विशेष दर्जा पाने वाले programmers के लिए यह narrative management को संतुलन फिर अपने पक्ष में झुकाने का नया तरीका देता है
LLM और programming languages के बीच मूलभूत अंतर
-
कुछ लोग LLM के प्रभाव की तुलना low-level language से high-level language में बदलाव से करते हैं, जैसे Assembly से Fortran तक, लेकिन यह कई मायनों में ग़लत तुलना है
- Fortran programming में जड़ें रखता था; उसने skill हटाने की कोशिश नहीं की बल्कि उसी पर निर्माण किया, और programming की precision व expressiveness को हटाने के बजाय उसे बढ़ाया
- Fortran input के लिए हमेशा सही result सफलतापूर्वक देता था, जबकि LLM की दुनिया में यह दोनों बातें सच नहीं हैं
-
computer और programming बहुत निराशाजनक हो सकते हैं, लेकिन कम-से-कम precision के मामले में उन पर भरोसा किया जा सकता था, और programming के ज़रिए वे वही करते थे जो उन्हें कहा जाता था
- computer की precision पर इस निर्भरता और भरोसे की वजह से, जब chatbot यह gaslight करता है कि उसने माँगा गया काम कर दिया है, तो उस पर विश्वास कर लेना आसान हो जाता है
-
LLM और उनका काम स्वभाव से ही inaccurate है; बड़ी language models की प्रकृति में भी और natural language में निर्देश देने के तरीक़े में भी गलतफ़हमी की गुंजाइश रहती है
- जो programmers non-determinism को नापसंद करते हैं, उनका इस approach को अपनाना दिलचस्प है, क्योंकि वे आमतौर पर predictability, composability, idempotence और stable integration tests को पसंद करते हैं
- LLM code इसका उल्टा, यानी असंगत अराजकता प्रस्तुत करता है
-
Dijkstra ने "On the foolishness of natural language programming" में कहा था कि यह मान्यता चुनौती दी जानी चाहिए कि natural language काम को सरल बना देगी; उन्होंने ज़ोर दिया कि formal text का लाभ यह है कि वैध होने के लिए उसे केवल कुछ सरल नियमों को पूरा करना पड़ता है
गहरी समझ और immersion का क्षय
-
AI-assisted development को कठोरता और bureaucracy के ज़रिए vibe-coding से अलग दिखाने की कोशिशें हो रही हैं, लेकिन यह मूल समस्या को नज़रअंदाज़ करती हैं
- LLM से बने code को आप उतनी बारीकी से नहीं पढ़ते जितनी अपने लिखे code या PR review के दौरान पढ़ते हैं; LLM coding में कुछ ऐसा अंतर्निहित है जो आँखों को सुस्त कर देता है
- आप बस ऊपर-ऊपर से देख लेते हैं, overwhelmed और bored महसूस करते हैं, और अगर CI pass हो जाए व program compile हो जाए, तो ख़तरनाक जालों को आँख मूँदकर स्वीकार कर लेते हैं
- आप यह भी नहीं देखते कि tests चलने के लिए configured हैं या नहीं, कहीं कोई non-existent library import तो नहीं की गई, या पूरी library को उसने खुद से फिर से implement तो नहीं कर दिया
-
किसी किताब की review या summary उसे सीधे पढ़ने के अनुभव की जगह नहीं ले सकती; सैकड़ों पन्नों में हर वाक्य को सावधानी से ग्रहण कर, विचारों पर ठहरकर सोचना ज़रूरी होता है
- उसी तरह AI द्वारा पूरे किए गए काम की summary पर नज़र फेरना domain, problem और possible solutions की गहरी समझ बनाने की प्रक्रिया छीन लेता है, और codebase से आपका संबंध तोड़ देता है
- अज्ञानता की गहराई में उतरकर विषय और उसके निहितार्थ खोलना, सीखना और समझना संतोषजनक भी है और अच्छे software के लिए अनिवार्य भी
- ownership, agency और गहरे संतोष देने वाला काम agents के tabs के बीच बिखरे ध्यान से बदल दिया जाता है
-
Joan Didion ने कहा था, "मैं यह जानने के लिए लिखती हूँ कि मैं क्या सोच रही हूँ, क्या देख रही हूँ, और जो देख रही हूँ उसका क्या अर्थ है," और Peter Naur ने "Programming as Theory Building" में इसी विचार को खोजा
- Naur का "Theory" codebase की समझ का साकार रूप है, जिसमें उसका काम करने का ढंग, formalism और वास्तविक दुनिया का उसका प्रतिनिधित्व शामिल है
- यह context और insight केवल immersion से मिलते हैं, और Naur ने "Theory" को software से ज़्यादा programming का मुख्य परिणाम और वास्तविक product बताया
- केवल अच्छी तरह विकसित "Theory" होने पर ही codebase में विस्तार और bug fixes प्रभावी ढंग से किए जा सकते हैं
-
अच्छा design immersion से निकलता है, और text buffer में आगे-पीछे के काम तथा अक्सर keyboard से दूर बिताए गए समय में आकार लेता है
- पूरा codebase एक साथ दिमाग़ में नहीं समा सकता, इसलिए modules, classes और functions में उतरकर धुँधले mental model को साफ़ करना पड़ता है
- code पढ़कर और लिखकर cognition को विस्तार देना होता है, और familiarity व problem domain की समझ को वापस पाना होता है
-
context का एक हिस्सा बन जाने और कई असफल कोशिशों के बाद अंततः समाधान मिल सकता है, और खराब design की विसंगति को महसूस करना ज़रूरी होता है
- जब आप भद्दा और repetitive code लिखते हैं तभी समझ आता है कि इससे बेहतर, अधिक concise, elegant, composable और reusable तरीका मौजूद है
- यह आपको रुककर समस्या के बारे में गहराई से सोचने, एक कदम पीछे हटने और फिर से शुरुआत करने पर मजबूर करता है
- इसके उलट AI agent का काम frictionless होता है, इसलिए वैकल्पिक solutions से बचा जाता है; आप यह भी नहीं जान पाते कि जो स्वीकार किया वह बेहतरीन था, साधारण था, भयानक था या नुकसानदेह भी
टीम collaboration और मानवीय जुड़ाव का विघटन
-
LLM-केंद्रित coding का cognitive debt skill erosion से आगे तक फैलता है; कम attention span वाले "slop-jockey" अपने output को pull requests और design docs में फेंकते हैं, जिससे collaboration बाधित होती है और team का काम बिगड़ता है
- code review करने वाले सहकर्मी इस चौंकाने वाली सच्चाई से जूझ रहे हैं कि वे अब आख़िरी quality-control layer नहीं, बल्कि पहली layer बन गए हैं
- उन्हें नई जोड़ी गई लेकिन कभी call न की गई functions, hallucinated libraries, और स्पष्ट runtime या compile errors तक इंगित करने पड़ते हैं
- लेखक, जिसने अपने code को शायद बस ऊपर-ऊपर देखा है, ज़िम्मेदारी नहीं लेता और कह देता है, "Claude ने ऐसा लिखा था। बेवकूफ़ AI, haha"
-
हस्तक्षेप करने वाले managers और पैसे बचाने वाले executives team में मानवीय interaction घटाने के लिए दबाव बना रहे हैं, शायद अनजाने में
- अलग-थलग और जुड़ाव से वंचित हालत में, अब लोगों को अपने काम के अनुभव के चारों ओर दीवारें खड़ी करने के लिए अधिकार भी दिया जा रहा है और प्रोत्साहन भी
- pair programmer की ज़रूरत हो, solution पर चर्चा करनी हो, prototype बनाना हो, architecture sketch करना हो, या codebase के पेचीदा हिस्सों पर किसी expert से सवाल पूछना हो—इन सबमें लोग इंसान की जगह LLM पर निर्भर होने लगते हैं
- अब onboarding buddy, mentor या colleague की ज़रूरत नहीं मानी जाती; उसकी जगह आप मशीन से बात कर सकते हैं
- LLM के सहारे human contact से बचना इतना आसान हो गया है कि यह नया standard बन सकता है
प्रोग्रामर पहचान की रक्षा
-
यह चौंकाने वाला है कि हम AI hype narrative के सामने कितने आज्ञाकारी हो गए हैं, skills को योजनाबद्ध ढंग से मिटाने में सक्रिय भागीदारी कर रहे हैं, और सोचने के अपने साधनों को कितनी सहजता से छोड़ रहे हैं
- हम उन भाग्यशाली लोगों में थे जो अपने शौक़ से रोज़ी कमा पाए, लेकिन अब slop का जवाब देने के लिए चाहे कितनी भी कठोर और सूक्ष्म process बना लें, हम फिर भी काम के मज़ेदार हिस्से को outsource कर रहे हैं और उसकी जगह निर्देशात्मक ऊब ला रहे हैं
-
LLM software complexity के लिए कक्षा से गिराया गया परमाणु बम जैसा समाधान लगते हैं; वे असली समस्या हल करने के बजाय लक्षणों के इलाज के लिए कहीं अधिक जटिल और धुँधली चीज़ की तरफ़ हाथ बढ़ाते हैं
sedको Claude से बदल देना, या किसी library या framework पर जवाब माँगना, जबकि documentation में घंटों खोजने के बाद भी स्पष्टता न मिली हो—यह ठीक है- लेकिन केवल operator या code reviewer बन जाना, और मज़ेदार व दिलचस्प काम से पीछे हट जाना स्वीकार्य नहीं है
-
ऐसे tools पसंद हैं जो repetitive काम में मदद करें, codebase समझने में मदद करें, और सही program लिखने में सहारा दें; लेकिन मेरी जगह सोचने के लिए बनाए गए products असहज करते हैं
- मैं ऐसे products को ठुकराता हूँ जो मेरे द्वारा बनाए गए software की समझ पर मेरी agency छीन लेते हैं और सहकर्मियों से मेरा जुड़ाव काट देते हैं
- भले ही LLM hype पर खरे उतरें, हम तब भी यह सब और अपनी skill खो देंगे
- इंसान मशीनों और उन्हें support करने वाली कंपनियों से अधिक महत्वपूर्ण हैं, जबकि वे मुनाफ़ा कमा रहे हैं और बाकी हम उनके बेचे जा रहे नए American Dream का पीछा कर रहे हैं
- बदले में हम अपनी critical thinking, आनंद, skill, privacy, और शायद इस ग्रह तक को दे रहे हैं
3 टिप्पणियां
कुल मिलाकर सहमत हूँ
खासकर context switching? prompt भेजकर इंतज़ार करने के दौरान फोकस टूट जाता है और productivity घटती है। अगर LLM की speed बढ़कर तुरंत response आने लगे, तो शायद इसका समाधान हो सकता है
ऐसा काफ़ी महसूस होता है कि लेख ने शुरुआत से ही निष्कर्ष तय कर लिया था और उसी दिशा में लिखा गया है। डेवलपर से ownership के हटने की समस्या, LLM से अलग, मुझे "कारीगर मानसिकता का युग बनाम औद्योगीकरण का युग" की कहानी के रूप में पढ़ी जाती है।
Hacker News राय
मेरे लिए सबसे प्रभावशाली बात यह रही कि code reviewers अब quality control का आख़िरी चरण नहीं, बल्कि पहली defense line बन गए हैं—और यह समझते-समझते उनकी मानसिक हालत बिगड़ती जा रही है। review request आता है, लेकिन अब उन्हें नई जोड़ी गई ऐसी functions पकड़नी पड़ती हैं जिन्हें कहीं call ही नहीं किया गया, अचानक जोड़ी गई libraries, साफ़ runtime या compile errors वगैरह एक-एक करके ढूँढने पड़ते हैं। code author ज़िम्मेदारी से बचते हुए बात को “यह Claude ने लिखा था, AI से गलती हो गई, haha” कहकर टाल देता है। LLM आने के बाद Brandolini's law (बकवास को खारिज करने में उसे बनाने से कहीं ज़्यादा ऊर्जा लगती है) पहले से कहीं ज़्यादा सच लगने लगी है। जब कम अनुभवी या कम कुशल developers कुछ ही मिनटों में हज़ारों lines का code उगल देते हैं, तो system की सेहत की असली ज़िम्मेदारी code reviewers पर डाल दी जाती है। PR के added/removed LoC delta को देखें तो LLM-लिखे PR लगभग सिर्फ़ code जोड़ते ही जाते हैं, जबकि अनुभवी senior engineers अक्सर जितना नया code जोड़ते हैं, उतना पुराना code हटाते भी हैं
मेरे हिसाब से यह technical problem नहीं, people problem है। एक बार ऐसा हो तो कड़ी चेतावनी देनी चाहिए, और दूसरी बार दोहराया जाए तो manager के पास भेजकर reject कर देना चाहिए। PR किसने लिखा, यह मायने नहीं रखता; आख़िर में उस output पर आपका नाम होता है, इसलिए code खराब है तो ज़िम्मेदारी भी आपकी ही है
मैं अब बड़े teams में code review नहीं करता, लेकिन अगर मैं ऐसी स्थिति में होता, तो इस तरह की ज़िम्मेदारी-टालने वाली बात एक बार तक शायद छोड़ देता, पर बार-बार हो तो उस व्यक्ति को बाहर करने की कोशिश करता। अगर वह संभव न हो, तो मैं खुद नौकरी छोड़ देता। माहौल इतना भयानक है
मुझे लगता है कि इन दिनों मेरी productivity गिरने का एहसास भी इसी से जुड़ा है। एक तरफ़ ज़्यादा code और तेज़ी से पैदा करने का दबाव है, और दूसरी तरफ़ agents जैसी चीज़ों का इस्तेमाल करने पर अपने लिखे code का पूरा context ठीक से समझ नहीं आता। मैं quality की गारंटी सिर्फ़ उतनी ही दे सकता हूँ जितना मैं line by line बहुत ध्यान से review कर पाऊँ, और यही सीमा है। इसलिए आजकल मैं AI को ज़्यादा धीरे, ज़्यादा conservatively इस्तेमाल करता हूँ, और अपने हाथ से लिखे code का हिस्सा बढ़ा रहा हूँ। साफ़ type definitions या किसी spec को कई properties पर दोहराकर लागू करना हो, तो AI कुछ मदद करता है, लेकिन तब भी output हमेशा भरोसेमंद नहीं होता
जितने ज़्यादा अनुभवी senior engineers होते हैं, उतनी ही संभावना होती है कि वे जितना code जोड़ते हैं उतना पुराना code काटते भी हैं। Negative 2,000 Lines Of Code भी पढ़ने लायक है
जैसे ही LLM शामिल होता है, हम ज़िम्मेदारी किस पर डालते हैं—यह एक बड़ा सामाजिक सवाल बन जाता है। लोग नतीजा अच्छा हो तो श्रेय खुद ले लेते हैं, और बुरा हो तो आसानी से AI पर दोष डाल देते हैं। ऐसे culture में बस कुछ सही lawsuits आ जाएँ, तो मुझे लगता है चीज़ें काफ़ी बदल जाएँगी
लंबे समय से मुझे लगता रहा है कि industry में आने वाले बहुत से लोग code को craftsmanship की तरह नहीं, बल्कि आसान पैसे कमाने के साधन की तरह देखते हैं। open source infrastructure developers की जीविका चलाना मुश्किल होने वाली बातें पढ़ने से लेकर, café में coding करने वाले developers, bootcamp या “बस code सीख लो” आंदोलन, Leetcode grinders, San Francisco में महँगे घरों के कारण कार में रहने वाले developers—और अब AI से खुद को automate करके अपनी ही नौकरी ख़त्म हो जाने की बात—यह सब इसी का हिस्सा है। समस्या यह है कि developers को सचमुच professionals की तरह नहीं देखा जाता। standards ढीले हैं, कोई ethics code नहीं, skills का कोई consistent baseline नहीं, और न ही proper representation है। हालत यह है कि industry के लोग अपने ही हितों के खिलाफ़ भी पर्याप्त agency नहीं रखते। lawyers के पास bar association है, doctors के पास medical association, लेकिन developers के पास सिर्फ़ अस्तित्वगत असुरक्षा है। अब bosses खुलेआम धमकाते हैं, “AI से automate करके तुम्हारी job हटा देंगे।” दूसरी professions अपने हितों के प्रति इतनी शत्रुतापूर्ण नहीं होतीं; तो फिर इस industry में ही ऐसा क्यों है, यह सवाल मैं खुद से पूछता हूँ
मेरे हिसाब से “coder” और software engineer अलग चीज़ें हैं। सिर्फ़ bootcamp करके Python में छोटे programs लिख लेने से कोई software engineer नहीं बन जाता। जब मैं कहता हूँ कि मेरे पास degree है, तो लोग उसे elitism कह देते हैं, और यह भी कहते हैं कि computer science में जो पढ़ाया जाता है उसका real-world काम में कोई उपयोग नहीं। लेकिन यह भी सच है कि degree के बिना भी कुछ लोग अपने दम पर बेहतरीन engineers बने हैं। फिर भी, किसी न किसी तरह के standards की ज़रूरत है—इससे मैं सहमत हूँ। किसी bootcamper को latest buzzword unicorn startup join करने पर बस बधाई देनी चाहिए, लेकिन Therac-25 जैसे संवेदनशील systems कम-से-कम formally trained लोगों को ही संभालने चाहिए
boss का यह कहना कि “अगर automate नहीं किया तो तुम्हारी नौकरी चली जाएगी”? वही तो हमारा काम है। labor को automate करना हमारे काम की प्रकृति का हिस्सा है, और अपनी ही workplace को automate करने का सबसे ज़्यादा मौका और समझ भी हमारे पास ही होती है
मुझे teaching profession में developers जैसी कुछ समानताएँ दिखती हैं। कुछ teachers शानदार होते हैं, कुछ बहुत खराब, और बहुत से बीच में आते हैं। सिर्फ़ subject जानना, अच्छी teaching की गारंटी नहीं है। शायद developers को मशीनों को सिखाने वाले teachers की तरह भी देखा जा सकता है। कोई उन्हें character by character, thought by thought सिखाता है, तो कोई पूरे mood या vibe से
LLM को कुछ देर किनारे रखें तो कभी-कभी मैं ऐसा code लिखता हूँ जिस पर मुझे सचमुच गर्व होता है। structure से लेकर हर line तक, कोई फ़ैसला बिना कारण नहीं होता; उस code में मैं expert होता हूँ और उसे पूरी तरह समझता हूँ। लेकिन ज़्यादातर code मैं ऐसे नहीं लिखता। अक्सर मानसिकता बस यह होती है कि “काम पूरा हो जाए”, और मैं अपने लिए थोड़ा नीचे standard स्वीकार कर लेता हूँ। फिर भी, कभी-कभी जब पूरी तरह डूबकर कुछ बनता है, तो वह बेहद संतोषजनक होता है और मेरे जीवन के सबसे अच्छे coding अनुभवों में से एक होता है। LLM को इसमें जोड़कर देखूँ तो एक तरफ़ high-quality coding आसान हुई है, लेकिन उतनी ही मुश्किल भी। मानसिक रूप से गहराई में उतर पाऊँ, तो LLM का अच्छा इस्तेमाल करके मैं तेज़ और ऊँचे standard का result बना सकता हूँ। मैं LLM के लिखे code से बहुत बेहतर code लिख सकता हूँ, लेकिन LLM की मदद से उससे भी बेहतर code भी लिख सकता हूँ। दिक्कत यह है कि उस deep focus को बनाए रखना दिन-ब-दिन मुश्किल हो रहा है। LLM के बनाए code को बस ऊपर-ऊपर देखकर, visuals अच्छे लगें और वह चलता हुआ दिखे, तो उसे आगे बढ़ा दिया जाता है। लेकिन ऐसे सरसरी तौर पर पास किया गया code धीरे-धीरे गड़बड़ होता जाता है, और जब तक लगातार इस तरह सुस्त होकर उसे पास करते रहते हैं, तब तक बहुत देर हो चुकी होती है। नतीजा यह होता है कि आप खुद उस code के expert नहीं बन पाते, और बस ढीला-ढाला code जमा होता जाता है
यह essay मुझे बहुत पसंद आया क्योंकि यह मेरे अपने विचारों से लगभग पूरी तरह मेल खाता है। मैंने company में AI इस्तेमाल करने की कोशिश की, लेकिन ज़्यादातर मामलों में output इतना कमजोर था कि आख़िर में लगभग सब कुछ मुझे खुद फिर से लिखना पड़ा। बेवजह सोचने का समय या problem solving AI को सौंप देना मेरे career के लिए सबसे बुरा फ़ैसला होगा—अब मुझे इस पर यक़ीन हो गया है। AI बस medium-quality text generator है
“आख़िर वे लोग programmer क्यों बने, जबकि उन्हें code में खुद कोई रुचि दिखती ही नहीं?” इस सवाल पर मैं यह ज़ोर देना चाहता हूँ कि लक्ष्य problem solving है। coding एक साधन है, अपने आप में लक्ष्य नहीं। “editor settings, dotfiles, development environment के साथ छेड़छाड़” मज़ेदार हो सकती है, लेकिन मैं उसे बेकार complexity मानता हूँ और ख़ुशी से delegate कर दूँगा
editor, dotfiles, और development environment को खुद set up करना दरअसल अपने काम के माहौल से परिचित होने, tools पर पकड़ बनाने, और ज़्यादा productive environment तैयार करने का हिस्सा है। जब build script छेड़नी हो तो जो “उसी को बुलाओ” वाला व्यक्ति बनता है, उसके पीछे यही maintenance होती है। दस-बीस साल Git इस्तेमाल करने के बाद भी merge conflicts या basic usage न समझने वाले लोग बहुत ज़्यादा हैं; नतीजा यह है कि tools को सच में सीखने वाले लोगों पर ही सारे झंझट वाले काम आ गिरते हैं
“इसकी कोई value नहीं” जैसी बात, अगर तर्क को अंत तक ले जाएँ, तो आख़िर में “फिर अस्तित्व की ही क्या value है” तक पहुँच सकती है
दुनिया की लगभग हर नौकरी problem solving के लिए है, लेकिन फिर इतने सारे professions में से software ही क्यों चुना—यह सवाल तो फिर भी बनता है
“problem solving लक्ष्य है, coding सिर्फ़ साधन” इस बात से मैं 100% सहमत हूँ। AI अगर coding कर दे तो जो लोग दुखी होते हैं, वे शायद “code artist” जैसे लोग हैं, जो क्या बनाया जा रहा है उससे ज़्यादा उसके “form” से जुड़े होते हैं। मैं problem पर केंद्रित रहने वाला इंसान हूँ, इसलिए AI अगर coding कर दे तो मुझे उसमें कोई दुख नहीं
“coding लक्ष्य नहीं, साधन है” और “editor से खेलना मज़ेदार है लेकिन मूल्यहीन है”—ये सब बेहद subjective बातें हैं। problem solving न भी रहे, तब भी बहुत लोग coding को सिर्फ़ coding के लिए पसंद करेंगे; अगर दुनिया में एक भी problem न हो, तब भी कई लोग coding का आनंद लेंगे
यह लेख पढ़कर सचमुच दिलचस्प लगा। LLM programming को लेकर मेरी भावनाओं से यह लगभग पूरी तरह मेल खाता है। मैं तो बस coding पसंद होने की वजह से यह काम करता था, और पेशे के रूप में भी इसका आनंद लेता था। लेकिन अब लगता है कि काम में अपने उसी शौक़ को जगा ही नहीं पा रहा हूँ। यह पूरी तरह अलग तरह का काम बन गया है
मेरी उम्र थोड़ी ज़्यादा है। 1995 के आसपास मैं आज से बिल्कुल अलग माहौल में programming करता था। तब engineers target customers, tech stack, industry trends—सब जानते थे, और सच में नियंत्रण उन्हीं के हाथ में था। अपना code उनका अपना playground था; वे चाहें तो उसे पूरी तरह बदल दें, indentation या braces style तक खुद तय करें (टूटे तो खुद ठीक भी करें)। unit tests जैसी चीज़ें नहीं थीं (तब parameter checking जैसी सीमित चीज़ें होती थीं), formal code reviews भी बहुत कम थीं, और colleagues के साथ दफ़्तर में गपशप करते हुए whiteboard पर चीज़ें बनाना ही आम था। bug मिले तो बस तुरंत ठीक कर दिया जाता था। आख़िर में management जीत गया, और अब लगता है कि उस तरह का “cowboy coding” युग फिर लौटना मुश्किल है। 90s का Apple याद आ सकता है, लेकिन अब वहाँ लौटना संभव नहीं। तब सच में बहुत मज़ा था
मैंने भी लगभग उसी दौर में शुरुआत की थी, लेकिन हमारे यहाँ ISO 9001 की वजह से नियमित code reviews होते थे। outputs को printer से निकालकर तीन लोग एक कमरे में बैठते, हर line देखते और sign करते। यह industrial control RTOS पर किया जाता था। project management के लिए 40-foot का Gantt chart print करके दीवार पर लगाया जाता था। पूरी तरह waterfall का ज़माना था
मैंने 2000s के आख़िरी वर्षों में शुरुआत की थी, और तब career paths और specialization की सीमाएँ कहीं ज़्यादा स्पष्ट थीं। system administrators और developers साफ़ तौर पर अलग होते थे, लेकिन अब मुझसे systems operator जैसी ज़िम्मेदारियों की भी उम्मीद की जाती है, इसलिए काम का दायरा उल्टा और बढ़ गया है। systems skills मैंने शौक़ में सीखी थीं, लेकिन असली काम में जब करना पड़ता है तो vendor documentation और training इतनी खराब मिलती है कि मन करता है इससे दूर भागूँ
पूरी industry फिर से cowboy coding में नहीं लौटेगी, लेकिन कुछ environments में यह शैली अब भी बची रहेगी—ऐसा मुझे लगता है। WhatsApp में 2011–2019 के बीच काफ़ी खुला माहौल था। हर environment में pre-production में error पकड़ने की लागत और production के बाद उसे ठीक करने की लागत अलग होती है, इसलिए सही approach भी बदलती है। मैं व्यक्तिगत रूप से error fix की लागत कम रखने वाले approach को पसंद करता हूँ। हाँ, इसके साथ यह भी मानता हूँ कि शर्मनाक ग़लतियाँ न हों, और ज़रूरी tests ज़रूर किए जाएँ
अब business mindset वाले, vibe coders, और script kiddies इतने ज़्यादा आ गए हैं कि सब कुछ खराब हो गया है
cowboy coding की समस्या यह है कि टीम में एक भी अविश्वसनीय सदस्य पूरी टीम को डुबो सकता है। जैसे-जैसे organization बड़ा होता है, खराब members का आना लगभग तय हो जाता है, और विस्फोट रोकने के लिए बड़े safeguards चाहिए होते हैं। भरोसे पर चलने वाली छोटी, elite teams में cowboy coding सबसे efficient हो सकती है, लेकिन hiring में candidates की क्षमता को सही परखना इतना कठिन है कि बड़े संगठनों के लिए यह बिल्कुल उपयुक्त नहीं। आगे भी शायद यह सिर्फ़ छोटी companies या बड़ी companies के भीतर छोटे teams में ही किसी रूप में बची रहे
लेखक की यह बात कि "<i>LLM software complexity पर लक्षित अंतिम nuclear-weapon जैसी solution है। यह असली समस्या हल करने की बजाय उससे भी बड़ी complexity लाकर symptoms को शांत करने की कोशिश करती है</i>"—मुझे इससे सहमत होना मुश्किल लगता है। AI अपनाने का असली लक्ष्य “creative और महँगे highly skilled talent” को AI बनाने वाली मुट्ठीभर कंपनियों में centralize करना है, और बाकी सभी कंपनियों में creative workers को निकालकर सिर्फ़ साधारण कर्मियों को छोड़ देना है। यानी हर business की complexity को AI के ज़रिए सरल बनाना इसका मकसद है। "The Wizard of Oz" की तरह, लोग परदे के पीछे क्या है यह नहीं देखना चाहते; उन्हें बस अपना काम आसान चाहिए। long-term risk को नज़रअंदाज़ करके short-term gains उठाने की प्रवृत्ति से यही होता है
यह लेख मुझे बहुत पसंद आया। कुछ लोग कहते हैं कि problem solving, code से ज़्यादा महत्वपूर्ण है—इससे मैं भी सहमत हूँ। लेकिन मेरे हिसाब से अगर हम गहरी सोच माँगने वाली problems भी AI को सौंपने लगें, तो समय के साथ वही deep problem-solving क्षमता ही कमजोर हो सकती है। सिर्फ़ “कुछ बनाकर दे दो” कहना असली problem solving नहीं है