🤖 AI

The Substrate Collapse: AI Code Generation Invalidates Authorship-Based Knowledge Metrics

यह शोधपत्र तर्क देता है कि एआई कोड जनरेशन, कोड के स्वामित्व और मानवीय समझ के बीच के संबंध को विच्छेदित करके, 'ट्रक फैक्टर' जैसे पारंपरिक लेखक-आधारित ज्ञान मेट्रिक्स को अमान्य कर देता है, जिससे वर्जन-कंट्रोल एट्रिब्यूशन के बजाय प्रत्यक्ष बोध के साक्ष्य पर आधारित नए मापन उपकरणों की ओर बढ़ने की आवश्यकता उत्पन्न होती है।

मूल लेखक: Brett Wheeler

प्रकाशित 2026-06-23

📖 7 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Brett Wheeler

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

यहाँ "द सबस्ट्रेट कोलैप्स" (The Substrate Collapse) शोध पत्र का सरल भाषा और रोजमर्रा के उदाहरणों के साथ विवरण दिया गया है।

मुख्य विचार: नक्शा अब क्षेत्र नहीं रहा

कल्पना कीजिए कि आप यह पता लगाने की कोशिश कर रहे हैं कि एक विशाल, प्राचीन शहर के लेआउट (नक्शे) को कौन जानता है। दशकों तक, यह अनुमान लगाने का एकमात्र तरीका यह था कि इमारतें किसने बनाईं। यदि आपने किसी विशिष्ट व्यक्ति द्वारा बनाया गया घर देखा, तो आपने मान लिया, "ठीक है, वे जानते हैं कि उस घर की वायरिंग कैसी है, पाइप कहाँ चलते हैं, और अगर कोई लीवर खींचा जाए तो क्या होगा।"

यह शोध पत्र तर्क देता है कि AI ने इस नियम को तोड़ दिया है।

अब, एक रोबोट घर बना सकता है, और एक इंसान बस उसे मंजूरी देने के लिए कागजी कार्रवाई पर हस्ताक्षर कर सकता है। इंसान का नाम अभी भी दस्तावेज़ (लेखकत्व/authorship) पर है, लेकिन उन्हें इस बात की रत्ती भर भी जानकारी नहीं हो सकती कि वह घर कैसे काम करता है। शोध पत्र इसे "सबस्ट्रेट कोलैप्स" (Substrate Collapse) कहता है। आधार (निर्माण और ज्ञान के बीच का संबंध) ढह गया है, जिससे हमारे पुराने मापने के उपकरण बेकार हो गए हैं।

1. पुराना तरीका: "फॉसिल" (जीवाश्म) सिद्धांत

अतीत में, सॉफ्टवेयर इंजीनियर "ट्रक फैक्टर" (Truck Factor) जैसे मेट्रिक्स का उपयोग करते थे। यह पूछता है: "यदि हमारा मुख्य डेवलपर कल ट्रक से टकराकर मर जाए, तो क्या प्रोजेक्ट खत्म हो जाएगा?"

इसे कैलकुलेट करने के लिए, वे कोड में "फॉसिल" देखते थे:

कोड की लाइनें किसने लिखीं?
फाइलों को किसने एडिट किया?
बदलावों को किसने कमिट (commit) किया?

तर्क: यदि आपने कोड लिखा था, तो उसे लिखने के लिए आपको उसे समझना ही था। इसलिए, कोड पर आपके नाम का "पदचिह्न" (footprint) इस बात का विश्वसनीय संकेत था कि आप सिस्टम को समझते हैं। यह एक जीवाश्म खोजने जैसा था; चट्टान (कोड) इस बात का प्रमाण थी कि जानवर (समझ) वहाँ मौजूद था।

2. कोलैप्स (पतन): रोबोट बिल्डर

अब, AI टूल्स (एजेंट्स) कोड लिखते हैं। एक मानव डेवलपर AI से पूछ सकता है, "मेरे लिए एक लॉगिन सिस्टम बनाओ," और AI इसे कुछ ही सेकंड में कर देता है। इंसान इसे देखता है, शायद "Approve" बटन दबाता है, और इसे मर्ज कर देता है।

