संज्ञानात्मक ऋण: जब गति समझ से आगे निकल जाती है

• AI-सहायित डेवलपमेंट कोड प्रोडक्शन की गति को इंसानी समझ की गति से भी तेज़ बना रहा है, और ‘संज्ञानात्मक ऋण (cognitive debt)’ पैदा हो रहा है
• भले ही कोड सही चले और टेस्ट पास कर ले, ऐसी स्थिति जमा होती जाती है जिसमें डेवलपर खुद कोड की संरचना और उसके पीछे के कारण को नहीं समझता
• रिव्यूअर की समीक्षा-सीमा, संगठन की अप्रकट ज्ञान-हानि, नए डेवलपर्स की सीखने में कमी जैसी चीज़ें इस ऋण को और तेज़ करती हैं
• संगठन सिर्फ गति-केंद्रित मेट्रिक्स (DORA, story points आदि) मापते हैं, इसलिए समझ की कमी पकड़ में नहीं आती
• उत्पादकता और समझ के बीच की खाई जितनी बढ़ती है, उतना ही लंबे समय में मेंटेनेंस विफलता, ज्ञान-विच्छेद और इंजीनियरों की वृद्धि रुकने का जोखिम बढ़ता है

---

समझ में देरी (The Comprehension Lag)

• मैनुअल कोडिंग उत्पादन और आत्मसात दोनों प्रक्रियाएँ एक साथ करती है, और टाइपिंग का घर्षण सोच को बढ़ावा देता है
  • कोड लिखते समय स्वाभाविक रूप से मानसिक मॉडल और अंतर्ज्ञान बनते हैं
• AI-सहायित डेवलपमेंट इस प्रक्रिया को अलग कर देता है, जिससे आउटपुट की गति बहुत बढ़ जाती है लेकिन समझ की गति इंसानी सीमाओं से बंधी रहती है
• आउटपुट और समझ के बीच की यही खाई संज्ञानात्मक ऋण है, और तकनीकी ऋण से अलग यह गति वाले मेट्रिक्स में दिखाई नहीं देती
• समस्या बाद में MTTR बढ़ने, change failure rate ऊँचा होने जैसे reliability मेट्रिक्स में सामने आती है

संगठन वास्तव में क्या मापते हैं (What Organizations Actually Measure)

• संगठन सिर्फ दिखने वाले आउटपुट (फीचर्स की संख्या, commits, review speed आदि) मापते हैं
• पहले आउटपुट और समझ आपस में जुड़े होते थे, इसलिए फीचर deploy होने का मतलब समझ भी मान लिया जाता था
• लेकिन AI युग में सतही समझ के साथ भी फीचर deploy करना संभव है, इसलिए यह धारणा अब वैध नहीं रही
• संगठनात्मक मेट्रिक्स समझ की कमी को पकड़ नहीं पाते, जिससे performance evaluation और reward systems विकृत हो जाते हैं

रिव्यूअर की दुविधा (The Reviewer’s Dilemma)

• AI की वजह से जूनियर डेवलपर, सीनियर से भी तेज़ कोड जनरेट कर सकता है
• सीनियर रिव्यूअर्स के पास विशाल कोड मात्रा की गहराई से समीक्षा करने का समय नहीं होता, इसलिए वे रिव्यू की गहराई की कीमत चुकाते हैं
• नतीजतन ‘reviewed code = understood code’ वाला अनुमान टूट जाता है
• संगठनात्मक दबाव गति को प्राथमिकता देता है, इसलिए रिव्यू क्वालिटी की बजाय throughput-केंद्रित संस्कृति और मजबूत होती है

बर्नआउट पैटर्न (The Burnout Pattern)

• AI टूल्स इस्तेमाल करने वाले इंजीनियर्स उच्च आउटपुट और कम आत्मविश्वास के साथ आने वाली थकान महसूस करते हैं
• कोड काम करता है, लेकिन अपने ही बनाए सिस्टम को पूरी तरह न समझ पाने की बेचैनी बनी रहती है
• गति-केंद्रित मूल्यांकन प्रणाली गहरी समझ के लिए समय देना नुकसानदेह बना देती है, और संज्ञानात्मक ऋण को तेज़ करती है

जब संगठनात्मक स्मृति विफल होती है (When Organizational Memory Fails)

• संगठनात्मक ज्ञान दस्तावेजीकृत स्पष्ट ज्ञान और डेवलपर्स के दिमाग में मौजूद अप्रकट ज्ञान से मिलकर बनता है
• AI डेवलपमेंट अप्रकट ज्ञान बनने की प्रक्रिया (सीधे implementation का अनुभव) को छोटा कर देता है, इसलिए ज्ञान का संचय नहीं हो पाता
• नतीजतन सिस्टम चलता रहता है, लेकिन उसे समझ सकने वाले लोग धीरे-धीरे गायब हो जाते हैं
• समस्या आने पर ऐसी स्थिति बनती है जहाँ कोई भी सिस्टम का संदर्भ समझा नहीं पाता

