AI कोड और सॉफ़्टवेयर कारीगरी

 (alexwennerberg.com)
25 पॉइंट द्वारा GN⁺ 2026-02-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI द्वारा बनाई गई निम्न-गुणवत्ता वाली सामग्री 'slop' अब पूरे इंटरनेट में फैल रही है, और संगीत, वीडियो, टेक्स्ट के साथ-साथ सॉफ़्टवेयर में भी ऐसा ही रुझान दिख रहा है
  • कंटेंट उत्पादन का अनुकूलन सिर्फ engagement और revenue को अधिकतम करने पर केंद्रित होता जा रहा है, जबकि कारीगरी और रचनात्मकता लगातार गायब होती दिख रही है
  • बड़ी टेक कंपनियों में गुणवत्ता में गिरावट और तकनीकी क्षरण AI के आने से पहले ही शुरू हो चुका था, और बहुत संकीर्ण role-based specialization इंजीनियरों की कौशल क्षमता और सोच को कमजोर करता है
  • AI agent अच्छी तरह परिभाषित दोहराए जाने वाले कामों में उपयोगी हैं, लेकिन वे झूठ गढ़ते हैं, कोड को ठीक से नहीं समझते, और खराब कोड बनाते हैं — यानी उनकी मौलिक सीमाएँ हैं
  • 19वीं सदी के Arts and Crafts आंदोलन की तरह, अब समय है कि सॉफ़्टवेयर में भी शुरुआती computing के विचारों को पुनर्स्थापित किया जाए और मानव-केंद्रित कारीगरी को फिर जीवित किया जाए

AI slop का प्रसार और technique की अवधारणा

  • AI models के सार्वजनिक होने के बाद ऑडियो, वीडियो और टेक्स्ट में 'slop' कहे जाने वाले निम्न-गुणवत्ता AI कंटेंट में तेज़ बढ़ोतरी हुई
    • बेकार कंटेंट पहले भी था, लेकिन AI की वजह से उसे बनाने में लगने वाला श्रम दर्जनों गुना कम हो गया
    • जहाँ discernment नहीं है, या उसका महत्व कम है, वहाँ AI मानव श्रम को बदलने लायक स्तर तक पहुँच चुका है
  • Jacques Ellul की 'technique' अवधारणा: गतिविधियों को मापे जा सकने वाले, स्पष्ट रूप से परिभाषित लक्ष्यों की ओर कुशल साधनों के समुच्चय में बदल देने वाली सोच
    • Instagram Reels, YouTube वीडियो, ब्लॉग पोस्ट को कम-से-कम मेहनत से अधिकतम engagement मिल जाए तो 'अच्छा' परिणाम माना जाता है
    • metrics और performance के प्रति जुनून, कारीगरी, सुंदरता और आनंद जैसे अमूर्त मूल्यों को खा जाता है

म्यूज़िक प्लेटफ़ॉर्म तुलना: Bandcamp vs Spotify

  • Bandcamp: पूरे album और व्यक्तिगत curation पर केंद्रित
    • 2010s~2020s के indie music boom को सहारा दिया, और Car Seat Headrest, Mitski, Alex G, Phoebe Bridgers जैसे कलाकारों के उभार में भूमिका निभाई
    • संगीत को ही लक्ष्य मानने वाले प्लेटफ़ॉर्म के रूप में AI-generated music को प्रतिबंधित करता है
  • Spotify: playlist और algorithmic recommendation पर आधारित मॉडल
    • संगीत से ज़्यादा metrics optimization पर फोकस
    • फीका और algorithm के मुताबिक ढला हुआ muzak फैल रहा है
    • जहाँ कारीगरी की कोई परवाह नहीं, वहाँ AI इंसानों द्वारा बनाए गए संगीत से कहीं ज़्यादा 'revenue maximization' के लिहाज़ से फ़ायदेमंद कंटेंट बड़े पैमाने पर बना सकता है