समस्या:

इंसान का नाम अब कोड पर है (पदचिह्न)।
लेकिन इंसान ने इसे लिखा नहीं है, इसलिए उसे इसे पूरा करने के लिए इसे समझने की आवश्यकता नहीं थी।
AI ने इसे लिखा, लेकिन AI इसे उस तरह से "समझता" नहीं है जिसे बाद में कोई इंसान समझा सके।

उपमा (Analogy):
कल्पना कीजिए कि एक थर्मामीटर है। सालों से, यदि थर्मामीटर 100°F दिखाता था, तो आप जानते थे कि व्यक्ति को बुखार है। वह नियम था।
अब, कल्पना कीजिए कि किसी ने एक ऐसी मशीन बनाई जो व्यक्ति के बीमार हुए बिना ही थर्मामीटर को 100°F तक गर्म कर सकती है।

थर्मामीटर अभी भी 100°F बिल्कुल सही दिखाता है।
लेकिन यह अब आपको यह नहीं बताता कि व्यक्ति बीमार है या नहीं।
टूल टूटा नहीं है; बल्कि रीडिंग और वास्तविकता के बीच का संबंध टूट गया है।

शोध पत्र कहता है कि हमारा "ट्रक फैक्टर" वही टूटा हुआ थर्मामीटर है। यह अभी भी एक नंबर देता है, लेकिन वह नंबर हमें यह नहीं बताता कि वास्तव में कौन सॉफ्टवेयर को समझता है।

3. हम पुराने टूल्स को "ठीक" क्यों नहीं कर सकते

आप सोच सकते हैं, "क्या हम सिर्फ गणित को थोड़ा बदल नहीं सकते? शायद हमें AI द्वारा लिखे गए कोड को अलग तरह से तौलना चाहिए?"

शोध पत्र कहता है कि नहीं। आप वजन को एडजस्ट करके इसे ठीक नहीं कर सकते।

उपमा: कल्पना कीजिए कि आप बाल्टी का वजन करके यह अंदाजा लगाने की कोशिश कर रहे हैं कि उसमें कितना पानी है। यदि कोई चुपके से पानी की जगह रेत भर दे, तो वजन बदल जाता है, लेकिन वजन का अर्थ खो जाता है। आप स्केल को फिर से कैलिब्रेट (recalibrate) करके यह नहीं बता सकते कि कितना पानी बचा है, क्योंकि बाल्टी अब रेत से भरी है।
"किसने कोड को छुआ" और "किसने कोड को समझा" के बीच का लिंक हमेशा के लिए खत्म हो गया है। पुराने डेटा पर कितना भी गणित लगा लें, वह वापस नहीं आएगा।

4. चेतावनी के संकेत (तनाव)

शोध पत्र बताता है कि सॉफ्टवेयर की दुनिया पहले से ही ऐसे संकेत देख रही है कि कुछ गलत है, भले ही उन्हें अभी तक ठीक से पता न हो:

"झूठी आत्मविश्वास" (False Confidence) की खाई: डेवलपर्स AI के साथ खुद को अधिक तेज़ और उत्पादक महसूस करते हैं, लेकिन अध्ययन दिखाते हैं कि वे वास्तव में धीमे हो जाते हैं क्योंकि वे अपना सारा समय यह समझने में बिता देते हैं कि AI का काम सही है या नहीं।
"चर्न" (Churn) का भ्रम: हम अधिक कोड लिखे जाने और हटाए जाने को देखते हैं, लेकिन हम यह नहीं बता सकते कि यह इसलिए हो रहा है क्योंकि लोग बग्स ठीक कर रहे हैं (अच्छा) या इसलिए क्योंकि AI गलतियाँ कर रहा है जिन्हें सुधारने के लिए लगातार काम करना पड़ रहा है (बुरा)। टूल्स अब अंतर नहीं कर सकते।
सतह बनाम गहराई: AI सतह के स्तर की छोटी गलतियों (जैसे स्पेलचेकर) को ठीक करने में बहुत अच्छा है, लेकिन यह अक्सर गहरे, तार्किक (logical) एरर पैदा करता है जिन्हें ठीक करने के लिए इंसान को वास्तव में सिस्टम को समझना आवश्यक होता है।

