AI जब बेहोश करता है, तो एक व्यक्ति नहीं बल्कि पूरा संगठन होता है: विमानन और चिकित्सा ने पहले झेली ऑटोमेशन की विडंबना

AI को अच्छी तरह संभालने की क्षमता और उसके आउटपुट को सत्यापित करने की क्षमता दो अलग अक्ष हैं, और एक बढ़ता है
तो दूसरा चुपचाप घिसता जाता है। यह लेख उस घिसावट के व्यक्ति नहीं बल्कि संगठन-स्तर पर
फैलने की प्रक्रिया और नेताओं द्वारा उसका संरचनात्मक जवाब देने के तरीकों पर चर्चा करता है।

• AI निम्न-स्तरीय श्रम को छिपाने वाली abstraction नहीं, बल्कि उसकी जगह बैठने वाला probabilistic agent है। React·ORM जैसी पुरानी abstractions में ज़रूरत पड़ने पर सीढ़ी उतरकर causality की पुष्टि की जा सकती थी, लेकिन AI के ऊपर उतरने के लिए वैसी सीढ़ी है ही नहीं।
• मुख्य अवधारणा है cognitive ownership, यानी "ऐसी अवस्था जिसमें यह शुरू से अंत तक समझाया जा सके कि यह कोड आखिर इस तरह क्यों लिखा जाना आवश्यक था।" सवाल यह नहीं कि कोड किन हाथों से गुज़रा, बल्कि यह कि उसका कारण-क्रम किसके दिमाग़ में मौजूद है।
• AI कौशल को नहीं, बल्कि plausibility को समतल करता है। कोड गुणवत्ता के वितरण का सिर्फ़ न्यूनतम स्तर ऊपर उठा है; कौशल नहीं बढ़ा। और मॉडल जितने बेहतर होते जाते हैं, यह बात उतनी ही कम दिखाई देती है कि causality अंदर से खाली है।
• generation cost लगभग 0 पर पहुँचती है, लेकिन verification cost वही रहती है। 1 सेकंड में बने कोड को 1 घंटे जाँचने वाला व्यक्ति संगठन के metrics में सबसे धीमा दिखने लगता है; इस आर्थिक दबाव में critical acceptance सिर्फ़ इच्छाशक्ति के दम पर टिक नहीं सकती।
• लेख विमानन·neuroscience·चिकित्सा से आए पहले के उदाहरणों का हवाला देता है: ऑटोमेशन की विडंबना (Bainbridge, 1983), Air France Flight 447, GPS पर निर्भर लोगों में hippocampus का संकुचन, और mammography CAD के साथ sensitivity में कमी।
• समाधान व्यक्ति के संकल्प में नहीं, टीम की संरचना में होना चाहिए। ownership की inefficiency को "नैतिकता" नहीं बल्कि "insurance premium" की तरह accounting में दर्ज करने का प्रस्ताव है।

विस्तृत सारांश

AI abstraction नहीं, agent है

• पुराने टूल deterministic थे (एक ही input पर एक ही output), इसलिए causality को ट्रेस किया जा सकता था। AI probabilistic agent है; एक ही request पर हर बार अलग परिणाम आ सकते हैं। कोड पढ़ा जा सकता है, लेकिन "यह ऐसे क्यों लिखा गया" तक पहुँचने का रास्ता नहीं होता।
• जो कोड हम खुद लिखते हैं उसकी causality दिमाग़ में रह जाती है, लेकिन AI द्वारा लिखे कोड में परिणाम तो होता है, कारण-क्रम दिमाग़ से होकर नहीं गुज़रता। इसकी तुलना हर बार ऐसी भाषा के अनुबंध पर हस्ताक्षर करने से की गई है जिसे हम जानते ही नहीं।

plausibility का समतलीकरण

• इंटरव्यू लेने वाले और PR reviewer के रूप में सामने की पंक्ति से किया गया अवलोकन: variable names साफ़-सुथरे होते हैं, structure भी ठीक-ठाक लगता है, लेकिन खोलने पर duplicate functions, जिम्मेदारियों का अस्पष्ट बँटवारा, और side effects के ढेर मिलते हैं।
• सबसे ईमानदार सबूत वह क्षण है जब सवाल "यहाँ आपने ऐसा क्यों किया?" पर जवाब अटक जाता है। यही उस कोड का सीधा संकेत है जो ऊपर से ठीक दिखता है लेकिन जिसमें causality गायब है।

