तकनीकी debt, cognitive debt, और intent debt
(martinfowler.com)- ऐसे माहौल में जहाँ 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 के बीच संबंध को अधिक स्पष्ट बना देते हैं
3 टिप्पणियां
"इंटेंशन डेब्ट" शब्द एक ऐसा शब्द है जिसे मैंने पहले अपने तरीके से परिभाषित किया था, इसलिए इसे फिर से देखना अच्छा लगा। लगता है लोग जो सोचते हैं, उसमें काफी समानता होती है.
ब्लॉग पोस्ट: https://brunch.co.kr/@limjk/2
बदलाव के मुताबिक संगठनात्मक पुनर्गठन को तेज़ी से आगे बढ़ाना भी थोड़ा रूढ़िवादी महसूस होता है, इसलिए उससे कुछ प्रतिरोध महसूस होता है.
Hacker News की राय
अगर आप उन लोगों में हैं जिन्हें तभी सुकून मिलता है जब वे जो कुछ deploy कर रहे हैं, उसे पूरी गहराई से समझते हों, तो ऐसा बदलाव काफ़ी असहज लग सकता है
अब ऐसी modernization project भी, जिसमें पहले 2 महीने लगते, अगर पूरे business logic को खोदकर वैसा-का-वैसा कॉपी करने की जगह boundaries और interfaces को सही तरह से design करने पर ध्यान दिया जाए, तो करीब एक हफ्ते में पूरी हो सकती है
और जैसा लेख में कहा गया है, एक अच्छा test harness बनाकर जितना संभव हो equivalence verify कर सकते हैं
शुरू में मुझे भी काफ़ी अंदरूनी संघर्ष हुआ था, लेकिन सोचने पर लगा कि जिन दूसरे systems को मैं रोज़ maintain करता हूँ, उनके internal implementation या business logic को भी मैं इतना गहराई से नहीं जानता था
वह अक्सर कुछ साल पहले लिखा हुआ मेरा अपना code होता था, जिसे मैंने लगभग छुआ भी नहीं होता था, इसलिए कुछ बदलना पड़ता तो आख़िरकार test suite पर भरोसा करना पड़ता, या code structure को follow करके किसी specific behavior को समझना पड़ता था
layoffs या cost-cutting के दौर में भी, मैंने बार-बार देखा है कि जिन लोगों के पास ऐसा ज्ञान ज़्यादा होता है, वे दूसरों से ज़्यादा समय तक टिकते हैं
मुझे जानना है कि मैं क्या miss कर रहा हूँ
ऐसा नहीं है कि LLM में आलस्य का गुण बिल्कुल नहीं होता
अगर आप उसे intent के अनुरूप base prompt दें, तो Claude-आधारित agent से code changes को minimal रखने, deduplication pass चलाने, और ऐसे व्यवहार करवाना काफ़ी हद तक संभव है जो किसी बहुत senior developer की instincts जैसे लगें
मेरा मानना है कि model ने यह ज्ञान सीखा ही नहीं है, ऐसा नहीं; बस default setup में वह सामने नहीं आता
मुझे लगता है हम सबने ऐसे models देखे हैं जो पूरे codebase में हाथ डालते हैं, और दूसरों के changes या knowledge loss के risk की बिल्कुल परवाह किए बिना over-editing करते हैं
documentation generation और verification की बात भी आख़िरकार पारंपरिक locking problem जैसी ही है, और उसके पारंपरिक solutions भी हैं
agent git पढ़कर यह काफ़ी हद तक समझ सकता है कि पहले क्या हुआ, और क्या convention के हिसाब से उसे दूसरे changes का इंतज़ार करना चाहिए
मैं खुद भी काफ़ी senior हूँ, और इस लेख में जिन कुछ लोगों का ज़िक्र है, उनके साथ वास्तव में एक ही team में काम कर चुका हूँ
मुझे नहीं लगता कि वे मेरे engineering standards पर शक करेंगे
लेकिन मेरे LLM workflow में इस तरह का debt लगभग दिखा ही नहीं, बल्कि पुराने standards से तुलना करूँ तो मुझे projects की quality 5 साल या 10 साल पहले से बेहतर लगी
यह कोई जादू नहीं है; बस ऐसे agents को ठीक से चलाइए जो quality की priorities साझा करते हों
और मैं conferences में attention लेने की बजाय असली काम ज़्यादा कर पा रहा हूँ
लेकिन पारंपरिक software quality metrics से भी 5 या 10 साल पहले से बेहतर होने वाली बात बहुत vague लगती है
आप कौन-से metrics इस्तेमाल करते हैं, और 10 साल पहले, 5 साल पहले, और आज के code की तुलना उनमें कैसी बैठती है, यह ज़्यादा ठोस रूप में जानना चाहूँगा
बिना ऐसी व्याख्या के message थोड़ा धुँधला और मुख्य बिंदु से भटका हुआ लगता है
अगर साझा करने लायक कुछ और है, तो मैं सच में जानना चाहूँगा
Practical LLM Coding जैसे शीर्षक से किताब भी लिख सकते हैं
मुझे लगता है यहाँ सबसे कम आंका गया हिस्सा intent debt वाला framing है
cognitive debt या technical debt कम-से-कम code में कुछ निशान छोड़ते हैं, लेकिन intent debt दिखता ही नहीं
इसलिए यह तभी सामने आता है जब कोई locally plausible लेकिन globally गलत बदलाव अंदर आ चुका हो
क्योंकि मूल constraints किसी artifact में बचे ही नहीं होते
सबसे मुश्किल मामला वह है जब enterprise system में वही constraint किसी regulatory requirement से आया था, वह 3 साल पहले चुपचाप बदल गया, और किसी ने code update ही नहीं किया
tests pass होते रहते हैं, इसलिए यह और भी आसानी से छूट जाता है
केवल test suite से intent वापस नहीं निकाला जा सकता
मुझे नहीं लगता कि Martin पूरी तरह गलत हैं, लेकिन यह तर्क ऐसा लगता है जिसे abstraction layer ऊपर जाते ही हर बार दिया जा सकता है
उनकी परिभाषा के हिसाब से Assembly से Python पर जाना भी भारी intent debt और cognitive debt पैदा करता है
क्योंकि आप bits को कैसे manipulate करना है, यह सीधे सोचने की जगह interpreter पर छोड़ देते हैं
मेरा जवाब यह होगा कि जिस technical intent की वे बात कर रहे हैं, वह आख़िरकार इसलिए पैदा हुआ क्योंकि इंसानी intent को machine code में translate करना पड़ता था
किसी समस्या पर गहराई से सोचना अपने-आप में इस बात पर निर्भर नहीं कि code के अंदर domain-driven abstractions ज़रूर बनाई जाएँ
आप mind map बनाकर, journal लिखकर, या दीवार पर post-it चिपकाकर भी गहराई से सोच सकते हैं
object-oriented abstraction अपने-आप में कोई जादू नहीं है
उसी प्रक्रिया में ambiguity, छूटे हुए details, और यहाँ तक कि यह भी सामने आ जाता है कि approach ही फिर से सोचनी चाहिए
natural language में लिखना भी thinking tool हो सकता है, लेकिन formal language की उस प्रकृति में, जो ambiguity को बर्दाश्त नहीं करती, सोच को ढालना मूल रूप से अलग बात है
यह वैसा ही है जैसे mathematical notation के बिना केवल natural language में mathematics करना—काम तो होगा, पर बहुत झंझट और त्रुटियाँ बढ़ जाएँगी
बस यह काम इंसानों के लिए अधिक समझ में आने वाली भाषा में किया जा रहा है
intent और implementation के बीच सीधा mapping मौजूद है
क्योंकि mapping अच्छी तरह defined और deterministic है
abstraction का उद्देश्य यह बनाना है कि नीचे फिर से देखे बिना भी आप भरोसा कर सकें कि ऊपर किया गया काम अब भी सही है
यह इसलिए संभव है क्योंकि मैंने, या किसी ऐसे व्यक्ति ने जिस पर मैं भरोसा करता हूँ, वह लागत पहले ही एक बार चुका दी थी
लेकिन LLM में generation के हर बार output verify करना पड़ता है, यानी हर बार वही debt फिर से देना पड़ता है
इसलिए इसे abstraction कहना मुश्किल है
यह लेख सचमुच बहुत अच्छा लिखा गया है
मैंने भी कल अपने निजी notes में लिखा था कि अगर code को organic तरीके से लगातार evolve नहीं किया जा रहा, तो यह कहना मुश्किल है कि आप वास्तव में उसके मालिक हैं
यह self-driving car जैसा लगता है—पहले कम-से-कम रास्ते का नज़ारा याद रहता था, अब बस आपको किसी दूसरी जगह teleport कर दिया जाता है और recording दिखा दी जाती है
इस तरह की review कम असरदार होती है
छोटे tools में ऐसा ghosted code शायद ठीक हो, लेकिन database जैसे systems में यह सचमुच चिंताजनक है
इसलिए अब मैं agents को लगभग कभी write access नहीं देता, और 2 साल पहले की तरह manual QA-केंद्रित workflow पर लौट आया हूँ
token usage और outcomes, दोनों ही लिहाज़ से वह मेरे लिए ज़्यादा efficient निकला
बेशक, यह सिर्फ़ मेरा अनुभव है
दुर्भाग्य से, उन्होंने जिस Wharton paper का लिंक दिया है, उसका बड़ा हिस्सा AI-generated लगता है, और अभी उसका peer review भी नहीं हुआ है
आजकल researchers writing में AI की मदद लेते हैं, यह मैं समझता हूँ, लेकिन जब paper का विषय ही cognitive surrender हो, तो उसे गंभीरता से लेना मुश्किल हो जाता है
not merelyका इस्तेमाल पूरे 7 बार करता हैसमझ नहीं आता कि LLM इतना भी एक ही phrase दोहराएगा या नहीं; हो सकता है लेखक ने ही LLM-जैसी writing habit अपना ली हो
Martin पूरी तरह गलत नहीं हैं, लेकिन मैंने ऐसे मामले खुद देखे हैं जहाँ AI ने आलसी code बनाया, जबकि सही जवाब उल्टा ज़्यादा code था
खास तौर पर, कुछ Python models थे जो कुछ logical concept sets के लिए database schema define करते थे
इसमें एक नया concept जोड़ा गया, जो मौजूदा logical set से बहुत मिलता-जुलता था, और Claude ने तय किया कि मौजूदा model set को बस reuse कर लेना चाहिए
सिद्धांत में यह चल जाता था, लेकिन असली consumer side पर runtime type inference की वजह से तरह-तरह के workarounds करने पड़ते थे
यह काम तो कर रहा था, लेकिन abstraction layer बिल्कुल गलत चुनी गई थी
इंसानी नज़रिए से हम abstractions चाहते हैं, लेकिन कभी-कभी plain duplication ही ज़्यादा सही होता है
अगर machine ही code लिख रही हो और maintain भी कर रही हो, तो जो extra abstraction layers पहले ज़रूरी थे, वे अब हर बार ज़रूरी न हों
पहले हम Duff's device इस्तेमाल करते थे और loops को manually unroll करके duplicate code बनाते थे
अब compiler intent समझकर duplicated assembly खुद generate कर देता है, और हमें उस duplication की परवाह नहीं करनी पड़ती
हाल में मुझे LLM से कुछ काफ़ी non-trivial computational geometry code के टुकड़े चाहिए थे; पहले होता यह कि library ढूँढनी पड़ती, compliance approval लेना पड़ता, और अपनी domain data structures को उस library format में ढालना पड़ता
सीधे खुद implement करने की तुलना में यह सस्ता होता, लेकिन किसी भी तरह मामूली नहीं
अब LLM मेरे लिए केवल वही हिस्सा लिख देता है जिसकी मुझे ज़रूरत है, और मेरे stored data format के साथ ही काम करता है
न कोई बड़ी library लानी पड़ती है, न data structure conversion करना पड़ता है
orthodox तरीके से देखें तो duplication से बचने के लिए geometry library इस्तेमाल करनी चाहिए, लेकिन यहाँ एक self-contained function बस ठीक से काम कर रहा है
यह वाकई बहुत समय बाद Hacker News पर पढ़ी सबसे अच्छी चीज़ों में से एक थी
मैं इससे बहुत जुड़ाव महसूस करता हूँ
Simon Willison के cognitive debt वाले विचार, और इस दृष्टिकोण—कि “तुम्हारा काम वही code deploy करना है जिसका काम करना तुमने सिद्ध किया हो”—की वजह से ही मैं Intent-Driven Development दिशा के projects पर काम करने लगा
पहले का intent मुझे ऐसा लगता था कि changes जमा होते-होते हमेशा धुँधला पड़ जाता है
शायद मैं इसे एक वास्तविक protocol के रूप में संगठित करके बाद में Hacker News पर पोस्ट करूँ
अगर आपने अभी तक मेरी posts नहीं देखी हैं, तो उन्हें ज़रूर देखें
सार यह है
इस समय मेरी problem visualization इस diagram के ज़्यादा क़रीब है: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU...
मुझे लगता है software engineering का cognitive bottleneck code के अंदर कम, artifacts के बीच ज़्यादा है
code उनमें से सिर्फ़ एक है
outcome → requirements → spec → acceptance criteria → executable proof → review
मैं experimental tooling बना रहा हूँ जो इन transitions के बीच के उबाऊ हिस्सों को automate करे, और इंसानों को इस बात की verification पर केंद्रित रखे कि हर चरण में intent बचा रहा या नहीं
इसमें मैं एक और layer जोड़ना चाहूँगा: proxies/metrics
analysis-heavy systems में असली loss कई बार spec → code में नहीं, बल्कि question → proxy में होता है
एक बार proxy acceptance criteria, dashboard, या eval में जम जाए, तो लोग उसी को optimize करने लगते हैं, और यह बात धीरे-धीरे भूल जाते हैं कि वह सिर्फ़ एक proxy metric था
फ़ोन पर pan, zoom, और scroll करने की कोशिश में मैं बार-बार canvas elements हिला देता हूँ