हर 10 साल में दोहराया जाने वाला डेवलपर्स को बदलने का सपना

• पिछले 50 से अधिक वर्षों में software development को सरल बनाकर developers पर निर्भरता घटाने की कोशिशें बार-बार दोहराई गई हैं
• 1960 के दशक के COBOL से शुरू होकर CASE tools, Visual Basic, low-code·no-code, और हाल के AI code assistants तक वही पैटर्न चलता रहा है
• हर तकनीक ने productivity बढ़ाई, लेकिन complexity को संभालने की thinking process अब भी इंसानों की जिम्मेदारी है
• AI developers की क्षमता को बढ़ाता है, लेकिन business problems की समझ और judgment की जगह नहीं ले सकता
• यह बार-बार दोहराया गया प्रयास tools की सीमाओं से अधिक problems की complexity को उजागर करता है, और अंततः मानवीय thinking ability में investment ही सबसे महत्वपूर्ण है

---

बार-बार लौटने वाले पैटर्न की शुरुआत

• हर 10 साल में यह वादा सामने आता है कि “इस बार development आसान हो जाएगा”
  • 1969 में Apollo program के बाद software एक core technology के रूप में उभरा
  • लेकिन जल्द ही स्पष्ट हो गया कि development के लिए specialized knowledge, concentration, और समय का निवेश जरूरी है
• यहीं से “development को सरल बनाकर manpower कम करें” वाला लगातार चलता सपना शुरू हुआ

COBOL: यह विश्वास कि business लोग खुद coding कर पाएंगे

• COBOL को उसके नाम Common Business-Oriented Language की तरह इस तरह design किया गया था कि business stakeholders अंग्रेज़ी जैसे वाक्यों में code लिख सकें
• लेकिन व्यवहार में logic, data structure, और system design की complexity बनी रही, और अंततः विशेषज्ञ COBOL developers की एक नई परत बन गई
• “हर कोई coding कर सकता है” वाला vision पूरा नहीं हो सका

1980 का दशक: CASE tools का auto-generation वादा

• CASE (Computer-Aided Software Engineering) tools इस वादे के साथ आए कि वे diagram से code अपने-आप generate करेंगे
• कंपनियों ने productivity में 10 गुना वृद्धि की उम्मीद से बड़े पैमाने पर investment किया
• लेकिन generated code performance issues, maintenance की कठिनाई, और model mismatch के कारण असफल रहा
• क्योंकि logical complexity की समझ अब भी जरूरी थी, इसलिए मूल समस्या हल नहीं हुई

1990 का दशक: Visual Basic और Delphi का दृष्टिकोण

• drag-and-drop approach ने UI बनाना आसान किया और development में प्रवेश की बाधा कम की
• simple applications बनाना संभव हुआ, लेकिन integration, security, performance, और maintenance वाले complex systems के लिए अब भी skilled developers की जरूरत रही
• नतीजतन developers की demand घटी नहीं, बल्कि और बढ़ी

2000 के बाद: web frameworks, low-code, no-code

• Ruby on Rails ने “convention over configuration” को आगे रखा, और low-code·no-code platforms ने “code के बिना development” का दावा किया
• कुछ खास क्षेत्रों में speed बढ़ी और participation का दायरा भी फैला, लेकिन professional developers की जरूरत लगातार बढ़ती रही
• बार-बार लौटने वाला सवाल: “यह पैटर्न आखिर चलता क्यों रहता है?”

complexity की असली प्रकृति

• software ऊपर से भले सरल लगे, लेकिन वास्तव में detail situations और exception handling में complexity विस्फोटक रूप ले लेती है
  • उदाहरण: inventory reservation conflict, payment failure, email service outage
• इन्हीं बारीक फैसलों में development की असली प्रकृति है, और कोई भी tool इसे हटा नहीं सकता

AI युग का नया अध्याय

• AI coding assistants natural language से code generate करते हैं, और explanation, debugging, तथा improvement suggestions भी देते हैं
• यह वास्तविक प्रगति है, लेकिन फिर भी problem definition, security, integration, और maintenance से जुड़े निर्णय इंसानों की भूमिका ही बने रहते हैं
• AI developers की productivity को amplify करता है, लेकिन judgment और context की समझ को replace नहीं कर सकता

