समझ अब नई bottleneck है
(geoffreylitt.com)- जब एजेंट द्वारा लिखा गया कोड किसी व्यक्ति के आसपास लगातार जमा होता जाता है, तो विकास की गति को सीमित करने वाला तत्व अब कोड generation क्षमता नहीं, बल्कि सिस्टम के साथ चलते हुए अगले बदलाव की कल्पना कर सकने वाली मानव समझ की गति बनता जा रहा है
- कोड को समझने का उद्देश्य सिर्फ़ नतीजे को approve या reject करने वाली verification तक सीमित नहीं है; इसका उद्देश्य एजेंट के लगातार चलने वाले कार्य-लूप में अगला आइडिया सुझाना और रचनात्मक प्रक्रिया में भाग लेना भी है
- raw code diff के बजाय background knowledge/बदलाव का लक्ष्य/interactive diagram/वर्णनात्मक code diff को साथ बाँधने वाले code explanation document को पहले पढ़ने से बदलाव की संरचना और मंशा को ज़्यादा तेज़ी से समझा जा सकता है
- explanation document के quiz और execution process को सीधे manipulate करने वाले microworld एजेंट को हमारी जगह निर्णय लेने नहीं देते, बल्कि इंसान को सिस्टम की state changes और अंदरूनी कामकाज का अनुभव कराते हैं
- अगर AI को सिर्फ़ इंसान को loop से बाहर करने वाले automation के रूप में नहीं, बल्कि समझ के लिए tools और simulations बनाने में इस्तेमाल किया जाए, तो इंसान और टीम उल्टा और गहराई से loop में भाग ले सकते हैं
कोड generation की रफ़्तार के साथ नहीं चल पा रहा इंसान
- जैसे एजेंट द्वारा लिखे गए कोड के ढेर किसी एक व्यक्ति के आसपास लगातार ऊँचे होते जाते हों, वैसे ही generated code की मात्रा बढ़ रही है, लेकिन उसे समझने की मानवीय गति उसी अनुपात में नहीं बढ़ती
- हर code diff को लाइन-दर-लाइन पढ़ने का तरीका अकेले एजेंट की काम करने की रफ़्तार के साथ चलने के लिए काफ़ी नहीं है
- कोड को समझने के लिए raw code diff के अलावा भी कई तरीके हैं
- सिस्टम और बदलावों को सिखाने वाले code explanation document
- यह जाँचने वाले quiz कि समझ वास्तव में बनी है या नहीं
- अंदरूनी कामकाज को सीधे manipulate करके सीखने वाले microworld
- पूरी टीम को एक ही mental model बनाने में मदद देने वाले shared spaces
समझ का उद्देश्य verification नहीं, participation है
- जब पूछा जाता है कि इंसान को कोड समझने की ज़रूरत क्यों है, तो अक्सर जवाब मिलता है कि एजेंट के काम की verification के लिए
- यह जाँचना कि वह specification के मुताबिक है या नहीं
- यह तय करना कि उसकी structure उचित है या नहीं
- अंत में approve/reject का फ़ैसला लेना
- प्रस्तुति में इसे अक्सर अंगूठा ऊपर या नीचे करने वाले द्विआधारी निर्णय की तरह दिखाया जाता है
- अगर verification को ही इंसान की भूमिका मान लिया जाए, तो समझ सिर्फ़ नतीजे के पास/फ़ेल का निर्णय बनकर रह जाती है
- लेकिन एजेंट अपने बनाए नतीजों को ख़ुद चलाकर, जाँचकर, और गलती ढूँढकर self-verification की क्षमता भी लगातार बेहतर कर रहे हैं
- जैसे-जैसे verification एजेंट ज़्यादा अच्छी तरह करने लगेंगे, सवाल उठेगा कि इंसान कहाँ बचेगा
- इसका विकल्प है समझ के ज़रिए भागीदारी
- एजेंट क्या कर रहा है, यह समझना ज़रूरी है ताकि इंसान रचनात्मक प्रक्रिया का सक्रिय सदस्य बना रह सके
- सिस्टम को समझने से बात सिर्फ़ मौजूदा नतीजे का मूल्यांकन करने पर नहीं रुकती, बल्कि अगले चरण में क्या बदलना है इस पर सोचने तक जाती है
प्रोजेक्ट एक loop नहीं, अनगिनत loops हैं
- वास्तविक प्रोजेक्ट ऐसा single loop नहीं होते जहाँ एजेंट को एक बार निर्देश देकर परिणाम ले लिया जाए
- goal setting/implementation/checking/fixing/expansion जैसे असंख्य iterative loops एक-दूसरे से जुड़े होते हैं
- हर iteration में इंसान की सिस्टम-समझ अगले आइडिया की गुणवत्ता और दायरा तय करती है
- दिमाग में पर्याप्त concepts और structure होने चाहिए ताकि ऐसे सवाल सहज रूप से संभाले जा सकें
- क्या जोड़ना या हटाना चाहिए
- किस structure को बदलना चाहिए
- मौजूदा implementation से कौन-सी नई संभावनाएँ खुली हैं
- अगर समझ कम हो, तो एजेंट द्वारा बनाया गया नतीजा “लगभग ठीक लग रहा है” जैसा लग सकता है, लेकिन प्रोजेक्ट को किस दिशा में ले जाना है, यह lead करना मुश्किल हो जाता है
समझ को टालने से जमा होने वाला cognitive debt
- सिस्टम को समझे बिना एजेंट के परिणाम लगातार स्वीकार करते रहने से अल्पकाल में काम तेज़ चल सकता है
- लेकिन जैसे technical debt बाद के बदलावों की लागत बढ़ा देता है, वैसे ही समझ को छोड़कर किया गया काम cognitive debt छोड़ता है
- cognitive debt जमा होने पर प्रोजेक्ट में शामिल लोग पूरे प्रवाह से कटने लगते हैं
- कोड की मौजूदा structure ऐसी क्यों बनी, यह समझना कठिन हो जाता है
- नई requirements को कहाँ जोड़ा जाए, यह तय करना कठिन हो जाता है
- एजेंट द्वारा सुझाए गए अगले बदलाव की उपयुक्तता पर चर्चा करना कठिन हो जाता है
- AI युग की समस्या यह नहीं कि कोड generate नहीं हो रहा, बल्कि यह है कि generated systems के बारे में इंसान के पास पर्याप्त conceptual understanding नहीं बन रही
शिक्षा के तरीक़ों को code understanding पर लागू करना
- तेज़ी से बदलते AI work environment में मानवीय समझ बनाना उस समस्या जैसा है जिसे शिक्षा लंबे समय से संभालती आई है
- सिर्फ़ नए facts बताना काफ़ी नहीं; वास्तविक समझ के लिए background knowledge/intuition/practice/feedback साथ देने पड़ते हैं
- code understanding में भी शिक्षा से विकसित तरीक़े लागू किए जा सकते हैं
- detailed implementation से पहले background और intuition देना
- पढ़ने के बाद याद करके जवाब देने को कहना
- abstract नियमों को सीधे manipulate करने के लिए environment देना
- दूसरों के साथ वही concepts और vocabulary साझा कराना
बदलावों को सिखाने वाला /explain-diff
- /explain-diff एक ऐसा skill है जो एजेंट द्वारा किए गए बदलावों को structured explanation document में बदलता है
- इसे HTML/Markdown/Notion page के रूप में output किया जा सकता है, और Notion document को टीम members comments के साथ चर्चा करने वाले collaborative artifact की तरह इस्तेमाल कर सकते हैं
- यह सिर्फ़ code changes की सूची नहीं, बल्कि इंसान को बदलाव सीखने के लिए डिज़ाइन की गई explanation material तैयार करता है
- गेम स्क्रीन के perspective को बदलने वाले उदाहरण में कोड तुरंत दिखाने के बजाय यह क्रम अपनाया जाता है
- पहले मौजूदा game engine के rendering method को समझाया जाता है
- फिर “2D drawing technique से बगीचे को 3D जैसा दिखाना” वाला change goal दिया जाता है
- isometric projection क्या है, यह समझाकर बदलाव के visual principle को समझाया जाता है
- उसके बाद ही वास्तविक implementation code पर जाया जाता है
पहले background knowledge सिखाना
- अच्छी explanation “क्या बदला” से पहले “बदलाव से पहले क्या था” से शुरू होती है
- अगर मौजूदा game engine की coordinate system और rendering structure मालूम न हो, तो नया perspective code पढ़कर भी बदलाव की वजह समझना मुश्किल है
- explanation document पहले existing system की structure को भरता है ताकि वह व्यक्ति भी बातचीत में शामिल हो सके जिसके पास एजेंट जैसी background नहीं है
- यह सिर्फ़ summary नहीं, बल्कि इंसान को मौजूदा project context में वापस लाने की प्रक्रिया है
implementation details से पहले intuition बनाना
- अगर कोड से पहले बदलाव का सार एक वाक्य में बता दिया जाए, तो यह समझना आसान होता है कि implementation details किस goal की ओर जा रही हैं
- बगीचे को 3D जैसा दिखाने वाले उदाहरण में isometric projection के formula से शुरुआत नहीं होती, बल्कि पहले यह visual goal दिया जाता है कि सपाट चित्र को त्रि-आयामी जैसा दिखाना है
- background और goal समझने के बाद code snippets देखने पर हर calculation और transformation की भूमिका को पूरे परिणाम से जोड़ना आसान होता है
- उद्देश्य इंसान को details का passive reader बनाना नहीं, बल्कि change intent को समझने वाला बराबरी का participant बनाना है
interactive diagrams से coordinate changes का अनुभव
- सिर्फ़ static image दिखाने के बजाय बगीचे के पत्थर को सीधे खींचकर हिलाने वाले interactive diagram का इस्तेमाल किया जाता है
- पत्थर को हिलाने पर स्क्रीन पर उसकी position और internal coordinates साथ-साथ बदलते हैं, जिससे isometric projection के coordinate transformation को देखा जा सकता है
- सिर्फ़ formulas या code पढ़ने की तुलना में input और output के संबंध को सीधे manipulate करके intuition बनाना आसान होता है
- Notion page के भीतर interactive HTML embed करके code explanation document को ही एक छोटा execution environment बनाया जा सकता है
- AI सिर्फ़ explanation लिखने तक सीमित नहीं है; वह समझ के लिए ज़रूरी visualization और manipulation tools भी बना सकता है
raw code diff को literate diff में बदलना
- सामान्य code diff बदली हुई files को filename order में सूचीबद्ध करता है
- वह files के बीच relations नहीं समझाता
- वह बदलाव का purpose नहीं बताता
- वह यह नहीं बताता कि किस क्रम में पढ़ना चाहिए
- literate diff बदलावों को लेखन के प्रवाह की तरह फिर से व्यवस्थित करता है
- पहले बदलाव का purpose रखा जाता है
- फिर समझने के अनुकूल क्रम में files और functions समझाए जाते हैं
- बीच-बीच में ज़रूरत भर के code snippets डाले जाते हैं
- आसपास के context और implementation choices के रिश्ते साथ दिखाए जाते हैं
- अगर raw code diff कच्चे सामान का ढेर है, तो literate diff बदलाव की प्रक्रिया को एक कहानी की तरह संपादित किया हुआ रूप है
- explanation पहले पढ़कर raw code diff देखने पर हर code snippet क्यों मौजूद है, यह समझकर पढ़ा जा सकता है, इसलिए review की गति बढ़ती है
AI द्वारा बनाई गई documentation को काग़ज़ पर पढ़ना
- तैयार explanation document को एक code explanation packet की तरह इस्तेमाल किया जा सकता है
- raw code diff पढ़ना जारी रहता है, लेकिन पहले explanation document पढ़ा जाता है
- जब गहरे focus की ज़रूरत हो, तो document print करके कैफ़े में काग़ज़ पर भी पढ़ा जाता है
- AI के साथ programming जैसी interactive activity का उल्टा एक गहरे concentration वाली static paper report में बदल जाना एक दिलचस्प विडंबना है
- मुख्य बात सबसे नया interface इस्तेमाल करना नहीं, बल्कि जानकारी को उस रूप में बदलना है जिसे इंसान वास्तव में बेहतर समझ सके
पढ़ लेने का एहसास और वास्तविक समझ का फ़र्क
- explanation document कितना भी अच्छा हो, सिर्फ़ पढ़ना समझ की गारंटी नहीं देता
- इंसान अक्सर सिर्फ़ वाक्यों पर नज़र फेर लेने से यह गलतफ़हमी पाल लेता है कि उसने समझ लिया या याद रख लिया
- यहाँ Andy Matuschak के “books don't work” और Andy Matuschak/Michael Nielsen के Quantum Country से विचार लिए गए हैं
- Quantum Country लेख के भीतर spaced repetition quiz डालता है ताकि पाठक सीधे याद करके जवाब दे
- इसी तरीक़े को code explanation document पर लागू करके अंत में बदलावों पर पाँच interactive questions रखे जाते हैं
quiz AI loop की speed governor है
- एक नियम इस्तेमाल किया जाता है कि किसी और को code भेजने से पहले explanation document का quiz pass करना होगा
- दूसरे व्यक्ति द्वारा लिखे code की review में भी यही मानदंड लागू किया जाता है
- quiz ज्ञान मापने के लिए कोई extra feature नहीं, बल्कि speed governor है
- AI के साथ काम करते हुए implementation/fixing/regeneration loop अक्सर मानवीय समझ से तेज़ चल पड़ते हैं
- quiz हर loop पर यांत्रिक ढंग से अगला सवाल पूछने पर मजबूर करता है
- क्या आप सचमुच समझा सकते हैं कि क्या बदला है
- क्या आप समझते हैं कि यह structure क्यों चुनी गई
- क्या आप उन constraints को जानते हैं जो अगले बदलाव को प्रभावित करेंगी
- अगर pass नहीं कर पाते, तो काम की गति धीमी करनी होगी और समझ को मज़बूत करना होगा; तभी इंसान रचनात्मक participant बना रह सकता है
Seymour Papert के Mathland से लिया गया microworld
- दूसरा तरीका, यानी microworld, शिक्षाविद Seymour Papert के विचार से शुरू होता है
- Papert का मानना था कि जैसे फ़्रेंच सीखने के लिए फ़्रांस में रहना मददगार होता है, वैसे ही गणित सीखने के लिए ऐसे Mathland में रहना चाहिए जहाँ गणित स्वाभाविक रूप से काम करता हो
- इसमें बच्चा सिर्फ़ explanation सुनने के बजाय जिज्ञासा के अनुसार environment को explore करके गणितीय concepts स्वाभाविक रूप से सीखता है
- इसे code पर लागू करने का मतलब है कि सिर्फ़ सिस्टम का description देने वाली document न देकर ऐसा environment बनाना जहाँ इंसान अंदर जाकर कार्यप्रणाली का प्रत्यक्ष अनुभव कर सके
- microworld पूरी production system को जस का तस खोल देने के बजाय, खास सिद्धांतों और state changes को देखने के लिए बनाया गया छोटा संसार होता है
Prolog interpreter को time axis पर explore करना
- Prolog interpreter विकसित करते समय अंदर क्या हो रहा है, यह intuitively समझना कठिन था
- इसलिए एजेंट के साथ execution process को step-by-step explore करने वाला dedicated debugger बनाया गया
- इस debugger में सीधे यह देखा जा सकता है
- execution time को आगे-पीछे ले जाना
- मौजूदा stack में कौन-से values हैं, यह देखना
- हर चरण पर कौन-सा rule evaluate हो रहा है, यह जाँचना
- जिस क्षण कोई rule सही लागू हुआ, वहाँ memo छोड़ना
- सिर्फ़ final result देखने के बजाय यह सीधे ट्रैक किया जा सकता है कि logic language का execution समय के साथ कैसे unfold होता है
- एजेंट को debugging सौंपने से समस्या हल हो सकती है, लेकिन debugger को इंसान द्वारा सीधे चलाने पर ही execution structure की समझ बनती है
एजेंट द्वारा debugging करने और understanding tool बनाने का फ़र्क
- “एजेंट समस्या ढूँढकर ठीक कर देता है” और “एजेंट ऐसा tool बनाता है जिससे इंसान समस्या explore कर सके” — ये दोनों अलग परिणाम देते हैं
- पहले मामले में नतीजा जल्दी मिल जाता है, लेकिन अंदरूनी प्रक्रिया को लेकर मानवीय समझ शायद ही बढ़े
- दूसरे में इंसान को execution state देखने, hypothesis बनाने, और result जाँचने की exploration process मिलती है
- कोड लिखने का कुछ हिस्सा एजेंट को देकर भी महत्वपूर्ण सोच और खोज इंसान ख़ुद कर सकता है
- यह एजेंट की भूमिका को answer provider से बढ़ाकर understanding environment creator तक ले जाने वाला दृष्टिकोण है
वेबसाइट migration को गेम की तरह करना
- व्यक्तिगत वेबसाइट को एक framework से दूसरे framework में migrate करते समय Claude ने automation script लिखा
- लेकिन नए framework से परिचित न होने के कारण script पढ़कर भी उसे “लगभग सही लगता है” से आगे आँकना मुश्किल था
- इसे हल करने के लिए Claude से migration को सीधे चलाने वाला video game शैली का command center बनाने को कहा गया
- command center में यह प्रक्रिया visually देखी जा सकती है
- button दबाकर migration steps को एक-एक करके चलाना
- पुरानी और नई साइट को स्क्रीन के दोनों ओर साथ-साथ दिखाना
- हर चरण पर नई साइट कैसी बदल रही है, यह देखना
- file tree किस क्रम में बदल रहा है, यह observe करना
- पूरी transformation एक साथ चलाने के बजाय, नई साइट के धीरे-धीरे जीवित होने की प्रक्रिया को सीधे अनुभव किया जा सकता है
- इससे हाथ से हर file ले जाने जैसी समझ मिलती है, लेकिन ज़रूरी काम और observation environment पहले से तैयार होने के कारण यह काफ़ी तेज़ हो जाता है
कोड समझने के लिए कोड generate करना
- एजेंट द्वारा लिखा जा सकने वाला code सिर्फ़ product features या automation scripts तक सीमित नहीं है
- ऐसा अस्थायी toolset भी बनाया जा सकता है जिससे इंसान दूसरे code को समझ सके
- execution visualization tools
- step-by-step debugger
- side-by-side comparison screens
- file tree change indicators
- interactive concept explanations
- काम को छोटे चरणों में बाँटने वाले command centers
- ये tools long-term maintained product code न भी हों, तब भी इनमें पर्याप्त मूल्य है
- AI से code बनाने की लागत घटने के साथ किसी ख़ास व्यक्ति और ख़ास काम के लिए one-off learning environments बनाना भी व्यावहारिक हो गया है
टीम में समझ साझा भी होनी चाहिए
- सिर्फ़ एक व्यक्ति का सिस्टम समझ लेना टीमवर्क के लिए काफ़ी नहीं है
- टीम members के पास एक जैसा mental model होना चाहिए ताकि छोटे संकेतों से भी वही structure और behavior याद आ सकें
- अगर shared vocabulary और images हों, तो ideas को तुरंत आगे-पीछे करना और नई दिशाओं को साथ विकसित करना आसान हो जाता है
- इसके उलट अगर हर व्यक्ति अपने-अपने अलग एजेंट के साथ isolated होकर काम करे, तो ये समस्याएँ आती हैं
- वही term अलग-अलग अर्थों में इस्तेमाल होने लगती है
- technical plan की assumptions साझा नहीं हो पातीं
- outputs जुड़ जाते हैं, पर समझ नहीं जुड़ती
- टीम में AI का उपयोग सिर्फ़ individual productivity बढ़ाने का सवाल नहीं, बल्कि पूरी टीम की shared understanding बनाने का सवाल है
एजेंट और इंसान के काम को एक ही shared space में छोड़ना
- Notion में Claude और Cursor एजेंट को page के भीतर चलाया जा सकता है
- एजेंट द्वारा लिखी गई technical plans मूल रूप से collaborative pages में बनती हैं
- टीम members एजेंट की बनाई योजना को किसी अलग channel में copy किए बिना उसी जगह तुरंत review कर सकते हैं
- किसी खास वाक्य पर comment छोड़ना
- implementation choice पर सवाल पूछना
- योजना को मिलकर edit करना
- टीम की चर्चा और एजेंट के परिणाम को एक ही context में रखना
- एजेंट अगर निजी silos में काम करने के बजाय shared document के केंद्र में काम करे, तो इंसान और एजेंट साथ मिलकर सोचते हैं
- shared space सिर्फ़ परिणाम जमा करने की जगह नहीं, बल्कि वह स्थान है जहाँ टीम मिलकर mental model बनाती है
कंप्यूटर का उद्देश्य शुरू से augmentation था
- code understanding के लिए explanation/quiz/microworld की यह समस्या सिर्फ़ programming तक सीमित नहीं है
- इंसान को ज्ञान सिर्फ़ परिणाम verify करने के लिए नहीं, बल्कि दुनिया कैसे काम करती है यह समझने और बदलाव में भाग लेने के लिए ज़रूरत होती है
- लगभग 50 साल पहले Alan Kay ने कंप्यूटर को किताबों से बेहतर नए educational medium के रूप में सोचा था
- उस समय की चित्रकारी में बच्चे tablet जैसे device को देखते दिखते हैं, लेकिन वे कोई वीडियो निष्क्रिय ढंग से नहीं देख रहे
- वे interactive physics simulation को manipulate कर रहे हैं
- गेम खेलते हुए code को सीधे modify कर रहे हैं
- और देख रहे हैं कि बदला हुआ code physical movement को कैसे बदलता है
- कंप्यूटर सिर्फ़ static information देने वाली मशीन नहीं, बल्कि जटिल concepts को चलाकर, बदलकर, और समझाकर दिखाने वाला dynamic medium हो सकता है
सिर्फ़ automation नहीं, और गहरी भागीदारी
- एक meme के ज़रिए इसका सार बताया गया है: एक astronaut पृथ्वी को देखकर पूछता है, “क्या कंप्यूटर का उद्देश्य जटिल concepts को समझने के लिए dynamic simulations बनाना ही था?”, और पीछे वाला astronaut जवाब देता है, “हमेशा से”
- अगर कंप्यूटर और AI का उद्देश्य सिर्फ़ इंसानी काम हटाना मान लिया जाए, तो इंसान सिस्टम के बाहर धकेला जा सकता है
- इसके उलट अगर AI को explanation/simulation/microworld/shared space बनाने में लगाया जाए, तो इंसान ज़्यादा concepts को और गहराई से समझ सकता है
- AI जब simulation बनाने की लागत घटाता है, तो किसी खास concept को सीखने के लिए custom environment ज़रूरत पड़ते ही बनाया जा सकता है
- लक्ष्य सिर्फ़ इंसान को loop से बाहर निकालना नहीं, बल्कि उसे पहले से और गहराई से loop के भीतर लाना है
संबंधित लेख
- Enough AI copilots! We need AI HUDs - copilot से आगे बढ़कर इंसानी मानसिक क्षमताओं को और सीधे expand करने वाले AI interfaces
- AI-generated tools can make programming more fun - AI से custom debugger UI बनाकर इंसान द्वारा सीधे programming करने की प्रक्रिया को बेहतर बनाने का उदाहरण
- Code like a surgeon - सहायक repetitive tasks को delegate करके इंसान को मुख्य काम पर केंद्रित रखने का तरीका
2 टिप्पणियां
बॉटलनेक को पूरी तरह हटाने के लिए
चूंकि इंसान की cognition और memory structure short-term memory और long-term memory में बंटी होती है, इसलिए AI की coding speed को इस तरह कितना भी बढ़ाने की कोशिश की जाए, बीच-बीच में इंसान का खुद verify करते हुए short-term memory बनाना ही cognitive debt के लिहाज़ से सबसे कुशल है—मैं यही कहना चाहूंगा।