बेहोशी संगठन-स्तर पर फैलती है

• पहले लेखक और reviewer की दोहरी ownership के कारण causality वितरित रूप में सुरक्षित रहती थी। लेकिन जब लेखन भी AI करे और समीक्षा भी AI, तो PR की causality टीम में किसी के भी दिमाग़ में नहीं रहती।
• "AI review bot सारांश दे दे, इंसान एक नज़र डालकर LGTM कर दे" सत्यापन जैसा दिखता है, पर असल में वह causality-विहीन एक और output है। "जो कोड मैं बनाऊँ, वही मैं चलाऊँ" वाला सिद्धांत ढहने लगता है।

taste सिर्फ़ खराबी के बीच बढ़ता है

• यह "implementation AI करे, इंसान सिर्फ़ taste रखे" जैसी धारणा का खंडन है। taste अच्छे कोड को बहुत पढ़ने से नहीं, बल्कि अपने लिखे हुए के टूटने और उसी जगह उसकी causality को टटोलने के अनुभव से बनता है।
• इसमें Heidegger के hammer रूपक (औज़ार का सार उसके टूटने पर ही उजागर होता है) और Aristotle की practical wisdom का हवाला दिया गया है। AI खराबी को नहीं, बल्कि "खराबी झेलने के अनुभव" को हटा देता है, और इस तरह taste विकसित होने वाली भट्ठी ही बंद कर देता है।

जहाँ apprenticeship टूट जाती है

• पहले की abstractions ने causality को सिर्फ़ "छिपाया" था, मिटाया नहीं; इसलिए सीढ़ी बची रहती थी। लेकिन AI के ऊपर वह सीढ़ी अपने-आप नहीं बनती। क्षमता बढ़ेगी या नहीं, यह व्यक्तिगत इच्छाशक्ति नहीं बल्कि उस संरचना पर निर्भर करता है जिसमें व्यक्ति रखा गया है।
• उस सीढ़ी को टीम के भीतर कृत्रिम रूप से फिर से बिछाना है या नहीं, यह तय करने वाला व्यक्ति नेता होता है।

समाधान टीम की संरचना में होना चाहिए

• "जिस कोड की causality समझाई नहीं जा सकती, उसे merge नहीं किया जाएगा"—इसे review rule बनाना; LGTM का अर्थ बदलकर इसे "मैं इस कोड को समझा सकता हूँ" जैसी acceptance declaration बनाना; random spot

checks लागू करना

• ऐसी टीम क्षमता विकसित करना जिसमें design इंसान के हाथ में रहे और AI को देने से पहले constraints और edge cases तक specification दी जाए।
• ऐसे स्थायी ठिकाने (core domain) चुनना जिन्हें कभी न छोड़ा जाए; inefficiency को इरादतन learning path में बदलना; और सिर्फ़ speed नहीं बल्कि ownership को भी मापना, लेकिन Goodhart's law से सावधान रहते हुए इसे KPI नहीं बल्कि dashboard indicator की तरह रखना।

नेता का संकट: सत्यापित न कर पाने वाला approver आखिर मैं ही हो सकता हूँ

• जब दोहरी सहारा-व्यवस्था हट जाती है, तो नेता का क्षरण व्यक्तिगत समस्या नहीं बल्कि संगठन का default बन जाता है। नेता को जिस चीज़ की रक्षा करनी है वह हर चीज़ की खुद जाँच नहीं, बल्कि यह परखने की क्षमता है कि टीम ने जो causality लिखी है वह असली है या नहीं।
• बेहोशी होगी या नहीं, यह पूरी तरह नियंत्रित नहीं किया जा सकता; लेकिन उसके फैलने की रफ़्तार नियंत्रित की जा सकती है। लक्ष्य है "संगठन को ऐसा बनाए रखना जो थोड़ी देर और सही-गलत में फर्क कर सके।"