फिर भी कम पड़ती development क्षमता

• technology ने तेज़ी से छलांग लगाई है, लेकिन software की demand supply से आगे बनी हुई है
• कंपनियां “और तेज़, और ज़्यादा कैसे बनाया जाए” इसका रास्ता खोजते हुए development simplification tools से उम्मीद लगाए रखती हैं
• लेकिन bottleneck typing speed या syntax नहीं, बल्कि complexity पर सोचने की क्षमता है

leaders को कौन से सवाल पूछने चाहिए

• सवाल यह नहीं होना चाहिए कि “क्या यह tool developers को replace कर देगा?” बल्कि
  • “क्या यह complex problems सुलझाने में मदद करता है?”
  • “क्या यह repetitive work कम करके creative problems पर ध्यान देने देता है?”
  • “क्या इसके लिए नई skills सीखनी होंगी?”
• ऐसे सवाल tools की सीमाओं और मानवीय सोच की अनिवार्यता को समझने में मदद करते हैं

50 साल का सबक: समस्या mechanical नहीं, intellectual है

• COBOL ने syntax सरल किया, CASE ने typing हटाने की कोशिश की, और AI पूरे functions generate कर देता है, लेकिन मूल कठिनाई अब भी बनी हुई है
• software development दरअसल ‘सोच को ठोस रूप देने की प्रक्रिया’ है, और इसे tools से replace नहीं किया जा सकता
• जैसे architectural design या medical diagnosis में, सोचने की प्रक्रिया ही मुख्य value होती है

आगे की दिशा

• नए tools आते रहेंगे, लेकिन मानवीय thinking power में investment सबसे महत्वपूर्ण रहेगा
• AI·low-code·नए frameworks के साथ प्रयोग करना चाहिए, लेकिन complexity को समझने की क्षमता को संगठन की core competency बनाना होगा
• Apollo program की तरह, tools से ज़्यादा सोच की precision ही सफलता का निर्णायक तत्व है

यह सपना बार-बार क्यों लौटता है

• “developers को replace करने का सपना” असफलता नहीं, बल्कि tool innovation को प्रेरित करने वाला optimism है
• हर कोशिश पूरी तरह replacement में भले असफल रही हो, लेकिन उसने नई पीढ़ी के उपयोगी tools ज़रूर पैदा किए
  • COBOL ने business systems development को फैलाया
  • CASE ने visual modeling को आगे बढ़ाया
  • Visual Basic ने development accessibility बढ़ाई
  • AI development के तरीके में बदलाव को तेज़ कर रहा है
• अंततः सीमा tools नहीं, बल्कि उन problems की complexity है जिन्हें हम हल करना चाहते हैं
• नए tools को ठुकराने की जरूरत नहीं, बल्कि realistic expectations और human judgment के महत्व को पहचानने की जरूरत है

[GN⁺]

Hacker News की राय

• इस बार की AI innovation की लहर को देखकर लगता है कि coding का बड़ा हिस्सा मूलभूत जटिलता नहीं, बल्कि आकस्मिक जटिलता है
  जो काम इंसानों के लिए conceptual है, वही AI के लिए procedural बन जाता है
  उदाहरण के लिए, पहले Java में public static void main(String[] args) लिखने के लिए कई concepts सीखने पड़ते थे, लेकिन AI को बस “class का entry method लिखो” जैसा prompt देने पर वह लगभग निश्चित रूप से वह code बना देता है
  जो procedural काम इंसानों के लिए कठिन है, वह AI के लिए आसान हो सकता है, लेकिन समाज ऐसी procedural labor के इर्द-गिर्द बना है, इसलिए innovation फैलने पर कुछ लोग ऊपर उठेंगे और कुछ लोग पीड़ित होंगे

  • मुझे लगता है कि सही सवाल पूछने के लिए ज़रूरी अनुभव और विशेषज्ञता को कम आंका जा रहा है

