तकनीकी debt, cognitive debt, और intent debt

• ऐसे माहौल में जहाँ LLM बड़े पैमाने पर code बनाते हैं, सिर्फ code की समस्याएँ ही नहीं, बल्कि टीम की साझा समझ और system goals के रिकॉर्ड भी कमजोर होने लगते हैं। इसलिए इन्हें technical debt, cognitive debt, और intent debt की तीन परतों में बाँटकर देखना ज़्यादा ज़रूरी हो जाता है
• Technical debt भविष्य में बदलाव की क्षमता को सीमित करता है, Cognitive debt टीम की system changes पर तर्क करने की क्षमता को कमजोर करता है, और Intent debt goals व constraints के रिकॉर्ड को धुंधला कर देता है, जिससे इंसानों और AI agents दोनों के लिए system को लगातार evolve करना मुश्किल हो जाता है
• AI को System 3 मानने वाली Tri-System theory उस स्थिति को cognitive surrender कहती है, जहाँ बाहरी कृत्रिम reasoning पर बिना आलोचनात्मक जाँच के भरोसा कर लिया जाता है और गहरी सोच को छोड़ दिया जाता है; इसे रणनीतिक रूप से cognition सौंपने वाले cognitive offloading से अलग देखा जाता है
• जैसे-जैसे coding की लागत घटती है, verification महँगा होता जाता है; correctness और success के मानदंड हर context में अलग होते हैं, जैसे traffic ETA, driver dispatch, या सैकड़ों microservices का संचालन, इसलिए human judgment और verification systems की design और भी महत्वपूर्ण हो जाती है
• Engineering का केंद्रीय फोकस implementation की मात्रा से verification की ओर खिसकता है, और आगे भी इंसान useful abstractions, naming, acceptance criteria, और test harness design जैसे कामों में system के अर्थ को संभालने की भूमिका निभाते रहेंगे

---

तीन तरह के debt और system health

• ऐसे माहौल में जहाँ LLM बड़े पैमाने पर code तैयार करते हैं, टीम के लिए यह समझ खो देना आसान हो जाता है कि system वास्तव में क्या कर रहा है; इसी वजह से इसे Cognitive Debt के रूप में देखने का दृष्टिकोण मजबूत हो रहा है
• तीन system health layers debt को code, people, और artifacts के स्तर पर बाँटती हैं
  • Technical debt code में मौजूद होता है; जब implementation decisions भविष्य में बदलाव की क्षमता को नुकसान पहुँचाते हैं, तब यह जमा होता है और system कैसे बदल सकता है, उसे सीमित करता है
  • Cognitive debt लोगों में मौजूद होता है; जब system की shared understanding, उसे फिर से भरने की गति से तेज़ी से कमजोर होती जाती है, तब यह जमा होता है और टीम की बदलावों पर तर्क करने की क्षमता को सीमित करता है
  • Intent debt artifacts में मौजूद होता है; जब system को दिशा देने वाले goals और constraints ठीक से रिकॉर्ड या maintain नहीं किए जाते, तब यह जमा होता है और यह सीमित करता है कि क्या system अब भी मूल इरादे को दर्शाता है, और क्या इंसान व AI agents मिलकर इसे प्रभावी ढंग से आगे evolve कर सकते हैं
• यह दृष्टिकोण हर debt को diagnose और mitigate करने वाले sections भी शामिल करता है, और यह भी बताता है कि ये तीनों debt एक-दूसरे से कैसे interact करते हैं
• टीमों को इन तीनों debt को नियंत्रण में रखने के लिए सामान्य गतिविधियाँ साथ-साथ चलानी चाहिए

Tri-System theory और cognitive surrender

• एक paper जो LLM को Kahneman के two-system thinking model में जोड़ता है AI को System 3 के रूप में रखकर सोच की रूपरेखा को बढ़ाता है
• System 1 intuition के आधार पर तेज़ी से निर्णय लेता है, और System 2 वह चरण है जहाँ समस्याओं पर जानबूझकर विचार किया जाता है
  • ऊर्जा बचाने के लिए इंसान स्वाभाविक रूप से intuition पर निर्भर रहते हैं, और इसके कारण वे उन बातों को चूक सकते हैं जिन्हें गहराई से सोचने पर पकड़ लेते
• System 3 के परिणामस्वरूप cognitive surrender सामने आता है; इसे ऐसी स्थिति के रूप में परिभाषित किया गया है जिसमें बाहर से उत्पन्न कृत्रिम reasoning पर बिना आलोचनात्मक जाँच के भरोसा कर लिया जाता है और System 2 को बायपास कर दिया जाता है
  • paper इसे cognitive offloading से अलग बताता है
  • cognitive offloading को सोच-विचार की प्रक्रिया में cognition को रणनीतिक रूप से सौंपने की क्रिया के रूप में देखा जाता है
• यह paper Tri-System theory of cognition को विस्तार से प्रस्तुत करता है, और कम-से-कम laboratory वातावरण में कई experiments के माध्यम से यह भी जाँचता है कि यह theory व्यवहार की भविष्यवाणी करने में कितनी प्रभावी है

code icon के रूप में <> notation