सॉफ़्टवेयर उद्योग में गुणवत्ता गिरावट की स्थिति

  • AI आने से पहले ही बहुत-सा सॉफ़्टवेयर समग्र रूप से निम्न गुणवत्ता की स्थिति में था
  • बड़ी टेक कंपनियों में सॉफ़्टवेयर इंजीनियरिंग, 'plumbing' जैसे काम में बदल गई है
    • यानी कई systems को जोड़कर data flow चालू रखना भर
    • Richard Hamming के कहे ‘महान कार्य’ — यानी मानवता के लिए उपहार जैसा कुछ बनाना — आज की टेक इंडस्ट्री में बहुत आदर्शवादी समझा जाता है
  • बहुत-सी बड़ी सॉफ़्टवेयर systems फूली हुई, खराब ढंग से डिज़ाइन की गई, और कम दस्तावेज़ित हैं
  • platform लगातार बिगड़ने वाली 'enshittification' प्रक्रिया में जाते हैं, और उपयोगकर्ताओं को उसका शिकार बनने से बचने के लिए हमेशा रक्षात्मक रहना पड़ता है
  • Jonathan Blow के व्याख्यान Preventing the Collapse of Software Civilization में दिए गए दृष्टिकोण से सहमति जताई गई है
    • विशेषज्ञ इंजीनियर और बड़ी सॉफ़्टवेयर कंपनियाँ काम ठीक से करना कैसे है, यह तक भूल चुकी हैं
  • noncompetitive monopoly जैसी संरचनाएँ उन्हें बाज़ार के दबाव से बचाती हैं
    • सॉफ़्टवेयर प्रथाएँ ढीली पड़ती जाती हैं
    • संगठन और अधिक भारी-भरकम होते जाते हैं
    • और कुल गुणवत्ता में बड़ी गिरावट आती है
  • Big Tech इंजीनियर बड़े संगठनों में बेहद सीमित भूमिका निभाते हैं
    • इस वजह से व्यापक engineering skill और कारीगरी स्वाभाविक रूप से क्षीण होती जाती है

मानव पूँजी और division of labor की समस्या

  • कोई कंपनी या समाज कंप्यूटरों से क्या-क्या हासिल कर सकता है, यह human capital पर निर्भर करता है — यानी वह कितने व्यापक कौशल वाले इंजीनियर तैयार करता है
  • बड़ी टेक कंपनियों की अतिशय division of labor संरचना
    • बहुत संकीर्ण कौशल वाले तकनीकी कर्मियों का उत्पादन करती है
    • और उन्हें ऐसे लोगों में बदल देती है जो सिर्फ मौजूदा Big Tech organizational structure के भीतर ही काम कर सकते हैं

AI के सॉफ़्टवेयर इंजीनियरिंग के लिए ख़तरा बनने की दो घटनाएँ

  • 1. यह यथार्थवादी समझ कि AI agents पेशेवर सॉफ़्टवेयर इंजीनियरिंग के लिए ख़तरा बन रहे हैं
    • खासकर उन इंजीनियरों के लिए जिनकी भूमिका दोहरावदार और सीमित दायरे वाली निम्न-गुणवत्ता सॉफ़्टवेयर उत्पादन तक सिमट गई है
    • वहाँ AI वास्तव में काफ़ी प्रभावी विकल्प बन सकता है
  • 2. AI agents की क्षमता का अतिरंजित सामान्यीकरण