• “No-code डेवलपरों की जगह ले लेगा” वाला दावा हर बार दोहराया जाता है, लेकिन वास्तव में इसने डेवलपर की नौकरियाँ और बढ़ाई हैं
  COBOL, VB, Squarespace, और अब AI तक — जब tools entry barrier कम करते हैं, तो ज़्यादा लोग कुछ बनाना चाहते हैं, और आखिरकार limits पर पहुँचने के बाद असली developers की ज़रूरत पड़ती है
  साधारण दोहराव वाले काम गायब हो सकते हैं, लेकिन क्या बनाना है यह तय करना और debugging करना अब भी बाकी रहता है

  • मैं भी चाहता हूँ कि यह विस्तार जारी रहे, लेकिन आख़िर में यह नई demand पैदा होती है या नहीं, इसी पर निर्भर करेगा
    अगर AI खुद ही complex projects को code कर सके, तो इंसानों को details की चिंता नहीं करनी पड़ेगी, और developers की demand घट सकती है
    पहले internet, cloud, mobile, machine learning जैसे बड़े trends थे, लेकिन आगे भी ऐसे ‘बड़े problems’ आते रहेंगे या नहीं, इस पर यक़ीन नहीं है
  • यह Jevons Paradox का क्लासिक उदाहरण है — कोई चीज़ सस्ती होती है तो बाज़ार उल्टा और बड़ा हो जाता है
  • बेशक इस बार मामला अलग भी हो सकता है। अगर AI सच में वादा किया गया काम कर दे, तो developers की संख्या कम हो सकती है
  • कृषि मशीनों ने किसानों को ज़्यादा efficient बनाया, लेकिन अब उल्टा ज़्यादा किसान मौजूद हैं
  • “developers की संख्या कम नहीं होगी” यह दावा बहुत ज़्यादा निश्चित है। अगर AI debugging और requirements interpretation तक करने लगे, तो स्थिति बदल सकती है

• पिछले 20 सालों में system administration में भी यही pattern देखा है
  “ऊँची abstraction से experts का काम लोकतांत्रिक हो जाएगा” यह वादा बार-बार आता है, लेकिन हक़ीक़त में महँगा reinvention होता है
  Kubernetes जैसे tools ने कहा कि उन्होंने complexity को ढक दिया है, लेकिन आखिर में developers बुनियादी concepts जाने बिना वही problems ज़्यादा महँगे तरीके से फिर सीख रहे होते हैं
  Excel इसका प्रतिनिधि उदाहरण है — इसने भयानक errors पैदा किए, लेकिन accessibility की वजह से सफल रहा
  आख़िरकार हम “Excel की accessibility और engineering की reliability” दोनों एक साथ चाहते हैं, लेकिन दोनों नहीं मिल सकते

  • तो क्या non-deterministic software इस्तेमाल करने पर insurance premium या compensation policy बदल जाएगी?
  • अगर Kubernetes ने labor कम नहीं किया, तो इसका मतलब हुआ कि बड़ी कंपनियों के 95% लोग मूर्ख हैं
    असल में scale बढ़ने के साथ काम की complexity ऊपर खिसक गई है
  • हर abstraction आख़िरकार leaky abstraction होती है। C में भी compiler के हिसाब से नतीजे बदल जाते हैं

• यह pattern बार-बार इसलिए दोहराया जाता है क्योंकि market incentives ऐसे हैं
  कंपनियों को AI को सर्वशक्तिमान समाधान की तरह पेश करना पड़ता है ताकि stock price बढ़े, इसलिए यह असली performance से ज़्यादा विश्वास बेचने की संरचना बन जाती है
  आखिर में जब हक़ीक़त सामने आएगी, तो बाज़ार में उथल-पुथल होगी

  • बाज़ार कोई गुरुत्वाकर्षण का नियम नहीं है। राजनीतिक व्यवस्था हो तभी बाज़ार मौजूद होता है
  • अगर product सच में वादे के मुताबिक काम कर रहा होता, तो वे “skeptics की आलोचना” पर ध्यान देने के बजाय development में लगे होते

