कोड सस्ता है। अब ‘बात’ दिखाओ

• 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 भी