AI agents की मौलिक सीमाएँ

  • ऐसे दावों के टिके रहने के लिए सॉफ़्टवेयर को लेकर बेहद संकीर्ण नज़रिया ज़रूरी है
    • ठीक वैसे ही जैसे AI-generated music को संगीत नहीं, सिर्फ consumption metrics के रूप में देखना पड़ता है
    • यानी सॉफ़्टवेयर को सिर्फ उद्देश्य प्राप्ति का साधन मानना, और यह सोचना कि “काफ़ी अच्छा है तो ठीक है”
  • AI agents के प्रत्यक्ष प्रयोग से पता चलता है कि वे उपयोगी तो हैं, लेकिन उनकी स्पष्ट सीमाएँ हैं
    • वे ग़लत बातों को भी विश्वसनीय ढंग से कह देते हैं, संदर्भ को ठीक से नहीं समझते, और अक्सर निम्न-गुणवत्ता वाला कोड बनाते हैं
    • कुछ क्षेत्रों में सुधार संभव है, लेकिन संगीत और टेक्स्ट की तरह यहाँ भी संरचनात्मक सीमाएँ साफ़ हैं
  • AI agents के पास स्वायत्त सोच नहीं होती, और वे खुद से यह नहीं समझ सकते कि उपयोगकर्ता वास्तव में क्या चाहता है
  • वे सबसे अच्छा तब काम करते हैं जब समस्या बहुत स्पष्ट रूप से परिभाषित हो
    • उदाहरण: “unit test लिखो”, “इस रूप का DB function implement करो”
  • उनकी क्षमता को सामान्यीकृत करने की कोशिशें अक्सर विफल होती हैं
    • वे नया दिखने वाला, लेकिन maintain, understand और extend करना मुश्किल राक्षसी कोड पैदा कर देते हैं

“Vibe Coding” की समस्याएँ

  • शुरुआत में यह प्रभावशाली लगता है, लेकिन समय के साथ इसकी खास खामियाँ उभरकर सामने आती हैं
    • अनावश्यक रूप से लंबा-चौड़ा कोड और लापरवाह शैली
    • संरचना में सरल लेकिन समतल और सौंदर्यहीन डिज़ाइन
    • बार-बार दिखने वाले इसके अपने निशान, जो धीरे-धीरे चिढ़ पैदा करते हैं
  • समस्या आने पर debugging की प्रक्रिया हताशा पैदा करने वाले दोहराव में बदल जाती है
    • आप दूसरे वीडियो देखते रहते हैं या SNS स्क्रॉल करते हुए यूँ ही coding करते रहते हैं
    • और agent से बार-बार कहते रहते हैं: “bug है, फिर से ठीक करो”
  • AI-generated code में अक्सर दिखने वाली बातें
    • ज़रूरत से ज़्यादा padded button
    • असंगत spacing और colors
    • कुल मिलाकर सपाट visual aesthetics
    • ऐसे UI elements जिनके होने का कारण स्पष्ट नहीं
    • हर चीज़ पर अनावश्यक labels और explanations जोड़ देने की प्रवृत्ति

सॉफ़्टवेयर उद्योग की संरचनात्मक समस्याएँ और कारीगरी की ज़रूरत

  • यह मानने से इनकार करना कठिन है कि ज़्यादातर कोड बहुत अच्छा नहीं होता, और बड़ी कंपनियों में यह बात और स्पष्ट दिखती है
  • AI का उपयोग करके निम्न-गुणवत्ता सॉफ़्टवेयर को और तेज़, और अधिक दक्षता से बनाते रहना संभव है
  • लेकिन AI सॉफ़्टवेयर उद्योग की मूलभूत संरचनात्मक समस्याएँ हल नहीं करता
    • असली समस्या यह है कि बड़े पैमाने के वातावरण में अच्छा सॉफ़्टवेयर कैसे बनाया जाए, यह अभी तक ठीक से स्थापित ही नहीं हुआ है
    • इस समस्या का समाधान automation नहीं, बल्कि कारीगरी और मानवीय आलोचनात्मक सोच से आएगा