• असल में developers की संख्या कम की जा सकती थी
  अगर कंपनियाँ ज़्यादा चयनात्मक hiring और training investment करतीं तो
  लेकिन हक़ीक़त उलटी रही, और web frameworks productivity बढ़ाने से ज़्यादा training cost घटाने और talent pool बढ़ाने के लिए बनाए गए

  • मैं सहमत नहीं हूँ। अच्छे frameworks maintainability और productivity बढ़ाते हैं

• middle management और executives technical departments को सिर्फ़ cost center मानते हैं
  इसलिए वे हर press release में AI का ज़िक्र करते हुए labor cost कटौती की बात करते हैं
  हक़ीक़त में वे AI की वजह से नहीं, बल्कि offshore workforce replacement से cost घटा रहे हैं
  बची हुई onshore teams ज़्यादा काम उठाकर productivity बढ़ा रही हैं

  • लेकिन offshore क्षेत्रों में भी layoffs उसी तरह हो रहे हैं
    labor cost कटौती नहीं, बल्कि कुल मिलाकर investment contraction इसकी वजह है
    आखिर में AI data center investment के ज़रिए capital को खींचकर jobs घटा रहा है
  • “sales product के बिना अस्तित्व में नहीं रह सकती” इस दावे के इतिहास में कई counterexamples हैं

• AI का उद्देश्य developers को replace करना नहीं, बल्कि abstraction level बढ़ाकर और ज़्यादा complex problems संभालने लायक बनाना है
  शुरुआती computers की wiring programming से शुरू होकर assembly, C, Python, frameworks तक आते-आते developers लगातार ऊँचे स्तर की समस्याएँ संभालने लगे
  लेकिन फ़र्क यह है कि पहले के सभी चरण deterministic और verifiable transformations थे, जबकि generative AI non-deterministic है
  इससे जुड़ी कहानी के लिए The Story of Mel देखी जा सकती है

  • लेकिन Anthropic के CEO समेत कंपनियाँ ऐसे दार्शनिक लक्ष्य से ज़्यादा cost cutting और replacement में दिलचस्पी रखती हैं
  • फिर भी लोग “developers replacement” की बात करते रहेंगे
  • abstraction के हर चरण में अंदर झाँक पाने की क्षमता होनी चाहिए
    LLM में compiler की तरह tokens, AST, IR वगैरह नहीं देखे जा सकते, इसलिए यह opaque है
  • AI कंपनियों का असली लक्ष्य सारे बौद्धिक श्रम का automation है
  • abstraction जितनी बढ़ती है, precision और control उतने घटते हैं
    natural language पर आधारित non-deterministic systems पिछली पीढ़ियों की abstraction से अलग हैं
    इसलिए “assembly से C में संक्रमण” वाली तुलना उपयुक्त नहीं है

• Dijkstra के शब्दों में, विज्ञान कठिन होने के कारण नापसंद किया जाता है, और उसकी शक्ति रखने वाले वैज्ञानिक भी नापसंद किए जाते हैं
  EWD1041 मूल लिंक

• इसके उलट, developers हमेशा से ग़ैर-डेवलपर भूमिकाओं को automate करने का सपना देखते आए हैं
  AI उस सपने का सबसे नया संस्करण है

  • क्या कभी हर नौकरी एक अच्छी नौकरी बन जाने वाली Star Trek जैसी दुनिया आएगी?

• 2000 के दशक की शुरुआत में, विश्वविद्यालयों में Rational Rose UML एक अनिवार्य विषय था
  उस समय एक startup CEO ने कहा था, “अब सिर्फ़ diagram बनाओ, code अपने-आप generate हो जाएगा, इसलिए developers की ज़रूरत नहीं रहेगी”
  लेकिन आखिरकार वह भविष्यवाणी सच नहीं हुई

[kayws426]

मशीनें मशीनों के लिए कोड बनाती हैं.
मशीन भाषा के ऊपर इंसानों ने जो रेत का महल बनाया है, उसका अंततः ढहना तय है.
...ऐसी बातें भी की जा सकती हैं, lol