कोड सस्ता है। अब ‘बात’ दिखाओ
(nadh.in)- LLM coding tools के आने से दशकों से चली आ रही software development की बुनियादी धारणा ही ढह गई है, और code लिखने से ज़्यादा समस्या को परिभाषित करने और structure design करने की क्षमता मुख्य skill बन गई है
- अब development का केंद्र ‘अच्छा code लिखने की क्षमता’ नहीं, बल्कि समस्या की कल्पना कर उसे स्पष्ट रूप से समझाने की ‘बोलने की क्षमता’ की ओर शिफ्ट हो रहा है
- साफ-सुथरी code structure, अच्छी तरह व्यवस्थित README और documents अब मेहनत या expertise के भरोसेमंद signal नहीं रहे, बल्कि वे जितने ज़्यादा परफेक्ट दिखें, उतनी ही slop होने की संभावना भी बढ़ जाती है
- AI द्वारा बनाए गए code और इंसानों द्वारा लिखे गए code के बीच दिखावट के आधार पर फर्क करना लगभग असंभव हो गया है, इसलिए quality से ज़्यादा accountability, provenance और humanness code की value तय करने वाले मानदंड बनकर उभर रहे हैं
- FOSS ecosystem को संभालने वाले collaboration और sharing के incentive कमजोर पड़ रहे हैं, और code से ज़्यादा trust, governance और curation capability अहम asset बनते जा रहे हैं
- ये tools अनुभवी developers के लिए शक्तिशाली amplifier हैं, लेकिन beginners के लिए बुनियादी समझ विकसित करने का मौका छीन लेने वाली खतरनाक genie भी बन सकते हैं
प्रस्तावना: Linus Torvalds का सूक्ति-वाक्य और उसका उलटफेर
"Talk is cheap. Show me the code"
- 2000 में Linus Torvalds की यह बात उस सोच का प्रतीक थी कि जब तक कोई असली code लिखकर साबित न करे, तब तक बातों की कोई कीमत नहीं
- उस समय चाहे development plan कितना भी स्पष्ट क्यों न हो, किसी जटिल program को implement करना अपने-आप में बहुत मेहनत, समय और दोहराव भरी ऊब मांगता था
- असली bottleneck technology नहीं बल्कि इंसानी सीमाएँ थीं: cognitive bandwidth, व्यक्ति का समय और ऊर्जा, और बड़े system को दिमाग में बनाए रखते हुए code की हर line लिखने की biological cost
- नतीजतन ज़्यादातर ideas ‘कभी न कभी करना है’ वाली wishlist में पड़े रह जाते थे, और बिना आज़माए ही गायब हो जाते थे
25 साल बाद: LLM ने सब कुछ उलट दिया
- 2025 में Linus Torvalds ने अपने hobby project में AI-generated code merge करते हुए कहा, “क्या यह उस code से बेहतर है जो मैं खुद हाथ से लिखता? बिल्कुल।”
- दशकों से software बना रहे developer के नज़रिए से लेखक यह साफ़ घोषणा करता है कि जिस तरह का software development हम जानते थे, वह अब खत्म हो चुका है
- dial-up से gigabit तक, Basic से Node.js तक, और SourceForge से GitHub तक के अनगिनत transitions को खुद देखने वाली पीढ़ी के तौर पर, वह इस बदलाव को क्षणिक trend नहीं बल्कि गुणात्मक discontinuity के रूप में पहचानता है
code quality को परखने के मानदंडों का पतन
- पहले FOSS project का मूल्यांकन करते समय project की उम्र, commit frequency, code structure की consistency, README और documentation की quality अहम संकेतक हुआ करते थे
- संक्षिप्त comments और अच्छी तरह व्यवस्थित documents को developer की thoughtful approach और दूसरे developers के लिए consideration के संकेत के रूप में देखा जाता था
- लेकिन अब LLM high-quality documentation pages, ज़रूरत से ज़्यादा detailed README, साफ UI, व्यवस्थित patterns और comments एक साथ generate कर सकता है, इसलिए ये संकेत अब भरोसेमंद नहीं रहे
- नतीजतन यह पहचानना मुश्किल हो गया है कि कोई repository किसी non-technical व्यक्ति ने vibe coding से बनाई है, या किसी skilled developer ने design की है
- उल्टा, जो चीज़ जितनी ज़्यादा परफेक्ट दिखती है, उसके low-effort one-shot output होने पर उतना ही ज़्यादा शक करना पड़ता है
- expert-level गहन review और analysis के बिना wheat और slop में फर्क करना लगातार मुश्किल होता जा रहा है
- इसी वजह से code से भी ज़्यादा यह किसने बनाया, क्यों बनाया, उसका track record क्या है, और governance व maintenance plan है या नहीं जैसी provenance महत्वपूर्ण हो गई है
मेहनत की value में बदलाव
- पहले किसी अनुभवी developer को महत्वपूर्ण नतीजा देने वाली high-quality 10,000 lines of code बनाने के लिए लंबे समय तक गहन focus और बार-बार refinement से गुजरना पड़ता था
- lines of code अपने-आप में quality का मापदंड नहीं हैं, लेकिन अच्छी तरह तराशी गई 10,000 lines का मतलब था कि उसमें समय, एकाग्रता, धैर्य, विशेषज्ञता और कुछ हद तक project management capability लगी है
- LLM अब ऐसे output कुछ ही seconds में generate कर सकता है, और testing, system setup, deployment तक पूरे technical workflow को संभाल सकता है
- जब इंसानी expertise और judgment साथ हो, तो output वास्तविक उपयोग के लिए पर्याप्त high quality तक पहुँच सकता है
- व्यक्तिगत रूप से भी लेखक ने ऐसे काम, जो पहले कई हफ्ते या महीने लेते, अब कुछ दिन या कभी-कभी कुछ घंटों में पूरे होते बार-बार देखे हैं
- AGENT.md या जटिल multi-agent orchestration के बिना, सिर्फ साधारण LLM agent CLI से यह compression संभव हुआ
- software output पाने के लिए चुकाई जाने वाली physiological, cognitive और emotional cost कई orders of magnitude तक घट गई है
- इस तरह बचा समय और cognitive headroom अब engineering thinking, architecture design, discussion, experimentation और imagination के विस्तार में दोबारा लगाया जा रहा है
- “Programming is 90% thinking and 10% typing” जैसी पुरानी बात अब रूपक नहीं बल्कि वास्तविकता बन चुकी है
Slop की परिभाषा और code की value
- जब एक भी line of code कभी न लिखने वाला व्यक्ति भी कुछ seconds में industrial scale पर code बना सकता है, तो आख़िर code नाम के output की value क्या रह जाती है?
- “हमें AI code नहीं, सिर्फ pure human code चाहिए” जैसी बात वास्तविकता के संदर्भ में लगभग एक विडंबनापूर्ण मज़ाक बन जाती है
- CrowdStrike IT outage (2024), Boeing 737 MAX grounding, UK Post Office scandal, India का large-scale data breach, Equifax data leak जैसे इंसानों द्वारा लिखे code से हुई बड़ी घटनाओं के उदाहरण पहले से पर्याप्त हैं
- दुनिया भर में इंसानों द्वारा रोज़ लिखे जाने वाले code का एक बड़ा हिस्सा quality के लिहाज़ से borderline ही होता है
- software development अब भी ऐसा क्षेत्र नहीं है जिसे वस्तुनिष्ठ रूप से पूरी तरह mature professional discipline कहा जा सके
- डॉक्टर या civil engineer के लिए कठोर शिक्षा, licensing और नतीजों की जवाबदेही होती है, लेकिन software development में ऐसी व्यवस्था लगभग नहीं है
- आज का समाज ढीले-ढाले design किए गए, जैसे-तैसे जोड़े गए और बेवजह फुलाए गए code systems पर चल रहा है
- अगर थोड़ी उकसाने वाली भाषा में कहें, तो AI द्वारा बना slop कम-से-कम दिखने में साफ, documentation में व्यवस्थित और syntax के स्तर पर consistent तो होता ही है
- इंटरनेट पर भरे हुए निर्जीव LLM-generated वाक्यों और messages को पढ़ना, शाब्दिक अर्थ में, amygdala neurons की activation की बर्बादी जैसा महसूस होने लगा है
- जब इंसानी रचनात्मक प्रक्रिया, और उसके भीतर की पूर्णता व कमियाँ, हट जाती हैं, तो भाषा, साहित्य, कला और संगीत मूलतः आनंदहीन चीज़ें बन जाती हैं
- जो चीज़ बिना मेहनत के, अनंत मात्रा में, तुरंत generate की जा सकती है, उसे इंसानों के लिए मूल्य देना बेहद कठिन हो जाता है
code कला जैसा नहीं है
- code मूल रूप से हमेशा किसी उद्देश्य के लिए साधन रहा है, अपने-आप में कभी उद्देश्य नहीं
- end users न code पढ़ते हैं, न उन्हें पढ़ने की ज़रूरत होती है, और न ही उन्हें code में दिलचस्पी होती है
- portal के पीछे चल रहे सैकड़ों systems किस language, framework या architecture में implement किए गए हैं, इसका users के लिए कोई मतलब नहीं
- code पूरी तरह छिपा हुआ अस्तित्व है; user सिर्फ UX के माध्यम से code के नतीजे और प्रभाव का अनुभव करता है
- functionally समान AI code slop है या नहीं, यह तय करने का मानदंड accountability की संरचना और humanness की भागीदारी है
- open source repository में किसी इंसान द्वारा खुद लिखकर भेजा गया PR, code quality से अलग, उसमें लगे मानव समय और मेहनत के आधार पर स्वाभाविक empathy और value हासिल कर लेता है
- इसके उलट LLM-generated PR पर, उसकी quality चाहे जो हो, पहली प्रतिक्रिया अक्सर “slop!” होती है, क्योंकि उसमें लगी इंसानी मेहनत का अंदाज़ा तुरंत नहीं लगाया जा सकता
- उसी समय उस code को पढ़ने और verify करने का बोझ उसे बनाने की लागत की तुलना में असंतुलित रूप से, exponential ढंग से बढ़ जाता है
- आखिरकार वह सिर्फ बिना मेहनत generated अनंत variations में से एक भर होता है, जिसके पास meaningful provenance या context नहीं होता
- इस बिंदु पर हमारी दुनिया धीरे-धीरे Borges की ‘The Library of Babel’ जैसी होती जा रही है
FOSS का भविष्य
- FOSS शायद मानवता द्वारा बनाया गया सबसे महान public good में से एक है
- FOSS की शुरुआत में यह ऐतिहासिक धारणा थी कि software बेहद महंगा था और उसे केवल कुछ विशेषज्ञ ही बना सकते थे
- दुनिया भर में बहुत कम लोग software बना सकते थे, और बाकी लोगों के पास सिर्फ उसका इस्तेमाल करने का विकल्प था
- अब स्थिति यह है कि चाहे ज़रूरत कितनी भी niche क्यों न हो, कोई expert अपनी ज़रूरत के हिसाब से एक छोटा library बहुत जल्दी बना सकता है
- इससे आगे, अगर कोई थोड़ा-बहुत smart हो, तो व्यक्तिगत उपयोग के छोटे tools को vibe coding से खुद बनाकर इस्तेमाल करने का दौर आ चुका है
- StackOverflow पर जो बदलाव दिखा, वही धीमी रफ्तार से पूरे software परिदृश्य में भी दिखाई दे रहा है
- यह बदलाव FOSS collaboration और sharing को सहारा देने वाली मानवीय प्रेरणा, सामाजिक परिस्थितियों और participation incentives की नींव को सीधे हिला देता है
- अभूतपूर्व पैमाने पर आने वाले FOSS projects के Cambrian explosion को देखते हुए
- अंततः जो high-quality FOSS projects बचेंगे और फलेंगे-फूलेंगे, उनमें code से ज़्यादा expert governance, curation और trust structure महत्वपूर्ण asset बन सकते हैं
पेड़ों में उलझकर जंगल खो देने वाली दो चरम स्थितियाँ
- syntax highlighting, IDE और तरह-तरह के tools के बिना भी इंसान पहले ही हैरान कर देने वाले स्तर का software बना चुका था
- दूसरी ओर, आज जब tools और resources की भरमार है, तब भी खराब software लगातार बनता जा रहा है
- अभिव्यक्ति में सक्षम और quality की परवाह करने वाला कुशल developer LLM हो या कोई और tool, अपने तरीके से उसका उपयोग कर अच्छा नतीजा निकाल लेता है
- इसके विपरीत जो developer समस्या समझा नहीं सकता और quality की परवाह नहीं करता, वह LLM इस्तेमाल करे या न करे, खराब output ही देगा
- अतिवादी ‘agentic’ vibe coding समर्थक हों या LLM को पूरी तरह नकारने वाले लोग, दोनों ही आखिरकार जंगल नहीं, सिर्फ पेड़ों पर अटके हुए हैं
- अनुभव, विशेषज्ञता, सोचने की क्षमता और अभिव्यक्ति रखने वाले लोगों के लिए ऐसा व्यावहारिक middle ground स्पष्ट रूप से मौजूद है जहाँ वे सही trade-off चुनकर मनचाहा परिणाम पा सकते हैं
- vibe coding non-technical लोगों के लिए पहली बार software को छूने, प्रयोग करने, आनंद लेने और अपनी क्षमता बढ़ाने का महत्वपूर्ण entry point भी है
- लेकिन vibe coding को अंधविश्वास की तरह मानने वाले लोग उस मूल तत्व को नज़रअंदाज़ कर रहे हैं जो इंसानों को किसी output को गंभीरता से लेने पर मजबूर करता है: finitude
- नतीजतन वे खुद भी खुशामद करने वाले agents द्वारा बनाए गए slop के समुद्र में रास्ता भटकने वाली एक विशाल Borges-जैसी library खड़ी कर रहे हैं
- जो output बिना मेहनत अनंत मात्रा में generate हो और जिसका meaningful provenance न हो, उसे value देना भी बेहद कठिन है और गंभीरता से लेना भी
- इंसान मूलतः अनंत supply, खासकर अनंत विकल्पों को अच्छी तरह संभाल नहीं पाता
- दूसरी तरफ LLM skeptics अक्सर argument from incredulity से आगे नहीं बढ़ पाते
- उन्हें कुछ व्यक्तिगत रूप से पसंद नहीं आया, वे मनचाहा नतीजा नहीं पा सके, अपेक्षाएँ टूट गईं, या वे बस ऊब गए—और इसी आधार पर पूरी technology को नकार देते हैं
- लेकिन यह रुख उस तथ्य के सामने टिकता नहीं कि बहुत से लोग यही tools प्रभावी ढंग से इस्तेमाल करके बिल्कुल उलटे अनुभव हासिल कर रहे हैं
- hype, frenzy और greed से प्रेरित मूर्खतापूर्ण और हानिकारक implementations निश्चित ही वास्तविक हैं और गंभीर चिंता का विषय भी
- AI business bubble शायद इतिहास के सबसे बड़े bubbles में से एक बन सकता है
- फिर भी FOSS AI technology का फैलाव साफ़ तौर पर उम्मीद जगाने वाला संकेत है
- बुरे actors, vanity metrics या बेतुके implementations को इन technologies की मूलभूत और भौतिक capabilities के बराबर मान लेना तर्कसंगत नहीं
मानवीय लागत
- अनुभवी developers और engineers के नज़रिए से देखें तो ये AI technologies बेहद शक्तिशाली और प्रभावी सहायक साधन हैं
- लेकिन जो लोग अभी-अभी industry में कदम रख रहे हैं, यानी शुरुआती learners और junior developers, उनके लिए बिल्कुल अलग समस्या खड़ी होती है
- अगर बुनियाद कमज़ोर हो, और systems व software development process की अंतर्निहित और सूक्ष्म समझ अभी बनी न हो, तो यह technology एक अविश्वसनीय और खतरनाक genie बन जाती है
- code माँगो तो code दे देती है, बदलाव कहो तो तुरंत बदल देती है—ऊपर से देखें तो यह बेहद सुविधाजनक लगता है
- लेकिन जल्दी ही user खुद को ऐसे codebase में फँसा पाता है जिसकी working वह समझता ही नहीं, और समस्या सुलझाने के लिए बार-बार उसी genie पर निर्भर होना पड़ता है
- यह निर्भरता अगर बार-बार दोहराई जाए, तो वह learning environment ही गायब हो सकता है जिसमें बुनियादी और गहरी क्षमताएँ स्वाभाविक रूप से विकसित होती हैं, और इससे cognitive decline तक का जोखिम पैदा हो सकता है
- नतीजतन ऐसी पूरी junior पीढ़ी उभर सकती है जिसे meaningful senior बनने का मौका ही न मिले
- असली चिंता यह है कि learners की पीढ़ी के पास slop क्या है और क्या नहीं, इसे वस्तुनिष्ठ रूप से पहचानने की विशेषज्ञता हासिल करने का अवसर ही खत्म हो सकता है
- इससे भी गंभीर समस्या यह है कि इन tools का कुशल उपयोग करने वाले अनुभवी लोग भी juniors को बुनियादी तरीकों से mentor और train करने की प्रेरणा खो सकते हैं
- यह जोखिम software development से आगे बढ़कर उस दिशा की ओर ले जाता है जहाँ इंसान अपनी agency और decision-making को पूरी तरह black box को सौंपने लगते हैं
निष्कर्ष: अब बात code से ज़्यादा मूल्यवान है
- जो developers अब तक हाथ से development करते आए हैं, उनके लिए भी अब code को पढ़ने और आलोचनात्मक रूप से evaluate करने की क्षमता, syntax सीखकर line-by-line typing करने की क्षमता से ज़्यादा महत्वपूर्ण हो गई है
- बेशक, दूसरी क्षमता अब भी महत्वपूर्ण skill है, और code को प्रभावी ढंग से पढ़ने की क्षमता अंततः उसी आधार पर बनती है
- फिर भी रोज़मर्रा का software development workflow स्वयं ही पूरी तरह उलट चुका है
- अच्छी तरह बोल सकने वाला skilled developer—जो कल्पना कर सके, समझा सके, समस्या define कर सके, architecture design कर सके और engineering कर सके—उसे दूसरों की तुलना में पहले से कहीं अधिक असंतुलित रूप से बड़ा advantage मिलता है
- किसी specific language, grammar या framework का ज्ञान अब मुख्य bottleneck नहीं रहा
- जो physiological और physical constraints कभी developers को बाँधकर रखते थे, वे भी अब निर्णायक बाधा नहीं रहे
- बड़े पैमाने का code तुरंत बना देने वाली मशीनें अब commoditized tools बन चुकी हैं, और
pip installजितनी आसानी से उपलब्ध हैं - अलग से specialized training या नई language और framework सीखने की ज़रूरत भी लगभग खत्म हो गई है
- अब ज़रूरत है सिर्फ पुरानी critical thinking, बुनियादी मानवीय क्षमता, और इस मशीन को चलाने की न्यूनतम operational skill की
- नतीजतन software development की पारंपरिक methodologies और roles—Waterfall और Agile, developer और tester, senior और junior—मूलभूत बदलाव से गुजर रहे हैं
- पारंपरिक सीमाएँ अब अकल्पनीय रूप से तेज़, compressed और धुंधले iterative ‘agentic’ loops में समाहित हो रही हैं
- इसके साथ software development से जुड़े लोगों, संगठनों और public communities की dynamics, और sharing व collaboration को टिकाए रखने वाले मानवीय incentives, भी तेज़ी से बदल रहे हैं
- curl bug bounty का अंत, Zulip की AI usage guidelines, और Ghostty की explicit AI policy जैसे उदाहरण इसे दिखाते हैं
- इतिहास में पहली बार, अच्छी बात (talk) अच्छे code की तुलना में exponentionally ज़्यादा मूल्यवान तत्व बन गई है
- इस बदलाव के ripple effects गंभीर भी होंगे और बेहद disruptive भी
10 टिप्पणियां
"सीखने का वातावरण ही गायब हो जाना"—इस बात से मुझे गहरी सहमति है। ऐसी दुनिया में जहाँ ज्ञान तक पहुँच की लागत लगभग शून्य के बराबर है, अब शिक्षा किस रूप में होगी?
"ऐसी स्थिति जहाँ एक भी लाइन code कभी न लिखने वाला व्यक्ति भी कुछ ही सेकंड में industrial scale पर code बना सकता है" -> अगर सू-सुक्कांग से apartment बनाया जाए, तो क्या उसे industrial scale कहा जाएगा?
हकीकत यह है कि ज़्यादातर भर्तियों में हमेशा Java जैसी भाषाओं में N+ साल का अनुभव मांगा जाता है।
"बोलना" और "लिखना" अलग चीज़ें हैं।
असल में लगता है कि "बोलने" से ज़्यादा "लिखना" अच्छी तरह आना चाहिए।
🐎🐎🐎🐎🐎
किमिनो आइबा गा ज़्क्यूनडोक्यून~
मुझे Torvalds की वह बात पसंद थी... अब ज़माना पूरी तरह बदल गया है।
कुछ ही साल पहले तक, अगर आप कंपनी के सहकर्मियों या developer meetups में जाते, तो ऐसे engineers जिन्हें कौशल तो नहीं होता था लेकिन सिर्फ़ बातें ही बड़ी-बड़ी करते थे (latest trend technologies और keywords के पीछे बिना सोचे-समझे early adopter वाली दीवानगी, ज़्यादा से ज़्यादा framework और library इस्तेमाल करने का अनुभव, लेकिन बुनियादी चीज़ें भी खुद कभी बनाकर न देखी हों...) उन्हें घटिया नज़र से देखते हुए "जीभ-प्रोग्रामर" कहा जाता था... अब तो "जीभ-प्रोग्रामर" ही developer की हक़ीक़त बन गया है। हाय, ज़माना कितना बदल गया।
Hacker News की राय
आज मैंने Codex से Redux के लिए unit tests लिखने को कहा
शुरुआत में ठीक-ठाक लगा, तो मैंने बस आगे बढ़ा दिया, लेकिन बाद में जब खुद कुछ tests जोड़ने के लिए फिर देखा तो दर्जनों जगहों पर लगा, “ये क्या है?”
चलता तो था, लेकिन बुरी तरह बिखरा हुआ था। कोड भी बहुत साधारण था, फिर भी स्तर ऐसा था
AI के साथ मेरा लगभग हर बार यही अनुभव होता है — ऊपर-ऊपर से ठीक लगता है, लेकिन जैसे ही इसे बढ़ाने की कोशिश करो, आपदा जैसा हो जाता है, और अंत में मुझे ही सब साफ़-सुथरा करना पड़ता है
“Code is cheap” वाली बात की समस्या यह है कि generation सस्ती है, maintenance महंगा है
रोज़ हज़ारों lines बनवाना credit card से कर्ज़ चढ़ाने जैसा है। पहले लगता है सब मुफ़्त है, फिर बाद में bill आ जाता है
पता नहीं हम सीधे कुछ बदल पाएँगे या नहीं, लेकिन क्या हुआ यह देखना चाहूँगा
संदर्भ के लिए, Redux का testing approach आधिकारिक docs में दिया गया है
पहले testing methodology साफ़ करनी चाहिए, फिर उसी आधार पर model से कहना चाहिए
AI जो स्पष्ट नहीं कहा गया है, उसके बारे में मनमाने अनुमान लगा लेता है, इसलिए सावधानी ज़रूरी है
मूल बात testing ही है। AI code को अंदाज़े से मत आँको, tests से verify करो
कोड की कीमत उसके tests के स्तर के अनुपात में होती है। “LGTM” कहकर बस आगे बढ़ जाना आँख बंद करके motorcycle चलाने जैसा है
कुछ मामलों में यह अच्छा काम करता है, लेकिन कुछ में पूरी तरह गड़बड़ कर देता है
उदाहरण के लिए, आपने सही use case दिया, लेकिन code गलत बना, और test fail होने पर AI ने test ही फिर से बदल दिया
यानी यह अपने हिसाब से success की परिभाषा तय कर देने का जोखिम रखता है
मैंने पहले Claude के दो instances चलाकर एक को tests और दूसरे को implementation दिया था, लेकिन setup बहुत झंझट वाला था
इसलिए मुझे लगता है कि यह उन वजहों में से एक है जिनकी वजह से यह तकनीक टीमों पर ऊपर से थोपी जा रही है
cloud migration की तरह, असली लागत बाद में सामने आती है। बस इस बार शायद बहुत जल्दी आएगी
अगर इसे car assembly की मिसाल से समझाएँ,
तो जो व्यक्ति सिर्फ spec के हिसाब से parts जोड़ता है, उसे robotic arm से replace हो जाने की चिंता हो सकती है
लेकिन जो design पर प्रयोग करता है, prototype बनाता है, और robotic arm को program करता है, उसे automation की चिंता कम होगी
बहुत-से counterarguments इस तरह के होते हैं कि “AI उस दूसरे role को भी automate कर देगी”, लेकिन वास्तव में मुझे लगता है कि पहले काम को दूसरे काम समझ लेने की गलती अक्सर होती है
क्योंकि वह debug कर सकता है, दिशा बदल सकता है, और ठोस निर्देश दे सकता है
आम user बस बार-बार इतना कहता है, “ये काम नहीं कर रहा, इसे ठीक कर दीजिए”
इसलिए काम का रूप बदलेगा, लेकिन पेशा खुद गायब नहीं होगा
अगर AI यह नकल कर सकती है, तो वह मेरी जगह ले सकती है
और कम प्रतिस्पर्धा वाली अर्थव्यवस्था में सिर्फ ‘काफ़ी भरोसेमंद नकल’ भी पर्याप्त हो सकती है
AI का घटिया output भी अगर revenue और exit दिला दे, तो उनके लिए वही काफ़ी है
दुनिया हमेशा से ‘हर तरफ़ फैला कचरा’ सहती आई है। Windows को देख लीजिए
वास्तव में उसमें से बहुत कुछ automate हो सकता था, और शायद अब तक मेरा अहंकार ही उसे ज़्यादा महत्व देता रहा
लेकिन आज के LLM कहीं अधिक सामान्य प्रकृति के हैं, इसलिए वे कई तरह के काम संभाल सकते हैं
अगर robotic arm से कहो “इस साल की car design बेहतर करो”, तो वह रुक जाएगी, लेकिन AI राय दे सकती है
अगर idea → design → build → test → evaluation तक पूरा flow AI कर सके,
तो यह पुरानी तकनीकों से मूल रूप से अलग तरह का innovation होगा
“हाथ से code लिखने का युग खत्म हो गया” कहना अतिशयोक्ति है
ऐसी अतिशयोक्ति लोगों की विशेषज्ञता को हिलाकर FOMO भड़काने का तरीका है
डरिए मत, अपने निर्णय पर भरोसा रखिए
हालाँकि यह सच है कि तकनीक काम करने के तरीके बदल देती है
अंत में अहम चीज़ है performance, cost, schedule, और quality के बीच संतुलन बनाने की क्षमता
“engineering खत्म हो गई” जैसे दावों का हमेशा काफ़ी विरोध होता है,
लेकिन मेरी नज़र में बड़े products में code लिखना कुल काम का सिर्फ 10~20% होता है
बाकी design, experimentation, analysis, communication वगैरह है, और LLM के लिए इस हिस्से को replace करना मुश्किल है
बल्कि collaboration और coordination और जटिल हो जाते हैं, और कई बार LLM इसे और खराब कर देते हैं
इसलिए AI को replacement नहीं, tool के रूप में देखना सही है
उन्होंने भी यह कहा था कि “दशकों पुराना development style खत्म हो गया”, यह नहीं कि engineering ही खत्म हो गई
अगर code लिखना 10~20% है, तो इसका मतलब है कि बाकी ‘बातचीत’ ज़्यादा महत्वपूर्ण हो गई है
जैसा Linus ने कहा, “दिखाओ कि code इरादे के मुताबिक काम करता है”
LLM से कुछ lines लिखवा लेना आसान है, लेकिन उन्हें सुरक्षित तरीके से बदलना अब भी मुश्किल है
कहा जाता है कि Honeycomb की Liz Fong-Jones भी ऐसी गलती कर चुकी हैं
कंपनियाँ जब LLM का ROI ट्रैक करेंगी, तब उन्हें हक़ीक़त समझ आएगी
अभी हम Gartner के hype cycle की चोटी पर हैं, और जल्द ही शायद disillusionment की valley में उतरेंगे
Claude की मदद से मैंने तेज़ी से refactor किया, फिर एक बिंदु पर पूरी तरह रुक गया
वजह यह थी कि मुझे खुद नहीं पता था कि मैं क्या चाहता हूँ
data model साफ़ न हो और आप बस कहते रहें “आगे लिखते जाओ”, तो नतीजा बहुत खराब निकलता है
programming अल्पकालिक गतिविधि है, लेकिन software engineering एक दीर्घकालिक प्रक्रिया है
AI पहले हिस्से को तेज़ करती है, लेकिन दूसरे की जगह नहीं ले सकती
“स्पष्ट development plan और implementation know-how” जैसी पूर्वधारणा यथार्थवादी नहीं है
programming खुद में ही planning की क्रिया है, और language एक बेहतरीन thinking tool है
इसलिए LLM को देखने के नज़रिए अलग-अलग हैं — कुछ लोग language को सोचने का औज़ार मानते हैं, और कुछ उसे सिर्फ execution tool मानते हैं
पहले तरह के लोग programming के अपने मूल्य को देखते हैं, जबकि दूसरे code को छिपाना चाहते हैं
आख़िरकार यह चुनाव का सवाल है: क्या आप शुरुआत से concept model मज़बूत बनाएँगे, या बाद में debugging hell झेलेंगे
मौजूदा tools पहले वाले तरीके के लिए बने ही नहीं हैं। tooling gap बहुत बड़ा है
कुछ लोग इन दोनों को मिलाकर काम करने के नए तरीके बना रहे हैं
“Talk is cheap” का मूल अर्थ है “बातें आसान हैं और उनकी कीमत नहीं”
लेकिन “Code is cheap. Show me the talk.” उससे भी अधिक बेमानी होने जैसा लगता है, इसलिए मुझे शुरू से यह अप्रिय लगा
और सच में, लेख पढ़कर लगा कि मेरा अनुमान सही था
लेखक code से अनजान नहीं है। वह open source में भी काफ़ी सक्रिय है
बात सीधी है — पहले अच्छा design code में उतारना महँगा था,
अब वह सस्ता हो गया है, इसलिए design की quality ज़्यादा महत्वपूर्ण हो गई है
“Talk is cheap, show me the code” की उलटी parody है
code से भी अधिक developer के दिमाग़ का model अहम होता है
code तो उस model का उप-उत्पाद मात्र है, और मानवीय व्याख्या के बिना उसका कोई अर्थ नहीं
यह दृष्टिकोण LLM के उपयोग पर भी गहरा असर डालता है
“दशकों से जिस तरह काम होता आया, वह खत्म हो गया” इस बात से सहमत होना मुश्किल है
2005, 2015, और 2025 में development का तरीका अलग-अलग था
बदलाव हमेशा रहे हैं, इसलिए यह मानना ही गलत है कि “दशकों तक सब एक जैसा था”
tools बेहतर हुए हैं, लेकिन developers के काम करने का तरीका काफ़ी समान रहा है
तो आज का neovim उससे कहीं अधिक शक्तिशाली है
पिछले 30 सालों की क्रमिक प्रगति को कम आँकने की प्रवृत्ति है
उस समय ज़्यादातर जानकारी किताबों या reverse engineering से मिलती थी
“Talk is even cheaper, still show me the code” मुझे ज़्यादा सही लगता है
AI 10x productivity का वादा करती है, लेकिन व्यवहार में मैंने शायद ही ऐसे नतीजे देखे हों
AI की वजह से complexity कुछ हद तक झेलने लायक हुई है, लेकिन React app लिखना अब भी पीड़ादायक है
non-deterministic API से निपटना भी मुश्किल है
फिर भी typo और example खोजने में कम समय लगना एक फ़ायदा है
लेकिन reasoning की कमी और knowledge limits की वजह से coding अब भी उबाऊ बनी हुई है
उसे ANSI characters में बदलता है और terminal पर overwrite करता है —
यानी उसने जो काम आसानी से curses से हो सकता था उसे अनावश्यक रूप से जटिल बना दिया
“Code is cheap. Show me the talk.” जैसे वाक्य अब clickbait की तरह ज़रूरत से ज़्यादा इस्तेमाल हो रहे हैं
लेख खुद बुरा नहीं है, लेकिन इसमें कुछ नया नहीं है
AI की लहर पर सिर्फ कंपनियाँ ही नहीं, blogger और influencer भी सवार हैं
AI पर सकारात्मक या नकारात्मक लेखों को बस उत्तेजक title दे दो, वे HN या Reddit पर trend करने लगते हैं
संदर्भ के लिए, इस वाक्य का मूल इस tweet और
इस meme page से जुड़ा है
आख़िरकार किसी ने चरम सीमाओं के बीच के यथार्थवादी मध्य क्षेत्र को अच्छी तरह व्यक्त किया
LLM न तो भगवान हैं, न आपदा। वे tools हैं
OpenAI, Google, Microsoft जैसी कंपनियों की rent extraction की आलोचना करते हुए भी
Qwen या Mistral जैसे local models का उपयोग किया जा सकता है
cloud LLM में सुरक्षा कारणों से E2EE संभव नहीं है, इसलिए enterprise माहौल में वे उपयुक्त नहीं हैं
लेकिन local LLM की वजह से अब अकेले भी enterprise-grade काम किया जा सकता है
एक Mac Mini से database queries, API integration, और automation तक संभाला जा सकता है
अगर बहुत बड़ा संगठन न हो, तो एक senior generalist तीन mid-level लोगों की जगह ले सकता है
बेशक नौकरियाँ घटने या copyright जैसे मुद्दों पर मेरी नाराज़गी अब भी बनी हुई है,
लेकिन local LLM अब मेरी core toolkit का हिस्सा बन चुके हैं
जो लोग "आस्था" में विश्वास कर रहे हैं, उन्हें दिखाना चाहूँगा ऐसा लेख है यह।