अस्पष्ट विफलताओं का सामान्यीकरण

“अस्पष्ट विफलताओं” का दायरा

• टिप्पणीकारों को लगता है कि अपारदर्शी, डिबग न होने वाली विफलताएँ अब कई जगहों पर अधिक आम हो गई हैं:
  • क्लाउड सेवाएँ और API, जो कभी-कभी 5xx के साथ विफल होते हैं और जहाँ “बस retry करो” ही सामान्य जवाब है।
  • उपभोक्ता उपकरण (खासकर कारें) जिनमें अस्पष्ट चेतावनियाँ और अनियमित कनेक्टिविटी दिखती है, लेकिन स्पष्ट निदान नहीं मिलता।
  • रोज़मर्रा का सॉफ़्टवेयर/OS व्यवहार, जहाँ “बंद करो और फिर चालू करो” de facto समाधान बन गया है।
• कुछ लोगों का तर्क है कि यह हमेशा से सच था; दूसरों के अनुसार “move fast and break things,” निरंतर deployment, और घटे हुए QA ने इसे स्पष्ट रूप से बदतर बनाया है।

निर्धार्यता, प्रायिकतामूलक प्रणालियाँ, और AI

• निर्धार्य प्रणालियों की सराहना उनके पूर्वानुमेय failure modes और स्पष्ट contracts के लिए की जाती है; प्रायिकतामूलक/LLM-आधारित प्रणालियों को शक्तिशाली लेकिन समझने या गारंटी देने में कठिन माना जाता है।
• चिंता: core libraries, infrastructure, और compilers में प्रायिकतामूलक व्यवहार को सामान्य बनाना पूरे stack की विश्वसनीयता को कमजोर कर सकता है।
• प्रत्युत्तर: AI-जनित code भी एक बार लिखे जाने के बाद deterministic ही होता है; असली समस्या maintainability और design quality है, probability अपने-आप में नहीं।

इंजीनियरिंग संस्कृति, गुणवत्ता, और जवाबदेही

• इस पर असहमति है कि क्या “bugs अपरिहार्य हैं”:
  • एक पक्ष: bugs मूलतः एक business choice हैं; “no bugs” संभव है लेकिन अधिकांश के लिए बहुत महँगा।
  • दूसरा पक्ष: गहरे stacks और जटिल distributed systems कुछ विफलताओं को व्यावहारिक रूप से अपरिहार्य बना देते हैं; अपूर्णता और resilience के लिए design करें (जैसे chaos testing)।
• कथाएँ:
  • overengineering बनाम YAGNI बहसें, जहाँ edge cases को तब तक नज़रअंदाज़ किया जाता है जब तक वे नुकसान न पहुँचाएँ।
  • enterprises, cron restarts और horrendous tail latencies के प्रति सहनशीलता से, systemic issues को ढकते रहते हैं।
• कई लोग “inexplicability” को जवाबदेही की कमी से जोड़ते हैं: दोष vendors, clouds, या अब “AI” पर डाला जा सकता है।

उपयोगकर्ता अनुभव और error reporting

• अपारदर्शी error dialogs (“something went wrong”) की व्यापक आलोचना होती है।
• बहुत से लोग अस्पष्ट alerts की बजाय विस्तृत, यहाँ तक कि तकनीकी, messages और सही logging पसंद करेंगे।
• minimalist “it just works” design का एक “evil twin” माना जाता है: “यह बस काम नहीं करता, और आप कारण देख भी नहीं सकते।”

उच्च-दांव वाले डोमेन और अलग-अलग सहनशीलता

• पारंपरिक banking और aviation को ऐसे domains के रूप में उद्धृत किया जाता है जो अभी भी low error rates और traceable behavior की माँग करते हैं, हालाँकि अपवाद और consumer-visible banking glitches भी मौजूद हैं।
• तर्क है कि ऐसे domains का exposure developers के standards बढ़ाएगा; अन्य लोग management incentives (speed, cost) को quality concerns पर हावी बताते हैं।

LLMs, agentic dev, Jev, और evals

• बहुत से लोग LLMs का भारी उपयोग करते हैं और रिपोर्ट करते हैं कि वे:
  • development को तेज़ करते हैं, tests सहित।
  • strong testing और determinism/reproducibility culture के साथ होने पर bugs को जल्दी introduce भी कर सकते हैं और fix भी कर सकते हैं।
• चिंताएँ:
  • “vibe-coded” OSS और business software: अधिक features, लेकिन असंगत UX, performance issues, और debug करने में कठिन व्यवहार।
  • managers AI का उपयोग अधिक और तेज़ ship करने के लिए करें, जिससे silent 10% failure rates को “good enough” के रूप में सामान्य बना दिया जाए।
• Jev जैसी classification services:
  • कुछ लोग इसके confidence scores को validate करके मजबूत, cost-effective performance पाते हैं।
  • अन्य लोग ज़ोर देते हैं कि यह validation (evals, benchmarks, A/B tests) ही वह चीज़ है जिसकी अक्सर कमी होती है; tool के अपने confidence पर independent evals के बिना भरोसा करना खतरनाक कहा जाता है।
• व्यापक सहमति: अच्छे evals कठिन हैं, लेकिन आवश्यक हैं। इनके बिना, रोमांचक AI demos वास्तविक दुनिया के mediocre performance को छिपा सकते हैं और अस्पष्ट विफलताओं की संस्कृति को और गहरा कर सकते हैं।