सॉफ़्टवेयर डेवलपमेंट का भविष्य सॉफ़्टवेयर डेवलपर्स ही हैं

• पिछले कई दशकों से दोहराई जाती रही “प्रोग्रामर के अंत” की भविष्यवाणी हर बार गलत साबित हुई है, और तकनीकी प्रगति ने उलटे ज़्यादा डेवलपर्स और ज़्यादा प्रोग्राम पैदा किए हैं
• WYSIWYG, 4GL, No-Code, LLM जैसी कई ऑटोमेशन तकनीकें आईं, लेकिन व्यवहार में वे डेवलपर्स की ज़रूरत कम नहीं कर सकीं
• LLM-आधारित टूल पिछली तकनीकों की तुलना में विश्वसनीयता और maintainability में कमज़ोर हैं, और ज़्यादातर टीमों में productivity में गिरावट और quality में खराबी लाते हैं
• प्रोग्रामिंग की मूल कठिनाई कोड लिखना नहीं, बल्कि मानव की अस्पष्ट सोच को तार्किक रूप में बदलने की क्षमता है, और यह अब भी इंसानों का क्षेत्र है
• इसलिए AI के डेवलपर्स की जगह लेने की संभावना कम है, और इसके उलट skilled डेवलपर्स की मांग और बढ़ने की संभावना है

---

बार-बार लौटने वाला “प्रोग्रामर के अंत” का चक्र

• पिछले 43 वर्षों में Visual Basic, Delphi, Executable UML, No-Code, Low-Code जैसी कई तकनीकों के बारे में कहा गया कि वे प्रोग्रामर्स की ज़रूरत खत्म कर देंगी
  • 1970~80 के दशक में 4GL, 5GL, उससे पहले Fortran, COBOL, और उससे भी पहले compiler A-0 तक के बारे में यही भविष्यवाणी की गई थी
  • शुरुआती इलेक्ट्रॉनिक कंप्यूटर COLOSSUS को physical wiring से प्रोग्राम किया जाता था, और उसके बाद की पीढ़ियों को कभी-कभी “असल प्रोग्रामर नहीं” कहकर भी मज़ाक बनाया गया
• लेकिन नतीजा यह रहा कि प्रोग्रामर्स की संख्या घटी नहीं, बल्कि बढ़ी, और इसे Jevons Paradox का एक प्रतिनिधि उदाहरण माना जाता है

LLM और पिछली तकनीकों में अंतर

• पिछली तकनीकों ने वास्तव में सॉफ़्टवेयर प्रोडक्शन की गति बढ़ाई और विश्वसनीयता भी सुनिश्चित की, लेकिन LLM ज़्यादातर टीमों में उलटा असर दिखाते हैं
  • LLM कोड quality को गिराते हैं और maintenance को कठिन बनाते हैं, जिससे “LOSE-LOSE” स्थिति पैदा होती है
  • एक ही prompt से भी एक जैसा परिणाम नहीं मिलता, और बने हुए कोड में मानव डेवलपर द्वारा verification और correction अनिवार्य है
• AI डेवलपर्स की जगह ले रहा है, इसका कोई प्रमाण नहीं है; हाल की layoffs के पीछे pandemic के दौर की over-hiring, ब्याज दरों में बढ़ोतरी, data center निवेश पर फोकस जैसे आर्थिक कारण हैं

प्रोग्रामिंग की मूल चुनौती

• प्रोग्रामिंग का केंद्र मानव की अस्पष्ट सोच को तार्किक और सटीक computational thinking में बदलने की प्रक्रिया है
  • यह punched card के दौर से लेकर COBOL, Visual Basic और Python तक नहीं बदली है
• Natural language स्वभाव से ही अस्पष्ट और असटीक होती है, इसलिए अंग्रेज़ी या फ़्रेंच में प्रोग्रामिंग का युग नहीं आएगा, इस संदर्भ में Dijkstra की भविष्यवाणी उद्धृत की गई है
• यह सोचने का तरीका सीखा जा सकता है, लेकिन यह ऐसा काम नहीं है जिसे हर कोई पसंद करे या अच्छी तरह कर सके, और skilled लोगों की supply हमेशा कम रहती है