• हाल की कुछ illustrations में code icon के रूप में “<>” चिन्ह का उपयोग किया जाता है, लेकिन programming language elements को घेरने के लिए यह notation कुछ अपरिचित-सा लगता है
• “{ }” जैसे दूसरे symbols की जगह “<>” के इस्तेमाल का कारण संभवतः यह है कि यह HTML या XML की याद दिलाता है
• जब “</>” जैसी form तक इस्तेमाल की जाती है, तो HTML का संकेत और भी सीधा हो जाता है, लेकिन HTML को आम तौर पर उस language की तरह नहीं देखा जाता जिसमें programmers programs लिखते हैं

जब coding सस्ती हो जाए, verification महँगा हो जाता है

• if coding agents make coding free, what becomes the expensive thing का तर्क है कि जैसे-जैसे coding agents coding की लागत घटाते हैं, verification सबसे महँगा तत्व बन जाता है
• correctness के मानदंड हर context में अलग-अलग होते हैं
  • Jakarta traffic के लिए ETA algorithm और Ho Chi Minh City traffic के लिए ETA algorithm में “correct” का अर्थ अलग हो सकता है
  • driver dispatch में revenue fairness, customer wait time, और vehicle utilization को एक साथ संतुलित करना पड़ता है, इसलिए “successful” की एक नहीं बल्कि कई definitions होती हैं
  • ऐसे माहौल में जहाँ सैकड़ों engineers लगभग 900 microservices पर लगातार deploy करते हैं, “correct” की एक परिभाषा नहीं रहती बल्कि वह हज़ारों definitions में बँट जाती है, और वे सभी लगातार बदलती व context-dependent होती हैं
• ऐसे निर्णय वे काम हैं जिन्हें agents पूरी तरह replace नहीं कर सकते
• agents उन flows में खास तौर पर अच्छा काम करते हैं जहाँ output के लिए अच्छा और संभव हो तो automated verification मौजूद हो
  • ऐसे flows Test Driven Development को बढ़ावा देते हैं
  • फिर भी verification का काम बहुत अधिक बचता है, इसलिए ऐसे तरीकों पर अधिक मेहनत की ज़रूरत है जो इंसानों को बड़े test surface को आसानी से समझने में मदद करें
• legacy modernization को लेकर कुछ असहमतियाँ भी सामने रखी गई हैं
  • यह उम्मीद कि agentic coding legacy modernization को अंततः पूरी तरह हल कर देगा, बढ़ा-चढ़ाकर आंकी गई है
  • लेकिन understanding what legacy code is doing के मामले में LLM के बहुत मददगार होने के मजबूत प्रमाण हैं

verification-केंद्रित संगठनों की ओर पुनर्गठन

• जब agents execution संभालते हैं, तब इंसानों का काम verification system design, quality की definition, और उन ambiguous cases को संभालने की ओर खिसकता है जिन्हें agents हल नहीं कर पाते
• संगठनात्मक संरचना को भी इस बदलाव के अनुसार बदलना होगा
  • सोमवार सुबह standup का सवाल “क्या deploy किया?” से ज्यादा “क्या verify किया?” पर केंद्रित होगा
  • output tracking की जगह इस बात को track किया जाएगा कि परिणाम सही थे या नहीं
• features बनाने वाली 10 engineers की टीम को 3 engineers और 7 लोगों की नई संरचना में बदला जा सकता है, जहाँ बाकी लोग acceptance criteria define करने, test harness design करने, और outcome monitoring की जिम्मेदारी लें
• ऐसा पुनर्गठन असहज लग सकता है, क्योंकि यह बनाने के काम की तुलना में निर्णय लेने के काम की प्रतिष्ठा बढ़ाता है
• जो engineering culture इस बदलाव का विरोध नहीं करेगी, उसके बेहतर करने की संभावना अधिक है

source code का भविष्य और LLM-friendly languages

• LLM को programmer की तरह इस्तेमाल करने की दिशा में बढ़ते हुए, source code का भविष्य खुद एक बड़ा सवाल बनकर उभरता है
• several views of the future of code code के भविष्य को लेकर कई दृष्टिकोणों को एक साथ रखता है
  • कुछ लोग पूरी तरह नई languages पर प्रयोग कर रहे हैं, जिन्हें शुरू से LLM को ध्यान में रखकर डिजाइन किया गया है
  • दूसरी तरफ कुछ लोगों का मानना है कि मौजूदा languages, खासकर TypeScript और Rust जैसी strict-typed languages, LLM के लिए बेहतर फिट हो सकती हैं
• इस लेख में quotes अधिक हैं और अपनी analysis कम है, लेकिन पूरी चर्चा का एक overview resource के रूप में इसे पढ़ा जा सकता है

abstraction और naming की जिम्मेदारी इंसानों की

• LLM के साथ software बनाते समय भी इंसान उस भूमिका में बने रहेंगे जहाँ वे ऐसे useful abstractions बनाते हैं जिनसे यह बताया जा सके कि code क्या कर रहा है
• यह DDD की Ubiquitous Language से जुड़ता है
• growing a language LLM के साथ मिलकर language विकसित करने के तरीकों पर बात करता है
• programming केवल वह काम नहीं है जिसमें computer के समझने और चलाने लायक coding syntax लिखा जाए, बल्कि यह solution को आकार देने की प्रक्रिया भी है
  • इसमें समस्या को केंद्रित हिस्सों में बाँटना, जुड़े हुए data और behavior को साथ रखना, और इरादे को स्पष्ट करने वाले names चुनना शामिल है
  • अच्छे names complexity को काटते हैं, code को ऐसी संरचना में बदलते हैं जिसे हर कोई follow कर सके, और problem structure व solution structure के बीच संबंध को अधिक स्पष्ट बना देते हैं