अगर कोडिंग हल हो गई है, तो सॉफ्टवेयर लगातार खराब क्यों हो रहा है?

• AI tools ने development productivity और team capability बढ़ाई है, लेकिन software quality और stability उतनी नहीं सुधरीं, इसलिए users अब updates के बाद पहले से खराब experience की ही उम्मीद करने लगे हैं
• banking app में बार-बार FaceID authentication, Slack का focus छीन लेना, LG warranty application fail होना, car infotainment errors जैसी रोज़मर्रा की bugs finance, work, customer support और driving तक में बाधा डालती हैं
• पहले के अपेक्षाकृत सरल दौर के उलट, नई abstractions, frontend frameworks और infrastructure complexity जमा होती गई है; बढ़ते user experience standards के साथ systems लगातार fragile होते जा रहे हैं
• latest models और पर्याप्त token budget होने पर भी stability improvements KPI या presentation decks में अलग से चमकना मुश्किल है, इसलिए companies bug fixes के बजाय new features और redesigns को प्राथमिकता देती हैं
• जब companies AI debt जमा कर रही हैं, individual developers ऐसे software बनाने की कोशिश कर सकते हैं जो पहले उनके लिए मुश्किल था; macOS और Windows के खिलाफ प्रतिक्रिया everyday software improvement तक फैल सकती है

---

AI युग में भी बिगड़ता user experience

• AI hype के बीच लोग सब कुछ automated हो जाने से पहले market value हासिल करने के लिए जरूरत से ज्यादा tokens खर्च कर रहे हैं
  • model performance में सुधार, लगातार programmers की layoffs, और साल के अंत तक AI द्वारा 100% code लिखे जाने की भविष्यवाणी चिंता बढ़ा रही है
• agent era ज्यादा productivity और quality का वादा करता है
  • नए tools software बनाने और इस्तेमाल करने के तरीकों को पहले ही बदल चुके हैं
  • management अब teams से अधिक output मांग रही है, और संभव है कि software teams की average capability भी पहले से अलग स्तर पर पहुंच गई हो
• लेकिन वास्तविक products अक्सर बुनियादी stability तक सुनिश्चित नहीं कर पाते
  • banking app 3D Secure confirmation screen आने तक औसतन तीन बार FaceID login मांगता है
  • macOS के लिए Slack देर से खुलने के बाद Ghostty का focus छीन लेता है, जिससे terminal में टाइप किया जा रहा git pull command group chat में भेज दिया जाता है
  • LG refrigerator warranty application कई fields वाले multi-step form के final submission step पर fail हो गया, और error समझने के लिए JavaScript console देखना पड़ा
  • car infotainment update के बाद हर drive में reboot होने लगा, turn indicator sound गायब हो गई या Google Maps की जगह radio खुल गया, और screen input में भी 1–2 seconds की delay होने लगी
  • car errors सिर्फ UX inconvenience नहीं, बल्कि driving concentration तक घटाते हैं
• car OS redesign team के PM ने LinkedIn पर result का जश्न मनाया, लेकिन actual users को product से जूझते रहना पड़ा
• इन teams के पास latest models और भरपूर token budget इस्तेमाल करने की संभावना है, और मौका मिलने पर LLMs भी bug fixing में शानदार performance दे सकते हैं

complexity और KPI का quality को पीछे धकेलने वाला ढांचा

• software में हमेशा bugs रही हैं, और macOS Snow Leopard के दौर को पूरी तरह stable मानने वाली nostalgia में selective memory भी शामिल है
  • अगर past software बेहतर था, तो मुख्य वजह यह थी कि वह आज की तुलना में कहीं ज्यादा simple था
  • उसके बाद नई abstractions, frontend frameworks और अधिक infrastructure complexity जुड़ती गई
  • user experience के standards लगातार बढ़े, लेकिन overall system उलटे और ज्यादा fragile हो गए
• macOS और उस पर निर्भर apps के updates अब उम्मीद से ज्यादा चिंता का विषय बन गए हैं, और users पहले यही मानते हैं कि नया version पुराने से खराब हो सकता है
• समस्या AI itself से ज्यादा इस बात में है कि AI को किस काम में प्राथमिकता से लगाया जा रहा है
  • GPU infrastructure ने developers को powerful capabilities दी हैं, लेकिन बेहतर software बनाने में उनका पर्याप्त इस्तेमाल नहीं हो रहा
  • software companies लंबे समय से KPI-centric तरीके से चलती रही हैं, और stability improvements सीधे metrics में दिखाई नहीं दे सकते
  • एक quarter तक new features और redesign रोककर केवल bug fixing पर focus करने की योजना presentation deck में आकर्षक दिखना मुश्किल है