AI की सीमाएँ और स्थिरता

• AGI (सामान्य कृत्रिम बुद्धिमत्ता) अभी भी दूर है, और इसके लिए मानव-स्तर की समझ, तर्क और सीखने की क्षमता चाहिए
• बड़े पैमाने के LLM भारी लागत और नुकसान पैदा कर रहे हैं, इसलिए वे लंबे समय में टिकाऊ नहीं हैं
  • समय के साथ मॉडल द्वारा सीखे गए language और library version की सीमाओं के कारण उनकी उपयोगिता घट सकती है
  • इन्हीं कारणों से अति-वृहद LLM ‘Apollo moon mission’ जैसी गैर-आर्थिक प्रयोगधर्मिता बनकर रह सकते हैं

भविष्य के डेवलपमेंट माहौल की दिशा

• निकट भविष्य में सॉफ़्टवेयर डेवलपमेंट का रूप ऐसा हो सकता है जहाँ छोटे language model-आधारित सहायक टूल prototype generation या code auto-completion जैसी सहायक भूमिका निभाएँ
• लेकिन महत्वपूर्ण फैसले और quality assurance की अगुवाई मानव डेवलपर्स ही करेंगे, और Jevons के नियम के अनुसार डेवलपर्स की मांग उलटे बढ़ भी सकती है
• कंपनियों को अभी से skilled डेवलपर्स की hiring और training में निवेश करना चाहिए; यह AI हो या न हो, productivity और reliability बढ़ाने की मुख्य रणनीति है

[GN⁺]

Hacker News की राय

• कई वर्षों तक agent-LLM के साथ काम करने के बाद, यह निष्कर्ष निकला कि असली प्रोग्रामिंग में यह बिल्कुल काम का नहीं रहा
  यह जटिल low-level library समस्याएँ या गैर-सहज bug हल नहीं कर पाता, और abstracted layers के logic को भी नहीं समझता
  हाँ, साधारण वेबसाइट बनाना जैसी पहले से हज़ारों बार दोहराई गई boilerplate tasks में यह शानदार रहा। ऐसे सरल कामों में इसने एक दिन का समय बचा दिया
  लेकिन ऐसा नहीं लगता कि LLM साधारण कामों से आगे बढ़कर जटिल समस्याएँ समझने के स्तर तक पहुँचेगा

  • मुझे लगता है कि “असली प्रोग्रामिंग” की परिभाषा अलग है
    केवल low-level coding या legacy bug fixing ही प्रोग्रामिंग नहीं है। वेबसाइट बनाना, जिसे LLM ने हल किया, वह भी निश्चित रूप से प्रोग्रामिंग का एक रूप है
  • मेरा अनुभव भी लगभग ऐसा ही है, लेकिन मैं इस बात से सहमत नहीं हूँ कि LLM पूरी तरह बेकार है
    बड़े codebase को समझने, feature brainstorming करने, implementation में gaps पहचानने जैसे कामों में इसने बहुत समय बचाया है
    यह पूरी तरह replacement नहीं है, लेकिन engineer के लिए एक शक्तिशाली tool के रूप में इसकी value साफ़ है
  • शायद आप बहुत low-level तरह का काम करते हैं
    लेकिन ज़्यादातर developers framework और libraries को जोड़कर काम करते हैं।
    जैसे electric vehicle भारी माल ढुलाई के लिए उपयुक्त नहीं है, लेकिन आम drivers के लिए काफ़ी उपयोगी है, LLM की स्थिति भी कुछ वैसी ही है
  • हाल ही में सुना कि Codex 5.2 ने एक CTF प्रतियोगिता में cryptography समस्या हल की
    कुछ महीने पहले तक मैं भी सहमत होता, लेकिन अब लगता है कि तकनीक उस सीमा को पार कर चुकी है
  • मेरा अनुभव बिल्कुल अलग है। इस्तेमाल की जाने वाली भाषा और architecture के अनुसार बहुत फर्क पड़ता है
    मैं ERP क्षेत्र में काम करता हूँ, और agents ने productivity को बहुत बढ़ा दिया है
    subscription fee अगर 500 डॉलर प्रति माह भी हो जाए, तब भी मैं इसे इस्तेमाल करता रहूँगा क्योंकि यह उतनी value देता है