संज्ञानात्मक ऋण कैसे बढ़ता जाता है (How the Debt Compounds)

• पहला, पुराना कोड जितना अधिक होता है, जोखिम उतना बढ़ता है — जो कोड लिखते समय भी अधूरा समझा गया था, वह बाद में पूरी तरह अपारदर्शी हो जाता है
• दूसरा, incident response के समय recovery time तेज़ी से बढ़ता है — “ब्लैक बॉक्स ने जो ब्लैक बॉक्स बनाया” उसे debug करने जैसी स्थिति आती है
• तीसरा, भविष्य के सीनियर इंजीनियर्स की कमी — AI पर निर्भरता से learning curve गायब हो जाता है, जिससे लंबे समय में leadership gap पैदा होता है

डायरेक्टर का नज़रिया (The Director’s View)

• प्रबंधन को सिर्फ उत्पादकता बढ़ना, समयसीमा घटना, workforce efficiency सुधरना जैसे सकारात्मक संकेत दिखते हैं
• ‘समझ की गहराई’ या ‘explainability’ को मापने वाले मेट्रिक्स मौजूद नहीं हैं, इसलिए संज्ञानात्मक ऋण रिपोर्ट ही नहीं होता
• इसलिए data-driven decision-making तर्कसंगत तो लगती है, लेकिन अधूरी होती है, और वास्तविक जोखिम छिपा रहता है

इस मॉडल की सीमाएँ (Where This Model Breaks)

• संज्ञानात्मक ऋण की अवधारणा हर तरह के काम पर एक जैसी लागू नहीं होती
  • साधारण दोहराव वाले काम या तेज़ प्रयोगों के लिए यह उपयुक्त हो सकती है
• पहले भी समझ का स्तर व्यक्ति-व्यक्ति में अलग था, इसलिए यह पूरी तरह नई घटना नहीं बल्कि वितरण में बदलाव भी हो सकता है
• आगे चलकर बेहतर टूल्स और documentation समझ की इस खाई को कम भी कर सकते हैं

मापन की समस्या (The Measurement Problem)

• संगठन वही ऑप्टिमाइज़ करते हैं जिसे वे माप सकते हैं
  • गति मापी जा सकती है, लेकिन समझ को मापना संभव नहीं
• जब तक समझ मूल्यांकन प्रणाली का हिस्सा नहीं बनती, गति-केंद्रित incentives बने रहेंगे
• यह किसी व्यक्ति या मैनेजर की विफलता नहीं, बल्कि पिछले दौर की measurement system का मौजूदा वास्तविकता से मेल न खाने का परिणाम है
• अंततः यह खाई मेंटेनेंस लागत बढ़ने, incident response में देरी, सिस्टम की कमजोरियाँ उजागर होने जैसी समस्याओं के रूप में सामने आ सकती है
• निष्कर्ष यह है: “सिस्टम उसी दिशा में ऑप्टिमाइज़ होता है जिसे वह मापता है। लेकिन अभी जो मापा जा रहा है, वह अब महत्वपूर्ण चीज़ों को समेट नहीं पा रहा”

[laeyoung]

मैं भी इन दिनों कुछ ऐसा ही सोच रहा था, इसलिए कल cognitive debt से जुड़ी एक blog post लिखी थी। लगता है कि सब लोग लगभग इसी तरह की चिंताओं से जूझ रहे हैं।

[bini59]

कोड को समझना कैसे चाहिए? क्या इसे मापने के लिए internal codebase के आधार पर क्विज़ वगैरह लेनी चाहिए?

[GN⁺]

Hacker News की राय

