AI युग में कैसे सोचें: Crash Course
6 Disciplines · 6 AI Failure Modes · 1 नियम
सोमवार सुबह 2 लोग वही AI tool खोलते हैं। Task भी वही है: क्या वे अपना budget एक experienced person hire करने पर लगाएँ, या वही पैसा ऐसे AI tools खरीदने में लगाएँ जो team के हर व्यक्ति को तेज़ काम करने में मदद दें? दोनों के पास Claude, ChatGPT और Gemini access है। दोनों के पास फैसला करने के लिए 1 week है।
Person A शुक्रवार को ऐसी clear recommendation के साथ finish करती है जिसे वह explain कर सकती है। उसने लिखा कि AI की कौन सी claims से वह agree हुई, किन पर उसने push back किया, और क्या चीज़ उसका mind change करेगी। Person B शुक्रवार को एक polished document के साथ finish करती है जो ज़्यादातर वही repeat करता है जो AI ने सोमवार को कहा था। जब उसका boss पूछता है "आपने यह recommend क्यों किया?", तो वह अपनी ही reasoning explain नहीं कर पाती। उसने बस वह forward कर दिया जो अच्छा सुनाई दिया।
Same tools. Same problem. अलग outcomes.
फ़र्क thinking है। Person A ने AI से पूछने से पहले अपनी राय बनाई। Person B ने AI के पहले answer को अपनी राय बनने दिया।
यही gap यह crash course बंद करता है। 6 thinking habits, 3 छोटे parts, no code. हर habit उस specific तरीके को address करती है जिससे AI आपको mislead करता है जब आप उसे अपनी जगह सोचने देते हैं। साथ मिलकर ये AI को एक magic answer machine (आप पूछते हैं, वह answer देता है, आप accept कर लेते हैं) से एक thinking partner में बदल देती हैं (आप पहले predict करते हैं, वह answer देता है, आप compare करते हैं, आप decide करते हैं)।
वह force जिसके खिलाफ यह course train करता है
Person B lazy नहीं है। वह careless भी नहीं। उसे एक ऐसी force खींच रही है जिसका अब नाम है।
MIT Sloan के professor Eric So इसे AI gravity कहते हैं: अपनी thinking का ज़्यादा हिस्सा AI को outsource करने का constant pull। Simple words में: हर दिन AI से सोचवाना थोड़ा आसान हो रहा है, और अपना सोचना बंद करना भी थोड़ा आसान।
इसे gravity क्यों कहें? क्योंकि यह real gravity की तरह काम करती है। आप इसे देख नहीं सकते। यह कभी off नहीं होती। और यह सबको, हर समय, तीन directions से एक साथ खींचती है:
- आपका दिमाग energy बचाना चाहता है। दिमाग hard work से बचना चाहता है। यह normal है। लेकिन AI जितनी smart होती है, उसे एक और task देना उतना आसान लगता है, और अपना answer पहले लिखना extra work लगता है।
- आप चाहते हैं कि आपका काम expert-level दिखे। AI seconds में ऐसा text लिख देती है जो expert जैसा लगता है। उसके बिना काम करना एक shoe के साथ race करने जैसा लगने लगता है।
- आप नहीं देख सकते कि बाकी लोग AI कितना use कर रहे हैं। Classmates और coworkers announce नहीं करते। इसलिए हर कोई मान लेता है कि बाकी लोग ज़्यादा AI use कर रहे हैं, और race अपने आप तेज़ हो जाती है।
अब Monday morning वाली Person B को फिर देखें। तीनों forces ने उसे same easy move की तरफ धकेला: AI खोलो, पूछो, accept करो। उसे महसूस ही नहीं हुआ कि वह decide कर रही है। Gravity well अंदर से ऐसा ही लगता है।
तीन forces, एक pull। Person A भी वही gravity face करती है। Difference counterweight का है।
इस pull की cost। MIT Media Lab के researchers ने इस पर early study की। लोगों ने ChatGPT की मदद से essays लिखे। Submit करने के तुरंत बाद 100 में से 83 लोग अपने essay की एक भी sentence repeat नहीं कर सके। Words screen से homework तक गए, writer के दिमाग से गुज़रे ही नहीं। Study preliminary है, लेकिन warning clear है।
Professor So इस loss को cognitive capital कहते हैं। इसे अपनी thinking muscle समझें: problem पर काम करने, wrong answer पकड़ने, और confident answer ने क्या छोड़ा है यह notice करने की ability। इस page की हर discipline इसी muscle पर चलती है।
Words screen से submission तक गए, writer के दिमाग से नहीं।
Teachers भी desk के दूसरी तरफ से वही pull feel कर रहे हैं। June 2026 में, Madrid के IE School of Science & Technology की dean ने कहा कि school में AI का असली danger यह नहीं कि वह worse summary लिखती है; danger यह है कि students वह mental muscle बनाना बंद कर देते हैं जो summaries लिखने से बनती थी। Advice simple थी: hard thinking करते रहें, और AI उसके ऊपर add करें। (BusinessWorld, June 2026)
Professor So push back के चार तरीके भी देते हैं। आप उन्हें पहचानेंगे, क्योंकि यह page वही सिखाता है:
| Push back का तरीका | यहाँ कहाँ practice होता है |
|---|---|
| Hard thinking खुद करते रहें | Exercises और नीचे caution box |
| जानें कि AI के बिना आप क्या कर सकते हैं | Prediction Lock और Discipline 6 का Solo path |
| AI से बचा time harder thinking पर लगाएँ | Part 3, Origination |
| AI को coach बनाएँ, answer machine नहीं | हर AICheck exercise |
यह section यह नहीं कह रहा कि AI कम use करें। Six disciplines diet नहीं हैं। वे counterweight हैं। Gravity सिर्फ उन चीज़ों पर जीतती है जो अपना weight रखना छोड़ देती हैं। बाकी page बताता है कि आप heavy कैसे रहते हैं।
Prerequisites. यह page मानता है कि आपने पहले वाले Foundations courses पूरे कर लिए हैं, खासकर mental model के लिए What AI Actually Is और AI Prompting in 2026। उस course ने mechanics सिखाए थे: AI को context कैसे दें, web search और deep research कैसे use करें, images और audio के साथ कैसे काम करें, और AI desktop apps कैसे use करें। यह course वह thinking discipline सिखाता है जिससे उन mechanics का payoff मिलता है। अभी किसी दूसरे tab में Claude, ChatGPT, या Gemini का एक free account खोलें। Practice sections में आप उसका use करेंगे।
AI models पर एक note. Practice exercises में AI-graded feedback है। ये एक strong, current AI model के साथ best काम करते हैं (Claude, ChatGPT, या Gemini अपने best reasoning level पर)। Older या weaker models vague या overly positive feedback देते हैं, चाहे आपने कुछ भी submit किया हो। आपके पास जो best model हो उसे use करें। Specific brand matter नहीं करता; matter यह करता है कि model carefully reason कर सके।
📚 Teaching Aid
पूरा Presentation देखें : Thinking with AI
एक line में rule
Deliverable कभी answer नहीं होता। Deliverable सोच का documented evidence होता है।
इसे 2 claims की तरह पढ़ें। पहला, deliverable, यानी जो चीज़ आप अपने boss, professor, या client को देते हैं, अब सिर्फ answer नहीं रहा। AI seconds में एक polished answer produce कर सकता है; एक answer बनाना अब hard part नहीं रहा। दूसरा, अब एक deliverable को trustworthy बनाती है आपने कैसे सोचा इसका written record: AI से पूछने से पहले lock की हुई prediction, वह row जहाँ आपने AI की किसी claim को REJECT mark करके reason बताया, और वह cascade map जो आपने side effects trace करने के लिए बनाई (एक one-page diagram जिसमें आपके decision से affected हर group के लिए एक छोटी column होती है, जैसे students, professors, parents, sponsors, और हर एक के नीचे 3 arrows दिखाते हैं कि पहले क्या होता है, उससे आगे क्या होता है, और उसके बाद क्या होता है; Discipline 4 इसे पूरा explain करता है)। अगर कोई पूछे "आपने यह decide क्यों किया?", तो आप evidence पर point करते हैं।
Practice में, evidence आम तौर पर deliverable के अंदर रहता है: एक footnote, एक "considered and rejected" paragraph, एक figure के रूप में cascade map, अंत के पास एक "what would change my mind" sentence। कभी यह deliverable के पास एक working doc में रहता है। दोनों cases में, जब कोई पूछे क्यों, आप उस पर point कर सकते हैं। अगर आप किसी भी चीज़ पर point नहीं कर सकते, तो आपके पास ऐसा answer है जिसे आप defend नहीं कर सकते, और 2026 में वह deliverable नहीं है।
कभी-कभी। एक chat session AI ने जो कहा और आपने जो पूछा, सब capture करता है, जो किसी भी reasoning receipt से ज़्यादा complete है। Low-stakes work के लिए, जैसे code debug करना, quick research, exploratory brainstorm, chat link अकेला अक्सर काफी है। लेकिन serious deliverables के लिए chat link की 3 limits हैं: वह दिखाता है AI ने क्या कहा पर यह नहीं कि आपने हर claim पर क्या decide किया, वह एक busy reader के scan करने के लिए बहुत लंबा है, और वह नहीं दिखाता कि AI कहाँ गलत था (catches आपके head में रहते हैं, transcript में नहीं)। Chat link को raw material की तरह treat करें, जैसे एक academic paper raw data को treat करता है। Reasoning receipt या memo वह deliverable है जो आप audience को देते हैं; chat link appendix या footnote में जाता है, उन लोगों के लिए जो verify करना चाहें।
Practice में यह कैसा दिखता है। Opening वाले Person A और Person B याद करें: same problem, same AI, different outcomes। Friday morning, उनका boss दोनों से पूछता है: "आपने यह recommend क्यों किया?" Person B के पास point करने को कुछ नहीं। वह AI की मदद से बना document forward करती है और कहती है कि यह सही लगा। Boss उसे पढ़ता है, 2 claims से disagree करता है, और अब जानने का कोई तरीका नहीं कि Person B ने उन claims को examine किया था या बस accept कर लिया था। Person A अपना working doc खोलती है और कहती है: "Monday को मैंने predict किया था कि experienced hire better choice होगा। AI की analysis ने वह prediction flip कर दी, और यहाँ है कि मैंने अपना mind क्यों बदला: 3 claims जो मैंने check कीं, 1 जिसे मैंने reject किया, और वह assumption जो मेरी recommendation वापस बदल देगी।" Same problem। दो बिल्कुल अलग conversations।
Evidence आपको अभी, इसी deliverable में, क्या देता है? 2 चीज़ें। एक: लिखने का act thinking को force करता है। आप एक specific prediction तब तक नहीं लिख सकते जब तक पहले यह decide न कर लें कि आप सच में क्या believe करते हैं, और आप किसी claim को REJECT तब तक mark नहीं कर सकते जब तक पहले explain न करें कि क्यों। लिखे बिना, thinking skip करना बहुत आसान है: आप AI का polished answer पढ़ते हैं, वह सही लगता है, और आप उसे अपना बना लेते हैं बिना कभी एक position बनाए जिससे उसकी तुलना हो। लिखना वह part है जिसे fake नहीं किया जा सकता। दो: written record एक working tool है, सिर्फ audit trail नहीं। जिस bank manager ने लिखा "my recommendation is to close the branches, because I think most of these customers are app-only" और फिर देखा कि AI ऐसा data लेकर आया जिसमें सिर्फ 45% app-only थे, उसने सिर्फ एक disagreement document नहीं किया: उसकी position और data के बीच का gap उसकी report की opening line और उसकी recommendation की spine बन गया। Record वह surface है जिस पर thinking का second pass होता है, और second pass ही वह जगह है जहाँ deliverable असल में improve होता है।
बदला यह नहीं कि चीज़ें लिख लेने की habit है। बदली है उसे skip करने की cost। जब polished output expensive था, hard part चीज़ बनाना था। AI ने polished output free कर दिया। Bottleneck काम produce करने से उसे evaluate करने पर shift हो गया, और written evidence ही वह तरीका है जिससे आप evaluation करते हैं। Tools हर 6 months में बदलते हैं; यह नहीं बदलता।
मुख्य बातें (5 bullets)
आपने अभी rule सीखा। बाकी page जिन 6 habits को सिखाएगा, उनमें से 5 यहाँ हैं, पहले short version, full version नीचे के sections में। Bullets बताती हैं कि क्या करना है; sections दिखाते हैं कि कैसे। (छठी habit, यानी common advice कहाँ टूटती है, एक bullet से ज़्यादा setup चाहती है और अपना section रखती है।)
-
AI से पूछने से पहले सोचें। कोई भी AI tool खोलने से पहले लिखें कि आपको answer क्या लगता है। क्यों? क्योंकि AI का answer पढ़ते ही वह आपकी thinking पर कब्ज़ा कर लेता है। अगर AI कुछ reasonable लगने वाला कहता है, तो आप बिना realize किए उसे अपना बना लेंगे। पहले अपना answer लिखना आपके independent judgment को protect करता है।
-
जो आपने accept किया और जो reject किया उसका एक written record रखें। जब AI आपको claims या recommendations दे, हर एक पर जाएँ और लिखें: क्या मैं इससे agree करता हूँ? क्या disagree करता हूँ? क्या AI कुछ important miss कर गया? हर एक के लिए why explain करता एक sentence लिखें। अगर आप AI की हर बात से बिना कहीं push back किए agree करते हैं, तो शायद आपने hard enough think नहीं किया।
-
Polished writing और correct writing एक चीज़ नहीं है। AI हमेशा confident और professional लगता है, even when it is wrong. 6 specific तरह के errors smooth-sounding AI output के अंदर छिपते हैं (आप नीचे छहों सीखेंगे)। AI ने जो लिखा उसे send, publish, या उस पर act करने से पहले हर type को name से check करें।
-
Obvious answer कभी complete answer नहीं होता। जब AI एक decision analyze करता है, तो वह आपकी पूछी हुई चीज़ पर focus करता है और side effects ignore कर देता है। किसी भी important decision से पहले, अलग-अलग affected people और groups में आगे क्या होता है trace करें। ऐसी जगहें खोजें जहाँ side effects वापस आकर original decision को undo करते हैं।
-
Best results AI के साथ काम करने से आते हैं, उसे wheel सौंपने से नहीं। अकेले काम करना slow है। AI को सब कुछ करने देना generic output देता है। Winning approach: thinking और deciding आप करते हैं, research और drafting AI करता है। अगर आप इसे उलट देते हैं (AI thinks, आप बस edit करते हैं), तो आप unnecessary हो जाते हैं। जो लोग बस AI के answers pass along करते हैं, उन्हें eventually AI ही replace कर देगा।
पूरा framework: 6 disciplines
ऊपर की 5 bullets working summary हैं। यहाँ पूरा architecture है: 6 disciplines, जिन्हें वे जिन AI failure modes का answer देती हैं उनके साथ one-to-one pair किया गया है, और 3 parts में grouped।
Figure 1: 6 disciplines, 6 AI failure modes से map होती हैं, 3 parts में arranged।
ये 3 parts order में चलते हैं। Part 1, Foundations, AI से पूछने से पहले सोचने के बारे में है: पहले अपनी position लें, फिर हर answer पर आप जो decide करते हैं उसे track करें। Part 2, Detection, AI जो गलत करता है उसे spot करने के बारे में है: confident prose में दबी गलतियाँ, और वे side effects जिन्हें वह कभी trace नहीं करता। Part 3, Origination, उस thinking के बारे में है जो AI आपके लिए नहीं कर सकता: common advice कहाँ टूटती है यह खोजना, और जब AI कब्ज़ा करने की कोशिश करे तब अपना judgment in charge रखना। हर part उससे पहले वाले पर depend करता है।
इस page पर 4 terms बार-बार आते हैं। एक discipline वह thinking habit है जिसे आप practice करते हैं, यानी कुछ जो आप करते हैं। एक failure mode वह specific तरीका है जिससे AI आपको mislead करता है, यानी कुछ जो AI करता है। हर discipline उस failure mode के साथ one-to-one paired है जिसका वह answer देती है (figure में हर discipline name के नीचे italic line में दिखाया गया)। Course का एक part ऐसे disciplines को group करता है जिनका job एक ही है; 3 parts हैं (Foundations, Detection, Origination), हर एक में 2 disciplines, और हर part अगले को enable करता है। एक deliverable वह चीज़ है जो आप अपने boss, professor, या client को देते हैं; 2026 में यह answer plus वह documented evidence of thinking है जिसने उसे produce किया (figure के नीचे का banner)।
Figure में हर numbered box एक discipline है। नीचे की small caps line action line है: वह एक specific action जो वह discipline आपसे माँगती है, एक sticky note पर fit होने जितना लिखा हुआ। Discipline name बताता है कि habit को क्या कहते हैं; action line बताती है कि actually करना क्या है।
यहाँ से शुरू करें। Part 1 की 2 disciplines वही हैं जो AI को आपकी जगह सोचने से रोकती हैं। इन्हें skip करें और बाकी 4 अपना काम नहीं कर पाएँगी।
इस page को कैसे पढ़ें
| आपके पास समय | क्या पढ़ें | क्या skip करें |
|---|---|---|
| 45 minutes | Habits 1, 2, 3, और 6 (सिर्फ पढ़ें, exercises नहीं) | Habits 4 और 5 (बाद में लौटें) |
| 90 minutes | सभी 6 habits + worked examples, सिर्फ पढ़ें | AICheck submissions |
| एक working day (recommended) | सब कुछ, और हर exercise अपने week के एक real decision पर चलाएँ | कुछ नहीं |
ये habits तब stick करती हैं जब आप इन्हें अपने week की real problems पर try करते हैं। 90 minutes में page पढ़ना आपको moves दिखाता है। Real decisions पर exercises करना ही उन्हें आपका बनाता है।
यहाँ की हर habit को काम करने के लिए कुछ चाहिए। Prediction Lock आपसे पहले अपना answer लिखने को कहता है, पर आप वह तभी कर सकते हैं जब आप पहले से इतना जानते हों कि आपके पास एक answer हो। Error Taxonomy आपसे एक fake number spot करने को कहता है, पर आप उसे तभी spot कर सकते हैं जब आप जानते हों कि एक real number कैसा दिखता है। ये habits आपके judgment को use करती हैं। वे उसे build नहीं करतीं।
तो अगर आप अभी भी एक student हैं, तो hard work skip न करें। Summary खुद लिखें। Problem set बिना AI के solve करें। हाँ, AI इसे faster कर सकता है। पर इसे खुद करना ही वह तरीका है जिससे आपका brain इतना strong होता है कि बाद में AI के गलत होने पर उसे पकड़ सके। अगर आप कभी hard work नहीं करते, तो आपका Prediction Lock बस एक guess है: AI एक answer देता है, और आपके पास compare करने को अपना कुछ नहीं। Habit काम करती दिखती है, पर वह खोखली है।
Simple rule: AI को एक ऐसी skill stretch करने के लिए use करें जो आपके पास पहले से है, उसे सीखना skip करने के लिए नहीं। बीस साल के experience वाला एक accountant AI पर बहुत भरोसा कर सकता है, क्योंकि वह पहले से जानता है कि एक good answer कैसा दिखता है। एक first-year student जिसने कभी hand से काम नहीं किया, अभी नहीं कर सकता।
Part 1: Foundations (posture, यानी शुरू करने से पहले आपकी stance)
अगर आप बाकी सब skip करते हैं, तो भी ये 2 habits skip न करें। ये AI के साथ लोगों की 2 सबसे बड़ी mistakes fix करती हैं:
-
Mistake 1: AI आपके लिए सोचता है। आप एक question पूछते हैं, AI एक smooth answer देता है, और अपनी राय बनाने से पहले आप उसे accept कर लेते हैं। Habit 1 (Prediction Lock) इसे fix करता है: आप AI खोलने से BEFORE लिखते हैं कि आपको क्या लगता है।
-
Mistake 2: AI का first draft finished दिखता है। Writing इतनी polished होती है कि आप उसे check किए बिना send कर देते हैं कि वह actually correct है या नहीं। Habit 2 (Reasoning Receipt) इसे fix करता है: आप हर claim पर जाते हैं और लिखते हैं कि आप agree करते हैं, disagree करते हैं, या verify करना है।
साथ में, ये 2 habits thinking आपके पास और typing AI के पास रखती हैं। Parts 2 और 3 की हर चीज़ इन्हीं पर build होती है।
Discipline 1: Prediction Lock
Goal एक ही है: AI का answer आने से पहले आपके पास अपनी एक written position हो। नीचे जो कुछ भी है, यानी 4 lines, sticky note, confidence percentage, सब इसीलिए हैं कि वह एक चीज़ सच में हो जाए। अगर आप चारों lines लिख देते हैं और फिर भी नहीं बता पाते कि AI खोलने से पहले आपकी position क्या थी, तो discipline ने काम नहीं किया। अगर आपकी position clear है और आप 4 के बजाय 2 lines में वहाँ पहुँच गए, तो discipline ने फिर भी काम किया। 4 lines एक recipe हैं, dish नहीं।
Lock के बिना आम तौर पर यह होता है। आप AI से कोई important question पूछते हैं। AI एक confident, well-written answer देता है। आप सोचते हैं "यह सही लगता है" और उसी के साथ चल पड़ते हैं। 2 दिन बाद कोई पूछता है "आपने यह decide क्यों किया?" और आपको realize होता है: वह AI का answer था, आपका नहीं। आपने कभी अपनी राय बनाई ही नहीं।
Fix में 3 minutes लगते हैं। AI खोलने से पहले एक कागज़ पर 4 lines लिखें। पहले किसी और के decision पर साथ मिलकर try करते हैं।
Maya 13 साल की है। उसके school ने email किया: एक summer activity चुनें। Option 1: debate camp (2 weeks, उसके सारे friends जा रहे हैं)। Option 2: coding bootcamp (1 week, वह curious है लेकिन nervous भी)। उसके dad कहते हैं "बस ChatGPT से पूछ लो, उसे पता होगा।"
AI से पूछने से पहले, Maya 4 lines लिखती है:
Figure: Prediction Lock की 4 lines, एक worked example के रूप में Maya के answers के साथ।
Line 1: यह decision असल में किस बारे में है?
"Debate या coding" नहीं। वह सिर्फ surface है। नीचे का real question शायद यह है: "क्या मैं वही करूँगी जो मेरे friends करते हैं, या वह जो मैं तब चुनती जब कोई देख न रहा हो?" या: "क्या मुझे coding miss करने का regret debate miss करने से ज़्यादा होगा?" Real question 1 sentence में लिखें।
Line 2: वह 1 fact कौन सा है जो सबसे ज़्यादा help करेगा?
"कौन सा better है?" नहीं। वह बहुत vague है। कुछ specific जो आप check कर सकें: "क्या coding bootcamp Python सिखाता है?" यह इसलिए matter करता है क्योंकि उसका school 9th grade में already Python पढ़ाता है। अगर bootcamp वही चीज़ सिखाता है, तो coding के 2 weeks ज़्यादातर वही repeat करते हैं जो वह वैसे भी सीखेगी। अगर वह कुछ ऐसा सिखाता है जो उसका school cover नहीं करता, तो bootcamp ऐसी skill offer कर रहा है जो उसे कहीं और नहीं मिलती।
Line 3: AI के weigh in करने से पहले आपका decision क्या है?
एक position लें। "It depends" नहीं। "देखती हूँ AI क्या कहता है" नहीं। Debate चुनें या coding, और why लिखें। Maya की reasoning: वह जानती है कि school 9th grade में Python cover करता है, bootcamp भी सबसे ज़्यादा संभावना Python ही cover कर रहा है, और friends के साथ 2 weeks कुछ ऐसा सीखना जो उसे एक school course से नहीं मिलता, next year के curriculum के एक repeat से ज़्यादा value रखता है। तो उसका decision है debate।
यही वह part है जिसे हर कोई skip करना चाहता है। "मैं AI से पहले पूछे बिना decide कैसे करूँ?" आप कर सकते हैं। आप पहले से चीज़ें जानते हैं: आपका school क्या पढ़ाता है, क्या miss करने का regret होगा, आपके friends क्या कर रहे हैं। जो आप जानते हैं उससे एक position बनाएँ। एक minute में AI का काम उस position को confirm या overturn करना है, उसे आपके लिए बनाना नहीं।
Line 4: आप कितने confident हैं, और कौन सा specific AI answer आपका decision flip कर देगा?
एक percentage चुनें: 60%, 75%, कुछ भी। Exact number matter नहीं करता। Matter यह करता है कि आपने commit किया। फिर वह 1 AI answer लिखें जो आपका mind बदल दे। Maya: "70% sure कि debate सही call है। अगर bootcamp कुछ ऐसा सिखाता है जो मेरा school नहीं सिखाता (Rust, embedded programming, game development), तो coding जीतती है क्योंकि वह ऐसी skill है जो मुझे कहीं और नहीं मिलती।"
अगर आप वह specific AI answer name नहीं कर सकते जो आपका decision flip करे, तो आपने अभी एक real position पर commit नहीं किया। "It depends" एक position नहीं है। "मैं X करूँगा जब तक AI मुझे Y न बताए" एक position है।
आपको कैसे पता चलेगा कि lock ने काम किया?
एक test है, और वह lines count करने के बारे में नहीं है:
क्या आप ज़ोर से बोल सकते हैं कि AI खोलने से पहले आपकी position क्या थी, और कौन सी चीज़ आपका mind change करती?
अगर हाँ, lock ने काम किया। Line count matter नहीं करता।
अगर नहीं, यानी आप खुद को यह कहते पाते हैं कि "well, AI ने X कहा इसलिए मैं X के साथ चला गया" या "मैंने सोचा और जो AI suggest करेगा वही decide किया", तो lock ने काम नहीं किया। Line count फिर भी matter नहीं करता।
4 lines training wheels हैं। ये goal को skip करना मुश्किल बनाती हैं। कुछ weeks की practice के बाद आप चारों को 1 paragraph या कुछ mental notes में compress कर सकते हैं, और lock फिर भी काम करेगा। लेकिन पहली 10 बार ये 4 lines explicitly लिखें। यही जानने का एकमात्र तरीका है कि आपने सच में एक position commit की, बजाय यह सोचने के कि आपने की।
4 lines असल में क्या कर रही हैं
Maya के लिए 4 lines इसलिए काम करती हैं क्योंकि उसका decision simple है: 1 binary choice, 1 fact जो इसे settle कर देगा। हर decision ऐसा नहीं दिखता। इसलिए 4-line template copy करने से पहले देखें कि हर line अंदर से क्या कर रही है। Maya की lines एक ऐसे process की 1 instance हैं जो decisions बदलने पर भी, form बदलने के बावजूद, same रहता है।
Prediction Lock के 4 parts हैं। किसी भी decision के लिए यही 4 parts होते हैं:
- Real decision surface करें। Label हटाएँ। Maya का surface decision "debate या coding" था। उसका real decision था "friends को follow करूँ या अपनी choice करूँ"। Bank manager का surface decision "2 branches close करना" था। उसका real decision था "ऐसे customer base के साथ क्या करना जो app पर shift हो चुका है"। Label हमेशा actual question छिपाता है। Actual question name करें।
- वह चीज़ identify करें जो इसे settle करेगी। कौन सी information मिल जाए तो decision obvious हो जाएगा? Maya के लिए, 1 fact (क्या bootcamp Python पढ़ाता है?)। 3 candidates वाले एक hiring decision के लिए, शायद 3 facts (क्या हर candidate के पास वह specific skill है जो हमें सबसे ज़्यादा चाहिए?)। 5 categories में budget allocation के लिए, शायद एक comparison (marginal dollar पर किस category का return सबसे कम है?)। Facts इतने specific name करें कि आप हर एक verify कर सकें। Number decision पर depend करता है; यह requirement कि वे checkable हों, नहीं बदलती।
- एक position commit करें। जो आप पहले से जानते हैं उसके आधार पर, AI से कुछ भी check करने से पहले, आप क्या करेंगे? उसे support करती reasoning के साथ लिखें। Maya के लिए: debate, क्योंकि school already Python cover करता है। एक hiring decision के लिए: एक specific candidate name करें, reason के साथ। एक budget cut के लिए: line items name करें, reason के साथ। एक position एक what plus a why है, सिर्फ एक what नहीं।
- Reversal condition name करें। कौन सी specific finding position बदल देगी? Maya: अगर bootcamp कुछ ऐसा सिखाता है जो school cover नहीं करता, coding जीतती है। एक hire के लिए: अगर second candidate का reference check top candidate के मुक़ाबले significantly stronger आए, तो switch करें। एक budget cut के लिए: अगर Category X का projected revenue 30% से ज़्यादा off हो, तो किसी और category को cut करें। अगर आप यह name नहीं कर सकते कि क्या आपको flip करेगा, तो आपने commit नहीं किया: आपके पास एक preference है।
Maya की sticky note 4 lines में fit हो जाती है क्योंकि उसका decision इतना छोटा है कि हर part 1 line में fit हो जाता है। एक बड़ा decision, जैसे एक hiring round, एक strategic pivot, एक major purchase, हर part के लिए एक paragraph ले सकता है और एक A4 page भर सकता है। एक छोटा decision, जैसे lunch के लिए क्या order करें जब आप सच में care करते हों, एक single index card पर fit हो सकता है।
Different shape वाला एक worked example: मान लें आप 3 software engineers में से 1 hire कर रहे हैं और decide करने के लिए 1 week है।
- Real decision: "paper पर कौन best है" नहीं, बल्कि "इन तीनों में से कौन 12 months बाद भी productive रहेगा जब codebase 2 बार बदल चुका होगा।"
- What would settle it: 3 चीज़ें, 1 नहीं। हर candidate का long projects पर track record, unfamiliar tools सीखने की उनकी willingness, और एक previous manager का reference जिसने एक tough quarter में उन्हें देखा।
- Your position: Candidate B, क्योंकि previous job में उसका 2-year stint durability suggest करता है, और उसका side project दिखाता है कि वह बिना कहे new tools pick कर लेती है।
- What flips you: अगर Candidate A का reference कहे कि उसने past year का hardest project ship किया, तो A पर switch करें। अगर Candidate C का reference कोई communication issue flag करे, तो B stays।
यह Maya वाला ही Prediction Lock है। अलग decision, हर part के नीचे लिखी अलग amount, same 4 parts।
4 lines क्यों? सिर्फ 1 क्यों नहीं?
यह वह question है जो लगभग हर reader पूछता है, आम तौर पर Line 3 पर ("क्या मैं बस decision नहीं लिख सकता?")। Answer no है, और यह समझना worth है कि क्यों।
हर line एक failure mode पकड़ती है जिसे बाकी नहीं पकड़ सकतीं। इन्हें 1 line में compress करें और आप specific चीज़ें खो देते हैं:
- Line 1 skip करें, और आप गलत question का answer देते हैं। Maya का surface decision "debate या coding" है। उसका real decision "friends को follow करूँ या अपनी choice करूँ" है। इनके answers अलग हैं। Bank manager का surface decision "2 branches close करना" था। उसका real decision "ऐसे customer base के साथ क्या करना जो app पर shift हो चुका है" था। Label हमेशा actual question छिपाता है। Line 1 उसे surface करती है।
- Line 2 skip करें, और आपका AI prompt lock को collapse कर देता है। पूछने के लिए एक specific question के बिना, reader default रूप से "मुझे कौन सा pick करना चाहिए?" पर आ जाता है, जो AI को decision बनाने का एक open-ended invitation है। Line 2 एक closed, verifiable question force करती है जिसे AI या तो confirm या contradict कर सके। "क्या bootcamp Python पढ़ाता है?" checkable है। "कौन सा camp better है?" नहीं।
- Line 3 skip करें, और AI के answer से compare करने को कुछ नहीं बचता। यह खुद lock है। Lines 1 और 2 इसे set up करती हैं; Line 4 इसे specific बनाती है। पर Line 3 वह line है जो आपको एक position देती है जिसे AI का confident answer आने पर आप defend कर सकें।
- Line 4 skip करें, और आपके पास एक hope है, commitment नहीं। "मैं debate pick करता हूँ" एक decision लगता है। पर जब तक आप वह specific AI answer name नहीं करते जो इसे flip करेगा, आप नहीं बता सकते कि आपने सच में commit किया या आप उस moment position छोड़ देंगे जब AI कुछ और suggest करे। Line 4 commitment को specific होने पर force करती है। यह वह line भी है जो आपको, months later, check करने देती है कि आपका gut calibrated था या नहीं, "मैंने 70% कहा था और opposite निकला", और यही एकमात्र तरीका है जिससे judgment समय के साथ improve होता है।
One-line version try करें और खुद देखें। "मुझे लगता है Maya को debate pick करना चाहिए" एक casual preference है, prediction lock नहीं। यह नहीं कहता कि असल में stake पर क्या है, यह नहीं कहता कि कौन सा AI question इसे settle करेगा, और यह नहीं कहता कि क्या आपका mind बदलेगा। जो reader सिर्फ वह single line लिखता है, वह AI का two-paragraph response पढ़ेगा और बिना resistance के उसे adopt कर लेगा, क्योंकि line में resist करने के लिए कुछ है ही नहीं।
4 lines surface पर similar दिखती हैं (वे सब "आपकी position" के बारे में हैं) पर अलग चीज़ें पकड़ती हैं। Discipline 4 इसलिए माँगती है क्योंकि experience दिखाता है कि जो कोई एक skip करने की कोशिश करता है, वह उसी specific failure mode में गिर जाता है जिसे वह line पकड़ती है।
एक pedagogical reason भी है। 4 lines इतनी short हैं कि एक reader सच में कर सके (3 minutes, एक sticky note पर fit), पर इतनी long कि लिखने का act thinking को force करे। 1 line बहुत short है: आप उसे बिना सोचे लिख सकते हैं। 10 lines बहुत long हैं: आप exercise पूरी तरह skip कर देंगे। 4 वह floor है जहाँ thinking को सच में होना पड़ता है, और वह ceiling है जहाँ एक busy reader एक meeting से पहले Tuesday morning को भी इसे करेगा।
तो: 1 line अगर आपको एक prediction lock की appearance चाहिए। 4 lines अगर आपको चीज़ खुद चाहिए।
Maya की sticky अब यह कहती है:
क्या चल रहा है: क्या वह वही करेगी जो उसके friends कर रहे हैं, या वह जो अकेले होती तो चुनती।
वह question जो help करेगा: क्या bootcamp Python use करेगा (जो उसका school 9th grade में already पढ़ाता है)?
Decision: Debate। 2 weeks friends के साथ, कुछ ऐसा सीखना जो school offer नहीं करता, next year के curriculum के एक 1-week repeat से बेहतर है।
Confidence + क्या flip करेगा: 70%. अगर bootcamp Rust, embedded systems, या कुछ भी ऐसा सिखाता है जो उसका school cover नहीं करता, तो coding जीतती है।
अब वह अपना question ChatGPT में type करती है। यह actual prompt है जो वह paste करती है:
My school's summer program runs a one-week coding bootcamp. I'm trying
to figure out one thing: will it teach Python? My school already teaches
Python in 9th grade, so I want to know if there's overlap. Just answer
the question. Don't recommend which camp I should pick.
Lock ने question बदल दिया। Sticky note पर 4 lines के बिना, Maya ने AI से पूछा होता "मुझे debate pick करना चाहिए या coding?", एक open question जो decision AI को सौंप देता है। Lock के साथ, उसके पास already एक decision है; उसे उसे confirm या overturn करने के लिए सिर्फ 1 fact चाहिए। तो वह बजाय एक closed question पूछती है। AI का role decision-maker से fact-checker में shift हो जाता है। वही shift है जो discipline produce करती है। 4 lines ने सिर्फ Maya की thinking clarify नहीं की: उन्होंने reassign किया कि इस conversation में कौन क्या करता है।
ChatGPT लौटाता है: "Most one-week coding bootcamps for middle schoolers cover Python basics in the first two to three days." Maya इसे अपनी sticky note के बगल में रखती है। AI का answer (Python) उस answer से match करता है जिसके लिए वह तैयार थी। उसका decision (debate) hold करता है, उस reason के लिए जो उसने लिख रखा था, इसलिए नहीं कि AI ने उसे बताया।
Dinner पर उसके dad पूछते हैं क्यों, और Maya के पास एक real answer है: "Bootcamp Python cover करता है और मेरा school next year वैसे भी वही पढ़ा रहा है। मैं अपने friends के साथ 2 weeks debate सीखना पसंद करूँगी, जो school बिल्कुल offer ही नहीं करता।" वह उसकी reasoning है। AI ने उसके अंदर का 1 fact confirm किया।
इसकी तुलना lock के बिना वाले version से करें। Maya ChatGPT खोलती है, पूछती है "मुझे debate camp pick करना चाहिए या एक 1-week coding bootcamp?" ChatGPT एक balanced two-paragraph answer लिखता है जो "दोनों valuable हैं; देखें कि आपको सबसे ज़्यादा क्या energize करता है" पर खत्म होता है। Maya उसे पढ़ती है, debate pick करती है क्योंकि वहीं उसके friends जा रहे हैं, और dinner पर कहती है "ChatGPT ने कहा दोनों अच्छे हैं, तो मैं debate के साथ चली गई।" Decision वही है। Reasoning गायब है। 2 दिन बाद वह explain नहीं कर पाती कि उसने जो चुना वह क्यों चुना।
एक बार आप AI का answer पढ़ लेते हैं, आप उसे un-read नहीं कर सकते। आप यह भी नहीं बता सकते कि उसके बिना आपने क्या सोचा होता। आप बस 2 दिन बाद notice करते हैं कि आप ठीक से explain नहीं कर पा रहे कि आपने जो decide किया वह क्यों किया। आपने AI का answer absorb कर लिया। आपने अपना answer earn नहीं किया।
Answer आने से पहले sealed, वरना यह prediction है ही नहीं।
यही discipline बड़े decisions पर भी काम करती है। एक bank manager को decide करना था कि पैसे गँवा रही 2 branches close करें या नहीं। AI से पूछने से पहले, उसने अपनी 4 lines लिखीं:
Line 1 (यह असल में किस बारे में है): Branches पैसे इसलिए गँवा रही हैं क्योंकि अब ज़्यादातर customers in-person आने के बजाय app use करते हैं। Real question यह है कि क्या इतने customers अभी भी walk in करते हैं कि branches खुली रखना justify हो।
Line 2 (वह 1 fact जो इसे settle करे): इन branches के कितने percent customers app-only हैं (कभी branch नहीं आते)?
Line 3 (AI के weigh in करने से पहले मेरा decision): Branches close करें। Customer-service team के साथ काम करने का मेरा experience बताता है कि इनमें से ज़्यादातर customers सालों पहले walk in करना बंद कर चुके। 2 साल पहले मैं यह predict नहीं करती, लेकिन app launch के बाद से pattern clear है।
Line 4 (confidence + क्या flip करेगा): 60% sure। अगर आधे से कम customers app-only हैं, तो इसका मतलब एक real walk-in base अभी भी मौजूद है, और branches close करने से वे customers पूरी तरह खो जाएँगे। उस case में branches खुली रखें।
फिर उसने अपने bank का customer data निकाला और Claude से पूछा:
I have transaction data for two branches we're considering closing.
For each customer who used these branches in the last 12 months,
I need to know what percentage NEVER walked into a branch and
only used the mobile app. Just give me the percentage. Don't
recommend whether to close the branches.
Claude ने 45% लौटाया। यह उसके 50% threshold से कम है, यानी उसकी Line 4 flip हो गई: branches close करना अब सही call नहीं था।
लेकिन ज़्यादा interesting चीज़ थी उसकी expectation (ज़्यादातर customers app-only) और data (सिर्फ 45%) के बीच का gap। उस gap ने उसे बताया कि उसने overestimate किया था कि customer base कितनी दूर शिफ्ट हो चुका है। उसने दोनों findings अपनी report में use कीं: data ने उसकी recommendation "close" से "keep open" में flip की, और gap उसकी opening line बन गया: "मुझे उम्मीद थी कि इनमें से ज़्यादातर customers app-only होंगे; data दिखाता है सिर्फ 45% हैं, जो recommendation बदल देता है।" आख़िर में उसने एक middle path propose किया: branches reduced staff hours के साथ खुली रखें, क्योंकि 55% customers अभी भी walk in कर रहे थे, पर full-day levels पर नहीं।
Prediction Lock के बिना, वह जो भी AI कहता उसे accept कर लेती और कभी notice नहीं करती कि उसकी अपनी assumption off थी, और middle path (reduced hours) surface नहीं होता, क्योंकि उसके पास notice करने को कोई gap ही नहीं होता।
Maya की 4 lines और bank manager की 4 lines surface पर अलग दिखती हैं। वे same Prediction Lock हैं: same 4 parts, अलग size के decisions पर apply।
अब आपकी बारी
आपने Maya के लिए already 4 lines लिख दीं। आप वही lines नीचे के boxes में paste कर सकते हैं। या, अगर आपके पास अपना कोई decision है, तो उस पर 4 lines try करें। For example: कुछ जो आप खरीदना चाहते हैं, 2 plans जिनमें से आप चुन रहे हैं, एक conversation जिसे आप टालते रहते हैं, या एक class जिसके बारे में आप sure नहीं हैं।
पहले अपनी 4 lines लिखें। फिर इस prompt से AI से अपना Line 2 question पूछें:
I'm trying to decide [describe your situation in 1-2 sentences].
My question is: [paste your Line 2 question here].
Just answer that one question. Don't make the decision for me.
यह same prompt का Maya वाला version है, उसकी sticky note से filled in:
I'm trying to decide between two summer camps. One is a one-week
coding bootcamp; the other is a two-week debate camp where all my
friends are going.
My question is: does the bootcamp teach Python? My school already
teaches Python in 9th grade, so I want to know if there's overlap.
Just answer that one question. Don't make the decision for me.
ChatGPT का response:
Most one-week coding bootcamps for middle schoolers cover Python
basics in the first two to three days, then move on to a small
project using those basics. Some bootcamps add light JavaScript or
web concepts later in the week, but Python is almost always the
core language.
Maya इसे अपनी Line 4 के साथ रखती है। उसकी Line 4 कहती थी कि coding सिर्फ तभी जीतेगी जब bootcamp कुछ ऐसा सिखाए जो उसका school cover नहीं करता। AI ने confirm किया कि Python core है, यानी वही जो उसका school already 9th grade में पढ़ाता है। यह उसकी flipping condition नहीं है। उसका decision रहता है: debate।
Prompt में सिर्फ Lines 1 और 2 जाएँ। Line 3 (आपका decision) और Line 4 (क्या आपका mind बदलेगा) AI के देखने वाले page से बाहर रखें। अगर AI को पता हो कि आपने क्या commit किया है, तो वह अक्सर आपसे agree करता है, और आप वह comparison खो देते हैं जिसके लिए lock बना था।
फिर AI के answer को अपनी Line 4 से compare करें। आपने एक specific finding लिखी थी जो आपका mind बदल देती। क्या AI ने वह finding बताई या नहीं?
-
अगर AI का answer वह नहीं है जो आपको flip करता, आपका Line 3 decision hold करता है। आप उसे अपनी लिखी reason से defend कर सकते हैं। Maya का case (जो असल में हुआ): उसकी Line 4 कहती थी कि coding सिर्फ तभी जीतेगी जब bootcamp Rust या कुछ ऐसा सिखाए जो उसका school cover नहीं करता। AI ने कहा bootcamp Python सिखाता है, यानी वही जो उसका school already पढ़ाता है। यह flipping condition नहीं है। उसका decision रहता है: debate।
-
अगर AI का answer exactly वही है जो आपको flip करता, आपका decision बदलता है, उस reason के लिए जो आपने advance में set किया था, इसलिए नहीं कि AI confident लगा। Maya का case अगर AI कुछ और कहता: मान लें AI ने लौटाया होता "bootcamp embedded systems सिखाता है, Python नहीं।" वह Maya की Line 4 पर exactly hit करता (school embedded systems नहीं सिखाता)। वह coding पर switch कर जाती, उस reason के लिए जिस पर उसने Monday को commit किया था, इसलिए नहीं कि AI ने उसे sell किया।
-
अगर AI का answer बीच में कहीं है, अपनी Line 3 reasoning पर वापस जाएँ। क्या new information उसे सच में weak करती है? अगर हाँ, अपना decision बदलें और why लिखें। अगर नहीं, आपका decision फिर भी hold करता है। Maya का case अगर AI ambiguous होता: मान लें AI ने कहा होता "bootcamp पहले 3 days Python cover करता है फिर React introduce करता है।" React ऐसी चीज़ है जो उसका school नहीं सिखाता, पर वह bootcamp के सिर्फ 2 days हैं। Maya अपनी Line 3 फिर पढ़ती है: case था "friends के साथ 2 weeks debate सीखना, 1 week ज़्यादातर Python repeat करने से बेहतर है।" 2 days React इसे नहीं बदलते: bootcamp अभी भी ज़्यादातर repeat material है। उसका decision रहता है।
अगर AI answer देने के बजाय hedge करे, 1 और sentence के साथ फिर पूछें: "Just give me the specific information; don't qualify it." अगर AI एक clarifying question पूछे, उसका answer दें पर add करें: "Then answer the original question." Goal एक concrete answer है जिसे आप अपनी Line 4 के बगल में रख सकें, "it depends on several factors" का एक paragraph नहीं। अगर आपका दूसरा attempt भी एक usable answer नहीं देता, तो आपका Line 2 question शायद बहुत broad है। उसे ज़्यादा specific होने के लिए rewrite करें, फिर दोबारा try करें।
Lock revise करने पर एक note. अगर AI का answer आपको realize कराए कि आपकी Line 4 गलत थी, यानी आपने गलत flipping condition name की, तो यह honor करने लायक एक real signal है, पर ध्यान रखें कि आप कब revise करते हैं। AI के answer पर react करने का decide करने से पहले Line 4 revise करना ठीक है; आपने कुछ miss किया था जो आपको दिखा, और आप अपनी thinking update कर रहे हैं। AI का answer आ जाने के बाद Line 4 revise करना ताकि answer एक flip न गिने, lock को defeat करता है। Test यह है: क्या आप नई Line 4 AI का answer देखे बिना भी लिखते? अगर हाँ, revise करें। अगर नहीं, आपकी पुरानी Line 4 कायम रहती है।
Check करें कि lock ने काम किया। ज़ोर से यह sentence पूरा करने की कोशिश करें: "मैंने यह इसलिए decide किया क्योंकि..." अगर आप इसे "AI ने कहा" शब्दों के बिना कर सकते हैं, तो lock ने काम किया। अगर नहीं कर सकते, तो वह line खोजें जो आपने skip की।
वह sentence, जिसे आप ज़ोर से पूरा कर सकते हैं, documented evidence of thinking का सबसे छोटा टुकड़ा है जो आप produce कर सकते हैं। यह वही चीज़ है जिसके बारे में इस page के top का rule है: एक polished answer नहीं जो AI ने आपको दिया, बल्कि एक reason जिस पर आप point कर सकें। नीचे की हर discipline इसी एक evidence के टुकड़े पर build होती है। इसे काम करा लें, और बाकी आसान हो जाती हैं।
नीचे की exercise यह check नहीं करती कि आपका decision "सही" है या नहीं। यह सिर्फ यह check करती है कि आपकी 4 lines clear हैं या नहीं: क्या आपने real decision name किया? क्या आपका question specific है? क्या आपकी position committed है ("it depends" नहीं)? क्या आपने वह specific AI answer name किया जो आपको flip करेगा? आपकी पहली try messy हो तो ठीक है।
आपके पास boxes में डालने के लिए 2 options हैं। Option 1: Maya के लिए 4 lines लिखें, यानी उसका decision (debate camp vs. coding bootcamp) use करें और हर line क्या कहनी चाहिए इसका अपना version लिखें। Grader check करेगा कि आपकी lines clear हैं या नहीं। Option 2: अपने week के किसी real decision के लिए 4 lines लिखें, यानी कुछ जिसे आपको सच में figure out करना है। Grader वही चीज़ check करेगा। दोनों option चलते हैं; discipline same है।
अगर आप Option 1 चुन रहे हैं, तो reference के लिए Maya की lines ये हैं:
Line 1 (क्या चल रहा है): क्या वह वही करेगी जो उसके friends कर रहे हैं, या वह जो अकेले होती तो चुनती।
Line 2 (वह question जो help करेगा): क्या bootcamp Python use करेगा (जो उसका school 9th grade में already पढ़ाता है)?
Line 3 (decision): Debate। 2 weeks friends के साथ, कुछ ऐसा सीखना जो school offer नहीं करता, next year के curriculum के एक 1-week repeat से बेहतर है।
Line 4 (confidence + क्या flip करेगा): 70%. अगर bootcamp Rust, embedded systems, या कुछ भी ऐसा सिखाता है जो उसका school cover नहीं करता, तो coding जीतती है।
चारों boxes भरें और submit click करें। Grader हर line को score करता है और बताता है कि क्या improve करें, ठीक वैसे जैसे एक teacher आपकी homework तुरंत check कर रहा हो।
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार इसमें लगभग 8 minutes लगते हैं। Score मिलने के बाद, कोई 1 जगह खोजें जहाँ आपको लगता है AI grader गलत है। वही इस exercise का सबसे useful हिस्सा है।
यह Discipline 1 का आधा हिस्सा cover करता है। दूसरा आधा (AI जो कहता है उसका track रखना और decide करना कि किन parts से आप agree करते हैं, disagree करते हैं, या उन्हें change करना चाहते हैं) Discipline 2 है।
यह काम क्यों करता है (इसके पीछे की research)
Prediction Lock कोई नया idea नहीं है। यह 3 पुरानी techniques का AI-era version है, जिनमें से हर एक decades से study की गई है।
Premortem (Gary Klein, 2007). एक project शुरू होने से पहले, team कल्पना करती है कि वह already fail हो चुका है और सारे reasons लिख लेती है कि क्यों। Failure reasons को पहले लिखने का act, project के optimism के हावी होने से पहले, ऐसे risks surface कर देता है जो वरना दबे रह जाते। Deborah J. Mitchell, Jay Russo, और Nancy Pennington की research ने पाया कि "prospective hindsight", यानी यह imagine करना कि एक event already हो चुकी है, future outcomes के reasons सही पहचानने की ability 30% बढ़ा देता है। आपने अभी जो discipline सीखी, वह छोटे पैमाने पर यही करती है: AI के weigh in करने से पहले, आप अपना decision और वह specific finding लिखते हैं जो आपका mind बदल दे। "पहले लिखना" ही load-bearing हिस्सा है।
Klein का original article पढ़ें: Performing a Project Premortem, Harvard Business Review, September 2007।
Forecasting calibration (Philip Tetlock, Good Judgment Project, 2011-2015). Tetlock और उनके colleagues ने एक multi-year tournament चलाया जहाँ हज़ारों forecasters ने world events पर probabilistic predictions कीं। Best forecasters, जिन्हें Tetlock "superforecasters" कहते थे, एक specific habit रखते थे: वे अपनी predictions confidence percentages के साथ answer आने से पहले record करते थे, फिर बाद में prediction को outcome के against compare करते थे। एक लिखी हुई prediction के बिना आप नहीं बता सकते कि आपका gut calibrated था या off, क्योंकि आप अपनी "prior beliefs" को जो भी हुआ उससे match करने के लिए reconstruct कर लेते हैं। Prediction Lock की Line 4 (confidence percentage) इस practice का सबसे छोटा संभव version है। Months और years तक, अपनी locked-in confidence को actual outcomes से compare करना ही judgment improve करने का एकमात्र तरीका है।
Project के बारे में पढ़ें: The Good Judgment Project (Wikipedia)। Book-length treatment के लिए: Tetlock and Gardner, Superforecasting: The Art and Science of Prediction (2015)।
Anchoring (Amos Tversky और Daniel Kahneman, 1974). जब एक confident answer आपके head में वह जगह घेर लेता है जहाँ आपका अपना answer होता, तो वह confident answer आपका reference point बन जाता है, और आप अब नहीं बता सकते कि उसके बिना आप क्या सोचते। Tversky और Kahneman के original work ने numerical examples use किए (लोगों से एक arbitrary number दिखाने के बाद एक percentage estimate करने को कहा गया, तो उनके estimates उस number से anchored निकले), पर principle general है: कोई भी confident answer जो आपके अपना answer बनाने से पहले आपके head में land कर जाए, वह anchor बन जाता है जिससे आपकी आगे की thinking adjust होती है। AI के answers by default confident होते हैं। यही उन्हें powerful anchors बनाता है। Prediction Lock वह move है जो anchor को बनने से रोकती है: आप अपना anchor पहले, लिखकर, AI के land करने से पहले रख देते हैं।
Original paper पढ़ें: Judgment under Uncertainty: Heuristics and Biases, Science, Vol. 185, No. 4157, September 27, 1974, pp. 1124-1131। (अगर Science journal का access नहीं है, तो इस mirror पर open-access उपलब्ध है।)
Prediction Lock तीनों को combine करती है। अपना decision और flipping condition पहले लिखें (premortem)। अपनी confidence record करें ताकि बाद में calibration check कर सकें (Tetlock)। और दोनों AI का answer पढ़ने से पहले करें, ताकि AI की confidence वह anchor न बने जिससे आप adjust करते हैं (Tversky और Kahneman)। एक sticky note पर 4 lines, research के 3 decades को एक 3-minute habit में compress कर देती हैं।
इस exercise का full version (10 ranked questions plus Reasoning Receipt template; 45-60 minutes) Part 0 Chapter 1, Lesson 1 में है। यह page discipline सिखाता है। वह page इसे एक system बनाता है।
Discipline 2: Reasoning Receipt
आपने सुबह Claude के साथ एक report पर काम करते हुए बिताई। Result अच्छा दिखता है। आप उसे भेज देते हैं और आगे बढ़ जाते हैं। 2 weeks बाद कोई पूछता है: "इसके कौन से parts आपने सच में check किए? कौन से parts आपने change किए?" आपके पास कोई answer नहीं। आपने पढ़ा कि AI ने क्या लिखा, वह ठीक लगा, इसलिए use कर लिया। काम हो गया, लेकिन आपने उस पर कभी सच में सोचा ही नहीं।
यह AI से अपनी जगह सोचने देने (Discipline 1) के बाद दूसरी सबसे common AI failure mode है। तब भी जब आपकी अपनी position locked हो, AI के drafts बड़े polished blocks में आते हैं (5 suggestions, एक 6-paragraph memo, एक 10-row plan), और बाद में आप उनमें से किसी को defend नहीं कर सकते क्योंकि आपने कभी track नहीं किया कि हर piece पर आपने क्या decide किया।
इसे fix ऐसे करें। हर बार जब AI आपको कोई claim, recommendation, या writing का एक chunk देता है जो आपके final work में जाता है, आप एक one-line note बनाते हैं कि आपने उसके साथ क्या किया और क्यों। पूरी चीज़ नहीं, बस हर piece पर एक note। साथ में इन notes को एक Reasoning Receipt कहते हैं।
एक row कैसी दिखती है। मान लें आपने Claude से एक group presentation plan करने में help माँगी, और उसने suggest किया: "Start the presentation with a short video clip to grab attention." आप उस पर सोचते हैं। आपकी teacher ने इसी semester पहले कहा था कि visual openings को better grades मिलते हैं, तो यह suggestion उससे match करता है जो आप पहले से जानते हैं कि इस class में क्या काम करता है। आप उसे रखने का decide करते हैं।
वह decision आपकी receipt में एक row बन जाता है:
| AI ने क्या कहा | आपने क्या किया | Why |
|---|---|---|
| Start with a short video clip to grab attention. | ACCEPT | हमारी teacher ने कहा कि visual openings को better grades मिलते हैं। यह fit होता है। |
3 columns। AI ने क्या कहा (ताकि future आप याद रखें कि किस बात पर decide हो रहा था), आपने क्या किया (एक one-word label), और why (एक sentence ताकि row बाद में defensible हो)।
अब मान लें Claude का अगला suggestion था "Give each person 5 minutes to speak." आपके group में 4 members हैं और कुल 15 minutes हैं। Math नहीं बैठता। तो आप उसे reject करते हैं:
| AI ने क्या कहा | आपने क्या किया | Why |
|---|---|---|
| Give each person 5 minutes to speak. | REJECT | हमारे पास 4 लोगों के लिए 15 minutes हैं। Math नहीं बैठता। |
यही discipline है। हर AI suggestion पर एक row, हर एक में 3 columns।
5 labels। आपने क्या किया हमेशा 5 categories में से किसी एक में आता है। ज़्यादातर बार आप ACCEPT, REJECT, या MODIFY use करेंगे। बाकी दो (SURFACED और MISSED) ऐसे cases पकड़ते हैं जिन्हें वरना skip करना आसान है।
| Label | आपने क्या किया | Why पर एक sentence लिखें |
|---|---|---|
| ACCEPT | AI ने जो कहा वह बिना change रखा। | आपने उस पर trust क्यों किया। |
| REJECT | आपने decide किया कि AI गलत था और उसे हटा दिया। | किस चीज़ ने आपको disagree कराया। |
| MODIFY | Idea रखा पर उसका एक हिस्सा बदला। | आपने क्या बदला और क्यों। |
| SURFACED | AI ने कुछ ऐसा उठाया जिस पर आपने सोचा नहीं था। आपने रखा। | यह क्यों matter करता है। |
| MISSED | आपने कुछ ऐसा notice किया जो AI बताना भूल गया। आपने add किया। | क्या missing था और वह क्यों matter करता है। |
ACCEPT, REJECT, और MODIFY basic moves हैं। SURFACED उन moments के लिए है जब AI ने आपको कुछ सिखाया: वे track करने लायक हैं क्योंकि उन्हीं cases में AI ने सच में ऐसी thinking add की जो आप अकेले न करते। MISSED उसके लिए है जो AI ने नहीं कहा पर कहना चाहिए था: वे cases हैं जहाँ आपके अपने judgment ने वह पकड़ा जिसे AI की drafting ने gloss कर दिया।
एक अच्छी receipt में समय के साथ पाँचों का एक mix होता है। अगर हर row ACCEPT कहती है, तो आप सच में सोच नहीं रहे: आप बस AI ने जो लिखा उस पर sign off कर रहे हैं।
"लेकिन कोई मेरे काम का audit नहीं करता, तो bother क्यों?"
यह इस discipline पर सबसे reasonable objection है, और इसका एक real answer बनता है। ज़्यादातर readers, ज़्यादातर बार, audit नहीं होंगे। आपका boss नहीं पूछता। आपका professor आगे बढ़ जाता है। आपका client sign off कर देता है। अगर एक Reasoning Receipt का एकमात्र payoff "किसी ने पूछ लिया तो" होता, तो receipt की मेहनत worth नहीं होती।
एक receipt रखना 3 चीज़ें करता है, तब भी जब कोई कभी न पूछे।
पहला, लिखने का act बदल देता है कि आप क्या decide करते हैं। जब आप किसी AI suggestion को चुपचाप accept करते हैं, आपका brain उसे "सही लगता है, आगे बढ़ो" की तरह process करता है। जब आपको एक one-word label और एक one-sentence reason लिखना पड़ता है, आपके brain को suggestion को सच में examine करना पड़ता है। ज़्यादातर readers, जब पहली बार यह try करते हैं, हर session में कम से कम एक row पाते हैं जहाँ वे "why" sentence पूरा नहीं कर पाते। वह row कुछ ऐसा था जिसे वे बिना सोचे use करने वाले थे। Receipt उसे ship होने से पहले पकड़ लेती है।
दूसरा, receipt आपके काम का हिस्सा बन जाती है, सिर्फ उसका record नहीं। Discipline 1 की bank manager ने अपनी position और data के बीच के gap को अपनी report की opening line बना दिया। नीचे के अगले example की student ने अपनी receipt को अपने group के साथ एक working document की तरह use किया, audit trail की तरह नहीं। REJECT label वाली एक row अक्सर final document में एक "considered alternatives" paragraph बन जाती है। SURFACED label वाली एक row अक्सर वह सबसे interesting insight बन जाती है जो आप meeting में लाते हैं। Receipt एक working tool है, filing cabinet नहीं।
तीसरा, future आप ही सबसे common auditor हैं। आज से 3 months बाद, आप इस काम को देखेंगे और याद नहीं रहेगा कि कौन से parts आपके थे, कौन से AI के, या आपने क्या क्यों decide किया। Receipt future आप के लिए एक note है। ज़्यादातर बार जब receipt काम आती है, सवाल खुद आपसे आता है, किसी boss से नहीं।
Audit scenario सबसे visible payoff है, पर सबसे rare। पहले 3 payoffs हर बार होते हैं जब आप एक receipt रखते हैं, तब भी जब कोई उसे कभी न पढ़े। Page का central rule practice में यही मतलब रखता है: deliverable सोच का documented evidence है। Receipt आपके काम से अलग नहीं है: यह काम produce करते समय उसे shape करती है, और समय के साथ यही वह चीज़ है जो project की memory fade हो जाने पर भी आपके पास रहती है।
एक receipt में हर row एक decision है। Label बताता है आपने क्या किया। "Why" future आप को (या किसी भी पढ़ने वाले को) बताता है कि row क्यों trust की जा सकती है।
Real life में यह कैसा दिखता है।
एक student ने Claude से class के लिए एक group presentation plan करने में help माँगी। Claude ने एक पूरा plan दिया। उसे बस use करने के बजाय, student ने हर suggestion पर जाकर लिखा कि उसने क्या सोचा:
| AI ने क्या कहा | Label | Why |
|---|---|---|
| "Start the presentation with a short video clip to grab attention." | ACCEPT | अच्छा idea। हमारी teacher ने कहा कि visual openings को better grades मिलते हैं। |
| "Give each person 5 minutes to speak." | REJECT | हमारे पास कुल सिर्फ 15 minutes हैं और हम 4 लोग हैं। Math नहीं बैठता। |
| "End with a Q&A session." | MODIFY | Q&A हाँ, पर अगर कोई कुछ न पूछे तो हम 3 backup questions तैयार रखेंगे। |
| "Add a live demo of the app you built." | SURFACED | मैंने यह सोचा नहीं था। एक live demo हमारी presentation को अलग दिखाएगी। |
| (AI ने यह नहीं बताया कि projector के लिए laptop और adapter कौन लाएगा।) | MISSED | मैंने यह add किया। पिछली बार हमारा group adapter भूल गया था और 5 minutes बर्बाद हुए। |
उसने receipt अपने group के साथ share की। Presentation के बाद, teacher ने पूछा कि उन्होंने हर person को 5 minutes क्यों नहीं दिए। उसने row 2 की ओर point किया: "हमारे पास 4 लोगों के लिए सिर्फ 15 minutes थे। Math नहीं बैठा।" वही एक sentence काफी था। Receipt के बिना, उसे सब कुछ scratch से याद करके explain करना पड़ता।
Receipt के बिना क्या होता है:
| AI ने क्या कहा | Label | Why |
|---|---|---|
| "Start with a short video clip." | ACCEPT | सही लगता है। |
| "Give each person 5 minutes." | ACCEPT | सही लगता है। |
| "End with a Q&A session." | ACCEPT | सही लगता है। |
| "Add a live demo." | ACCEPT | सही लगता है। |
| (कुछ नहीं लिखा।) |
अगर हर row reason के रूप में "सही लगता है" के साथ ACCEPT कहती है, तो आपने उस पर सच में सोचा नहीं। आपने बस AI ने जो कहा वह copy कर लिया। एक अच्छी receipt में labels का mix होता है। अगर आप explain नहीं कर सकते कि आपने कुछ accept क्यों किया, तो आपने उसे रखने का decide नहीं किया। आप बस उसके साथ चल पड़े।
खुद try करें
आप अपनी university का annual tech fest organize कर रहे हैं। आपकी team में 10 members हैं। Event 3 weeks में है। आपने अभी marketing शुरू नहीं की। एक दूसरी university ने उसी weekend एक similar event announce कर दिया। आपने AI से पूछा: "क्या हमें event एक week पहले move करना चाहिए, या original date रखनी चाहिए?" AI ने आपको 5 suggestions दिए। हर एक के लिए एक label (ACCEPT, REJECT, MODIFY, SURFACED, या MISSED) चुनें और एक sentence में why लिखें।
- "Move it earlier. Being first matters when two events compete for the same audience."
- "If you keep the original date, students will compare the two events and may pick the other one."
- "Your social media posts get the most engagement on Thursdays, so start marketing this Thursday."
- "Moving one week earlier means your team has only 2 weeks to prepare instead of 3."
- "Most students decide which events to attend based on what their friends are going to."
AI grader 2 चीज़ें check करेगा:
- क्या आपने अपनी reasoning explain की, या बस "सही लगता है" लिखा? 1-10 rate करें। मेरी weakest explanation quote करें।
- क्या आपने 1 से ज़्यादा label use किए? अगर हर row ACCEPT कहती है, तो आपने उस पर सच में सोचा नहीं। 1-10 rate करें।
मेरे काम को rewrite न करें। अगर box empty या vague है, तो बस साफ़ कहें।
Claim 1: "Move it earlier. Being first matters."
Claim 2: "Students will compare the two events and may pick the other one."
Claim 3: "Start marketing this Thursday because that is when posts get the most engagement."
Claim 4: "Moving earlier means only 2 weeks to prepare instead of 3."
Claim 5: "Students decide based on what their friends are going to."
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार 10-15 minutes लगते हैं। Score मिलने के बाद, कोई भी ऐसी row खोजें जहाँ आपने बिना किसी real reason के "सही लगता है" लिखा। वही वह row है जहाँ आपने अपनी thinking किए बिना AI की thinking accept कर ली। वापस जाकर उस एक row के लिए एक real explanation लिखें।
जो आपने अभी किया, वह हर suggestion को एक बार में एक check करने में help करता है। लेकिन यह हर suggestion के अंदर की गलतियाँ नहीं पकड़ता, जैसे made-up facts, outdated information, या AI का किसी ऐसी चीज़ पर confident होना जो उसने गलत बताई। वह Discipline 3 का काम है।
एक good example देखना है? (अपना submit करने के बाद खोलें।)
एक और student ने यही tech fest exercise किया। यह अकेला सही answer नहीं है, पर दिखाता है कि एक अच्छी receipt कैसी दिखती है।
| Claim | Label | Why |
|---|---|---|
| 1 | REJECT | यहाँ पहले होना matter नहीं करता। Students event इस आधार पर चुनते हैं कि क्या fun लगता है, यह नहीं कि किसे पहले announce किया गया। |
| 2 | MODIFY | Students compare कर सकते हैं, पर तभी जब उन्हें दोनों के बारे में पता चले। अगर हम better market करें, तो दूसरा event matter नहीं करता। |
| 3 | ACCEPT | पिछले semester का हमारा Instagram data दिखाता है कि Thursday posts को 2x ज़्यादा likes मिलती हैं। यह सही बैठता है। |
| 4 | SURFACED | मैंने यह सोचा नहीं था। एक week की prep time खोना एक real problem है क्योंकि हमने अभी venue book नहीं किया। |
| 5 | ACCEPT | यह सच है। पिछले साल हमने registration form में "bring your friend" option जोड़ने के बाद sign-ups में एक बड़ा jump देखा। |
| 6 | MISSED | AI ने यह mention नहीं किया कि हमारे सबसे बड़े sponsor को 3 weeks notice चाहिए। पहले move करने का मतलब हम sponsorship खो सकते हैं। |
यह अच्छा क्यों है: सिर्फ 2 ACCEPTs हैं, और दोनों के पीछे real reasons हैं (पिछले semester और पिछले साल का actual data, सिर्फ "सही लगता है" नहीं)। MISSED row (row 6) कुछ ऐसा पकड़ती है जो AI जान ही नहीं सकता था (sponsor का 3-week notice rule)। Student ने आख़िर में original date रखने का decide किया, पर एक ऐसे reason से जो AI ने कभी mention नहीं किया: sponsorship।
यह क्या करने की कोशिश नहीं करता: clever होना। ज़्यादातर rows एक sentence हैं। Point real reasons लिखना है, लंबे नहीं।
यह काम क्यों करता है (इसके पीछे की research)
Reasoning Receipt भी कोई नया idea नहीं है। आपने क्या decide किया और क्यों, यह लिख लेना उन सबसे ज़्यादा study की गई habits में से एक है कि experts असल में कैसे सोचते हैं। 3 bodies of work बताती हैं कि यह क्यों काम करता है।
Reflection-in-action (Donald Schön, 1983). यह study करते हुए कि doctors, architects, engineers, और teachers असल में कैसे काम करते हैं, Schön ने पाया कि skilled professionals सिर्फ act करके आगे नहीं बढ़ते: वे एक running internal commentary रखते हैं, surprises notice करते हैं और काम चलते-चलते decide करते हैं कि उनके बारे में क्या करना है, बाद के किसी review में नहीं। जो professionals सबसे तेज़ improve हुए, वे वही थे जिन्होंने उस commentary को tacit छोड़ने के बजाय explicit बनाया। Reasoning Receipt वही commentary लिखी हुई है: चुपचाप यह सोचने के बजाय कि "यह AI suggestion कुछ off लगता है," आप label और reason तब लिखते हैं जब आप अभी भी काम में हैं, जहाँ यह बदल सकता है कि आप आगे क्या करते हैं।
और पढ़ें: Reflective practice (Wikipedia), जो Schön की The Reflective Practitioner (Basic Books, 1983) का summary देता है।
Single-loop vs. double-loop learning (Chris Argyris, 1977). Argyris ने 2 तरह के correction के बीच एक line खींची। Single-loop learning तुरंत की गलती fix करता है: answer गलत था, तो आप answer बदल देते हैं। Double-loop learning पीछे हटकर पूछता है कि क्या पूरा approach या assumption ही गलत था। उनकी finding यह थी कि smart, capable लोग by default single-loop mode में फँस जाते हैं; वे output tune करते हैं और frame पर कभी सवाल नहीं उठाते। एक ऐसी receipt जहाँ हर row ACCEPT कहती है, single-loop thinking को visible बना देती है: आप outputs approve कर रहे हैं बिना यह पूछे कि approach सही है या नहीं। हर row पर एक real "why" force करना, और यह notice करना कि कब आप एक नहीं लिख पाते, वही आपको double loop में धकेलता है।
Argyris का original article पढ़ें: Double Loop Learning in Organizations, Harvard Business Review, September 1977।
Elaboration और generation effect (Brown, Roediger & McDaniel, 2014). Decades की memory research एक simple finding पर पहुँचती है: आप किसी चीज़ को तब कहीं बेहतर याद रखते हैं जब आप उसे अपने शब्दों में डालते हैं और जो आप पहले से जानते हैं उससे जोड़ते हैं, बजाय इसके कि बस दोबारा पढ़ लें। Explanation generate करने का act, एक single sentence भी, वही है जो durable memory बनाता है। आपकी receipt का हर "why" बिल्कुल यही move है। 3 months बाद, जिस row के लिए आपने एक real reason लिखा, वही आप अब भी समझेंगे; जिस row पर "सही लगता है" का rubber-stamp लगाया, वह एक blank होगी।
और पढ़ें: Make It Stick: The Science of Successful Learning (Belknap Press of Harvard University Press, 2014), book के central findings का एक summary।
Reasoning Receipt तीनों को combine करती है। आप हर AI claim पर अपना decision तब लिखते हैं जब आप अभी भी काम में हैं (Schön), forced "why" आपको outputs पर rubber-stamp लगाने से approach पर सवाल उठाने की ओर धकेलती है (Argyris), और reason को अपने शब्दों में डालना वही है जो आपको बाद में याद दिलाता है (Brown, Roediger & McDaniel)। किसी ने Reasoning Receipt को AI के against specifically test नहीं किया, पर इसके नीचे की habit, यानी अपने choices लिखना और उन्हें explain करना, यह कैसे लोग सोचते और सीखते हैं इसके सबसे established results में से एक है। इसे AI output पर use करना natural next step है।
Go deeper: Part 0 Chapter 1: Asking Better Questions. Full version (एक real AI conversation के against एक 10-row receipt, plus Contradiction Challenge जहाँ एक अलग AI आपके reasoning पर attack करता है, 45-60 min) वहाँ foundational sequence के हिस्से के रूप में है। यह page discipline सिखाता है। वह chapter इसे एक habit बनाता है जिसे आप हर high-stakes AI conversation पर run कर सकते हैं।
Part 2: Detection (AI जो miss करता है उसे पकड़ना)
Part 1 ने आपको AI use करने से पहले सोचना सिखाया। Part 2 आपको सिखाता है कि AI जो वापस देता है उसमें mistakes कैसे spot करें।
Problem यह है: AI सही हो या गलत, एक जैसा confident लगता है। उसकी सबसे बुरी mistakes अक्सर उन्हीं sentences में छिपती हैं जो सबसे polished लगते हैं। AI यह भी करता है कि आपने जो एक चीज़ पूछी उसी पर focus करता है और side effects ignore कर देता है।
Discipline 3 (Error Taxonomy) आपको 6 common AI mistakes की एक checklist देती है ताकि आप output पर trust करने से पहले उन्हें scan कर सकें। Discipline 4 (Thinking in Systems) आपको पूछना सिखाती है "अगर मैं यह करूँ, तो और क्या बदलता है?" ताकि आप वे side effects पकड़ें जिन्हें AI ने miss किया।
Discipline 3: Error Taxonomy
यह discipline What AI Actually Is, Idea 3 का practical answer है: machine के अंदर कोई built-in truth-checker नहीं, इसलिए checker आप हैं। नीचे के 6 error types दिखाते हैं कि practice में 'checker होना' कैसा दिखता है।
आपने शायद यह अनुभव किया है। आप AI से एक question पूछते हैं, answer smooth और professional लगता हुआ आता है, आप उसे पढ़ते हैं, सब ठीक लगता है, आप उसे use कर लेते हैं। 3 days बाद आपको पता चलता है कि एक number गलत था, या AI ने जो एक source mention किया वह असल में exist ही नहीं करता। Mistake वहीं बैठी थी, पर आपने उसे miss कर दिया क्योंकि writing इतनी अच्छी लग रही थी।
अब जो part matter करता है: उस missed mistake की क़ीमत आम तौर पर आप चुकाते हैं, कोई बाद में पकड़ने वाला auditor नहीं। अगर AI ने आपको बताया कि एक used car में 32,000 miles हैं जबकि असल में 58,000 थे, तो आप किसी meeting में embarrass नहीं होते: आप गलत car खरीद लेते हैं। अगर AI ने आपकी report के लिए एक statistic बना दी, तो आप सिर्फ तब बुरे नहीं दिखते जब कोई check करे; आपने एक ऐसे number पर decision ले लिया जो कभी real था ही नहीं। AI की mistakes सबसे पहले उसी इंसान को hurt करती हैं जो उन पर act करता है। वह इंसान आप हैं।
"Taxonomy" क्यों? एक taxonomy बस एक naming system है: labeled categories का एक fixed set जिनमें आप चीज़ें sort करते हैं, ठीक वैसे जैसे biologists living things को species में sort करते हैं। ताक़त naming में है। "Check करो कि यह कोई अच्छी है क्या" act करने के लिए बहुत vague है; आपकी आँखें page पर फिसल जाती हैं और कुछ उन्हें रोकता नहीं। पर "check करो कि कोई fabricated source है क्या" एक specific target के साथ एक specific hunt है, तो आप सच में हर citation पर रुककर देखते हैं। Error Taxonomy, AI mistake की 6 named categories हैं। उन्हें name देना ही एक vague worry ("शायद कुछ गलत है") को 6 concrete searches में बदल देता है जिन्हें आप सच में run कर सकते हैं।
इन्हें ऐसे पकड़ें। AI के output को पढ़कर खुद से "क्या यह सही लगता है?" पूछने के बजाय, उसमें एक बार में एक specific type की mistake खोजते हुए जाएँ। 6 types हैं:
| Mistake type | यह कैसी दिखती है | पहले कहाँ देखें |
|---|---|---|
| Factual error | एक गलत fact: गलत number, गलत date, गलत name। | Specific number वाली कोई भी sentence। Exact दिखने वाले numbers चीज़ों को researched feel कराते हैं। Example: "73.6% लोग AI के numbers check नहीं करते।" यह real लगता है। मैंने इसे अभी बना दिया। |
| Logical gap | Conclusion evidence से सच में follow नहीं करता। | "therefore" या "so" जैसे शब्द खोजें। फिर पूछें: क्या evidence सच में यह prove करता है, या एक step missing है? |
| False confidence | AI किसी uncertain चीज़ को ऐसे कहता है जैसे वह एक fact हो। | सबसे smooth लगने वाले paragraphs। अगर AI "may" या "could" use करता है, तो वह जानता है कि unsure है। अगर AI किसी debatable चीज़ को बिना "may" या "could" के कहता है, वही warning sign है। |
| Missing context | AI ने कोई important detail छोड़ दी जो answer बदल देती। | सोचें कि एक expert सबसे पहले क्या पूछेगा। अगर आप पूछेंगे "पर X का क्या?", तो AI ने शायद उसके बारे में सोचा ही नहीं। |
| Fabricated source | AI किसी book, article, study, या tool का ज़िक्र करता है जो असल में exist ही नहीं करता। | AI जो भी source name करे, हर एक check करें। Title को Google करें। अगर नहीं मिलता, तो AI ने शायद उसे बना दिया। |
| Stale fact | कुछ जो पहले true था पर अब true नहीं। | जो भी समय के साथ बदलता है: prices, rules, laws, software versions, कोई company कौन चलाता है। |
एक scan कैसा feel होता है। बस पहला type लें, Factual error। Instruction कहती है: specific number वाली कोई भी sentence देखें। तो आप AI का output पढ़ते हैं और हर number पर रुकते हैं, बाकी सब ignore करते हुए। मान लें AI ने लिखा "this car has 32,000 miles on the odometer." यह एक number है, तो आप रुकते हैं। आप "क्या यह सही लगता है?" नहीं पूछते: एक गलत mileage बिल्कुल उतना ही reasonable लगता है जितना एक सही। बजाय इसके आप उसे source के against check करते हैं: आप dashboard की photo देखते हैं। उस पर 58,000 लिखा है। पकड़ा गया। आपने इसे ध्यान से पढ़कर नहीं पकड़ा; आपने इसलिए पकड़ा क्योंकि आप specifically एक type की mistake खोज रहे थे, यानी एक गलत number, और एक number ही वह जगह थी जहाँ आप रुके।
यही पूरी technique है, 6 बार दोहराई गई। हर pass एक type खोजता है। आप output को 6 बार नहीं पढ़ रहे; आप उसे एक बार पढ़ रहे हैं पर 6 अलग questions दिमाग में रखकर, हर question जिस जगह point करता है वहाँ रुकते हुए। नीचे की exercise में आप 2 passes practice करेंगे (Factual error और Fabricated source) ताकि rhythm सीख सकें। अगला worked example छहों दिखाता है।
6 error types खुद announce नहीं करते। वे उन paragraphs में छिपते हैं जो सबसे professional पढ़ते हैं, और इसीलिए name से scan करना feel से पढ़ने को beat करता है।
छहों real life में कैसे दिखते हैं।
एक parent एक reliable used car ढूँढ रहे थे। उन्हें एक listing पसंद आई: एक 2021 Honda CR-V। उसे देखने के लिए 1 hour drive करने से पहले, उन्होंने Claude से उसे review करने को कहा। उन्होंने listing, photos और अपने mechanic का एक note paste किया। Claude ने एक clean, confident summary लिखी: low miles, clean history, strong engine, grab करने लायक एक rebate। यह अच्छा पढ़ा। वे लगभग इसे partner को "let's buy this one" के साथ forward कर देते। Instead, उन्होंने six-row scan run किया।
| Error type | Write-up में उन्हें क्या मिला | Verdict |
|---|---|---|
| Factual error | Write-up ने कहा: "32,000 miles on the odometer." Dashboard की listing photo साफ़ 58,000 दिखाती थी। 26,000 miles off। | Caught. Photo से correct किया। |
| Logical gap | Write-up ने कहा: "It has a clean accident history, therefore it has no mechanical problems." एक clean accident record, engine के बारे में कुछ नहीं कहता। "therefore" hold नहीं करता था। | Caught. एक clean history एक clean engine नहीं है। |
| False confidence | Write-up ने कहा: "You will get at least 200,000 trouble-free miles out of this engine." No "should," no "likely," no basis। Flat promise ही सारा काम कर रहा था। | Caught. Rewrite किया: "many CR-Vs last a long time, if serviced." |
| Missing context | Write-up ने timing belt mention नहीं किया, जो करीब 60,000 miles पर replacement के लिए due होती है। Parent के mechanic ने इसे flag किया था। Model ने वह note कभी नहीं देखा। | Caught. Belt को check करने की first चीज़ बनाया। |
| Fabricated source | Write-up ने कहा: "As Consumer Reports wrote in their March 2026 reliability issue, this is the most dependable small SUV on the market." Parent ने Consumer Reports check किया। ऐसा कोई note नहीं था। | Caught. Quote remove किया। |
| Stale fact | Write-up ने कहा: "It still qualifies for the dealer's $1,000 loyalty rebate." Parent ने dealer को call किया। वह rebate last month end हो चुका था। | Caught. Rebate को math से drop किया। |
एक short summary में 6 में से 5 mistake types दिखे। सबसे मुश्किल पकड़ fake Consumer Reports quote थी, क्योंकि वह बिल्कुल वैसी लगती थी जैसा कुछ एक real magazine लिखता। क्योंकि parent ने हर mistake type को name से check किया, वे car देखने गए तो real mileage, ज़रूरी repair, और actual price जानते थे। Notice करें यह किसे protect करता है: parent की किसी auditor के सामने reputation नहीं, बल्कि parent का अपना wallet। अगर उन्होंने summary पर trust किया होता, तो वे 1 hour drive करके ऐसी car खरीदते जो उन्हें 32,000 miles की लगती, एक ऐसी price देते जो एक ऐसे rebate को मानकर चलती जो अब था ही नहीं, और एक ऐसी repair skip कर देते जो आने वाली थी और जिसका उन्हें पता नहीं था। Scan ने उन्हें बुरा दिखने से नहीं बचाया। उसने उन्हें अपने ही decision के बारे में गलत होने से बचाया।
अगर आप type से check किए बिना बस पढ़ते हैं तो क्या होता है:
| आप कैसे पढ़ते हैं | क्या miss होता है | क्यों |
|---|---|---|
| आप पूरी चीज़ "क्या यह अच्छा लगता है?" पूछते हुए पढ़ते हैं | गलत numbers। जब सब कुछ smooth लगता है तो आपकी आँखें numbers से आगे फिसल जाती हैं। | गलत mileage (32,000 के बजाय 58,000) miss करना आसान है। "Factual Error" के लिए check करना आपको हर number पर रुकने पर force करता है। |
| आप एक quote पर trust करते हैं क्योंकि वह एक जानी brand name करता है | Fake Consumer Reports quote। Magazine name real, पर quote बना हुआ था। | यह real लगता है, और वही trap है। "Fabricated Source" के लिए check करना आपको हर quote look up करने पर force करता है। |
| आप "therefore" को बस एक connecting word की तरह पढ़ते हैं | Logical gap। "Clean history, therefore no problems" सही लगता है पर एक step skip करता है। | जब आप "Logical Gap" के लिए check करते हैं, तो आप हर "therefore" पर रुकते हैं और पूछते हैं: क्या यह सच में वह prove करता है जो claim करता है? |
| आप missing info तभी notice करते हैं जब कुछ off लगे | 60,000 miles पर due timing belt replacement। AI ने उसे कभी mention नहीं किया, तो page पर कोई warning नहीं। | Missing information कभी खुद jump out नहीं करता। आपको खुद से पूछना पड़ता है: cars के बारे में जानने वाला कोई क्या पूछता जो AI ने नहीं पूछा? |
जिस parent ने type से check किया और जिसने बस casually पढ़ा, वे एक ही person हो सकते हैं। फ़र्क सिर्फ इतना है कि उन्होंने AI का output कैसे पढ़ा: एक ने हर mistake type को name से check किया, दूसरे ने बस पढ़ा और उम्मीद की कि कुछ गलत नहीं है।
भरी हुई scan grid भी सिर्फ चलाने लायक नहीं, रखने लायक भी है। यह उसी तरह का evidence है जिसके बारे में page का rule है: deliverable सोच का documented evidence है। जब आप किसी को एक report देते हैं और वे पूछते हैं "क्या आपने AI के numbers check किए?", तो grid आपका answer है। ज़्यादातर बार, यह future आप के लिए एक note है: 6 months बाद, जब आप सोचते हैं कि आपने वह statistic verify की थी या बस trust कर लिया था, grid बताती है कि कौन सा।
खुद try करें
आप इस weekend एक used car खरीद रहे हैं। Seller कहता है कि एक और buyer पहले से interested है, तो आपको जल्दी decide करना है। आपने AI से 2 cars compare करके बताने को कहा कि कौन सी खरीदें। AI ने यह वापस लिखा। इसे पढ़ें, फिर इसे ऊपर listed 6 mistake types में से हर एक के लिए check करें। Factual Error और Fabricated Source से start करें (ये दोनों miss करने पर आपको सबसे ज़्यादा पैसे की क़ीमत देते हैं)। नीचे के boxes fill करें।
Which car should you buy?
Go with the 2020 Toyota Corolla. The Corolla gets 47 mpg combined, so you will spend far less at the pump than with most cars its size. According to the CarReliability Index 2026 rankings, the Corolla scores 9.4 out of 10, the top spot in its class. The 2019 Honda Civic is also a fine car. The Civic has lower mileage, therefore it is the more reliable choice if you want fewer surprises down the road.
Either car will run for another decade without a major repair, so you can pick on price and color and feel good about it. Both still qualify for the $2,000 state clean-vehicle rebate, which brings your real cost down nicely. Either way, you are getting a dependable car.
(अगर आप चाहें, तो car example छोड़कर बजाय अपनी life का कोई भी real AI output use कर सकते हैं: एक homework answer, एक college application draft, एक research summary। 6 mistake types किसी भी topic पर काम करते हैं।)
AI grader 2 चीज़ें check करेगा:
- क्या आपने सच में हर type check किया, या बस पढ़कर guess किया? 1-10 rate करें। एक अच्छे answer में हर row के लिए कुछ लिखा होता है। अगर आपने एक type check किया और कुछ गलत नहीं मिला, तो खाली छोड़ने के बजाय "checked, nothing found" लिखें।
- क्या आपने important mistakes पकड़ीं, या सिर्फ आसान वाली? 1-10 rate करें। अगर मैंने उसी write-up में कोई बड़ी mistake miss की, तो मुझे बताएँ कि कौन सी sentence मुझे पकड़नी चाहिए थी।
मेरे काम को rewrite न करें। अगर एक row बिना explanation के blank है, तो बस साफ़ कहें।
6 mistake types में से हर एक के लिए, AI के write-up से वह exact sentence copy करें जिसमें mistake है, और explain करें कि क्या गलत है। अगर आपने एक type check किया और कोई mistake नहीं मिली, तो "checked, nothing found" लिखें।
आप हर एक के बारे में कितने sure हैं? (1-10 rate करें और एक sentence में why कहें।)
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार इसमें लगभग 8-15 minutes लगते हैं। Practice के साथ यह faster हो जाता है। Score मिलने के बाद, एक जगह खोजें जहाँ AI grader आपसे disagree करता है। वह disagreement ही वह जगह है जहाँ आप सबसे ज़्यादा सीखते हैं।
जो आपने अभी किया, वह AI के answer के अंदर की mistakes ढूँढने में help करता है। पर एक और तरह की problem है जिसे यह नहीं पकड़ता: AI की advice पर act करने के बाद क्या होता है? अगर आप गलत car खरीदते हैं, तो आप repairs पर पैसे गँवाते हैं। अगर एक company बुरी AI advice follow करती है, तो customers चले जाते हैं। एक decision दूसरी problem पैदा करता है, जो एक और पैदा करती है। Discipline 4 आपको वे chain reactions होने से पहले trace करना सिखाती है।
तुलना के लिए एक strong sample चाहिए? (अपना submit करने के बाद खोलें।)
एक और reader ने यही used-car exercise किया। यह अकेला सही answer नहीं है, पर दिखाता है कि एक अच्छा कैसा दिखता है।
| Mistake type | AI के write-up से sentence | क्या गलत है |
|---|---|---|
| Factual error | "The Corolla gets 47 mpg combined." | गलत number। Real rating लगभग 33 mpg है। यह बदलता है कि आप gas पर कितना खर्च करते। |
| Logical gap | "The Civic has lower mileage, therefore it is the more reliable choice." | Lower mileage help करती है, पर यह prove नहीं करती कि एक car reliable है। "therefore" शब्द इसे prove किया हुआ दिखाता है जबकि वह नहीं है। |
| False confidence | "Either car will run for another decade without a major repair." | एक used car के बारे में कोई यह promise नहीं कर सकता। AI ने इसे बिना "probably" या "likely" के एक fact की तरह कहा। यह एक fact होने का दिखावा करता एक guess है। |
| Missing context | (Write-up में नहीं।) 2019 Civic पर एक open airbag safety recall है। | AI ने इसे कभी mention नहीं किया। एक safety recall बिल्कुल वैसी चीज़ है जो खरीदने से पहले आपको जाननी चाहिए, और AI उसे छोड़ गया। |
| Fabricated source | "According to the CarReliability Index 2026 rankings, the Corolla scores 9.4 out of 10." | यह index exist नहीं करता। AI ने एक ऐसा source बना दिया जो real लगता है। अगर आप "CarReliability Index" search करें, आपको कुछ नहीं मिलेगा। |
| Stale fact | "Both still qualify for the $2,000 state clean-vehicle rebate." | वह rebate 2025 में end हो गया। यह पहले true था पर अब नहीं। यह वह price बदलता है जो आप असल में चुकाते हैं। |
यह अच्छा क्यों है: हर row का एक answer है, और हर quoted sentence वह है जो सच में बदलेगा कि आप कौन सी car खरीदते हैं। Missing Context row एक specific safety recall name करती है। Fabricated Source row एक ऐसे index की ओर point करती है जो exist नहीं करता।
यह क्या करने की कोशिश नहीं करता: सब कुछ पकड़ना। आप एक full report नहीं लिख रहे। 15 minutes में 6 rows goal है। 3 real catches, 30 weak catches से बेहतर हैं।
यह काम क्यों करता है (इसके पीछे की research)
Error Taxonomy इसलिए काम करता है क्योंकि human judgment smooth writing को handle करने में एक quirk रखता है। जब text पढ़ने में आसान होता है, हम उस पर ज़्यादा trust करते हैं, चाहे वह true हो या नहीं। AI बहुत smoothly लिखता है, जो उसे उस bias के लिए एक near-perfect trigger बनाता है। 4 findings बताती हैं कि named type से scan करना feel से पढ़ने को क्यों beat करता है।
Processing fluency (Adam Alter & Daniel Oppenheimer, 2009). Decades के experiments review करते हुए, Alter और Oppenheimer ने दिखाया कि किसी चीज़ को process करने की ease, यानी clear type, simple words, smooth phrasing, brain द्वारा एक signal की तरह गलत पढ़ी जाती है कि content true है। "यह अच्छा पढ़ता है" का feeling "यह correct है" के judgment में रिसता है, जबकि दोनों का एक-दूसरे से कोई लेना-देना नहीं। AI output को maximally fluent होने के लिए engineer किया गया है, तो यह इस lever को ज़ोर से खींचता है। एक specific error type के लिए scan करना spell तोड़ देता है: आप यह evaluate करना बंद कर देते हैं कि text कैसा feel होता है और यह check करना शुरू करते हैं कि एक particular तरह की claim hold करती है या नहीं।
Paper पढ़ें (open access): Uniting the Tribes of Fluency to Form a Metacognitive Nation, Personality and Social Psychology Review, 13(3), 2009।
Cognitive ease (Daniel Kahneman, 2011). Kahneman का framework इस mechanism को एक name देता है: जब information effortlessly आती है, तो mind का fast, automatic part (System 1) उसे accept कर लेता है और slow, checking part (System 2) कभी जागता ही नहीं। Smooth AI prose System 2 को सोया हुआ रखता है। Six-type scan System 2 को वापस on करने का एक deliberate तरीका है: हर named check एक ऐसा task है जो automatic mind autopilot पर नहीं कर सकता, जो उस effortful look को force करता है जिससे fluent text आपको दूर lull कर रहा था।
और पढ़ें: Thinking, Fast and Slow (Wikipedia); relevant material cognitive ease पर chapter है।
Confidence accuracy नहीं है (Nate Silver, 2012). politics, finance, और sports में forecasters को study करते हुए, Silver ने एक consistent gap document किया: जो लोग सबसे ज़्यादा certain लगते हैं, वे अक्सर सबसे कम accurate होते हैं, क्योंकि confidence और calibration अलग skills हैं। AI इसका सबसे बुरा हिस्सा inherit करता है: यह लगभग हर चीज़ को same assured tone में कहता है, चाहे वह सही हो या invent कर रहा हो। Scan में "False confidence" row exactly इसलिए है कि tone को truth से अलग किया जा सके: आप उस flat, unhedged claim को एक warning sign के रूप में flag करते हैं, बजाय उसकी certainty को evidence की तरह पढ़ने के।
और पढ़ें: The Signal and the Noise (Wikipedia)।
एक overall judgment के बजाय 6 अलग checks क्यों। Gerd Gigerenzer का risk पर काम दिखाता है कि एक problem कैसे represent की जाती है यह तय करता है कि लोग उसके बारे में अच्छी तरह reason करते हैं या नहीं: एक murky judgment को clear, concrete pieces में तोड़ें और accuracy jump करती है, जबकि underlying facts नहीं बदले। "क्या यह AI output कोई अच्छा है?" बिल्कुल उसी तरह का murky, all-at-once judgment है जिसमें लोग बुरे हैं। Scan इसे 6 concrete questions में decompose कर देता है जिन्हें आप एक बार में एक answer कर सकते हैं, और इसीलिए यह वे mistakes पकड़ता है जिनसे एक single holistic read आगे निकल जाता है।
और पढ़ें: Gerd Gigerenzer (Wikipedia), जो Calculated Risks (2002) के argument का summary देता है।
Error Taxonomy चारों को combine करता है। Fluent text true feel होता है (Alter & Oppenheimer) और checking mind को सोया रखता है (Kahneman), AI की uniform confidence छिपाती है कि कौन सी claims असल में shaky हैं (Silver), और एक vague "क्या यह सही लगता है?" mistakes पकड़ने के लिए गलत representation है (Gigerenzer)। 6 error types को name देना और हर एक को check करना चारों को एक साथ fix करता है। किसी ने यह exact checklist AI के against specifically test नहीं किया, पर mechanism का हर piece well established है। इसे AI output पर apply करना natural next step है।
Go deeper: Part 0 Chapter 2: Detecting Broken Reasoning. Full version (8 mistake types, एक दूसरे AI के साथ cross-checking, और समय के साथ अपनी accuracy track करना; 60-75 min) इसे एक complete system बना देता है।
Six-type scan तब best काम करता है जब आप topic जानते हैं। पर उन topics का क्या जिनमें आप नए हैं? 3 tricks help करती हैं:
- AI से exact source माँगें। "studies show" accept न करें। पूछें: "मुझे author name, title, year, और यह कहाँ publish हुआ बताओ।" अगर AI आपको एक real source नहीं दे सकता, तो उस claim पर trust न करें।
- बिना source वाले exact-दिखने वाले numbers से suspicious रहें। "Sales 47.3% बढ़ी" बहुत precise लगता है। पर अगर AI यह नहीं बताता कि वह number कहाँ से आया, तो precision एक warning sign है, proof नहीं।
- जब आप sure न हों, उसे MODIFY label करें। अगर आप एक claim 2 minutes में check नहीं कर सकते, उसे ACCEPT न करें। MODIFY लिखें और "not yet checked" add करें। आप उसे use करने से पहले बाद में look up कर सकते हैं।
Discipline 4: Thinking in Systems
एक university ने कुछ in-person tutoring को एक AI chatbot से replace करके पैसे बचाने का decide किया। उन्होंने AI से पूछा, और AI ने कहा: "This saves 30% on tutoring costs." यह great लगा, तो वे आगे बढ़ गए।
6 months बाद: जो students सबसे ज़्यादा struggle करते थे, उन्होंने help के लिए आना बंद कर दिया, क्योंकि chatbot उनके questions समझ नहीं पाता था। उनके grades गिर गए। Parents ने complain किया। University को damage fix करने के लिए और tutors hire करने पड़े, और आख़िर में यह original budget से ज़्यादा खर्चीला निकला। Answer "saves 30%" कागज़ पर correct था। पर chain reaction ने savings को मिटा दिया।
यह Discipline 4 की failure mode है। जब आप AI से किसी decision के बारे में पूछते हैं, तो वह आपकी पूछी हुई question का answer देता है, यानी "यह कितना बचाएगा?", और वहीं रुक जाता है। यह लगभग कभी chain reactions trace नहीं करता: Effect A, Effect B पैदा करता है, जो Effect C पैदा करता है, और कभी-कभी Effect C वापस आकर आपके original decision को undo कर देता है। एक Cascade Map वह तरीका है जिससे आप उन chain reactions को खुद trace करते हैं, commit करने से पहले, ताकि surprise एक ऐसे budget के 6 महीने अंदर के बजाय कागज़ पर हो जिसे आप वापस नहीं ले सकते।
Notice करें यह किसे protect करता है: एक auditor के सामने आपकी reputation नहीं, बल्कि आपका अपना decision। एक बुरे chatbot rollout के लिए university का किसी ने audit नहीं किया। University ने बस पैसा खर्च किया, consequences के साथ जिया, और उसे fix करने में और पैसा खर्च किया। Cascade map कोई defense नहीं जो आप बाद में दिखाते हैं: यह वह thinking है जो आपको पहली जगह में expensive move करने से रोकती है।
"thinking in systems" क्यों? एक system parts का कोई भी ऐसा set है जो एक-दूसरे को affect करते हैं: students, tutors, budgets, और grades अलग facts नहीं हैं, वे एक-दूसरे पर push करते हैं। हम में से ज़्यादातर सीधी lines में reason करते हैं: यह वह पैदा करता है, end of story। पर एक system के parts loops में connected होते हैं, तो एक effect घूमकर वापस आ सकता है और उस चीज़ को बदल सकता है जिसने उसे शुरू किया। "Thinking in systems" का बस मतलब है पहले effect पर रुकने से इनकार करना: आप पूछते रहते हैं "और फिर क्या?" जब तक आप वह जगह न पा लें जहाँ line मुड़कर एक circle बन जाती है। Cascade Map उस habit का कागज़ी version है: यह parts बिछाता है, उनके बीच lines trace करता है, और वह जगह खोजता है जहाँ एक line loop करके वापस आती है।
एक कैसे बनाएँ। पहली बार इसमें लगभग 20 minutes लगते हैं, और एक बार आदत हो जाने पर 10 minutes।
- अपना decision एक clear sentence में लिखें। Specific रहें। "शायद tutoring बदलें" नहीं बल्कि "next semester से in-person tutoring hours का आधा एक AI chatbot से replace करें"।
- 5 groups of people list करें जिन्हें यह decision affect करता है। हर बड़ा decision अलग-अलग लोगों को छूता है। एक अच्छी starting list: काम करने वाले लोग (e.g., tutors), service use करने वाले लोग (e.g., students), जो आपसे compete करते हैं (e.g., other universities), जो rules apply होते हैं (e.g., university policies), और जो आपकी team जानती या नहीं जानती (e.g., chatbot असल में कितना अच्छा है?)।
- हर group के लिए "और फिर क्या?" 3 बार पूछें। पहली चीज़ से शुरू करें जो होती है। फिर पूछें कि वह किस ओर ले जाती है। फिर पूछें कि उसके बाद क्या आता है। 3 layers deep।
- कम से कम एक loop खोजें। एक ऐसी जगह खोजें जहाँ एक बाद का effect घूमकर वापस आता है और आपके original decision को worse (या better) बनाता है। Specific रहें कि यह कैसे होता है।
- अगर आपका map clean और simple दिखता है, तो आप बहुत जल्दी रुक गए। Real risks second और third layers में छिपते हैं। तब तक deeper push करें जब तक यह messy न दिखे।
एक chain बनाना कैसा feel होता है। Tutoring decision लें और बस "students who struggle most" group। पहली चीज़ से शुरू करें जो होती है, फिर "और फिर क्या?" 2 बार और पूछें।
- First layer: Struggling students chatbot try करते हैं। यह उनके half-formed questions नहीं समझ पाता, तो वे हार मान लेते हैं और help माँगना बंद कर देते हैं।
- और फिर क्या? (Second layer।) Help के बिना, उनके grades गिर जाते हैं। ये वही students हैं जिन्हें support की सबसे ज़्यादा ज़रूरत थी, और उन्हें सबसे कम मिला।
- और फिर क्या? (Third layer।) उनमें से कुछ एक ऐसी university में transfer हो जाते हैं जिसके पास अभी भी human tutors हैं। University उनकी tuition खो देती है।
वह आख़िरी link वह जगह है जहाँ surprise रहती है। Decision था "tutoring पर 30% बचाएँ"। पर 3 layers नीचे, यह बदलकर "उन students से tuition revenue खोना जिन्हें हमारी सबसे ज़्यादा ज़रूरत थी" बन जाता है। आप यह AI से "यह कितना बचाएगा?" पूछकर कभी नहीं देखते, आप इसे सिर्फ "और फिर क्या?" लगातार 3 बार पूछकर देखते हैं।
अब loop खोजें: खोई हुई tuition का मतलब एक और tighter budget, जिसका मतलब tutoring के लिए और भी कम पैसा, जिसका मतलब chatbot को और भी ज़्यादा cover करना पड़ता है, जिसका मतलब और भी ज़्यादा struggling students हार मान लेते हैं। Original decision खुद को खिलाता है। यही loop है, और यही वह चीज़ है जो एक one-time 30% saving को एक ongoing decline में बदल देती है।
इस drawing को एक Cascade Map कहते हैं। Goal future को perfectly predict करना नहीं है। Goal commit करने से पहले loops खोजना है, जब decision बदलना अभी भी free है।
अगर आपका map neat और tidy दिखता है, तो आपने शायद सिर्फ obvious effects लिखे। Real risks deeper layers में हैं। चलते रहें।
यहाँ आपके और AI के opposite blind spots हैं, और इसीलिए यह discipline एक partnership है। AI आपकी पूछी हुई specific question का answer देने में अच्छा है और आपके decision से पैदा होने वाले side effects notice करने में बुरा। आप उन लोगों के बारे में सोचने में बेहतर हैं जिन्हें AI भूल गया और उन chain reactions के बारे में जो महीनों में unfold होती हैं। तो आप map पहले draw करते हैं, यानी वह part जो सिर्फ आप कर सकते हैं, और फिर आप AI से आपकी draw की हुई हर branch को stress-test करने में help माँग सकते हैं।
एक real decision के लिए, map में 20-30 minutes लग सकते हैं। नीचे की exercise एक shorter example use करती है ताकि आप technique practice कर सकें।
Map दिखाता है कि कहाँ देखें; loop दिखाता है कि decision को क्या undermine करता है। Mess एक feature है, bug नहीं।
Diagram को 2 passes में पढ़ें। Top half breadth pass है: बीच में एक decision ("replace loan officers with AI"), उसके चारों ओर 5 domains, और हर एक के साथ पहली चीज़ जो होती है। इनमें से ज़्यादातर वे effects हैं जो कोई भी list करेगा: employees की jobs जाती हैं, customers को worse service मिलती है, competitors आपको copy करने का pressure महसूस करते हैं। जिसे miss करना आसान है वह है Internal knowledge: tacit local lore lost। Loan officers ऐसा knowledge carry करते हैं जो कभी किसी system में लिखा ही नहीं गया: कौन से local businesses thin credit file के बावजूद reliable हैं, किसकी income seasonal है तो March में एक late payment normal है, कब एक applicant straight नहीं है। Officers को replace करें और वह knowledge दरवाज़े से बाहर चला जाता है, क्योंकि वह कभी उस software में था ही नहीं जिससे AI ने सीखा।
Bottom half depth pass है, और यही वजह है कि decision backfire करता है। Customers domain को आगे follow करें: cost cut officers को हटाता है, तो service गिरती है (AI वे cues miss करता है जो humans पकड़ा करते थे, यानी बिल्कुल वही lore जो खो गया), तो customers चले जाते हैं, तो revenue जो बचा था उससे नीचे गिरती है, तो savings मिट जाती हैं। Dashed arrow ही पूरा point है: chain start पर वापस loop करती है, यानी cost-cutting move अपनी ही justification मिटा देता है। वही circling-back वह चीज़ है जिसे ढूँढने के लिए आप एक cascade map बनाते हैं, और यह invisible है अगर आप सिर्फ AI से "यह कितना बचाएगा?" पूछते हैं।
यहाँ एक अलग decision पर वही discipline है।
एक student council president अपने annual sports day को एक rented stadium से university के अपने ground पर move करके पैसे बचाना चाहती थी। AI ने कहा: "This saves 40% of the event budget." Benefits obvious थे: कोई rental fee नहीं, campus के पास, set up करना आसान। AI ने सारे positives list किए और आगे बढ़ने की recommend किया।
Idea present करने से पहले, उसने एक cascade map draw किया। उसका decision: sports day को rented stadium से university ground पर move करें ताकि budget का 40% बचे। उसने 5 groups list किए और हर एक के लिए 3 layers trace किए। Obvious effects expected थे (पैसे बचते हैं, students के लिए कम travel, छोटा venue)। पर third layer ने एक problem reveal की जिसके बारे में उसने सोचा नहीं था: university ground बहुत कम spectators रखता है, तो कम families attend करेंगी, तो event छोटा महसूस होगा, तो जो sponsors visibility के लिए pay करते थे वे next year कम pay करेंगे, तो budget सिकुड़ेगा, तो event को फिर छोटा होना पड़ेगा। एक loop, जहाँ cost-saving move चुपचाप event को साल दर साल सिकोड़ती है।
ऊपर की image उसका पूरा cascade map दिखाती है: हर group (students, sports teams, food vendors, admin, sponsors) के साथ क्या होता है, वह loop जो event को साल दर साल सिकोड़ देता, और वे protections जो उसने इसे रोकने के लिए add कीं: एक guaranteed minimum sponsor package और commit करने से पहले एक spectator-capacity check। AI के original answer ("बस इसे move करो, आप पैसे बचाते हैं") में इनमें से कोई protection नहीं थी। उसने फिर भी पैसे बचाए, पर उसने उन्हें loop trigger किए बिना बचाया।
जो cascade map उसने draw किया वह खुद documented evidence of thinking का एक piece है, यानी वही चीज़ जिसके बारे में इस page के top का rule है। जब उसने council को present किया और किसी ने पूछा "क्या इससे event नहीं सिकुड़ेगा?", तो उसे मौके पर सोचना नहीं पड़ा। उसने उस loop की ओर point किया जो वह already map कर चुकी थी और उस protection की जो वह already build कर चुकी थी। Map thinking भी था और उसका evidence भी।
खुद try करें
आपकी exercise: आपकी university ने अभी announce किया कि next semester सारे exams AI proctoring (एक AI exam के दौरान आपके webcam से आपको देखता है) use करेंगे और online-only होंगे। अब कोई in-person exams नहीं।
5 groups के साथ एक cascade map draw करें: students, professors, IT staff, parents, और administration। हर group के लिए 3 layers deep जाएँ। एक loop खोजें जहाँ एक बाद का effect घूमकर वापस आता है और original decision को worse बनाता है।
(या इस week अपनी life के किसी real decision को use करें। वही इसे stick कराता है।)
AI grader 2 चीज़ें check करेगा:
- क्या आपने सभी 5 groups को 3 layers each के साथ cover किया, और क्या आपने explain किया कि हर effect कैसे होता है (सिर्फ name नहीं किया)? 1-10 rate करें। मुझे बताएँ कि कौन सा group सबसे weak है और मैंने क्या miss किया।
- क्या आपका loop cause और effect की एक real chain है, या सिर्फ एक label? 1-10 rate करें। "Students react" एक label है। "Bad internet वाले students exams में fail होते हैं, जो university की pass rate गिराता है, जो administration को policy rethink कराता है" एक real chain है। अगर मेरा सिर्फ एक label है, तो मुझे दिखाएँ कि इसे एक chain में कैसे बदलें।
मेरे map को redraw न करें। अगर एक box empty या vague है, तो बस साफ़ कहें।
आपका cascade map (decision लिखें, फिर हर group को 3 layers of effects के साथ list करें। इसे neat होना ज़रूरी नहीं):
आपका loop (इसे cause और effect की एक chain के रूप में लिखें):
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार इसमें लगभग 15-20 minutes लगते हैं। पहले कुछ "और फिर क्या?" questions awkward लगते हैं। यह normal है। Real insights आम तौर पर third layer पर दिखते हैं, first पर नहीं। Practice के साथ, आप एक full map 8-12 minutes में कर सकते हैं।
Score मिलने के बाद, एक ऐसा group खोजें जिसका AI grader ने ज़िक्र किया पर आप भूल गए। वहीं आपका blind spot है। अगर AI ने एक loop खोजा जो आप miss कर गए, उस पर extra ध्यान दें। Loops सबसे important चीज़ हैं क्योंकि वे आपको दिखाते हैं कि एक decision समय के साथ कब backfire करेगा।
जो आपने अभी किया, वह यह trace करने में help करता है कि एक decision के बाद क्या होता है। पर यह check नहीं करता कि decision पहली जगह में सही information पर based है या नहीं।
एक perfectly mapped plan जो एक गलत assumption पर बना है, फिर भी fail होता है। यह बस बाद में fail होता है, better notes के साथ। वह Discipline 5 का काम है।
एक good example देखना है? (अपना submit करने के बाद खोलें।)
एक और student ने यही AI-proctored exam exercise किया। यह अकेला सही answer नहीं है, पर दिखाता है कि एक अच्छा cascade map कैसा दिखता है।
Decision: Next semester सारे exams AI-proctored और online-only होंगे।
| Group | पहले क्या होता है | वह क्या पैदा करता है | वह फिर क्या पैदा करता है |
|---|---|---|---|
| Students | Slow internet या पुराने laptops वाले students struggle करते हैं | कुछ को AI proctor "cheating" के लिए गलत flag करता है | वे students appeals file करते हैं; exam system में trust गिरता है |
| Professors | Professors exam के दौरान students को नहीं देख सकते | वे नहीं बता पाते कि कोई student confused है या अटका हुआ | Professors exams को shorter और simpler redesign करते हैं, जो standard गिराता है |
| IT staff | IT को proctoring software set up और support करनी पड़ती है | Exam week में students tech problems के साथ लगातार IT को call करते हैं | IT overwhelmed हो जाता है; campus पर सबके लिए response times worse हो जाते हैं |
| Parents | Parents privacy को लेकर worry करते हैं (webcam recording) | कुछ parents complain करने administration से contact करते हैं | University को नई privacy policies लिखनी पड़ती हैं, जिसमें महीनों लगते हैं |
| Administration | Administration exam halls पर पैसे बचाता है | पर वे proctoring software licenses पर पैसे खर्च करते हैं | Cost savings expected से छोटी निकलती हैं |
Loop: Bad internet वाले students cheating के लिए flag होते हैं → वे complaints file करते हैं → administration को हर complaint manually review करने के लिए लोग hire करने पड़ते हैं → यह exam halls book करने से ज़्यादा खर्चीला है → administration in-person exams पर वापस जाने पर विचार करता है → original decision reverse हो जाता है।
यह अच्छा क्यों है: सभी 5 groups 3 layers each के साथ covered हैं। हर effect explain करता है कि यह कैसे होता है, सिर्फ क्या होता है नहीं। Loop एक real chain है: यह एक student problem से शुरू होता है और original decision को undo करके खत्म होता है।
यह क्या करने की कोशिश नहीं करता: हर संभव effect list करना। इस scenario में और भी loops हैं (professors quit करना, students transfer करना)। Point अपनी पहली try में cause और effect की एक clear chain के साथ एक real loop खोजना है, उन सबको खोजना नहीं।
अगर आपका map इससे tidier दिखता है, तो वही signal है: अपने 2 weakest domains में एक और "और फिर क्या?" deeper जाएँ और एक loop के लिए फिर देखें।
यह काम क्यों करता है (इसके पीछे की research)
Cascade Map कोई नया idea नहीं है: यह system dynamics का एक stripped-down version है, एक ऐसा field जिसने सत्तर साल एक stubborn fact document करने में बिताए: लोग सीधी lines में reason करते हैं, पर दुनिया loops पर चलती है। 3 bodies of work बताती हैं कि map draw करना इसे अपने head में सोचने से क्यों beat करता है।
Demand amplification (Jay Forrester, 1958). Forrester, जिन्होंने MIT में system dynamics की नींव रखी, ने दिखाया कि एक chain में एक point पर लिया गया decision बाहर की ओर ripple करता है और distorted वापस आता है। उनका सबसे famous demonstration वह है जिसे अब bullwhip effect कहते हैं: retail end पर customer demand में एक small, steady change upstream factory orders में wild swings पैदा करता है, क्योंकि हर link पूरे loop को देखे बिना अपने बगल वाले link पर react करता है। यह lesson supply chains से कहीं आगे generalize होता है: जब आप straight-line terms में decide करते हैं ("यह 30% बचाता है"), तो आप वह तरीका miss कर देते हैं जिससे effect system से होकर travel करता है और बदला हुआ वापस आता है। Cascade Map वह tool है जो return trip को commit करने से पहले visible बना देता है।
और पढ़ें: Bullwhip effect (Wikipedia), जो idea को Forrester के "Industrial Dynamics: A Major Breakthrough for Decision Makers," Harvard Business Review, 36(4), 1958 तक trace करता है।
Misperception of feedback (John Sterman, the Beer Game). Sterman ने एक अब-classic experiment चलाया, beer distribution game, जिसमें players एक simple supply chain के एक link को manage करते हैं। Smart, motivated participants भी, यानी MBA students, executives, reliably बड़े, costly oscillations पैदा करते हैं, क्योंकि वे जो उनके सामने है उस पर react करते हैं और जो delays और feedback loops वे नहीं देख सकते उन्हें ignore कर देते हैं। Failure effort या intelligence की कमी नहीं है; यह है कि loops invisible रहते हैं जब तक कुछ आपको उन्हें बिछाने पर force न करे। वह "कुछ" exactly वही है जो Cascade Map provide करता है: उस forced drawing का एक five-minute, low-stakes version जो loop को आपको कुछ भी खर्च होने से पहले visible बना देता है।
और पढ़ें: Beer distribution game (Wikipedia)। Full treatment Sterman की Business Dynamics: Systems Thinking and Modeling for a Complex World (McGraw-Hill, 2000) में है।
Leverage points (Donella Meadows, 2008). Meadows, जिन्होंने उसी MIT tradition में काम किया, ने अपना career यह argue करने में बिताया कि एक system को बदलने की सबसे powerful जगहें लगभग कभी obvious वाली नहीं होतीं। सबसे बड़ा leverage आम तौर पर feedback loops में बैठता है, यानी बिल्कुल वे structures जिन्हें straight-line analysis कभी name नहीं करता। उनका blunt corollary: आप एक ऐसे loop को adjust, weaken, या उससे protect नहीं कर सकते जिसे आपने draw ही नहीं किया। Cascade Map का पूरा काम कम से कम एक loop surface करना है, क्योंकि वह loop hidden risk भी है और intervene करने की highest-leverage जगह भी।
और पढ़ें: Meadows का essay Leverage Points: Places to Intervene in a System, जो उनकी book Thinking in Systems (Chelsea Green, 2008) का आधार बना।
Cascade Map तीनों को combine करता है। Decisions एक system से होकर ripple करते हैं और distorted वापस आते हैं (Forrester), लोग reliably उन return trips को miss कर देते हैं जब तक उन्हें draw करने पर force न किया जाए (Sterman), और जो loops वे miss करते हैं वे exactly act करने की highest-leverage जगहें हैं (Meadows)। Map वह forced drawing है जो loop को तब पकड़ता है जब decision बदलना अभी भी free है। किसी ने Cascade Map को AI के against specifically test नहीं किया, पर underlying finding, कि humans feedback loops miss करते हैं और उन्हें externalize करना इसे fix करता है, इस field के सबसे ज़्यादा replicated results में से एक है। AI-era twist बस यह है कि अब आपके पास opposite blind spot वाला एक partner है: AI उस breadth पर strong है जो आप भूल जाते और उन loops पर weak जिन्हें आप sense करने के लिए बने हैं, तो map को साथ draw करना दोनों gaps एक साथ बंद कर देता है।
Go deeper: Part 0 Chapter 3: Thinking in Systems. Full version (peer review plus AI counter-analysis plus assessment rubric; 60 minutes) इसे एक system बना देता है।
Part 3: Origination (वह करना जो AI नहीं कर सकता)
Part 1 ने आपको AI से पूछने से पहले सोचना सिखाया। Part 2 ने AI के answers में mistakes पहचानना सिखाया। Part 3 कुछ अलग है: वह thinking करना जो AI आपके लिए नहीं कर सकता।
यहाँ AI के 2 बड़े blind spots हैं। पहला, वह आपको सबसे common answer देता है, ज़रूरी नहीं कि आपकी situation के लिए best answer दे। अगर 1000 लोगों ने वही question पूछा हो, तो AI उनके लिए काम करने वाली चीज़ का average देता है। लेकिन आपकी situation अलग हो सकती है। दूसरा, जितना ज़्यादा आप AI use करते हैं, उतना आसान होता है खुद सोचना बंद कर देना और उसकी हर बात accept कर लेना।
Disciplines 5 और 6 दोनों problems fix करती हैं।
शुरू करने से पहले एक important phrase सीखें: named threshold। Named threshold एक specific condition है जो बताती है कि कोई advice कब काम करना बंद करती है। Example: "यह advice तब काम करती है जब आपकी class में 30 से कम students हों" एक named threshold है। "यह कभी-कभी काम करती है" named threshold नहीं है, क्योंकि "कभी-कभी" यह नहीं बताता कि कब। आप एक minute में इस phrase का use करेंगे।
Discipline 5: First Principles
आप अपनी university के coding club के president हैं। Campus के हर दूसरे club ने membership fee लेना शुरू कर दिया है। आपके vice president, faculty advisor, और 2 senior members सभी एक ही बात कहते हैं: "हमें भी fee लेनी चाहिए, बाकी सभी ऐसा कर रहे हैं।" आप AI से पूछते हैं। AI भी agree करता है। हर कोई एक ही direction में point कर रहा है।
यही agreement danger है। जब AI समेत सभी एक ही answer के पीछे खड़े हो जाते हैं, तो बात settled लगती है और सोचना बंद करके साथ चलना आसान हो जाता है। लेकिन common answer इस पर बना है कि ज़्यादातर clubs के लिए क्या काम करता है। आपका club exception हो सकता है, और room में कोई check नहीं कर रहा कि ऐसा है या नहीं। यह discipline वही check करने का तरीका है।
Check की एक specific shape है: common advice लें और वह exact condition खोजें जहाँ वह काम करना बंद कर देती है। ज़्यादातर लोग advice पर doubt करते समय एक vague complaint देते हैं: "Fee लेना हमेशा good idea नहीं होता।" यह useless है, क्योंकि "हमेशा नहीं" कभी नहीं बताता कि कब। Skill है उस vague complaint को एक named threshold में बदलना, यानी एक specific, numbered condition जहाँ advice टूटती है।
"First principles" क्यों? First principles से reason करने का मतलब है किसी answer को सिर्फ इसलिए accept न करना क्योंकि हर कोई उसे repeat कर रहा है। इसके बजाय, पता लगाएँ कि आपकी situation में सच क्या है। आम तौर पर लोग इसे scratch से answer build करने की तरह देखते हैं। यह discipline उसका lighter, faster version करती है: advice को फिर से build करने के बजाय उसे test करें। वह exact condition खोजें जहाँ common answer आपके लिए true रहना बंद कर देता है। Root move वही है, यानी consensus को authority मानकर accept न करें, अपने case के against check करें, लेकिन blank page के बजाय boundary पर focus करें।
Move को 1 बार देखें। Same situation, advice पर doubt करने के 2 तरीके:
- Vague complaint: "Fee लेना हमेशा good idea नहीं होता।"
- Named threshold: "जब आपके club का main goal ऐसे first-year students को attract करना हो जिन्होंने पहले कभी code नहीं किया, और उनमें से ज़्यादातर fee afford न कर सकें, तो पैसे माँगना उन्हीं लोगों को डरा देगा जिन तक आप पहुँचना चाहते हैं।"
पहला बस एक shrug है। दूसरा exact बताता है कि advice कब fail होती है (first-years जो fee afford नहीं कर सकते) और क्यों (fee उन लोगों को रोकती है जिन तक club पहुँचना चाहता है)। पहला कुछ नहीं बदलता। दूसरा आपका decision बदलता है। Shrug और named condition के बीच यही gap पूरी discipline है।
इसे practice ऐसे करें। Common advice का कोई एक piece चुनें जिसे आपके आसपास हर कोई, और AI, follow करने को कहता है। फिर 3 rows लिखें। हर row में एक specific situation describe करें जहाँ वह advice काम नहीं करेगी। सिर्फ "कभी-कभी" नहीं, एक real number या real condition use करें।
| Common advice | यह कब काम करना बंद करती है? (एक specific number या condition use करें।) |
|---|---|
अगर आप 3 rows specific conditions के साथ नहीं भर सकते, तो आप advice को सच में समझे बिना follow कर रहे थे।
कैसे बताएँ कि आपकी row अच्छी है: "जब आपके club के 80% से ज़्यादा members first-year हों और उनकी income न हो, तो fee लेने से membership आधी रह जाएगी" useful है। यह exact बताती है कि advice कहाँ टूटती है। "Fee लेना हमेशा काम नहीं करता" decision लेने में help करने के लिए बहुत vague है।
ध्यान दें कि यह किसे protect करता है। Club president से fee लेने के decision का कोई audit नहीं करने वाला था। पूरा room और AI agree कर रहे थे कि वही सही move है। अगर वह consensus follow करती, तो बस एक worse decision लेती, membership गिरती देखती, और कभी नहीं जानती कि named threshold reason था। Threshold बाद में खुद को defend करने के लिए बनाई गई चीज़ नहीं है। वह bad decision को तब पकड़ती है जब आसपास सब अभी भी हाँ में सिर हिला रहे हों।
एक good result ऐसा दिखता है।
ऊपर वाली coding club president ने पहली try में 3 perfect rows नहीं लिखीं। सोचने के बाद, उसके पास यह था:
| Common advice: "हर club को membership fee लेनी चाहिए।" |
|---|
| Boundary 1. जब आपके 80% से ज़्यादा members ऐसे first-year students हों जिनकी कोई income नहीं, तो fee उन्हीं लोगों को डरा देगी जिन तक आप पहुँचना चाहते हैं। Threshold: 80% first-year, no-income members। |
| Boundary 2. जब आपके club की main value free workshops हों जिन्हें कोई भी join कर सके, तो fee एक ऐसी barrier बनाती है जो walk-in attendance खत्म कर देती है। यह तब सबसे ज़्यादा matter करता है जब आपके campus में 3 या ज़्यादा competing clubs अभी भी free हों। Threshold: same campus पर 3+ free competing clubs। |
| Boundary 3. जब आपके club का ज़्यादातर budget university grant से आता हो जिसकी requirement सभी students के लिए open रहना है, तो fee लेने से grant जा सकती है। Threshold: "open access" requirement वाली grant जो आपके आधे से ज़्यादा budget को cover करती हो। |
उसने 3 boundaries अपने faculty advisor के सामने रखीं। उन्होंने club free रखने और sponsored hackathons से पैसे जुटाने का फैसला किया। Semester के end तक membership 40% बढ़ी, जबकि fee शुरू करने वाले दूसरे clubs की attendance घटी। 3 boundaries में से कोई common advice में नहीं थी। AI के first answer में भी कोई नहीं थी।
ये 3 boundaries documented evidence of thinking का भी एक piece हैं, वही चीज़ जिसके बारे में page के top वाला rule है। जब president अपने advisor के साथ बैठी, उसने यह नहीं कहा "मुझे fee के बारे में bad feeling है।" उसने table पर 3 named conditions रखीं। Feeling और 3 named thresholds के बीच का फ़र्क overrule होने और सुने जाने के बीच का फ़र्क है। Rows उसकी thinking भी थीं और इस बात का proof भी कि उसने thinking की थी।
Named thresholds के बिना उसने शायद ऐसा कुछ लिखा होता:
| Common advice: "हर club को fee लेनी चाहिए।" | यह help क्यों नहीं करता |
|---|---|
| कभी-कभी fee लेना good idea नहीं होता। | बहुत vague। "कभी-कभी" नहीं बताता कब। इसका मतलब 5% members छोड़ें या 90%, कुछ भी हो सकता है। इससे decision नहीं होता। |
| दूसरे clubs हमेशा नहीं जानते कि वे क्या कर रहे हैं। | यह दूसरे clubs की complaint है, आपके decision का reason नहीं। इससे कुछ नहीं बदलता। |
| यह situation पर depend करता है। | किस चीज़ पर depend करता है यह बताए बिना "it depends" कहना help नहीं करता। सभी पहले से जानते हैं कि depend करता है। |
खुद try करें
आपकी exercise: कोई common advice चुनें जो लोग आपको बार-बार बताते हैं। Examples: "अपने passion को follow करें," "हमेशा group में study करें," "हर paycheck का 20% save करें," "lectures skip न करें।" 3 rows लिखें। हर row में एक specific situation, number या condition के साथ, name करें जहाँ वह advice काम करना बंद कर देती है।
(आप कोई भी advice चुनें, यह उसी तरह काम करता है।)
शुरू करने से पहले याद रखें: Threshold एक specific number या condition use करती है ("जब आपकी class में 200 से ज़्यादा students हों")। "कभी-कभी," "अक्सर," और "it depends" जैसे words thresholds नहीं हैं।
अगर third row नहीं बन रही, तो इसका मतलब है कि आप advice को सच में समझे बिना follow कर रहे थे। Weak third row force करने के बजाय अलग advice चुनें। यह खुद एक useful discovery है।
AI grader 2 चीज़ें check करेगा:
- क्या हर row में एक specific threshold है (number, condition, clear situation)? 1-10 rate करें। मेरी weakest row quote करें।
- क्या हर row explain करती है कि advice उस situation में क्यों fail होती है, या सिर्फ कहती है "यह काम नहीं करती"? 1-10 rate करें। कोई row vague complaint है, real explanation नहीं, तो point out करें।
मेरी rows rewrite न करें। कोई row empty या vague हो तो बस कहें।
वह common advice जिसे मैं examine कर रहा हूँ:
Row 1: यह advice कब काम करना बंद करती है? (एक specific condition name करें और explain करें कि क्यों।)
Row 2:
Row 3:
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार इसमें लगभग 15-25 minutes लगते हैं। Thresholds लिखना आपकी expectation से hard है। Score मिलने के बाद कोई row खोजें जहाँ आपने "कभी-कभी" या "it depends" लिखा और उसे real number या condition के साथ rewrite करें। अगर rewrite नहीं कर सकते, तो वह row शायद real boundary नहीं है। उसे drop करके अलग one try करें।
आपने अभी यह पता लगाना सीखा कि advice का एक piece कहाँ काम करना बंद करता है। लेकिन यह उन problems पर AI के साथ काम करने में help नहीं करता जहाँ challenge करने के लिए कोई obvious advice नहीं है। Discipline 6 वही करती है।
एक good example देखना है? (अपना submit करने के बाद खोलें।)
एक दूसरी student ने "हमेशा group में study करें" advice चुनी। उसकी 3 rows ये थीं:
| Common advice: "हमेशा group में study करें।" |
|---|
| Row 1. 5 से बड़े groups अच्छे से काम नहीं करते। ज़्यादातर लोग बस बैठकर सुनते हैं जबकि 2-3 लोग real work करते हैं। जब यह टूटती है: 5 से ज़्यादा लोग। |
| Row 2. कुछ subjects में quiet focus चाहिए, जैसे math problems solve करना या essays लिखना। Group में कोई हर कुछ minutes में interrupt करता है। जब यह टूटती है: ऐसे tasks जिनमें 30 minutes से ज़्यादा quiet thinking चाहिए। |
| Row 3. जब 1 person बाकी सब से बहुत ज़्यादा जानता है, तो वह study करने के बजाय पूरा time explain करने में लगाता है। वह अपने work में पीछे रह जाता है। जब यह टूटती है: जब best और weakest student में 2 grade levels से ज़्यादा gap हो। |
यह अच्छा क्यों है: हर row एक specific number use करती है (5 people, 30 minutes, 2 grade levels)। हर row explain करती है कि advice क्यों fail होती है, सिर्फ यह नहीं कि fail होती है।
3 clear rows काफ़ी हैं। हर possible situation list करने की ज़रूरत नहीं।
यह काम क्यों करता है (इसके पीछे की research)
First Principles move, यानी वह exact condition खोजना जहाँ common advice आपके लिए true रहना बंद करती है, 3 पुराने ideas पर बनी है जो बताते हैं कि advice क्यों fail होती है और उसे कैसे test करें।
Ecological rationality (Gerd Gigerenzer, Peter Todd & ABC Research Group, 1999). उनकी core finding एक छोटी equation में आती है: heuristic + environment = outcome। Rule of thumb अपने आप good या bad नहीं होती। वह उन environments में good है जहाँ fit होती है और उन environments में bad जहाँ fit नहीं होती। पूरी skill यह जानना है कि आप किस environment में हैं। "Membership fee लें" ऐसे clubs के लिए tuned heuristic है जिनके members pay कर सकते हैं। उसे no-income first-years वाले club में डालें और वही rule backfire करती है। Named threshold सिर्फ exact बताती है कि environment कहाँ advice के fit होना बंद करता है, और इसी judgment को यह work good और bad decisions के बीच का फ़र्क कहती है।
और पढ़ें: Ecological rationality (Wikipedia), जो Gigerenzer, Todd & ABC Research Group की Simple Heuristics That Make Us Smart (Oxford University Press, 1999) summarize करती है।
Recognition-primed decisions (Gary Klein, 1998). Firefighters, nurses, और pressure में काम करने वाले दूसरे experts को study करके Klein ने पाया कि वे rarely options weigh करते हैं। वे situation को familiar pattern की तरह recognize करते हैं और पहला fit होने वाला pattern run करते हैं, अक्सर यह notice किए बिना कि उन्होंने ऐसा किया। यह fast है और अक्सर right, लेकिन consensus advice भी इसी तरह बिना examine हुए निकल जाती है: वह एक recognized, settled answer जैसी feel होती है। Pattern कब fail होगा यह लिखने के लिए खुद को force करना वह deliberate pause है जो automatic match interrupt करता है। आप pattern-matching को इतना रोकते हैं कि check कर सकें आपका case exception तो नहीं।
और पढ़ें: Recognition-primed decision (Wikipedia); full account Klein की Sources of Power: How People Make Decisions (MIT Press, 1998) में है।
Falsifiability (Karl Popper, 1959). Popper ने argue किया कि कोई claim दुनिया के बारे में तभी कुछ बताती है जब आप बता सकें कि उसे गलत क्या prove करेगा। हर possible outcome में survive करने वाला belief कुछ explain नहीं करता। Named threshold advice पर applied falsifiability test है: "यह तब तक काम करती है जब तक 80% से ज़्यादा members fee afford न कर सकें" वह exact condition name करती है जहाँ आप advice छोड़ देंगे। Vague complaint, "यह हमेशा काम नहीं करती," कोई condition name नहीं करती, कभी check नहीं हो सकती, और इसलिए कुछ नहीं बदलती। Threshold और shrug में यही फ़र्क है।
और पढ़ें: Falsifiability (Wikipedia), वह idea जिसे Popper ने The Logic of Scientific Discovery (1959) में introduce किया।
First Principles तीनों को combine करती है। Advice सिर्फ उस environment के लिए right होती है जहाँ वह fit करती है (Gigerenzer & Todd), consensus बिना check निकला जाता है क्योंकि "settled" answer recognize करना automatic है (Klein), और cure है वह exact condition name करना जो आपके लिए advice को wrong prove करेगी (Popper)। Named threshold तीनों एक साथ करती है: environment state करती है, automatic match interrupt करती है, और check करने लायक specific होती है। इस exact exercise को AI के against किसी ने test नहीं किया, लेकिन underlying ideas decades से hold कर रहे हैं। AI के confident consensus answers को pressure-test करने के लिए उन्हें use करना natural next step है।
Go deeper: Part 0 Chapter 4: Reasoning from First Principles. Full version (Blank Page Sprint: जिस practice को आप follow कर रहे हैं उसके against 500 words लिखें, फिर structured AI counter-analysis और peer review run करें; 60 minutes) Part 0 में है। यह page row shape सिखाता है। वह page longform argument सिखाता है।
Discipline 6: Working WITH AI
आपने सुबह AI के साथ एक important essay पर काम किया। Result शानदार दिखता है। Arguments clear हैं और writing polished है। फिर professor पूछते हैं: "इसके कौन से parts आपके ideas हैं और कौन से AI से आए?" आप बोलने के लिए मुँह खोलते हैं और realize करते हैं कि बता नहीं सकते। कुछ sentences आपके हैं। कुछ AI के। ज़्यादातर mix हैं। Essay अच्छा है। बस आप नहीं जानते कि कौन से parts आप सच में explain और defend कर सकते हैं।
इसे fix करने के लिए same task को 3 अलग तरीकों से करें, फिर results side by side compare करें।
- Solo. 15 minutes, no AI। सिर्फ आप और problem।
- AI-only. 5 minutes। AI से पूछें, पहला answer accept करें, कुछ change न करें।
- Collaborative. 10 minutes। AI से पूछें, critically पढ़ें, जहाँ ज़रूरत हो disagree करें, follow-up questions पूछें, और कुछ parts खुद rewrite करें।
फिर तीनों versions compare करें। खुद से पूछें: कौन सा version best है? "Together" version के कौन से parts इसलिए better हैं क्योंकि आपने किसी चीज़ पर push back किया? "Together" version आम तौर पर जीतता है, लेकिन real lesson यह exact देखना है कि आपकी thinking ने उसे कहाँ better बनाया। यही discipline है।
Comparison ऐसा feel होता है। मान लें आपका task professor को email की closing line लिखना है। तीनों versions साथ रखकर सिर्फ वही 1 line पढ़ें:
- Solo: "Thanks, and sorry again for the trouble." (Apologetic, थोड़ी weak।)
- AI-only: "Thank you for your time and consideration." (Polished, लेकिन यह किसी की भी email हो सकती है।)
- Collaborative: "अगर इससे help हो, तो मेरे पास अभी तक जो है वह मैं आपको दिखा सकता हूँ।" (आपकी, यह prove करती है कि आपने work शुरू कर दिया है।)
इन्हें side by side पढ़ना ही पूरा move है। Solo line दिखाती है कि आप अकेले क्या लिखते। AI-only line दिखाती है कि AI का default क्या है। Collaborative line वह है जिसे आप defend कर सकते हैं, क्योंकि आप जानते हैं कि वह बाकी 2 से क्यों better है: वह ऐसा काम करती है जो बाकी दोनों नहीं करतीं। आपने सिर्फ feel नहीं किया कि collaborative version better है। आप line पर point करके बता सकते हैं कि वह क्या करती है। यही pointing skill है।
Real project में full comparison लगभग 30 minutes लेता है। नीचे की exercise quick 10-minute version है ताकि आज ही difference feel कर सकें।
पूरे task में यह ऐसा दिखता है।
एक student को major assignment की deadline extension माँगने के लिए professor को email लिखनी थी। उसके पास real reason था, family emergency, लेकिन email honest होनी थी और excuse जैसी नहीं लगनी थी। उसने तीनों paths try किए।
Solo, 15 minutes। उसने बिना AI help के email खुद लिखी। वह honest और personal थी। उसने situation clearly explain की। लेकिन वह बहुत लंबी हो गई, और actual request ("क्या मुझे 5 days और मिल सकते हैं?") bottom में दब गई। Email इतनी लंबी थी कि professor शायद end तक न पढ़ते।
AI-only, 5 minutes। उसने AI को situation दी और first draft बिना change accept किया। Email polished और well-structured थी। लेकिन वह generic लगती थी, जैसे कोई भी template भेज सकता था। उसमें उसकी situation की कोई specific details नहीं थीं। वह उसकी आवाज़ नहीं लगती थी। Professor शायद सोचते कि उसने AI email copy कर दी।
Collaborative, 10 minutes। उसने opening खुद लिखी, अपनी specific situation अपने words में explain की, फिर AI से email restructure करने में help माँगी ताकि request first आए। AI ने tone soften करने को कहा। उसने disagree करके direct wording रखी क्योंकि वह जानती थी कि यह professor politeness से ज़्यादा honesty पसंद करते हैं। उसने AI से closing line भी माँगी। AI का version बहुत formal था, इसलिए उसने उसे अपने बोलने के तरीके से match करने के लिए rewrite किया। Final email clear, personal, और well-structured थी। Professor ने 1 hour में reply करके extension दे दी।
Collaborative version 2 specific चीज़ों के कारण जीता जो उसने कीं: उसने अपनी direct wording रखी, जिसे AI soften करना चाहता था, और request को top पर रखा, जो उसे अकेले नहीं सूझता। वह exact point कर सकती है कि उसके judgment ने email कहाँ better बनाई।
Last sentence top वाले rule से connection है। 3 versions side by side documented evidence of thinking हैं। Win यह नहीं कि "email अच्छी थी।" बहुत सी AI-only emails अच्छी होती हैं। Win यह है कि वह line by line दिखा सकती है कि उसके judgment ने result कहाँ change किया, और professor का question, "कौन से parts आपके हैं?", असल में यही पूछ रहा था। यह भी ध्यान दें कि payoff professor के कभी पूछने पर depend नहीं था। अगर किसी ने question न भी किया होता, comparison ने email को genuinely उन दोनों paths से better बनाया जो अकेले बनते। Audit बस उस value को visible करता है जो दोनों cases में थी।
सिर्फ Collaborative नहीं, तीनों versions क्यों चाहिए:
- Solo version के बिना, आप नहीं जानते कि अकेले क्या लिखते। इसलिए final email में कौन से ideas आपके हैं और कौन से AI के, आप नहीं बता सकते।
- तीनों compare किए बिना, आप prove नहीं कर सकते कि Collaborative version सच में better है। अगर कोई पूछे क्यों, तो "better feel होती है" real answer नहीं।
- AI-only version के बिना, आप नहीं बता सकते कि आपने AI की हर बात बस accept कर ली। अगर Collaborative और AI-only लगभग same दिखते हैं, तो आपने collaborate नहीं किया। बस copy किया।
इसे ऐसे work के लिए use करें जहाँ आपका personal experience matter करता है: emails जिन्हें आपकी आवाज़ जैसा लगना है, decisions जहाँ AI आपकी situation नहीं जानता, creative work जिसे आपके ideas चाहिए। ऐसे simple tasks जहाँ AI अकेला अच्छा करता है, जैसे table format करना या notes summarize करना, AI को करने दें। ऐसे tasks पर यह exercise waste न करें जिन्हें आपके judgment की ज़रूरत नहीं।
खुद try करें
यहाँ से शुरू करें: Landlord को rent reduction माँगने का message लिखें, या professor को deadline extension माँगने का message। कुछ ऐसा जहाँ आपके पास वह context है जो AI के पास नहीं, जैसे payment history, सामने वाले के साथ आपका relationship, या specific situation।
Workplace version: Boss आपसे 1-page memo माँगते हैं कि company को एक smaller competitor खरीदना चाहिए या नहीं। Competitor में 90 people हैं और वह last quarter तक fast grow कर रहा था, जब उसने अपना biggest customer खो दिया जो revenue का 22% देता था। वे $40-55M में buyout के लिए open हैं। आपकी recommendation अगले 3 years तक quote की जाएगी।
दोनों options में तीनों versions करें: Solo (5 min), AI-only (3 min), Collaborative (5 min)। तीनों side by side रखें। Point memo नहीं है। Point 3 paths के बीच का felt difference है।
(या इस week अपने desk का कोई real decision चुनें। जितना real होगा, comparison उतना sharp होगा।)
AI-only draft skip न करें। यही वह draft है जिसे drop करना सबसे tempting है ("मुझे already पता है AI क्या कहेगा") और रखना सबसे diagnostic है। अगर Collaborative uncomfortable रूप से AI-only के करीब निकलता है, आपने over-accept किया। यह सिर्फ दोनों लिखकर पता चलता है।
AI grader 2 चीज़ें check करेगा:
- क्या आपके 3 versions सच में अलग हैं, या सब same बात कहते हैं? 1-10 rate करें। अगर Solo और Collaborative लगभग identical लगें, तो कहें।
- क्या आपके 3 overrides specific हैं? 1-10 rate करें। हर override ऐसी चीज़ होनी चाहिए जिस पर आप point करके कह सकें "इसके बिना email worse होती।" कोई override vague हो, जैसे "मैंने इसे better बनाया," तो कहें।
मेरे work को rewrite न करें। कोई box empty या vague हो तो बस कहें।
अपने तीनों versions describe करें (आपने क्या लिखा, किस बात ने surprise किया, और कहाँ वह short रहा):
Collaborative version में change या add की हुई 3 specific चीज़ें name करें जिन्होंने उसे better बनाया:
आप कौन सा version सच में send करेंगे, और क्यों?
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
Thinking time सहित इसमें total लगभग 15 minutes लगते हैं। Score मिलने के बाद वह जगह खोजें जहाँ AI grader कहता है कि आपका Solo version किसी चीज़ में better था। वह बताता है कि Collaborative version में आपने अपनी thinking के बजाय AI पर ज़्यादा भरोसा कहाँ किया।
आपने अभी 1 exercise में पूरा crash course किया। AI से पूछने से पहले अपनी राय बनाई (Discipline 1)। किस बात से agree और disagree किया उसका track रखा (Discipline 2)। Mistakes check कीं (Discipline 3)। आगे क्या होता है सोचा (Discipline 4)। Common advice कहाँ काम करना बंद करती है test किया (Discipline 5)। और AI के takeover करने की कोशिश के दौरान अपना judgment अपने पास रखा (Discipline 6)। Point कभी answer खुद नहीं था। Point यह दिखा पाना है कि वहाँ पहुँचने के लिए आपने कैसे सोचा।
एक good example देखना है? (अपना submit करने के बाद खोलें।)
एक दूसरी student ने deadline extension माँगते हुए professor को email लिखी। हर version ऐसा दिखा:
| Version | उसने क्या लिखा |
|---|---|
| Solo (15 min) | Honest और personal। Family situation clearly explain की। लेकिन बहुत लंबी थी, और actual request ("क्या मुझे 5 days और मिल सकते हैं?") bottom में दब गई। उसे पता था restructure चाहिए लेकिन time खत्म हो गया। |
| AI-only (5 min) | Short और well-organized। लेकिन template जैसी लगी। "I would greatly appreciate your consideration" जैसे phrases use हुए जो वह real life में कभी नहीं कहती। Course या professor की कोई specific detail नहीं थी। |
| Collaborative (10 min) | Opening अपने words में लिखी, फिर AI से request top पर रखने में help माँगी। AI ने tone softer करने को कहा; उसने direct wording रखी क्योंकि वह जानती थी professor honesty पसंद करते हैं। AI का structure use किया लेकिन closing अपने sentence से replace की। |
Collaborative version में उसने 3 चीज़ें change कीं:
- अपना direct tone रखा। AI ने उसे ज़्यादा formal बनाने की कोशिश की ("I would be grateful for your understanding")। उसने original wording ("मुझे 5 days और चाहिए") रखी क्योंकि professor ने कहा था कि उन्हें point पर आने वाले students पसंद हैं। इसके बिना email हर AI-written extension request जैसी लगती।
- Request को first line में move किया। उसे अकेले यह नहीं सूझता। AI ने suggest किया। Solo version पर यही single biggest improvement था।
- AI की closing line replace की। AI ने लिखा "Thank you for your time and consideration." उसने इसे "अगर इससे help हो, तो मेरे पास अभी तक जो है वह मैं आपको दिखा सकती हूँ" से replace किया। इससे पता चला कि उसने work शुरू कर दिया था। इसके बिना email generic line पर end होती जिसका कोई काम नहीं था।
यह अच्छा क्यों है: हर override ऐसी चीज़ पर point करती है जिसे वह जानती थी और AI नहीं, जैसे professor को directness पसंद है और उसने work शुरू कर दिया है। वह exact बता सकती है कि उसके judgment ने email कहाँ better बनाई। यही test है।
यह काम क्यों करता है (इसके पीछे की research)
यह exercise जिस pattern पर बनी है, human + AI दोनों अकेले से better होते हैं लेकिन तभी जब human decisions अपने पास रखे, AI productivity research की सबसे consistent findings में से एक है। 3 pieces of work इसे 3 angles से explain करते हैं।
Human + machine teaming (Garry Kasparov, "centaur" chess पर)। 1997 में IBM Deep Blue से हारने के बाद Kasparov ने conclusion नहीं निकाला कि machines बस जीत गईं। उन्होंने advanced chess popularize करने में help की, जहाँ human computer के साथ खेलता है। बाद के freestyle tournaments में strongest competitors अक्सर grandmasters या best engines नहीं, बल्कि ordinary players थे जो machine को manage करना जानते थे, यानी उसकी calculation पर कब trust करना और strategy पर human judgment से कब override करना। Durable lesson chess के बारे में नहीं है (आज के engines इतने strong हैं कि human pure play कम ही improve करता है)। Lesson है कि teaming तब जीतती है जब human वह चीज़ लाता है जो machine में नहीं। Writing और decision-making में वह चीज़ आपका private context है: आपकी situation, reader, और आप सच में क्या कहना चाहते हैं। Collaborative path यही add करने पर force करती है।
और पढ़ें: Advanced chess (Wikipedia); Kasparov यह argument Deep Thinking (PublicAffairs, 2017) में develop करते हैं।
AI उन लोगों को सबसे ज़्यादा उठाता है जो सबसे कम जानते हैं (Brynjolfsson, Li & Raymond, 2023). Generative AI at work की पहली large field study में researchers ने AI assistant use करने वाले 5,179 customer-support agents track किए। Productivity average 14% बढ़ी, लेकिन gain लगभग पूरी तरह novices में concentrated था (लगभग 34% jump), जबकि most experienced agents पर little effect था। Reason revealing है: AI नए workers को वही knowledge दे रहा था जो expert workers के पास पहले से थी। इस exercise के लिए implication direct है: collaboration तभी value add करती है जब आप वह चीज़ लाते हैं जो AI में नहीं। जहाँ AI answer पहले से जानता है, आपके लिए judgment add करने को कुछ नहीं; जहाँ context आपके पास है, overrides ही पूरा point हैं।
और पढ़ें: Generative AI at Work (NBER), Quarterly Journal of Economics (2025) में published।
AI सबको same middle की ओर compress करता है (Noy & Zhang, 2023). Controlled experiment में 444 professionals ने writing tasks किए, half ने ChatGPT के साथ। Tool ने time घटाया और average quality बढ़ाई, लेकिन distribution compress करके: weaker writers बहुत improve हुए, stronger writers मुश्किल से बदले, और outputs आपस में ज़्यादा similar हो गए। यह compression exercise में built warning है। अगर आप AI draft as-is लेते हैं, तो same competent, generic middle पर land करते हैं जहाँ बाकी सब। Collaborative path उस middle से वापस ऊपर चढ़ने का तरीका है। आपके overrides result को shared default के बजाय आपका बनाते हैं।
Paper पढ़ें: Experimental evidence on the productivity effects of generative artificial intelligence, Science, 381, 2023।
Three-path comparison तीनों combine करती है। Teaming solo work को तभी beat करती है जब human machine को manage करे, defer नहीं (Kasparov); AI वहाँ सबसे ज़्यादा add करता है जहाँ आप सबसे कम जानते हैं, यानी आपकी value वह है जो AI के पास पहले से नहीं (Brynjolfsson, Li & Raymond); और unmanaged AI हर output को same generic middle की ओर खींचता है (Noy & Zhang)। Task को Solo, AI-only, Collaborative तीन तरीकों से लिखना तीनों को एक साथ visible करता है: AI-only draft generic middle दिखाती है, Solo draft दिखाती है uniquely आपका क्या है, और Collaborative draft वह जगह है जहाँ आपका judgment पहले को दूसरे में बदलता है। इस exact exercise को किसी ने test नहीं किया, लेकिन underlying finding इस field की सबसे established results में से है।
इस exercise का full version (95-minute three-path comparison, peer review, XP tracking, और full collaboration-style diagnosis के साथ) Part 0 Chapter 6: Working WITH AI, Not For AI में है। यह page discipline सिखाता है। वह page उसके आसपास working week build करता है।
Capstone: 1 Decision, 6 Disciplines
आप अपनी university के student council के president हैं। University ने council को अचानक $10,000 budget दिया है जिसे semester end होने से पहले spend करना है। आपको 2 options दिखते हैं। Option A: एक professional event planner hire करके एक बड़ा end-of-year farewell party organize करें। Option B: पैसे से ऐसे AI tools और equipment खरीदें जो council के हर member को पूरे year better events plan करने में help करें। आधी council farewell party चाहती है। आधी AI tools। Friday की council meeting में आपको recommendation present करनी है। हर discipline decide करने में ऐसे help करती है।
Discipline 1, Prediction Lock. AI से कुछ पूछने से पहले 4 lines लिखें। Real decision: "farewell party vs. tools" नहीं, बल्कि "एक बड़ा event vs. हर future event को better बनाना।" Question जो settle करेगा: क्या AI tools को इतने council members सच में use करेंगे कि investment justify हो? आपकी position: Option B, AI tools चुनें, क्योंकि आपने पूरे year council को event planning में struggle करते देखा है और जानते हैं कि right tools सिर्फ 1 नहीं, अगले 4 events बदलेंगे। Confidence + क्या flip करेगा: 55% sure। अगर 8 में से 6 से कम council members tools सच में use करेंगे, तो Option A पर switch करें।
फिर पूछें। ध्यान दें, Line 2 question council members के बारे में था, इसलिए answer AI से नहीं, उनसे आता है: आप 8 लोगों से directly poll करते हैं। 6 कहते हैं कि वे tools use करेंगे और training finish करेंगे; 2 unsure हैं। यह 6 वाला bar clear करता है। आपकी position Option B hold करती है, उसी reason पर जो आपने लिखा, और अब hunch के बजाय उसके पीछे number है। (हर settling question AI question नहीं होता। Prediction Lock बस बताता है कि कौन सा question answer करना है; कभी आप model के बजाय लोगों से पूछकर answer करते हैं।)
Discipline 2, Reasoning Receipt. अब AI से पूछें कि पैसे कैसे spend करें। AI कहता है farewell party "500+ students के लिए lasting memories बनाएगी।" इसे MODIFY label करें: venue में सिर्फ 300 आ सकते हैं। AI कहता है AI tools event quality 35% बढ़ाते हैं। REJECT करें: कोई source नहीं, और council ने ये tools पहले use नहीं किए। AI mention करता है कि दूसरी universities ने event planning में AI use करके पैसे बचाए। SURFACED करें: आपने दूसरी universities के बारे में नहीं सोचा था। आप यह भी notice करते हैं कि AI ने $10,000 farewell party के event insurance और security का ज़िक्र नहीं किया। इसे MISSED label करके खुद add करें। AI suggestions के बाद आपके पास 8 labeled rows हैं। आप exact जानते हैं किन claims पर trust है और किन पर नहीं।
Discipline 3, Error Taxonomy. Receipt उन claims को संभालती है जहाँ आप रुके; error scan उन claims के लिए है जिन्हें निकलने दे सकते थे। AI output को 6 mistake types से scan करें और receipt से miss हुई 3 catches पाएँ: एक fabricated source (AI ने "2025 National Student Events Report" cite की जो कहीं नहीं मिलती), एक stale fact (AI-tools की quoted price last year की है; current price लगभग 15% higher है), और false confidence (AI ने बिना evidence flat claim किया कि tools "1 semester में अपनी cost recover कर लेंगे")। Stale price budget math बदलती है; बाकी दोनों याद दिलाते हैं कि AI के confident tone का कितना हिस्सा unearned था।
Discipline 4, Cascade Map. दोनों options का 5 groups पर आगे का effect trace करें:
- Council members: Option A का मतलब 1 बड़ा event और फिर कुछ नहीं। Option B का मतलब सभी के लिए new skills।
- Students: Option A में 300 students को 1 great night। Option B सभी students के हर event को improve करता है।
- University admin: Option A safe और familiar है। Option B दिखाता है कि council forward-thinking है।
- Next year's council: Option A कुछ पीछे नहीं छोड़ता। Option B tools और training छोड़ता है जिन्हें next team use कर सकती है।
- Sponsors: Option A उन sponsors को attract करता है जिन्हें 1 event में visibility चाहिए। Option B sponsors को pitch करना harder है।
आप 1 loop खोजते हैं: अगर Option B चुनें लेकिन 8 में से सिर्फ 4 members tools use करें, तो events improve नहीं होंगे, next year's council कोई benefit नहीं देखेगी, और AI tools cancel कर देगी। Investment waste हो जाएगी। यह वही reversal condition है जो Prediction Lock की Line 4 में name की थी, और इतनी real है कि उसके against safeguard build करें।
Discipline 5, First Principles. सभी कहते हैं "एक बड़ा event school spirit बनाता है।" Test करें कि advice कहाँ टूटती है। Boundary: जब 20% से कम students attend कर सकें (2,000 में से 300), तो farewell party एक small group के लिए spirit बनाती है और बाकी left out feel करते हैं। वह boundary picture बदलती है।
Discipline 6, Working WITH AI. Recommendation 3 तरीकों से लिखें। Solo: Option B का solid case, लेकिन farewell party चाहने वाले council members को address करना भूल गए। AI-only: polished recommendation जो difference split करती है ("दोनों करें!") लेकिन explain नहीं करती कि budget में दोनों कैसे fit होंगे। Collaborative: core argument खुद लिखें, AI से farewell party supporters की concerns address करने में help लें, और specific rule add करें: अगर 8 में से 6 से कम members 3 months में AI training complete करें, तो remaining money farewell party में जाएगा।
Council safeguard rule के साथ Option B के लिए vote करती है। Recommendation का हर part आप explain कर सकते हैं क्योंकि उसे AI की help के साथ खुद build किया।
6 disciplines ने क्या किया: उन्होंने answer नहीं दिया। उन्होंने trail दिया: Monday को commit की गई position और वह specific finding जो उसे flip करती, receipt जो दिखाती है कौन सी AI claims पर trust किया और कौन सी reject, numbers fix करने वाला error scan, risk खोजने वाली cascade map, obvious choice challenge करने वाली boundary, और safeguard खोजने वाला three-version comparison। 6 disciplines के बिना meeting में आप कहते "मुझे लगता है Option B better है।" उनके साथ evidence और backup plan लेकर जाते हैं।
Lunch कहाँ करना है decide करने के लिए Cascade Map नहीं चाहिए। हर text message के लिए Reasoning Receipt नहीं चाहिए। 6 disciplines उन decisions के लिए use करें जो सच में matter करते हैं। बाकी के लिए बस decide करके आगे बढ़ें।
किस decision के लिए कौन सी disciplines?
| Decision कितना important है? | Example | कौन सी disciplines use करें | Time |
|---|---|---|---|
| बिल्कुल important नहीं | कहाँ खाना है, routine message का reply | None | 0-1 min |
| कुछ हद तक important | Next semester course चुनना, laptop खरीदना | Top AI recommendation पर Prediction Lock + Error Taxonomy | 10-15 min |
| Important, deadline के साथ | Career choice, big purchase, group project proposal | Prediction Lock + Reasoning Receipt + Error Taxonomy + fit होने वाली 1-2 others | 30-60 min |
| बहुत important, लोग आपकी reasoning judge करेंगे | Thesis defense, job interview presentation, council recommendation | सभी 6 disciplines | 90+ min |
🚀 Projects
ऊपर वाला capstone किसी और का decision था। ये 4 projects आपके हैं। आप URL ship या app build नहीं करते। अपने week का real decision लें, disciplines से तब तक run करें जब तक कोई ऐसी चीज़ catch न हो जो आप miss करते, और trail रखें।
Disciplines catch करने के लिए बनी हैं। Premortem plan fail होने का तरीका catch करता है। Receipt वह claim catch करती है जिस पर सच में trust नहीं। Error scan AI का बनाया हुआ source catch करता है। यहाँ win छोटी और real है: एक sentence जिसे आप ज़ोर से बोल सकें और जो verb पर end हो। "मैं लगभग X decide कर चुका था, लेकिन fail होने का तरीका catch किया, इसलिए plan change किया।" "यह certain लगा, लेकिन made-up source catch किया, इसलिए बस accept नहीं किया।" और जो चीज़ आप रखते हैं वह Decision Dossier है: एक short file, सिर्फ आपके लिए, जो "आपने यह decide क्यों किया?" का answer देती है बिना कुछ याद रखने की ज़रूरत के। यह file top के rule को concrete बनाती है, यानी आपकी thinking का documented evidence।
ये made-up case की exercises नहीं हैं। Catch तभी count करती है जब decision real और आपका हो। 4 projects capstone की ओर build करते हैं: पहला plan fail होने का 1 तरीका पकड़ता है, दूसरा confident answer audit करता है, तीसरा question को reframe करता है, और चौथा एक decision पर सभी 6 disciplines run करके result रखता है।
Project 1~15 minहोने से पहले call करेंDecision lock करें, फिर commit करने से पहले उसके fail होने का तरीका पकड़ने के लिए premortem run करें।
इस week लेने वाला 1 real decision चुनें। Offer लें या stay करें। चीज़ खरीदें या wait करें। Conversation करें या जाने दें। Plan switch करें या hold करें।
AI से कुछ भी पूछने से पहले अपना Prediction Lock लिखें। Discipline 1 की 4 short lines: label के नीचे का real decision, उसे settle करने वाला 1 fact, reason के साथ आपकी position, और confidence plus क्या flip करेगा।
अब premortem run करें। Prediction Lock के नीचे का यही move Discipline 1 के research box ने name किया था: imagine करें decision already fail हो चुका है और पूछें क्यों। ध्यान दें, यही वह 1 समय है जब आप जानबूझकर AI को अपना decision बताते हैं। Discipline 1 में position off-page रखी थी ताकि AI बस agree न करे। यहाँ attack चाहिए, इसलिए exact बताएँ आपने क्या चुना:
मैंने [आपका decision] decide किया है। Imagine करें 6 months बाद यह mistake निकला। मुझे reassure न करें। इसके fail होने के 3 सबसे likely reasons list करें, most likely पहले, और उन्हें मेरी situation के लिए specific रखें।
3 reasons को Line 4 के against पढ़ें। उनमें से 1 आम तौर पर ऐसा failure mode होता है जो आपने नहीं देखा। वही catch है। उसके against safeguard का 1 sentence लिखें, कोई rule, check, या tripwire, जैसे student council president ने add किया "अगर 8 में से 6 members training finish न करें, तो money party में जाएगा।"
Win जिसे ज़ोर से कह सकते हैं: "Commit करने से पहले मैंने इसके fail होने का तरीका catch किया और safeguard build किया।"
Done when: Premortem से surfaced ऐसा 1 failure mode name किया हो जो आपने नहीं देखा था, और उसके against safeguard की 1 line लिखी हो। दोनों lines रखें; ये dossier का first page हैं।
Project 2~20 minConfident answer audit करेंAI से उसकी own claims list कराएँ, फिर वह 1 claim catch करें जिसे वह back up नहीं कर सकता।
इस week AI से सच में पूछने वाला कोई real question लें और उसे full, confident recommendation देने दें। कौन सा laptop। कौन सा loan। Client से क्या charge करें। Supplement worth है या नहीं। Tenant को कैसे handle करें।
ज़्यादातर readers recommendation पढ़कर polished पाते हैं और use कर लेते हैं। आप 2 disciplines साथ use करके audit करेंगे। पहले Reasoning Receipt (Discipline 2): हर claim पर 1 row, ACCEPT, REJECT, MODIFY, SURFACED, या MISSED label और 1-sentence why। फिर Error Taxonomy (Discipline 3): same answer को 6 error types के लिए scan करें, खासकर fabricated source, stale number, और false confidence।
उन्हें surface करने का fastest तरीका AI से अपना answer खुद grade कराना है। Recommendation के ठीक बाद यह paste करें:
अभी दी recommendation पर वापस जाएँ। हर factual claim numbered list में लिखें। हर एक के लिए honestly बताएँ कि आप सच में जानते हैं या estimate कर रहे हैं, और उसे KNOW या GUESS mark करें। Source वाली हर चीज़ का exact title और year दें ताकि मैं उसे look up कर सकूँ।
अब catching करें। Named sources में 1 खोजें: real source search survive करता है, fabricated नहीं। 1 number आज की actual price या figure से check करें। जो claim hold नहीं करती वही catch है। उसे reason और error type के साथ receipt में रखें।
Win जिसे ज़ोर से कह सकते हैं: "यह sure लगा, लेकिन मैंने made-up source catch किया, इसलिए बस accept नहीं किया।"
Done when: एक labeled row हो जो real catch है, जैसे source जो नहीं मिला, stale number, या बिना basis confidence, और आप 6 error types में उसका name बता सकें। Receipt dossier में add करें।
Project 3~20 minवह question जिसने unlock कियाAI से answer माँगना बंद करें; problem को dissolve करने वाला question खोजने के लिए उसके साथ काम करें।
पूरा page argue करता है कि leverage answer में नहीं, question में है। यहाँ इसे उस चीज़ पर prove करें जिस पर सच में stuck हैं। Week की कोई real problem चुनें जिसे normally "मुझे क्या करना चाहिए?" कहकर AI पर dump करते: decision जो settle नहीं होता, conflict जिसे replay करते रहते हैं, goal जो बार-बार miss होता है।
पहले वह question 1 line में लिखें जो normally पूछते। फिर उसे न पूछें। Problem दें और answer के बजाय better questions माँगें:
मैं [आपकी problem] पर stuck हूँ। अभी solve न करें। इसके बजाय वे 5 questions पूछें जिनका answer मुझे solve करने की कोशिश से पहले देना चाहिए, उस question से order करके जो मेरी पूरी approach बदलने की सबसे ज़्यादा संभावना रखता है, फिर least तक। फिर बताएँ मैं शायद कौन सा question avoid कर रहा हूँ।
List को पहले लिखे question के against पढ़ें। आम तौर पर उनमें से 1, अक्सर वही जिसे AI कहता है कि आप avoid कर रहे हैं, पूरी problem reframe करता है: पता चलता है आप wrong thing solve कर रहे थे। उस 1 question का answer खुद 1-2 sentences में दें और original problem को shrink या shape change करते देखें। वही reframed question catch है।
Win जिसे ज़ोर से कह सकते हैं: "मैंने wrong question का answer देना बंद किया, और real question ने problem छोटी कर दी।"
Done when: Reframed question name कर सकें जिसने problem देखने का तरीका बदला, और 1 sentence में बता सकें कि starting question wrong क्यों था। दोनों dossier में add करें।
Project 430-45 minDecision Dossierएक real decision पर सभी 6 disciplines run करें और पूरा trail 1 file में रखें।
यह capstone है। इस week matter करने वाला 1 decision चुनें, ऐसा जहाँ बाद में कोई justification माँग सकता है: hire, big purchase, project direction, career move, hard conversation। सभी 6 disciplines run करके result को Decision Dossier की तरह रखें: सिर्फ आपके लिए 1 file, जो बिना कुछ याद रखे "आपने यह decide क्यों किया?" का answer दे। यह polished memo नहीं और कहीं post नहीं होती। यह आपकी thinking का documented evidence एक जगह है।
Blank doc खोलें। नीचे का हर step 1 short section add करता है।
- Prediction Lock (2 minutes)। 2-line lock लिखें: label के नीचे का real decision name करता 1 sentence, और specific flipping finding के साथ position commit करता 1 sentence।
- Reasoning Receipt (5 minutes)। AI से real question पर recommendation माँगें, फिर 3 claims को ACCEPT, REJECT, या MODIFY और 1-sentence why के साथ receipt करें। (Project 2 का self-audit prompt claims देखना easy बनाता है।)
- Error Taxonomy (3 minutes)। AI output में 6 types में से 1 named error scan करें। Exact sentence quote करके type name करें।
- Cascade Map (5 minutes)। Decision से affected 3 groups चुनें। हर एक के नीचे "और फिर क्या?" की 1 layer लिखें। 1 loop name करें जहाँ effect वापस decision पर circle करता है।
- First Principles (3 minutes)। 1 boundary row लिखें: वह threshold जहाँ हर कोई जो advice repeat करता है आपके case में काम करना बंद करती है।
- Three-Path Comparison (5 minutes)। Recommendation का 1 short paragraph solo, फिर 1 AI की help से लिखें। Compare करें। Override रखें: AI version में missing वह line जो आपने खुद लिखी।
यह polished नहीं होगा। यह आपका और complete होगा: locked position, trusted और rejected claims, caught error, cascade का risk, tested boundary, और रखा override। यही catch है, पूरे decision के scale पर।
Win जिसे ज़ोर से कह सकते हैं: "किसी ने पूछा मैंने यह क्यों decide किया, और मेरे पास answer ही नहीं, दिखाने को पूरा trail था।"
Done when: 1 real decision के लिए सभी 6 sections भरी 1 file हो, और "आपने यह decide क्यों किया?" पूछने वाले किसी व्यक्ति को वह file देकर answer मिल सके।
यहाँ से आगे कहाँ जाएँ
6 disciplines में से किसी पर deeper practice के लिए, इस किताब का Part 0 long-form treatment है:
- Part 0 Ch 1: Asking Better Questions. Prediction Lock और Position Lock, 4 exercises और Question Quality Portfolio में expanded।
- Part 0 Ch 2: Detecting Broken Reasoning. Error Taxonomy, confidence calibration और domain-expertise stress test के साथ extended।
- Part 0 Ch 3: Thinking in Systems. 4 real decisions पर cascade maps, plus human-vs-AI systems-analysis exercise।
- Part 0 Ch 4: Reasoning from First Principles. Blank Page Sprint, Assumption Autopsy, और constraint-rebuild exercise।
- Part 0 Ch 6: Working With AI, Not For AI. Working week में Three-Path Comparison, collaboration logs, और override tests।
यह crash course जिन 5 thinking skills को cover नहीं करता, उनका full treatment Part 0 में है:
- Ch 5: Communicating What Matters. Audience prediction, live adaptation, hard conversations।
- Ch 7: Reasoning Through Dilemmas. Ethical position locks, adversarial defences, stakeholder swaps।
- Ch 8: Building Something From Nothing. Blank page sprints, creation logs, three-draft evolutions।
- Ch 9: Deciding Under Uncertainty. Sealed decisions, reversal triggers, decision audits।
- Ch 10: Learning How to Learn. Meta-learning, 72-hour sprints, Personal Learning Framework।
इस किताब में next step के लिए, एक mode चुनें:
- अगर code लिखते हैं, Claude Code & OpenCode पर जाएँ। Mode 1 का engineering surface, यानी already किए जाने वाले work को AI से improve करना।
- अगर knowledge work करते हैं (legal, finance, marketing, operations, healthcare, education, leadership), Cowork पर जाएँ। Mode 1 का domain-expert surface।
- अगर independently run करने वाले AI Workers build करने के लिए ready हैं, Build AI Agents पर जाएँ। यह Mode 2 है, independently काम करने वाले AI systems build करना।
Disciplines हर tool, mode, और domain में transfer होती हैं। यहाँ से कहीं भी जाते समय इन्हीं को साथ ले जाते हैं।
Glossary
अगर page के बीच पहुँचकर किसी word का meaning भूल गए, तो load-bearing terms एक जगह यहाँ हैं।
4 key ideas (rule section और diagram से)।
- Discipline: एक thinking habit जिसे आप practice करते हैं। कुछ जो आप करते हैं।
- Failure mode: एक specific तरीका जिससे AI आपको mislead करता है। कुछ जो AI करता है। हर discipline अपने answer किए failure mode के साथ one-to-one paired है।
- Part: common job share करने वाली disciplines का group। Course के 3 parts (Foundations, Detection, Origination) हैं, हर एक में 2 disciplines।
- Deliverable: वह चीज़ जो boss, professor, या client को देते हैं। 2026 में deliverable सिर्फ answer नहीं; answer plus वह documented evidence of thinking है जिसने उसे produce किया (लिखी prediction, AI claims accept या reject करने वाली receipt rows, cascade map, named threshold)। Evidence पर point नहीं कर सकते, तो deliverable नहीं है।
6 disciplines।
| # | Discipline | Action line | यह क्या करती है |
|---|---|---|---|
| 1 | Prediction Lock (Part 1: Foundations) | PREDICT BEFORE YOU PROMPT | AI से पूछने से पहले committed position लिखें, उस specific AI answer सहित जो उसे flip करेगा। |
| 2 | Reasoning Receipt (Part 1: Foundations) | DOCUMENT EVERY DECISION | AI की हर बात के लिए ACCEPT / REJECT / MODIFY / SURFACED / MISSED mark करें, साथ में 1-sentence why। |
| 3 | Error Taxonomy (Part 2: Detection) | PREDICT WHERE ERRORS HIDE | AI output को 6 specific mistake types के लिए scan करें: Factual error, Logical gap, False confidence, Missing context, Fabricated source, Stale fact। |
| 4 | Thinking in Systems (Part 2: Detection) | CASCADE MAPS & LOOPS | Decision के बाद affected groups में 3 layers deep क्या होता है trace करें, और वे loops खोजें जहाँ effects वापस circle करते हैं। |
| 5 | First Principles (Part 3: Origination) | FIND THE BOUNDARY | Named threshold name करें, यानी वह specific number या condition जहाँ common advice काम करना बंद करती है। |
| 6 | Working WITH AI (Part 3: Origination) | OVERRIDE & ITERATE | Solo में आप क्या लिखते हैं, AI अकेला क्या लिखता है, और Collaboratively क्या लिखते हैं compare करें। Collaborative तभी जीतता है जब exact overrides दिखा सकें जहाँ judgment ने उसे better बनाया। |
Page पर use हुए कुछ और terms।
- Named threshold: specific number या condition जो बताती है advice कब काम करना बंद करती है। "यह तब काम करती है जब आपकी class में 30 से कम students हों" named threshold है। "यह कभी-कभी काम करती है" नहीं।
- Cascade map: 1-page diagram जिसमें decision से affected हर group (students, professors, parents, sponsors, etc.) की short column और उसके नीचे 3 arrows होते हैं: पहले क्या होता है, उससे next क्या होता है, और उसके बाद क्या होता है।
- Reasoning receipt: हर important AI claim की 1 row वाली list। हर row के 3 parts हैं: AI ने क्या कहा, आपने क्या किया (ACCEPT, REJECT, MODIFY, SURFACED, या MISSED), और 1-sentence why।
- Loop: cause और effect की chain जहाँ later effect वापस circle करके original decision बदलता है, आम तौर पर worse बनाता है।
Flashcards Study Aid
अपनी understanding test करें
Disciplines deliverable नहीं हैं। वे जो evidence produce करती हैं वह deliverable है। Disciplines evidence produce करने का तरीका हैं।
क्या इससे AI आपके hands में more powerful tool बनता है, या आप tool का slower version बन जाते हैं?