Arts and Crafts आंदोलन और सॉफ़्टवेयर की समानता

  • ध्यान 19वीं सदी के Arts and Crafts आंदोलन पर जाता है
  • John Ruskin और William Morris ऐसे समय में सामने आए जब मशीन और औद्योगिक उत्पादन की अपार क्षमता व्यक्तिगत कारीगर को पीछे धकेल रही थी
    • उन्होंने औद्योगिक उत्पादन को अपने-आप में प्रगति नहीं माना, बल्कि यह समझा कि उसके परिणामों और श्रम स्थितियों का भी अपना एक विशिष्ट 'style' होता है
    • उन्होंने आलोचना की कि मज़दूर धीरे-धीरे विशाल औद्योगिक मशीन के पुर्ज़े बनते जा रहे हैं
    • उन्होंने कहा कि कुछ क्षेत्र स्पष्ट रूप से ऐसे हैं जो मशीन नहीं कर सकती, और यह बात तब भी सच थी, आज भी है
    • प्रेरणा के स्रोत के रूप में उन्होंने मध्यकालीन कारीगरी की पुनर्स्थापना की ओर देखा

सॉफ़्टवेयर में आवश्यक वैसा ही बदलाव

  • सॉफ़्टवेयर क्षेत्र में भी ऐसे ही बदलाव और आंदोलन की ज़रूरत है
    • शुरुआती computing के तरीकों और विचारों का फिर से अध्ययन और पुनरुद्धार ज़रूरी है
  • मुख्यधारा द्वारा नज़रअंदाज़ किए गए, लेकिन खत्म न हुए विचारों का समृद्ध ख़ज़ाना मौजूद है
    • ऐसे projects जो आज के सॉफ़्टवेयर से बिल्कुल अलग ढंग से प्रभावशाली और सुंदर थे
  • अभी हम तकनीकी विकास की बहुत संकरी शाखा पर टिके हैं — यानी C/Unix से Javascript/web तक की धारा
    • जबकि खोजने के लिए इससे कहीं ज़्यादा व्यापक क्षेत्र मौजूद हैं
  • जैसे ही आप थोड़ा भी गैर-पारंपरिक दिशा में जाते हैं, AI की मदद लगभग ग़ायब हो जाती है
    • Claude से Forth लिखवाने की कोशिश की गई, लेकिन परिणाम मदद से ज़्यादा बाधा जैसे रहे
  • शुरुआत के लिए Permacomputing wiki की सिफ़ारिश की गई है

AI code युग की संभावनाएँ

  • AI code निम्न-गुणवत्ता, बड़े पैमाने पर बने सॉफ़्टवेयर को और आम बना सकता है
  • साथ ही यह कारीगरी और रचनात्मक अभिव्यक्ति को वापस लाने की कोशिश करने वाले इंजीनियरों के लिए नई जगह भी खोल सकता है
  • दृष्टिकोण पूरी तरह निराशावादी नहीं है: कारीगरी जितनी दुर्लभ होती जाएगी, उसका मूल्य उतना ही बढ़ेगा
  • ऐसे समय में जब मुख्यधारा का सॉफ़्टवेयर अपनी सीमाएँ दिखा रहा है, सॉफ़्टवेयर की गुणवत्ता गिरती जा रही है, और राजनीतिक चेतना के स्तर पर केंद्रीकृत संरचनाओं के मूल्य पर फिर से विचार हो रहा है
    • प्रयोगधर्मी, मनुष्यों द्वारा बनाया गया, और मानवीय पैमाने पर चलने वाला सॉफ़्टवेयर हाशिए से चमकने के लिए यह एक अच्छा क्षण हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-04