• अगर ये priorities नहीं बदलतीं, तो software quality decline भी जारी रहना तय है

individual developers के लिए खुला अवसर

• जब companies सामूहिक रूप से AI debt में फंस रही हैं, individual developers को ऐसा software बनाने का मौका मिल रहा है जो पहले उनकी क्षमता से बाहर होता
• car Android Auto या LG website से expectations कम हैं, लेकिन current state को लेकर जमा dissatisfaction everyday software सुधारने की ताकत बन सकती है
  • macOS और Windows की मौजूदा स्थिति के खिलाफ backlash movement पहले ही दिखाई दे रहा है
  • उम्मीद है कि यह trend पूरे software stack में फैल सकता है

[GN⁺]

Hacker News की राय

• पहले लोग इस उम्मीद में अपडेट करते थे कि कौन-सा नया फीचर मुफ्त में मिलेगा, और Fedora Workstation 45 के बदलाव भी ढूँढते थे, लेकिन अब फ़ोन, TV, कार और non-Linux operating systems के अपडेट से पहले डर लगता है
  चिंता रहती है कि कहीं फिर से अनचाहे फीचर और बाहरी कनेक्टिविटी न जोड़ दी जाए, और macOS तो बहुत पहले से उत्साह खत्म कर चुका है, जैसे window resize करने के लिए छोटी-सी transparent boundary खोजनी पड़े
  Windows 11 में security updates के बाद अनचाही connected features या AI फीचर्स फिर से सुझाने जैसे dark patterns दिखते हैं

  • अब ‘अपडेट लंबित है’ आइकन दिखे तो पहले यही चिंता होती है कि इस बार क्या बिगड़ेगा
    वीडियो गेम्स को छोड़कर लगभग हर software update बुरा लगता है, और Dead By Daylight में भी बस यही तसल्ली है कि developer Behaviour की अयोग्यता गेम के अंदर तक ही सीमित है
  • जिन software updates से डर नहीं लगता, वे free/open source software (FOSS) के हैं
    proprietary software अब उपयोगकर्ताओं के लिए नहीं बनाए जाते, लेकिन कुछ FOSS अब भी user-first हैं
  • Windows के cumulative security updates में अपने-आप नए operating system features शामिल नहीं होते, और Pro edition में कम-से-कम पहले quality/feature updates को skip किया जा सकता था
    इसकी जगह auto-updating Store/AppX packages के जरिए ‘connected experiences’ पहुँचाए जाते हैं, और patch के बाद reboot पर OOBE चलाकर फीचर्स फिर से सुझाए या enable किए जाते हैं
    तकनीकी रूप से ये security update से बँधे नहीं हैं, लेकिन user को नज़रअंदाज़ करने वाला dark pattern फिर भी हैं

• इन tools और Silicon Valley की ‘move fast and break things’ संस्कृति ने मिलकर टीम उत्पादकता को लेकर management की अपेक्षाएँ बढ़ा दी हैं, और उन्हीं अपेक्षाओं को संभालना सबसे पीड़ादायक है

• software जल्दी बनाया जा सकता है, लेकिन उसके सही होने का भरोसा पाने में ज़्यादा समय लगता है
  AI code generation से कोई अनुभवी engineer वह काम एक घंटे में बना सकता है जो पहले एक हफ्ता लेता था, लेकिन यह correctness verification time कम नहीं करता
  कई developers सिर्फ generation speed का फायदा लेते हैं और stability, performance, और bug-free होने की जाँच की लागत को नज़रअंदाज़ करते हैं, हालांकि mass-market software की quality गिरना AI से पहले भी जारी था

  • समान quality मानें तो 1 हफ्ते को 1 घंटे में बदल देना बेहद आदर्श स्थिति जैसा है; आम तौर पर असर इतना होता है कि दो-तीन घंटे का काम एक घंटे में हो जाए
    काम के हिसाब से असर बहुत बदलता है, लंबी परियोजनाओं में यह linear तरीके से scale नहीं करता, और कभी-कभी AI उल्टा और बड़ी देरी पैदा करता है
    quality को नज़रअंदाज़ करें तो बहुत तेज़ी मिल सकती है, लेकिन AI के बिना भी quality की परवाह न करें तो काम और तेज़ हो जाता है
  • भरोसा विकास अवधि से नहीं, बल्कि production में काम कर चुके समय से आता है
    चाहे development कितना भी लंबा हो, field में 3 महीने ठीक से चले नतीजे ज़्यादा भरोसेमंद होते हैं, इसलिए जल्दी और बार-बार release करना चाहिए