5. हमें इसके बजाय क्या चाहिए: "थ्योरी" को मापना, "पदचिह्न" को नहीं

शोध पत्र का तर्क है कि हमें इस पर ध्यान देना बंद कर देना चाहिए कि किसने कोड लिखा और यह मापना शुरू करना चाहिए कि वास्तव में कौन सिस्टम को समझता है।

पुराना मेट्रिक: "इस फाइल को किसने छुआ?" (लेखकत्व/Authorship)
नया आवश्यक मेट्रिक: "क्या यह व्यक्ति समझा सकता है कि सिस्टम ऐसा क्यों करता है?" (समझ/Comprehension)

चुनौती:
"समझ" को मापना "कोड की लाइनों" को गिनने से बहुत कठिन है। यह एक छात्र के पास कितनी किताबें हैं (आसान) बनाम यह टेस्ट करने के बीच के अंतर जैसा है कि क्या वह बिना किताब देखे गणित का सवाल हल कर सकता है (कठिन)।

शोध पत्र स्वीकार करता है: हमारे पास यह नया टूल अभी नहीं है। यह एक अनसुलझी समस्या है। लेकिन सबसे महत्वपूर्ण कदम यह एहसास करना है कि पुराने टूल्स मृत हैं ताकि हम उन्हें ठीक करने की कोशिश करने के बजाय नए टूल्स बनाना शुरू कर सकें।

6. भविष्यवाणी (परीक्षण)

शोध पत्र इसे साबित करने के लिए एक साहसिक भविष्यवाणी करता है:

परिदृश्य: एक सॉफ्टवेयर टीम की कल्पना करें जो कागजों पर एकदम सही दिखती है। उनका "ट्रक फैक्टर" बहुत अधिक है (कई लोगों ने कोड को छुआ है, इसलिए यह सुरक्षित दिखता है)।
वास्तविकता: क्योंकि कोड AI-जनरेटेड है, कोई भी वास्तव में इसकी गहरी लॉजिक को नहीं समझता।
परिणाम: जब कोई अजीब, नई समस्या आती है, तो टीम उसे जल्दी से ठीक करने में विफल रहती है। वे फंस जाते हैं, घबरा जाते हैं, और उसे सुलझाने में बहुत लंबा समय लेते हैं।
प्रमाण: पुराना "ट्रक फैक्टर" मेट्रिक कहेगा, "आप सुरक्षित हैं!" लेकिन वास्तविकता यह होगी, "आप मुसीबत में हैं।" यह अंतर साबित करता है कि पुराना मेट्रिक टूटा हुआ है।

सारांश

अतीत: यदि आपने कोड लिखा था, तो आप उसे समझते थे। हमने ज्ञान को यह गिनकर मापा कि किसने क्या लिखा।
वर्तमान: AI कोड लिखता है, इंसान बस उसे अप्रूव करता है। कोड पर "हस्ताक्षर" अब यह नहीं दर्शाता कि "मैं इसे समझता हूँ।"
परिणाम: हमारे पुराने सुरक्षा चेक (जैसे ट्रक फैक्टर) अब हमें झूठ बोल रहे हैं। वे यह मापते हैं कि किसने काम पर हस्ताक्षर किया, न कि किसने काम को जानता है।
समाधान: हमें वास्तविक समझ को मापने का एक नया तरीका खोजने की आवश्यकता है। जब तक हम ऐसा नहीं करते, हम अंधेरे में उड़ रहे हैं, यह सोचकर कि हम सुरक्षित हैं क्योंकि हमारे पुराने उपकरण ऐसा कह रहे हैं, जबकि "बुखार" (जोखिम) वास्तव में बढ़ रहा है।