• पिछले कुछ महीनों का अनुभव लेख की बातों से बहुत मेल खाता है
  जिस प्रोजेक्ट पर मैं काम करता हूँ, वह लगातार बढ़ा है लेकिन engineer की संख्या उल्टे कम हुई है
  हमने test पर निर्भरता बढ़ाई और simulator-based development की ओर शिफ्ट किया। असली system पर verify करना अब कम ही होता है, और जब होता है तो सबसे जटिल हिस्सों से जुड़ा होता है
  पिछले साल के आसपास से मैंने महसूस किया कि जिन features पर कई महीनों तक काम किया था, उनके details भी जल्दी भूलने लगा था। यह तब भी था जब coding agents अभी गंभीर रूप से अपनाए नहीं गए थे
  agents आने के बाद PR review कहीं ज़्यादा implicit हो गया है, इसलिए context दिमाग में नहीं टिकता और जानबूझकर focus करना पड़ता है। टीम के बाकी लोगों ने भी यही अनुभव बताया
  अभी हम कई प्रयोग कर रहे हैं, जैसे code के साथ agent की plan भी commit करना। इससे process ज़्यादा systematic और explicit बन रही है
  लेकिन engineering manager शायद इस cognitive load में बढ़ोतरी को लगभग पहचान ही नहीं रहे थे

  • मेरे अनुभव में managers अक्सर जंगल देखते हैं, पेड़ नहीं। अच्छे manager की भूमिका टीम का cognitive burden कम करना होती है
  • मैंने आखिरकार यही सीखा कि लिखकर रिकॉर्ड करने की आदत ज़रूरी है। सिर्फ पढ़ने से बातें दिमाग में नहीं रहतीं
  • अभी सचमुच AI-driven development को support करने वाली abstraction की कमी है। हमने खुद को replace तो कर लिया है, लेकिन उसके ऊपर वाली layer के tools अभी नहीं हैं
  • आगे चलकर agents के साथ हुई conversation logs (prompt, plan, result report) को बचाकर रखना और ज़्यादा महत्वपूर्ण होगा

• लेख की यह premise कि “developer को 6 महीने पहले लिखा अपना code याद रहता है” गलत है
  पहले से ही code लिखते समय समझना, उसे पढ़ते समय समझने से आसान रहा है। Joel Spolsky ने भी कहा था, “code पढ़ना, code लिखने से कठिन है”

  • detailed logic भूल भी जाएँ, overall flow याद रहता है, इसलिए दोबारा समझना आसान होता है
  • मैंने 4 साल पुराना codebase फिर से देखा और उसकी structure और intent काफ़ी अच्छी तरह याद आ गए
  • मैं कई codebases के बीच काम करता हूँ, लेकिन 6 महीने बाद लौटूँ या 1 हफ़्ते बाद, एहसास लगभग एक जैसा रहता है। परिचित coding style और structural intuition जल्दी वापस आ जाते हैं
  • शुरुआत में सीखते समय हाथ से सीधे code लिखते हुए critical thinking को internalize करना महत्वपूर्ण है। इसलिए मैं अक्सर Jupyter notebook में step-by-step experiment करता हूँ
  • पढ़ना कठिन है, इसका मतलब यह नहीं कि वह धीमा है। AI अगर code लिख भी दे, तब भी समझने की प्रक्रिया ज़रूरी रहेगी। बस इंसान स्वाभाविक रूप से कठिन काम से बचना चाहता है

• “समझ में न आने वाला code” की समस्या AI से पहले भी थी
  उदाहरण के लिए Microsoft के Pinball code deletion case की तरह, पुराना outsourced code इतना जटिल हो सकता है कि कोई उसे समझ न पाए और अंत में feature छोड़ना पड़े
  Oracle RDBMS codebase case भी ऐसा ही है

  • लेकिन OP की बात सही है कि AI code में ऐसी स्थिति ज़्यादा बार और ज़्यादा जल्दी आ सकती है
  • इसलिए मुझे लगता है कि prompts को version control में साथ store करना चाहिए। वही इंसान और मशीन दोनों के लिए context बनता है
  • यह मज़ाक याद आता है: “जब मैं code लिखता था, तब उसे मैं और भगवान समझते थे; अब सिर्फ भगवान समझते हैं”

• “सामान्य रूप से काम करने वाला लेकिन अजनबी system” वाली पंक्ति असरदार लगी
  यह वैसी ही भावना है जैसी developer से manager बनने पर महसूस होती है। code से जितना दूर जाते हैं, समझ उतनी ही abstract और disconnected लगती है

  • मैं भी manager और developer दोनों हूँ, और आजकल “vibe-coding” मेरे काम का बड़ा हिस्सा है। बड़ी तस्वीर सोचना और यह verify करना कि code उस तस्वीर से मेल खाता है, यही मुख्य काम है
  • आखिरकार अच्छी management की तरह स्पष्ट domain boundaries, quality standards, और iterative improvement process की ज़रूरत होती है

• “जो engineer गहराई से समझना चाहता है, वह speed metrics में पीछे रह जाता है” यह बात सबसे ज़्यादा चुभी
  बाज़ार quality से ज़्यादा speed को महत्व देता है, और अंत में सावधान engineer के निकाले जाने वाली संरचना बनती है

  • हाँ, constraints कभी-कभी creativity भी पैदा करते हैं। अगर समय और पैसा असीमित हो तो हम perfection चाहेंगे, लेकिन असल दुनिया में competition और resource limits के बीच constraints quality भी बनाते हैं ऐसे कई उदाहरण हैं