• software quality हमेशा market incentives से तय हुई है, और AI अपने-आप robust software बनाने की प्रेरणा नहीं देता
  market उन apps या कई independent solutions के संयोजन के बजाय Microsoft के one-stop products चुनने पर इनाम देता है जो हर update में न टूटें
  पहले कंप्यूटर की क्षमता और ज्ञान की कमी के कारण ऐसा पूरी तरह नहीं हो पाता था; अब उद्योग ने मानो software के किसी तरह टिके रहने की न्यूनतम शर्तें और वह सीमा खोज ली है जहाँ तक user छोटी-मोटी असुविधाएँ सह लेते हैं

  • क्या लोगों को छोड़ने या नुकसान उठाने के ठीक पहले की हालत में लगातार रोके रखना सचमुच वह बिंदु है जहाँ समाज टिकेगा, इस पर संदेह है
  • पूर्णता और सटीकता 90~99% दायरे में पहुँचते ही लागत वक्र asymptotically बहुत ऊपर चला जाता है, इसलिए मुनाफे के नज़रिए से उसमें निवेश करना उचित नहीं लगता
    पूरी तरह सही और सटीक software तभी बनता है जब defects से कानूनी ज़िम्मेदारी का जोखिम बड़ा हो
  • quality गिरने के बावजूद लोग कब तक उपभोग करते रहेंगे, और किस व्यावहारिक सीमा बिंदु पर जाकर कहेंगे “अब बहुत हुआ”, यह जानने की जिज्ञासा है

• KDE Plasma के Wayland में यह नियंत्रित करने के लिए global setting है कि कौन-सी window focus छीन सकती है, और यह बहुत अच्छी तरह काम करती है
  काम के Mac या Windows PC का उपयोग करते समय यह फीचर बहुत याद आता है; दस्तावेज़ में इसे ‘Focus stealing prevention’ के तहत देखा जा सकता है: https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehavi...

  • लगातार बिगड़ते software से बचने का पक्का तरीका FOSS और Linux/KDE पर जाना है
    यह ऐसा माहौल लगता है जैसे Windows 7 धीरे-धीरे सुधरते हुए उपयोगी परिपक्वता तक पहुँच गया हो
    NixOS में लंबे समय से library loading के n² होने के कारण GUI programs धीरे शुरू होने की समस्या है, लेकिन N100 mini PC पर भी सब कुछ लगभग 1 सेकंड के भीतर चल जाता है और 4K 240Hz HDR monitor भी स्मूदली संभल जाता है
    सबसे बढ़कर, कंप्यूटर वही करता है जो उसे कहा जाता है
  • ऐसा नहीं कि macOS में focus stealing prevention नहीं है; बल्कि लगता है कि इसके designers ने ऐसी स्थिति की कल्पना ही नहीं की जिसमें app launch में देरी हो
    अगर user इंतज़ार करते-करते कोई और input दे दे, तो यह संकेत हो सकता है कि वह अब उस app को focus नहीं देना चाहता, लेकिन design मानो सिर्फ उसी आशावादी स्थिति पर आधारित है जिसमें app तुरंत खुल जाता है
  • आज की तकनीक में सबसे पीड़ादायक चीज़ है यह अपूर्वानुमेयता कि user के दबाने ही वाला होने पर interface बदल जाए
    touch keyboard के सुझाए गए शब्द उंगली लगने से ठीक पहले बदल जाते हैं, और iOS Liquid Glass या अस्थिर web apps में तो buttons भी हिल जाते हैं
    pop-ups और “क्या आपको यह app पसंद है?” जैसे engagement prompts भी भरे पड़े हैं
    Windows का focus stealing 1995 में भी समस्या था, और 100ms के अंतराल पर दोहराए जाने वाले ऐसे अचानक बदलाव मांसपेशियों की startle response और limbic system को लगातार उत्तेजित करते रहते हैं, जिससे कुछ घंटों बाद शरीर काँपने लगे
    slot machine जैसे stimuli और clicks गिनने वाले engagement metrics को रोककर लोगों को काम पर ध्यान लगाने देना चाहिए
  • यह शानदार फीचर है, लेकिन अभी ‘Low’ से ऊँचे prevention levels पर यह जरूरत से ज़्यादा आक्रामक blocking करने वाले bug से प्रभावित है: https://bugs.kde.org/show_bug.cgi?id=509990
  • Windows में Slack background में load होता है और तैयार होने पर सिर्फ taskbar icon blink करता है, इसलिए user खुद switch करने तक यह मौजूदा app का focus नहीं छीनता