• यह डर लगता है कि AI programmers की ज़रूरत कम कर देगा, यह भविष्यवाणी सच हो सकती है
  पहले ही लगता है कि AI design, code review, bug detection, project planning जैसे कामों में मुझसे बेहतर है
  मुझे तो बस उस प्रक्रिया को संचालित करने वाले conductor की भूमिका निभाने जैसा महसूस होता है
  कभी-कभी डर लगता है कि जो काम पहले 20 लोग करते थे, अब मैं अकेला कर रहा हूँ

  • मुझे लगता है कि LLM इंसानों में सीखी हुई लाचारी पैदा करता है
    long-term planning और decision-making में इंसान ही सच में बेहतर हैं। हमारे पास चिंता, गर्व, भावनाएँ हैं, और वही हमारी असली ताकत है
    AI तो बस शब्दों की एक थैली है, उसमें न प्रेम है न निरंतरता
  • यह सच नहीं है कि AI उस स्तर का काम अच्छी तरह करता है
    मुझे लगता है कि अगर किसी इंसान में बुनियादी क्षमता भी हो, तो वह इससे कहीं बेहतर होता है
  • यह कुछ विज्ञापन जैसा लगता है। असल में AI जटिल समस्याओं में बेकार नतीजे देता है, और testing भी कमजोर होती है
    अगर आप अकेले 20 लोगों का काम कर रहे हैं, तो शायद वे 20 लोग पहले से ही कम productive थे
  • मैंने 11 साल तक Michelin restaurant chef के रूप में काम किया है
    वहाँ dishwashing machine को लगातार चलाते रहना बहुत महत्वपूर्ण था, और AI coding agent भी उसी मशीन जैसा है
    मैं prompt देता हूँ, output की जाँच करता हूँ और उसे व्यवस्थित करता हूँ। अंत में इंसान का हाथ अब भी ज़रूरी है
  • कार इंसान से तेज़ चलती है और ज़्यादा देर तक चल सकती है, लेकिन फिर भी driver की ज़रूरत होती है
    अगर AI की वजह से 20 लोगों का काम 1 व्यक्ति कर पाता है, तो यह productivity improvement है और इससे अधिक संपत्ति पैदा होती है

• मुझे लगता है कि मौजूदा LLM उन्माद बड़े पैमाने का Eliza effect है
  संबंधित अवधारणाएँ ELIZA effect और Weizenbaum की किताब Computer Power and Human Reason में देखी जा सकती हैं

  • मुझे भी लगता है कि Eliza effect बहुत मजबूत है
    ऐसा लगता है कि LLM को प्रभावशाली लोगों (CEO, investors) को प्रभावित करने के लिए evolve किया गया है
    इसे वास्तव में expert level होने की ज़रूरत नहीं है, बस “काफ़ी ठीक दिखने” भर का स्तर हो तो इसे अपनाया जाता है

• अमेरिकी developers के लिए असली खतरा AI नहीं, outsourcing है
  मैं एक immigrant हूँ और New York की एक financial company में काम करता हूँ। कर्मचारियों में 95% विदेश से हैं, और नई hiring भी ज़्यादातर H1B visa धारकों की होती है

  • सही है, यह रुझान तो कई दशकों से चलता आ रहा है

• जैसा कि Dijkstra ने 50 साल पहले ही कहा था, मानव भाषा में प्रोग्रामिंग करना असंभव है
  क्योंकि natural language अपनी प्रकृति में अस्पष्ट और अनिश्चित होती है
  जो लोग कहते हैं कि “prompt ही नया source code है”, वे कुछ-कुछ Excel से apps बनाने वाले लोगों जैसे लगते हैं

