प्रोग्रामिंग का अंत

यह दावा कि AI coding agents “प्रोग्रामिंग का अंत” लेकर आए हैं, उत्साह और संदेह—दोनों को जन्म दे रहा है। टिप्पणीकार Bun JavaScript runtime के AI-सहायता प्राप्त बड़े पुनर्लेखन जैसे उदाहरणों को इस बात के प्रमाण के रूप में देखते हैं कि मॉडल अब विशाल कोडबेस जनरेट और refactor कर सकते हैं, लेकिन तर्क देते हैं कि यह अभी भी मानव-निर्मित tests, architectures, और product decisions पर निर्भर है। कई लोगों की अपेक्षा है कि software work का स्वरूप line-by-line coding से हटकर specification, verification, और system understanding की ओर जाएगा, जबकि वे चेतावनी देते हैं कि AI पर अत्यधिक निर्भरता विशेषज्ञता को कम कर सकती है, software quality गिरा सकती है, और developer job markets को उलट-पुलट कर सकती है.

“प्रोग्रामिंग के अंत” पर समग्र प्रतिक्रिया

  • कई लोग इस शीर्षक को बढ़ा-चढ़ाकर या क्लिकबेट मानते हैं; अन्य कहते हैं कि यह कोड बनाने के तरीके में आए एक वास्तविक बदलाव का सही वर्णन करता है।
  • ऐतिहासिक समानताएँ खींची जाती हैं (जैसे FORTRAN का “कोडिंग का अंत”); आम सहमति यह है कि “प्रोग्रामिंग” समाप्त नहीं होती, बल्कि उसका रूप बदलता है।
  • कई लोगों का तर्क है कि यह सॉफ्टवेयर इंजीनियरिंग के अंत से अधिक मैनुअल कोडिंग के डिफ़ॉल्ट रूप होने के अंत के बारे में है।

साक्ष्य के रूप में Bun Zig→Rust पुनर्लेखन

  • समर्थक Bun पुनर्लेखन को इस बात का प्रभावशाली प्रमाण मानते हैं कि एजेंट मजबूत ऑरेकल (टेस्ट, संदर्भ कार्यान्वयन) होने पर बड़े, जटिल कोडबेस को जेनरेट और क्रमिक रूप से परिष्कृत कर सकते हैं।
  • आलोचक जवाब देते हैं कि:
    • पूर्ण टेस्ट सूट के साथ अनुवाद एक सर्वोत्तम-स्थिति (best-case) है, जो सामान्य परियोजनाओं का प्रतिनिधित्व नहीं करता।
    • परिणामी Rust कोड में कथित तौर पर गंभीर soundness और गुणवत्ता संबंधी समस्याएँ थीं।
    • लाभ का बड़ा हिस्सा केवल भाषा बदलने या AI से नहीं, बल्कि सामान्य refactors से आ सकता है।
  • कई लोग नोट करते हैं कि मार्केटिंग जितना संकेत देती है, उससे कहीं अधिक मानव समीक्षा और इंजीनियरिंग हुई होगी, यह मानना चाहिए।

कोड गुणवत्ता, आर्किटेक्चर, और रखरखाव

  • LLM आउटपुट को बार-बार “slop” कहा जाता है: बग-भरा, अति-आत्मविश्वासी, refactoring में कमजोर, और आर्किटेक्चर में खराब, जब तक बहुत सख्ती से मार्गदर्शन न दिया जाए।
  • लोग LLMs को boilerplate, translation, और छोटे टूल्स में उत्कृष्ट, लेकिन सिस्टम के अधिक जटिल या पुराने होने पर संघर्षरत मानते हैं।
  • यह गहरी चिंता है कि AI पर निर्भरता मानव विशेषज्ञता को क्षीण कर देती है, जिससे खराब architectural निर्णय और “cognitive debt” पैदा होता है।
  • टेस्ट और verification को महत्वपूर्ण माना जाता है; कुछ का विश्वास है कि कोड disposable हो जाएगा, specs/tests से फिर से जेनरेट किया जाएगा, जबकि अन्य near-perfect coverage के बिना अंतहीन regressions की चिंता करते हैं।

प्रोग्रामरों की बदलती भूमिका

  • कई लोग line-by-line coding से हटकर निम्न पर ध्यान देने की उम्मीद करते हैं:
    • सटीक specs, constraints, और verification harnesses को परिभाषित करना।
    • सिस्टम architecture, trade-offs, और product decisions।
    • AI-जनित code की समीक्षा, debugging, और रखरखाव।
  • कुछ लोग मानते हैं कि इससे अत्यधिक कुशल engineers को लाभ होगा और “सिर्फ पैसे के लिए यहाँ” devs बाहर होंगे; अन्य को उलटा डर है—craft और passion का नुकसान, जिसे prompt jockeying से बदल दिया जाएगा।

आर्थिक और श्रम प्रभाव

  • भविष्यवाणियाँ इन दायरों में हैं:
    • छोटे onshore teams + बड़े token budgets, जो बड़े engineering groups या outsourcing की जगह ले लें।
    • वैश्विक स्तर पर white-collar वेतन पर महत्वपूर्ण deflationary दबाव।
  • कुछ लोगों को लगता है कि software skills product roles के लिए table-stakes बन जाएँगे, जिससे समर्पित “software engineer” headcount घट जाएगा।
  • सामाजिक तैयारी को लेकर चिंता है: UBI या यहाँ तक कि “universal high income” की बातें, साथ ही यह डर कि मौजूदा राजनीतिक प्रणालियाँ पर्याप्त प्रतिक्रिया नहीं देंगी।

दीर्घकालिक दिशा और खुले प्रश्न

  • कई लोग इसे metaprogramming / declarative या intent-based development के उदय के रूप में देखते हैं, न कि विलुप्ति के रूप में।
  • अन्य तर्क देते हैं कि fully agentic systems का rewrites और product direction तय करना असुरक्षित या आर्थिक रूप से असंगत होगा।
  • यह स्पष्ट नहीं है कि भविष्य के मॉडल code के अलावा उच्च-स्तरीय product, political, और organizational context को वास्तव में संभाल पाएँगे या नहीं।