• जब उपयोगकर्ता input दे रहा हो या UI के साथ interact कर रहा हो, तब किसी भी दूसरे app को कभी भी focus नहीं लेना चाहिए; focus चोरी debounce default होना चाहिए
  चाहे popup, sound, या icon flashing का इस्तेमाल हो, जो app अभी किए जा रहे काम से असंबंधित है उसे input hijack नहीं करने देना चाहिए
  Cisco AnyConnect की तरह connect button दबाने के बाद सिर्फ connect हो जाने के कारण exception माँगने की भी ज़रूरत नहीं होनी चाहिए, और जैसे terminal app द्वारा STDIN छीन लेना स्वीकार्य नहीं है, वैसे ही GUI में भी इसे अनुमति नहीं मिलनी चाहिए

  • ऐसी स्थिति practically होती ही नहीं जिसमें कोई उपयोगकर्ता चाहे कि focus अपने-आप छिन जाए, फिर भी यह behavior default है और बार-बार होता है, यह समझ से बाहर है
  • macOS में भी नए खोले गए app को focus से बाहर रखा जा सकता है, और laptop को लंबे समय तक reboot न करने पर यह लगातार होता है
    यह bug हो सकता है, लेकिन अगर app launch पूरा होने से पहले उपयोगकर्ता किसी दूसरी window पर click कर दे, तो यह उल्टा एक उचित feature भी हो सकता है
  • operating system की event queue process और window के पार काम करती है, इसलिए इसे simple debounce करना आसान नहीं है
    X11 की तरह नए window को focus न देना संभव है, लेकिन शायद ज़्यादातर उपयोगकर्ता यही behavior नहीं चाहेंगे
  • popup, warning sound, और icon flashing भी काफ़ी बुरी रुकावटें हैं, और उपयोगकर्ता की एकाग्रता उनसे भी ज़्यादा कीमती है

• समस्या मूल रूप से code लिखने की क्रिया नहीं थी, बल्कि किसी चीज़ को सावधानी और कठोरता से बनाने की प्रक्रिया थी
  software development ने लंबे समय में आदतों, safety guardrails, और tested structures को जमा करते हुए प्रगति की, लेकिन अब हम सिर्फ समस्या का वर्णन करते हैं और बहुत तेज़ी से generate हुए नतीजों की ठीक से समीक्षा भी नहीं कर पाते, यहाँ तक कि क्या deploy किया यह भी पता नहीं रहता
  जैसे हस्तनिर्मित furniture factory-made माल में बदल गया, जहाँ यह भी पता नहीं चलता कि किसने कौन-सा हिस्सा बनाया और चीज़ें टिकाऊ भी नहीं रहीं, वैसे ही software भी समझ के बिना assembly और deployment के चरण तक पहुँच गया है
  घटियापन जमा होता जाएगा, लेकिन यह फिर से चीज़ों को ठीक से बनाने के तरीके पर गंभीरता से सोचने वाले एक नए चक्र की शुरुआत भी हो सकती है

  • NPM left-pad घटना को भी अब 10 साल हो चुके हैं, supply chain attack और SBOM की चर्चा भी पुरानी है, और SourceForge तो distribution files में adware तक जोड़ चुका है
    अगर code review किया ही नहीं जा रहा, तो AI को code लिखने देना PIP या NPM install को बिना समीक्षा चलाने से कोई खास ज़्यादा बुरा नहीं है