• मैंने “Blood in the Machine” नाम की किताब पढ़कर Luddite आंदोलन का इतिहास जाना
  औद्योगिक क्रांति से पहले परिवार स्तर पर कपड़े बनाए जाते थे, लेकिन मशीनों के आने से हस्तशिल्प उद्योग ढह गया
  अब लगता है कि developers भी उसी रास्ते पर चल रहे हैं

  • Luddites का विरोध loom के खिलाफ था। कपड़ा बनाने की प्रक्रिया में वही सबसे समय लेने वाला हिस्सा था
    लेकिन software development में coding पूरी प्रक्रिया का सिर्फ़ एक हिस्सा है
  • automobile industry वाली तुलना ज़्यादा उपयुक्त लगती है
    जैसे Toyota ने कारीगरों की जगह ली, वैसे ही अगर LLM maintenance तक automate कर दे, तो developers का भी वही हश्र हो सकता है
  • लेकिन garment industry आज भी मौजूद है
    सस्ते कपड़ों की भरमार होने पर भी designers और premium brands बचे हुए हैं। software भी शायद वैसा ही बदल जाएगा

• पहले Visual Basic और Delphi जैसे WYSIWYG tools के बारे में भी कहा गया था कि वे programmers की जगह ले लेंगे, लेकिन ऐसा नहीं हुआ
  AI भी वैसा ही है। यह कमज़ोर और अस्थिर code बना सकता है, लेकिन उसे स्थिर बनाने के लिए अब भी असली programmer चाहिए

• 1980 के दशक में भी सरकारों और उद्योग ने 4GL पर भारी निवेश किया था, लेकिन अंत में वह भी विफल रहा
  जापान का MITI Fourth Generation Project भी ऐसा ही था। उस समय का “software crisis” आज के AI उन्माद जैसा लगता है

• यह लेख AI की प्रशंसा करने वाला लेख लगता है। अंत में education service का प्रचार वाला हिस्सा खास तौर पर वैसा लगा
  फिर भी यह सच है कि मेरी productivity वास्तव में बढ़ी है, इसलिए अंततः developers की demand में कमी शायद टाली नहीं जा सकेगी

  • मुझे भी यही लगा। लेखक एक बेहतरीन शिक्षक हैं, लेकिन उसमें कोई नई insight नहीं थी
    बल्कि वह कई रायों को जोड़कर बने किसी LLM द्वारा लिखे गए लेख जैसा लगा
  • जैसे coal engine जितना efficient हुआ, coal की demand उतनी बढ़ी, वैसे ही Jevons paradox software पर भी लागू हो सकता है
    अगर development cost आधी हो जाए, तो और ज़्यादा क्षेत्रों में software का उपयोग होने लगेगा
    Jevons paradox देखें

• aviation safety में बताए जाने वाले Swiss cheese model की तरह, LLM को भी software development की एक layer के रूप में देखा जा सकता है
  विचार यह है कि भले हर layer पूरी तरह perfect न हो, वे एक-दूसरे की कमियों की भरपाई करके कुल quality बढ़ाती हैं

  • यह दिलचस्प तुलना है, लेकिन अभी हम LLM को ऐसी supporting layer के रूप में इस्तेमाल नहीं कर पा रहे हैं
    code verification या test analysis में इसे बुद्धिमानी से लागू करने की स्थिति अभी नहीं है
    लेकिन मुझे भरोसा है कि कभी न कभी इसका सही use case सामने आएगा
  • LLM तो Kraft Singles जैसे नकली cheese के ज़्यादा करीब है
    safety सुनिश्चित करने के लिए अंत में इंसान को पूरा काम जाँचना ही पड़ता है
  • aviation industry के safety paradigm को LLM पर लागू करना ज़्यादा खींचा हुआ है
    aviation software की reliability और LLM की instability की तुलना ही नहीं की जा सकती