Hacker News की राय

  • Jacques Ellul के विचारों का उल्लेख किया गया हिस्सा पसंद आया
    इससे फिर सोचने पर मजबूर होना पड़ता है कि तकनीकी ‘प्रगति’ का सार दक्षता को सर्वोच्च मूल्य बना देना है
    यह दिलचस्प है कि इस मूल्य को लगभग बिना चुनौती के स्वीकार कर लिया गया है। फिर भी मेरा मानना है कि दूसरे विकल्प अब भी संभव हैं

    • दक्षता, शेयरहोल्डर रिटर्न को अधिकतम करने का भी सबसे अच्छा तरीका नहीं है
      दक्षता में मूल रूप से अनुकूलनशीलता और लचीलापन की कीमत चुकानी पड़ती है
    • दक्षता को मापना आसान है। और जो मापा जा सकता है, वही लक्ष्य बन जाता है
      जबकि कारीगरी, बारीकी, विस्मय को मापना कठिन है। मैं जिन मेट्रिक्स का उपयोग करता हूँ, वे असल लोगों के ईमेल हैं, जो अनियमित और अप्रत्याशित होते हैं

  • मुझे लगता है कि coding agents के जरिए भी high-quality code बनाया जा सकता है
    यह एक ही prompt में खत्म होने वाली चीज़ नहीं है, बल्कि योजना–इम्प्लीमेंटेशन–वैरिफिकेशन–रिव्यू की समन्वित प्रक्रिया चाहिए
    आखिरकार यह अब भी engineering का काम है, बस tools बदल गए हैं। जैसे हाथ की आरी और chainsaw का फर्क: नतीजा वही, प्रक्रिया अलग

    • वास्तविकता में LLM द्वारा बनाया गया code, हाथ से लिखे code जैसा लगभग नहीं होता। उसकी quality कई गुना खराब होती है
    • कभी-कभी तो बस खुद लिखना ही ज़्यादा तेज़ पड़ता है
    • यह जानने की उत्सुकता है कि क्या किसी ने ऐसी प्रक्रिया सीधे अनुभव की है, या कोई काम के resources हैं
    • असली सीमा latency और inference cost है। पूरा plan–verify loop बहुत tokens खाता है और flow तोड़ देता है
    • यह भी जानना है कि “high-quality code” वास्तव में कैसा दिखता है, और “code matters” कहने का ठोस मतलब क्या है

  • enterprise software की quality खास तौर पर खराब होती है क्योंकि उसे अक्सर ऐसे managers को बेचा जाता है जो उसका उपयोग नहीं करते
    इसके विपरीत consumer software को उपयोगकर्ता खुद चुनते हैं, इसलिए वह ज़्यादा user-friendly होता है
    जब आप अपने लिए code लिखते हैं, तो सिर्फ वही features बनाते हैं जिनकी ज़रूरत है, इसलिए वह थोड़ा कच्चा होते हुए भी अच्छे से काम करता है
    coding agents को किसी project को साफ़ करने वाले pressure washer की तरह इस्तेमाल किया जा सकता है। यह कला नहीं है, लेकिन संतोषजनक है
    बस नाज़ुक code पर इसका इस्तेमाल नहीं करना चाहिए। लेकिन अधिकांश web apps अच्छी तरह tested हैं, और अब उन्हें हाथ से करने की वजह लगभग नहीं बची

    • enterprise software के खराब होने की एक और वजह है कि हर ग्राहक अपनी-अपनी मांगें ठूंसता है
      नतीजतन अनावश्यक features और toggles की भरमार हो जाती है
    • managers और कर्मचारियों के लक्ष्य अलग होते हैं
      managers data accuracy चाहते हैं, लेकिन कर्मचारी input भरने की झुंझलाहट की शिकायत करते हैं
      integration के लिए बजट नहीं होता, या contract बहुत छोटा होता है, इसलिए CRM integration भी नहीं हो पाता
    • consumer software अक्सर engagement maximization के लिए optimized होता है, इसलिए उसकी वास्तविक value या functionality कम हो सकती है
      वहीं enterprise software में भुगतान करने वाले और उपयोग करने वाले के incentives अलग होने के कारण वह अजीब workflows में विकृत हो जाता है

  • अधिकांश software engineers, AI से पहले भी, कारीगरी से ज़्यादा salary और efficiency पर ध्यान देते थे
    इसलिए AI जो code बना रहा है, वह भी बस वैसा ही औसत code है

  • मुझे लगता है AI कारीगरी को पुनर्जीवित नहीं करेगा, बल्कि उसके आखिरी निशान भी मिटा देगा

    • नई technology पुरानी technology या कारीगरी को खत्म नहीं करती। वह सिर्फ उपयोगकर्ता और उपयोग बदलती है
      जैसे power tools ने handcrafted woodworking को खत्म नहीं किया, वैसे ही AI भी ऐसा नहीं करेगा
      भविष्य में “IDE वाले लोग” और “agent prompt वाले लोग” साथ-साथ मौजूद रहेंगे
    • “कारीगरी पहले ही गायब हो रही है” यह मान लेना खुद में हद से ज़्यादा निराशावाद है

  • Forth का ज़िक्र देखकर अच्छा लगा। मैं इसे अक्सर इस्तेमाल करता हूँ
    LLM से generated Forth code का style खराब होता है, जैसे C का अनुवाद हो
    standard Forth छोटा और स्पष्ट होना चाहिए, लेकिन LLM लंबे code बनाता है जो nested conditionals से भरे होते हैं

  • आजकल Turing’s Cathedral पढ़ रहा हूँ
    इससे युद्धोत्तर अमेरिका की engineering craftsmanship का फिर से एहसास होता है
    लगता है अब हम हर चीज़ को स्वाभाविक मान लेते हैं और भूल गए हैं कि असली engineering कैसी होती थी

  • अधिकांश code पहले से ही बेहद खराब था
    नतीजा-केंद्रित संस्कृति में quality पीछे छूट गई, और bugs व्यापार की लागत का हिस्सा बन गए
    AI ऐसे माहौल में पूरी तरह फिट बैठता है। यह पहले से ही निम्न-स्तरीय code culture में फल-फूल रहा है

    • यह offshoring का अगला चरण है। कंपनियों को कारीगरी नहीं, सिर्फ problem-solving चाहिए
    • मैं भी agents को अपनाने के पक्ष में नहीं हूँ, लेकिन “सारा code खराब है” वाला उद्योग का माहौल मुझे पसंद नहीं

  • मुझे लगता है AI का उपयोग करके बेहतर software बनाया जा सकता है
    AI-generated code में भी design, patterns, best practices को शामिल किया जा सकता है
    यह पारंपरिक guitar making और आधुनिक CNC-आधारित guitar making के अंतर जैसा है
    Ulrich Teuffel की guitar making वीडियो देखें तो technology और art साथ-साथ दिखते हैं
    बेशक कारीगरी महंगी होती है, इसलिए ज़्यादातर लोग industrial products चुनते हैं

    • लेकिन CNC को इंसान सीधे program करता है, जबकि LLM एक probabilistic tool है
      इसे बड़े projects पर लागू किया जा रहा है, लेकिन लंबे समय के नतीजे अब भी अज्ञात हैं
    • मैं wood और metal puzzle artisan हूँ, और LLM को design assistant tool की तरह इस्तेमाल करता हूँ
      जिन algorithms को पहले मैं खुद लिखता था, अब उन्हें agent को सौंप देता हूँ
      जैसे manual milling की जगह CNC का उपयोग, वैसे ही tech stack को विकसित करके मैं ज़्यादा high-quality काम बनाता हूँ
    • लेख का तर्क tool selection और product quality को आपस में मिला देता है
      अगर AI से खराब software सस्ते में बनाया जा सकता है, तो वह ठीक है
      असली सवाल यह है कि क्या अच्छे software का अनुपात बढ़ता है। AI उस संभावना को बढ़ाता है

  • AI उन माहौल में फलता-फूलता है जहाँ software को ‘काफ़ी अच्छा’ स्तर तक optimize किया जाता है
    बेहतरीन engineers को replace करने के बजाय, यह पहले से मौजूद यांत्रिक और metrics-केंद्रित औद्योगिक वास्तविकता को उजागर कर रहा है
    जैसे-जैसे mass-produced code आम होगा, इंसानी judgment और aesthetic sense सचमुच दुर्लभ संसाधन बन जाएंगे