• coding solve हो गई है यह मान्यता ही ग़लत है, इसलिए software लगातार बदतर होता जा रहा है

  • coding भले solve हो गई हो, लेकिन वह शुरू से bottleneck थी ही नहीं
    coding बहुत पहले से सस्ती थी और कंपनियाँ सबसे सस्ते लोगों को outsource करती रही हैं, लेकिन समस्या पहचानने और समाधान design करने की क्षमता अलग चीज़ है
    code asset से ज़्यादा debt है, इसलिए सिर्फ उतना ही लिखा जाना चाहिए जितना वास्तविक समस्या हल करने के लिए न्यूनतम हो, और इसके लिए engineer चाहिए
    AI output की समीक्षा करके और उसकी गलतियाँ ठीक करके देखें तो समय लगभग उतना ही लगता है जितना खुद लिखने में, इसलिए काम में बड़ी मदद नहीं मिलती
  • असली समस्या यह नहीं है कि coding solve हो गई है, बल्कि यह मान लेना है कि ऐसा हो चुका है

• मैं इस बात से सहमत हूँ कि software बदतर हो रहा है, लेकिन इसका दोष सिर्फ AI पर नहीं डाला जा सकता
  streaming का TV पर cast fail होना, browser में 500 error, और सार्वजनिक touchscreen पर blue screen पहले से मौजूद थे
  programmers की संख्या geometric रूप से बढ़ गई है और उनमें से आधे के पास कुछ ही साल का अनुभव है; ऊपर से सिर्फ single-threaded algorithm practice से distributed systems, CQRS, event sourcing, auditability, और idempotency को नहीं संभाला जा सकता
  इसके अलावा जब गैर-तकनीकी product owner (PO) lifecycle पर कब्ज़ा कर लेते हैं और MVP के happy path को ही implement करवाते हैं, तो bugs और भविष्य के rewrite तय हो जाते हैं
  languages C++ से Java, JavaScript, और Python तक beginner-friendly हुई हैं, लेकिन काम enterprise distributed systems, 24x7 operation, लाखों users, security, और machine learning के कारण और जटिल हो गया है

  • MVP ख़त्म होते ही उसे जादू की तरह shipped product मान लिया जाता है, और जब तक team सुधार का तरीका समझे, management फिर से organization को reshuffle कर देता है
    executive promotion और department merger को 'रोमांचक खबर' बताकर पेश किया जाता है, और product improvement की continuity गायब हो जाती है
  • product manager-केंद्रित सोच और MVP obsession quality गिरने के बड़े कारण हैं
    agile को शब्दशः और मूर्खतापूर्ण ढंग से लागू करने की ज़रूरत नहीं है; infrastructure हो या user-facing app, पहले के products, competitors, और team के अनुभव के आधार पर 3, 6, 12 महीने बाद ज़रूरी होने वाली features की योजना बनाई जा सकती है
    जैसे GPS follow करते समय हम पूरा route और अगले तीन steps भी देखते हैं, वैसे ही agile का मतलब यह नहीं कि एक कदम खत्म होने तक अगले कदम के बारे में पहली बार सोचना भी शुरू न किया जाए
  • programming को इतना सरल बना दो कि कोई भी कर सके, तो सचमुच कोई भी करने लगेगा
  • Uncle Bob भी अब AI को पूरी तरह अपनाकर समस्या का हिस्सा बनने के जोखिम में हैं
  • AI quality गिरने का कारण न भी हो, फिर भी यह पतन को तेज़ कर रहा है
    अगर मशीन bed को 150% faster बनाती है लेकिन defect rate 70% है, तो defective products बढ़ेंगे, woodworking expertise मिटेगी, और कारीगरों की motivation व उपयोगिता दोनों घटेंगी
    भले किसी दिन मशीन बेहतर हो जाए, तब तक बहुत-से लोगों को घटिया bed पर सोना पड़ेगा

• LLM पूरे codebase को एक साथ पढ़कर, समझकर, फिर उस समझ के आधार पर निर्णय नहीं ले सकता
  programming का कठिन हिस्सा कोई एक function या class नहीं, बल्कि यह है कि वे एक विशाल system में एक-दूसरे के साथ कैसे interact करते हैं; software का scale मूल रूप से LLM context window से बड़ा है
  context window बड़ी हो जाने पर भी यह इंसानों की तरह समझ जमा नहीं करता, इसलिए यह नहीं कहा जा सकता कि AI ने coding solve कर दी है
  नए project में यह उपयोगी है, लेकिन नया software जल्दी बनाना तो पहले भी पुराने code पर काम करने से आसान था