• अब शायद “LGTM, LLM” के दौर में जाना पड़े
  industry हमेशा अति तक जाती है और बाद में संतुलन खोजती है। समस्या यह असंभव उम्मीद है कि 20x productivity भी दो और 100% responsibility भी लो
  आखिरकार या तो समझ से समझौता करना होगा, या अधिकतम लगभग 20% productivity gain ही स्वीकार करना होगा

  • Sid Meier की game design सलाह “Double it or cut it in half” की तरह, extreme adjustment की ज़रूरत हो सकती है (लिंक)
  • productivity gains codebase की structure पर निर्भर करते हैं। legacy projects में उल्टे चीज़ें धीमी हो सकती हैं, जबकि LLM-friendly structure में बड़ा सुधार संभव है
  • मैं भी अभी वह structure सीख ही रहा हूँ, और यह अभी bleeding edge चरण में है
  • code लिखने के अलावा, अगर LLM को पूरे product delivery process में रचनात्मक रूप से इस्तेमाल किया जाए तो productivity में और बड़ा सुधार आ सकता है
  • लेकिन आख़िर में जब समस्या फूटती है, तो वही सवाल आता है: “यह अभी तक ठीक क्यों नहीं हुआ?” short-term launch केंद्रित culture अब भी वैसा ही है
  • अंत में टूटे बिना ठीक नहीं होगा, और temporary fixes बस दर्द को लंबा खींचती हैं

• Richard Gabriel की Worse Is Better philosophy याद आती है
  AI code अक्सर correctness से ज़्यादा simplicity चुनता है, लेकिन “बस काम कर जाए तो जीत है” वाला व्यावहारिक दृष्टिकोण जीत सकता है
  एक बार काम करने वाला system बन जाए तो उसे धीरे-धीरे बेहतर किया जा सकता है

  • लेकिन इसका प्रतिवाद भी है कि लक्ष्य “जीतना” नहीं, बल्कि ऐसा product बनाना होना चाहिए जिस पर गर्व हो
  • कुछ मामलों में AI इंसानी code को refactor भी करता है। सच कहूँ तो AI मुझसे ज़्यादा साफ़ और ज़्यादा तेज़ code लिखता है
  • यह दिलचस्प सवाल है कि simplicity का correctness से टकराव कैसे होता है

• हमारी टीम ने भी पिछले 6 महीनों में लेख में बताई गई वही चीज़ हूबहू झेली है
  यह मुख्य पंक्ति बिल्कुल सही है कि AI-assisted development implicit knowledge accumulation को तोड़ देता है
  लेकिन यह भी संभव है कि यह एक अस्थायी संक्रमणकाल हो
  लंबी अवधि में LLM code structure को अच्छी तरह व्यवस्थित करके, इंसान को सिर्फ ज़रूरत पड़ने पर गहराई से समझने में मदद देने वाला meta-level value दे सकता है

  • लेकिन अभी के LLM बहुत ज़्यादा अनावश्यक code और बिना तराशे हुए समाधान बना देते हैं, इसलिए debugging और maintenance के लिए भी LLM लगभग ज़रूरी हो जाता है

• documentation कम हो तो product support team पर भी बड़ा असर पड़ता है
  जब ग्राहक product के व्यवहार के बारे में पूछते हैं, तब अगर engineer को भी अपने लिखे code का ठीक से पता न हो तो जवाब देना मुश्किल हो जाता है
  update की रफ़्तार तेज़ हो तो दूसरी teams के लिए उसके साथ चलना कठिन होता है

  • जितना समय code writing में बचा है, उतना ही documentation को workflow का हिस्सा बनना चाहिए। अब मुझे भी लगता है कि ऐसा करना चाहिए

• high-level languages के आने पर भी ऐसा कुछ हुआ था, लेकिन अंत में सब ठीक रहा
  तो क्या LLM अगर code understanding को abstract कर दें, तब भी ठीक रहेगा?
  फ़र्क यह है कि compiler deterministic होता है, जबकि LLM probabilistic होता है

  • LLM को compiler से तुलना करना ज़्यादा ठीक नहीं। compiler deductive होता है, LLM inductive प्रक्रिया है
  • भविष्य में अगर deterministic agents, ultra-fast models, और local execution environments आ जाएँ, तो शायद high-level languages से बहुत फ़र्क न रहे
  • लेकिन programming education पूरी तरह बदल जाएगी। language को जानना आज की assembly-जैसी चीज़ बनकर पीछे चला जाएगा
  • high-level languages का उद्देश्य इंसानों के पढ़ने लायक structure को explicit बनाना था, जबकि LLM इसका उलटा करते हैं
  • वास्तव में hardware-level intuition गायब होने पर inefficient code या security vulnerabilities पैदा होने का ख़तरा बढ़ जाता है