AI युग में कैसे सोचें: 90-minute crash course
6 Disciplines · 6 AI Failure Modes · 1 नियम
सोमवार सुबह 2 लोग वही AI tool खोलते हैं। Task भी वही है: पता लगाना कि उनकी company को senior strategy lead hire करना चाहिए, या उतने ही पैसे licenses, infrastructure और design time में invest करके ऐसी AI workforce बनानी चाहिए जो हर existing consultant की क्षमता बढ़ा दे। दोनों के पास Claude, ChatGPT और Gemini access है। दोनों के पास फैसला करने के लिए वही 1 week है।
Person A शुक्रवार को ऐसी recommendation के साथ finish करती है जिसे वह defend कर सकती है, हर accepted और rejected claim का लिखा हुआ record उसके पास है, और 3 साफ़ signs हैं जिनसे वह course बदल देगी, ऐसे signs जिन्हें board बाद में पकड़ सके। Person B शुक्रवार को एक polished memo के साथ finish करती है जो ज़्यादातर वही analysis दोहराता है जो AI ने सोमवार को लौटाया था, और जब CFO पूछता है कि paragraph 4 वहाँ क्यों पहुँचा, तो उसके पास कोई जवाब नहीं होता।
Same tools. Same problem. अलग outcomes. फ़र्क यह नहीं कि उन्होंने किस model को prompt किया। यह भी नहीं कि उन्होंने कौन से features use किए। यह भी नहीं कि कौन सी prompt-engineering tricks लगाईं। फ़र्क cognitive है: Person A ने कोई भी AI खोलने से पहले अपनी position बनाई; Person B ने पहली reasonable-sounding paragraph से position inherit कर ली।
यही gap यह crash course बंद करता है। 6 disciplines, 3 छोटे parts, no code. हर discipline उस अलग तरीके को address करता है जिससे AI unsupervised छोड़े जाने पर fail होता है। साथ में ये AI को oracle से बदलते हैं, जहाँ आप पूछते हैं, वह जवाब देता है, आप accept करते हैं, और उसे ऐसे partner में बदलते हैं जो push back करता है: आप predict करते हैं, वह जवाब देता है, आप compare करते हैं, फिर decide करते हैं।
Prerequisites. यह page मानता है कि आपने 2026 में AI Prompting पूरा कर लिया है। उस course ने mechanics सिखाए थे: context, reasoning modes, deep research, multimodal, AI desktop apps. यह course वह discipline सिखाता है जिससे mechanics का payoff मिलता है। अभी किसी दूसरे tab में Claude, ChatGPT, या Gemini का free account खोलें। Practice callouts में आप उसका use करेंगे।
Thesis एक line में
Deliverable कभी answer नहीं होता। Deliverable सोच का documented evidence होता है।
मुख्य बातें (5 bullets)
ये 5 bullets इस page का shape हैं। ये page खुद नहीं हैं। इन्हें map की तरह पढ़ें; नीचे की disciplines को territory की तरह पढ़ें। Bullets बताती हैं कि करना क्या है; नीचे की disciplines बताती हैं कि 2023 में prompting शुरू करने के बाद से चली आ रही पुरानी patterns में लौटे बिना उसे real काम में कैसे करना है।
- Prompt करने से पहले predict करें। एक बार AI का answer पढ़ लिया, तो उसे un-read नहीं कर सकते। पहली reasonable-sounding paragraph उस जगह को घेर लेती है जहाँ आपकी अपनी position होनी थी। कोई भी tool खोलने से पहले diagnosis, ranked questions, predicted answers और confidence seal करें।
- Receipt ही deliverable है। AI के हर ऐसे claim के लिए, जो गलत निकला तो आपकी recommendation बदल देगा, आप ACCEPT, REJECT, MODIFY, SURFACED, या MISSED record करते हैं, साथ में 1 sentence कि क्यों। खाली receipt या all-ACCEPT receipt का मतलब है कि real thinking हुई ही नहीं।
- Fluent prose accurate prose जैसी चीज़ नहीं है। AI सही हो या गलत, confident लगता है। Polished output के अंदर 6 error types छिपे रहते हैं। Forward, ship, या act करने से पहले उन्हें name से scan करें।
- First-order कभी पूरा answer नहीं होता। AI visible variable optimize करता है और उन 3 variables को ignore करता है जिन्हें उसने अभी disturb किया। Meeting लायक किसी भी decision को cascade-map करें। कम से कम 1 feedback loop खोजें। Labels नहीं, mechanisms insist करें।
- Collaboration तीसरा रास्ता है। Solo speed पर हारता है। AI-only originality पर हारता है। Collaboration दोनों जीतता है, लेकिन तभी जब decision वाला reasoning आप करें और AI tedious काम करे। उस split को उलट दें और आप question और answer के बीच middleman बन जाते हैं। Middlemen automate हो जाते हैं।
छठी discipline (First Principles) और ऊपर की 5 bullets के पीछे की practice scaffolding ही इस list को real काम में operational बनाती है।
Figure 1: 6 disciplines, 6 AI failure modes से map होती हैं, 3 arcs में arranged. Detection को Foundations चाहिए; Origination को दोनों चाहिए।
ये disciplines पीछे मुड़कर देखने पर obvious क्यों लगती हैं
ऊपर की 5 bullets पढ़कर reaction अक्सर आधा सा shrug होता है: हाँ, बिल्कुल। Prompt से पहले predict करें। Decisions document करें। Errors check करें। Second-order effects trace करें। जहाँ consensus टूटता है वह boundary खोजें। Accept करने के बजाय collaborate करें। ये ideas नए नहीं हैं। Lindy Effect, यानी वह heuristic कि जो चीज़ लंबे समय तक survive कर चुकी है उसके आगे भी survive करने की संभावना ज़्यादा है, ठीक यही कहता है: cognition category में पुराने दिखने वाले ideas अक्सर इसलिए पुराने लगते हैं क्योंकि सोचने वालों की हर पिछली generation उन्हें already test कर चुकी है। Predict-before-you-prompt, 400 साल पुराना courtroom rule है। Reasoning receipts वैसे ही हैं जैसे editors हमेशा drafts पढ़ते रहे हैं। Cascade maps second-year systems engineering हैं। First principles Aristotle है।
2026 में disciplines नहीं बदलीं। उन्हें skip करने की cost बदली। जब polished output महंगा था, bottleneck production था: क्या आप सच में चीज़ बना सकते हैं? AI ने polished output free कर दिया। Free account वाला कोई भी 12-year-old ऐसा memo produce कर सकता है जो finished दिखता है। Bottleneck evaluation पर shift हो गया: क्या आप बता सकते हैं कि चीज़ सही है या नहीं? Confidently wrong AI analysis, no analysis से ज़्यादा dangerous है, क्योंकि वह finished दिखता है। नीचे की disciplines अब optional good habits नहीं हैं। यही वह जगह है जहाँ आपका judgment दूसरों को visible होता है, और आपका judgment ही वह चीज़ है जिसे AI fake नहीं कर सकता।
Lindy point का दूसरा half: tools हर 6 months में बदलते हैं; thinking नहीं। जिन teams ने अपना पूरा 2023 workflow एक AI product के around बनाया था, उनमें से ज़्यादातर ने 2024 में और फिर 2025 में उसे दोबारा बनाया, जब model releases ने surface reshuffle कर दिया। Products के नीचे वाली skills अपनी value रखती हैं, भले products न रखें। उस पर bet करें जो टिकता है।
Reading paths
आज आपके पास कितना time है, उसके हिसाब से इस page को पढ़ने के 3 तरीके हैं:
- 30-minute taste (पहली बार पढ़ रहे हैं, या coffee break जितना time है): Disciplines 1, 2, 3 और 6 पढ़ें। ये 4 सबसे ज़रूरी shifts cover करते हैं: prompt से पहले predict करें, काम करते हुए अपने verdicts document करें, AI output को 6 error types के लिए name से scan करें, और AI को oracle की तरह treat करना बंद करें। Discipline 2 (Reasoning Receipt) छोटी है लेकिन निर्णायक है। इसे skip करें और आपके पास ऐसा Prediction Lock रह जाएगा जिसे room में defend नहीं कर पाएँगे। Real work में फ़र्क महसूस होने के बाद Disciplines 4 और 5 के लिए अलग sitting में लौटें।
- 90-minute essential read (standard path, recommended): सभी 6 disciplines order में पढ़ें। हर worked example पढ़ें। इस week हर discipline से कम से कम 1 practice callout run करें। Optional Blank Page Sprint extension skip करें।
- Full read with practices (लगभग 2 hours plus real-work application का 1 week): इस page की हर चीज़, plus अगले 7 दिनों में आपके सामने आने वाले actual decisions पर हर practice exercise run करें। यही path instincts बनाता है। पहली बार Prediction Lock try करेंगे तो आपके predicted answers vague या wrong होंगे। यही point है। आपकी prediction और AI के answer के बीच का gap ही calibration की जगह है।
अपनी week के हिसाब से path चुनें। Disciplines real problems पर चलाने से stick होती हैं, उन्हें एक बार पढ़ लेने से नहीं।
Part 1: Foundations (posture)
आगे आने वाली हर चीज़ के नीचे 2 habits हैं। बाकी हर section skip कर दें तो भी इन 2 को skip न करें। 2026 में AI का पहला failure mode: यह खुशी-खुशी आपकी thinking आपके लिए कर देता है। आपकी अपनी position बनने से पहले ही यह finished-sounding answer दे देता है। दूसरा failure mode: first draft बहुत जल्दी finished महसूस होता है। AI की polish completeness जैसी लगती है, इसलिए आप evaluate करने से पहले ship कर देते हैं। Discipline 1 (Prediction Lock) वह posture है जो आप AI खोलने से पहले लेते हैं। Discipline 2 (Reasoning Receipt) वह artifact है जो AI के साथ काम करते हुए produce करते हैं। साथ में ये judgment को human के पास रखते हैं और heavy lifting model से करवाते हैं। Parts 2 और 3 की हर चीज़ मानती है कि ये 2 आपके पास already हैं।
Discipline 1: Prediction Lock
आप AI से कोई important question पूछते हैं। Answer तेज़ और smooth आता है। आप nod करते हैं। उसे forward कर देते हैं, या उस पर act कर लेते हैं। 2 दिन बाद कोई पूछता है कि आपने वह रास्ता क्यों चुना, और आपको realize होता है कि answer AI का था। उसके नीचे आपका अपना answer था ही नहीं।
Fix sticky note पर 4 lines है। 3 minutes. AI खोलने से पहले। Explain करने से आसान करना है, इसलिए पहले किसी और के decision पर साथ चलते हैं।
Maya, 13 साल की है। उसके school ने अभी email किया: एक summer track चुनें। Debate camp (2 weeks, उसके सभी friends जा रहे हैं) या coding bootcamp (1 week, वह curious है लेकिन थोड़ी nervous भी)। उसके dad उसके shoulder के ऊपर से email पढ़ते हैं। "बस ChatGPT से पूछ लो, उसे पता होगा।"
Maya की जगह खड़े हों। Question भेजने से पहले, उसके लिए 4 lines लिखें।
Step 1. एक sentence में, यह decision असल में किस बारे में है?
अगर आपने लिखा "debate या coding करना है या नहीं," तो फिर से कोशिश करें। वह label है, decision नहीं। Decision वह है जो label छिपा रहा है। शायद यह इस बारे में है कि वह वही करेगी जो उसके friends कर रहे हैं या वह चुनेगी जो कोई देख न रहा हो तो चुनती। या उसे coding miss करने का regret ज़्यादा होगा या debate miss करने का। या वह nervousness से आगे निकलने लायक curious है या नहीं। जो सबसे close लगे उसे 1 sentence में चुनें। Cause, topic नहीं।
Step 2. वह 1 question जिसका answer सबसे बड़ा हिस्सा settle कर देगा।
Maya ChatGPT से सब कुछ नहीं पूछ सकती। वह 1 question क्या है जिसका answer सच में उसके options narrow करेगा?
अगर आपने कुछ general लिखा ("कौन सा better है?"), तो फिर कोशिश करें। Question को किसी specific चीज़ पर point करना होगा: number, name, measurement, या particular fact. "क्या bootcamp Python use करेगा?" specific है। उसके school में 9th grade में already Python पढ़ाया जाता है, इसलिए answer decision बदलता है। Maya के लिए अपना 1 question लिखें।
Step 3. Answer पर आपका guess.
Specific. "It depends" नहीं। अगर आपका question है "क्या bootcamp Python use करेगा?", तो आपका guess yes या no है। अगर question है "September में उसके कितने friends अभी भी close रहेंगे?", तो आपका guess एक number है ("लगभग half")।
अगर आप guess नहीं कर सकते, तो question बहुत vague था। उसे narrow करें या दूसरा question चुनें। अपना guess लिखें।
Step 4. कितने sure हैं, और Maya का mind क्या बदलेगा।
उस पर percentage लगाएँ। 60%, 75%, number matter नहीं करता। Number attach करने का act matter करता है। फिर 1 specific चीज़ name करें जो उसे पता चले तो वह flip कर दे। "70%. अगर bootcamp वही चीज़ use करता है जो school already पढ़ाता है, तो debate wins क्योंकि debate उसे कहीं और नहीं मिलेगी।"
अगर flip-condition name नहीं कर सकते, तो आपके पास position नहीं है। आपके पास hope है। Step 3 rewrite करें जब तक step 4 में कुछ real न हो।
Maya की sticky अब यह कहती है:
क्या चल रहा है: क्या वह वही करेगी जो friends कर रहे हैं, या वह चुनेगी जो अकेले चुनती। Question: क्या bootcamp Python use करेगा (जो उसका school 9th grade में already पढ़ाता है)? Guess: Yes. कितनी sure, क्या flip करेगा: 70%. अगर bootcamp कुछ ऐसा use करता है जो school नहीं पढ़ाता, तो debate wins.
अब वह अपना 1 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.
Notice करें, उसने "मुझे क्या pick करना चाहिए" नहीं पूछा। उसने अपना specific Step 2 question पूछा, और एक line add की कि AI उसके लिए decide न करे। Move यही है।
ChatGPT लौटाता है: "Most one-week coding bootcamps for middle schoolers cover Python basics in the first two to three days." Maya इसे अपनी sticky के बगल में रखती है। उसका guess (yes), AI के answer (yes) से match करता है। Lock काम आया: bootcamp ज़्यादातर वही repeat करेगा जो उसे 9th grade में वैसे भी मिलेगा। वह debate चुनती है। Dinner पर dad पूछते हैं कि क्यों, और उसके पास अपना reason ready है, ChatGPT का hedge नहीं।
ये 4 lines Prediction Lock हैं। AI का confident answer आपके head में वह spot लेने से पहले 3 minutes की writing जहाँ आपका अपना answer होना चाहिए था। एक बार AI का answer उस spot में पढ़ लिया, तो उसे un-read नहीं कर सकते। आप यह भी नहीं बता सकते कि उसके बिना आपने क्या सोचा होता। बस 2 दिन बाद notice करते हैं कि आप ठीक से explain नहीं कर पा रहे कि आपने जो decide किया वह क्यों decide किया। आपने AI का answer absorb किया। आपने अपना answer earn नहीं किया।
पहले अपनी prediction लिखें, या फिर उसे लिखना छोड़ ही दें।
यही move higher stakes पर भी काम करता है। एक bank manager, 2 losing branches बंद करने का decision लेते हुए, अपनी 4 lines लिखती है: "Branches lose money because customers went mobile. What fraction of those branches' deposits belong to mobile-only customers? Guess: 70%+. 60% sure; under 50% and the closure case collapses." फिर उसने AI से अपना 1 question पूछा। AI ने 45% लौटाया। उसका guess गलत था, लेकिन question सही था। उसके number और AI के number के बीच का gap उस memo की opening line बन गया जिसे वह boardroom में लेकर गई।
Maya की 4 lines और bank manager की 4 lines surface पर अलग दिखती हैं। वे same move हैं।
अब आपकी बारी
Submit करने के लिए आपका अपना decision होना ज़रूरी नहीं। Maya के लिए आपने जो 4 lines अभी लिखीं, वे real practice हैं; कुछ और न सूझे तो वही paste करें। अगर अपनी life की किसी चीज़ पर यह move run करना चाहें, तो common options ये हैं: $50 से ऊपर की purchase जिस पर आप सोच रहे हैं, 2 activities जिनमें से केवल 1 चुन सकते हैं, कोई conversation जिसे आप avoid कर रहे हैं, कोई class या commitment जिसके बारे में sure नहीं हैं।
Either way: 4 lines लिखें। फिर, अगर सच में AI से पूछना चाहते हैं, तो template यह है (Maya वाला same shape):
I'm trying to decide [your situation in 1-2 sentences].
My specific question is: [your Step 2 question].
Just answer that one question. Don't make the decision for me.
AI का answer पहले न देखें। नीचे का AI आपकी 4 lines की FORM grade करता है: क्या आपका "what's going on" cause name करता है, सिर्फ label नहीं; क्या आपका question options को सच में narrow करता है; क्या आपका guess इतना specific है कि गलत हो सके; क्या आपकी flip-condition आपको real way out देती है। यह आपके decision के सही होने को grade नहीं करता। आपका पहला attempt Maya के लिए लिखी चीज़ से messier होगा। यही assignment है, failure mode नहीं।
AI यह check करेगा:
- क्या आपका "what's going on" cause name करता है, या सिर्फ label? 1-10 rate करें। मेरे काम का वह part quote करें जो decide करता है।
- अगर आपके question का answer मिल जाए, तो क्या वह आपके real options को narrow करेगा? 1-10 rate करें। उसी situation में fit होने वाला 1 दूसरा cause name करें जिसे मेरा question distinguish नहीं करेगा।
मेरे काम को rewrite न करें। अगर कोई field empty या vague है, तो साफ़ कहें। Messy first attempt पर honest रहें; न flatter करें, न crush करें।
आपका "what's going on" (cause, label नहीं):
आपका 1 question (वह 1 जिसका answer सबसे बड़ा हिस्सा settle करेगा):
आपका guess (specific, hedge नहीं):
आप कितने sure हैं, और क्या आपको flip करेगा:
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार 8 minutes plan करें। AI feedback के साथ सबसे useful move: ऐसी 1 जगह खोजें जहाँ आप disagree करते हैं। वहीं आपका judgment रहता है।
यह discipline का half है। दूसरा half है: conversation के दौरान AI के किन claims को accept, reject, या modify करते हैं, उसका log रखना। वह Discipline 2 है।
यह काम क्यों करता है (short version)
किसी outside source से consult करने से पहले अपना guess लिखना AI से decades पुराना है। Gary Klein ने workplace version को "project premortem" कहा था (Harvard Business Review, 2007): imagine करें कि project fail हो गया है, और शुरू करने से पहले reasons लिखें। Same idea. Phil Tetlock की forecasting research (Good Judgment Project, Superforecasting, 2015) ने दिखाया कि calibration तब improve होती है जब आप answer आने से पहले prediction record करते हैं, बाद में नहीं। और Tversky और Kahneman के anchoring work (1974) ने दिखाया कि एक confident answer आपकी अपनी answer वाली जगह घेर ले, तो आप नहीं बता सकते कि उसके बिना आपने क्या सोचा होता।
Prediction Lock, इन तीनों का AI version है।
इस exercise का full version (10 ranked questions plus Reasoning Receipt template; 45-60 minutes) Part 0 Chapter 1, Lesson 1 में है। यह page move सिखाता है। वह page इसे system बनाता है।
Discipline 2: Reasoning Receipt
आपने सुबह Claude के साथ real document पर iterate करते हुए बिताई। Output clean है। आपने उसे slides में डाला, meeting चलाई, आगे बढ़ गए। 2 weeks बाद post-mortem में boss पूछता है, "किस parts पर आपने सच में push back किया था?" और आपको realize होता है कि याद नहीं। आपने skim किया, accept किया, ship किया। Deliverable pass हो गया। Thinking नहीं।
Fix यह है। AI के साथ काम करते हुए, उसके हर decisive claim को 5 verdicts में से 1 के साथ log करें। Claim decisive है अगर उसके wrong निकलने पर आपकी recommendation बदल जाएगी।
| Verdict | इसका मतलब क्या है | 1-sentence why |
|---|---|---|
| ACCEPT | आपने claim as-is लिया। | आपने इसे trust क्यों किया (source, prior experience). |
| REJECT | आपने claim discard किया। | किस evidence ने इसे beat किया। |
| MODIFY | आपने बदला हुआ version use किया। | आपने क्या बदला और क्यों। |
| SURFACED | AI ने ऐसा point उठाया जिस पर आपने विचार नहीं किया था। आपने रखा। | यह matter क्यों करता है। |
| MISSED | आपने ऐसा point उठाया जो AI नहीं पकड़ पाया। आपने add किया। | AI ने क्या miss किया और वह matter क्यों करता है। |
Log को Reasoning Receipt कहा जाता है। Real document पर receipt row-by-row बढ़ती है जैसे conversation आगे बढ़ती है। नीचे की exercise में आप 5 claims को एक साथ receipt करेंगे।
Receipt में 1 row, 1 decision. Verdict बताता है आपने क्या किया। Why बताता है कि future reader, जिसमें future you भी शामिल हैं, इसे trust क्यों करे।
Real life में यह कैसा दिखता है।
एक product lead ने Claude से new feature का launch plan draft करने को कहा। Claude ने clean 3-page plan लौटाया। उसे doc में drop करने के बजाय, product lead ने side-by-side खोला और plan बदलने वाले हर claim को पढ़ते हुए receipt बनाई:
| AI का claim | Verdict | Why |
|---|---|---|
| "Ship the launch with one clear action (one button) to get the most people to act." | ACCEPT | हमारी last 3 launches से match करता है; 1 clear action वाली pages, 2 actions वाली pages को हर बार beat करती हैं। |
| "Start with the first 10% of users, including paying customers." | REJECT | Paying customers वही हैं जो bugs tolerate करने को सबसे कम ready होते हैं; launch buggy हुआ तो trust burn होगा। |
| "Send the launch announcement on a Tuesday morning." | MODIFY | Tuesday yes; morning no. इस segment के लिए engagement window Tuesday 6-8pm है। |
| "The feature has overlap with [competitor]'s March release; lead with differentiation." | SURFACED | Competitor की release timing से compare नहीं किया था। Differentiation framing wins. |
| (AI ने new feature के paid-tier pricing implications mention नहीं किए।) | MISSED | मैंने note add किया: launch से पहले pricing review होना चाहिए, वरना longtime customers को discounts दे देंगे। |
उसने launch plan के साथ receipt भेजी। 2 weeks बाद CEO ने पूछा कि rollout में paid cohort क्यों skip किया। उसने row 2 दिखा दी। Conversation 90 seconds चली। Receipt के बिना यह 30-minute defend-yourself meeting होती जहाँ वह reconstruct नहीं कर पाती कि उसने असल में क्या decide किया था।
Receipt के बिना वही product lead यह produce करती है:
| AI का claim | Verdict | Why |
|---|---|---|
| "Ship the launch with one clear action (one button)." | ACCEPT | Sounds right. |
| "Start with the first 10% of users, including paying customers." | ACCEPT | Sounds right. |
| "Send the launch announcement on a Tuesday morning." | ACCEPT | Sounds right. |
| "Lead with differentiation against [competitor]." | ACCEPT | Sounds right. |
| (कुछ log नहीं किया।) |
लगातार 5 ACCEPTs का मतलब 2 में से 1 है: AI हर चीज़ में सही है (rare) या receipt real काम नहीं कर रही। All-ACCEPT receipt, no receipt जैसी ही है। हर "why" लिखने की friction ही discipline है। अगर आप real "why" नहीं लिख सकते, तो आपने claim सच में accept नहीं किया। आपने उसे inherit किया।
खुद try करें
आप 60-person software company में product head हैं (mid-sized sales teams के लिए sales-tracking tools, yearly revenue लगभग $12M, year over year 30% growth). Feature है redesigned reporting layer जिसे आपके top customers 6 months से request कर रहे हैं। Current version में 2 minor cases में known bugs हैं जो roughly 4% accounts को affect करते हैं। आपका closest competitor last week similar feature launch कर चुका है। आपने AI से पूछा: "Should we ship this feature now, or wait two weeks for more testing?" AI ने 5-claim recommendation लौटाई। 5 verdicts में से 1 use करके हर claim को receipt करें, और 1-sentence why लिखें।
- "Ship now. Getting there first matters most when a product is new."
- "The two-week delay risks losing the news cycle, since [competitor] launched their version last week."
- "The data from your last three launches shows bugs surface in week 1-3, so two extra weeks of testing won't catch them."
- "Customer support load typically rises 40% in the first week after launch."
- "The engineers ship about 15% slower while they are firefighting a launch."
(अगर आप software ship नहीं करते, surface swap करें: AI ने अभी आपको इस week के किसी real decision पर 5-claim recommendation दिया है। वही use करें।)
Form से पहले 1 note. नीचे का feedback frontier model (Claude Sonnet 4.5+, Opus 4.7, GPT-5, Gemini 2.5 Pro) के लिए tuned था। Smaller models input quality जैसी भी हो, अक्सर handwave करते हैं।
AI यह check करेगा:
- क्या आपने हर verdict के लिए real "why" लिखा, या "sounds right" / "makes sense" patterns लिखे? 1-10 rate करें। मेरी receipt का weakest "why" quote करें।
- क्या कम से कम 1 REJECT या MODIFY, plus कम से कम 1 SURFACED या MISSED है? अगर हर verdict ACCEPT है, receipt काम नहीं कर रही। 1-10 rate करें। अगर मेरी receipt all-ACCEPT है, तो 1 line में साफ़ कहें।
मेरे काम को rewrite न करें। Personality पर grade न करें। अगर field empty या vague है, तो साफ़ कहें।
Claim 1 के लिए ("Ship now. Getting there first matters most when a product is new"):
Claim 2 के लिए ("The two-week delay risks losing the news cycle"):
Claim 3 के लिए ("The data shows bugs surface in week 1-3"):
Claim 4 के लिए ("Customer support load typically rises 40%"):
Claim 5 के लिए ("The engineers ship about 15% slower while firefighting a launch") OR आपकी अपनी MISSED row (कुछ जो AI ने raise नहीं किया):
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार 10-15 minutes plan करें। उसके बाद faster. AI feedback के साथ सबसे useful चीज़: ऐसी 1 row खोजें जहाँ आपने "sounds right" लिखा लेकिन उसे earn नहीं किया। वही row है जहाँ आप लगभग किसी और का reasoning अपने name से ship करने वाले थे। उस row को real "why" के साथ फिर receipt करें, और exercise की cost already recover हो गई।
जो आपने अभी किया, वह decisive claims को 1 at a time पकड़ता है। जो यह नहीं पकड़ता: हर claim के अंदर छिपे technical errors, fabricated citations, stale facts, false confidence. वह scan Discipline 3 है।
Compare करने के लिए strong sample चाहिए? (अपना submit करने के बाद खोलें।)
एक reader ने same ship-now-or-wait scenario पर यह लिखा। यह अकेला good answer नहीं है; यह shape दिखाता है।
| Claim | Verdict | Why |
|---|---|---|
| 1 | REJECT | पहले पहुँचना उन markets में सबसे ज़्यादा matter करता है जहाँ products interchangeable हों, हमारे में नहीं: हम regulated work वाले buyers को sell करते हैं जो slowness से ज़्यादा bugs punish करते हैं। |
| 2 | MODIFY | Competitor ने related feature launch किया, हमारा नहीं: differentiation news cycle से ज़्यादा matter करती है, और cycle already over है। |
| 3 | ACCEPT | हमारी last 3 launches से match करता है: emergency fixes weeks 1-3 में होती हैं, weeks 4-6 में almost never. |
| 4 | SURFACED | मैंने support load में 20% rise budget किया था, 40% नहीं: support team के पास 1.5 weeks staffing cushion है, जो मेरे लिए real risk close करता है। |
| 5 | MISSED | AI ने यह raise नहीं किया कि 2 और weeks हमें उस window में धकेलते हैं जहाँ हमारा biggest customer अपने annual plans lock करता है; real limit वही है। |
जो इसे काम कराता है: सिर्फ 1 ACCEPT है, वह भी real evidence के साथ। 5 में से 2 Whys prior internal data quote करते हैं, vibes नहीं। MISSED row ऐसा constraint पकड़ती है जो AI जान ही नहीं सकता था (customer का planning calendar). Reader का final decision है "wait, because of the customer lock-in", जो "wait, because more testing" से अलग answer है। Same verdict, different reasoning, room में defensible.
यह क्या करने की कोशिश नहीं करता: brilliant होना। ज़्यादातर rows 1 sentence हैं। Discipline real Whys लिखने में है, literary Whys में नहीं।
अगर इस move के नीचे की cognitive science चाहिए (click to expand)
Receipt, AI से बहुत पुरानी है।
- Schön, D. (1983). The Reflective Practitioner. Direct ancestor. Schön की "reflection-in-action" का move है कि काम होते समय decisions का written track बनाया जाए, ताकि practitioner बाद में हर decision defend कर सके। Reasoning receipt, model के साथ काम पर applied reflection-in-action है।
- Argyris, C. (1977). "Double Loop Learning in Organizations." Harvard Business Review. Single-loop learning existing model against errors correct करता है; double-loop learning model itself surface करता है। All-ACCEPT receipt best case में single-loop है। हर Why लिखने की friction second loop force करती है।
- Brown, P. C., Roediger, H. L. & McDaniel, M. A. (2014). Make It Stick: The Science of Successful Learning. Belknap Press / Harvard University Press. Retrieval-practice और elaboration research का popular synthesis, जिसे Roediger, H. L. & Karpicke, J. D. (2006). "Test-enhanced learning: Taking memory tests improves long-term retention." Psychological Science 17(3), 249-255. में formalize किया गया। किसी चीज़ के matter करने पर अपनी words में 1 sentence लिखना, 6 months बाद याद रहने वाली चीज़ को dramatically improve करता है। Receipt अपने decisions पर retrieval practice है; boss-asks-six-months-later moment ठीक वही scenario है जिसकी research बात करती है।
AI specifically के लिए Reasoning Receipt test करने वाला कोई single trial नहीं है। Mechanism (decisions बनाते समय उन्हें लिखना, बाद में defend करना) well-studied है; उसे AI interactions पर apply करना obvious extension है, separately validated finding नहीं।
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 move सिखाता है। वह chapter इसे habit बनाता है जिसे आप हर high-stakes AI conversation पर run कर सकते हैं।
Part 2: Detection (AI जो miss करता है उसे पकड़ना)
Foundations ने posture दिया। Detection वह pattern recognition train करता है जो AI के consistent misses पकड़ती है। यहाँ 2 failure modes dominate करते हैं। AI सही हो या wrong, confident लगता है, और उसके ज़्यादातर errors उन paragraphs में छिपते हैं जो सबसे professional पढ़ते हैं। AI visible variable optimize भी करता है और अभी disturb किए गए 3 variables ignore करता है। Discipline 3 (Error Taxonomy), fluent prose के against चलाया जाने वाला named-category scan है जिससे ship होने से पहले 6 specific error types मिलते हैं। Discipline 4 (Thinking in Systems), meeting लायक किसी भी decision के against खींचा जाने वाला cascade map है जिससे वे second-order effects मिलते हैं जिन्हें AI ने trace नहीं किया।
Discipline 3: Error Taxonomy
Trap आप जानते हैं। आप real document Claude या ChatGPT में paste करते हैं, answer polished और fluent आता है, और आप उसे वैसे पढ़ते हैं जैसे अपनी writing पढ़ते हैं: general sense के लिए, argument के shape को देखते हुए। It flows. आप nod करते हैं। Error draft के सबसे professional paragraph में बैठा रहता है, उसी paragraph में जिसे आपकी आँख skip कर गई क्योंकि कुछ wrong feel नहीं हुआ। 3 days बाद वह ship होता है, और 1 fabricated number, या 1 citation जो exist नहीं करती, वही चीज़ बनती है जिसे reader सबसे पहले पकड़ता है।
Fix यह है। AI output को "feel" से पढ़ने के बजाय name से scan करें, एक error type at a time. 6 types, हर एक के साथ where-to-look-first prompt.
| Error type | यह कैसा दिखता है | पहले कहाँ देखें |
|---|---|---|
| Factual error | Demonstrably false specific claim: number, date, name, citation, API method. | Specific number वाली हर sentence, especially decimals. Precision research जैसा appearance बनाती है। मैं कह सकता हूँ कि 73.6% analysts AI figures verify नहीं करते, और वह credible लगेगा। मैंने इसे 10 seconds पहले बना दिया। |
| Logical gap | Conclusion stated premises से सच में follow नहीं करता। | "Evidence" और "therefore" के बीच का bridge. "Therefore" bracket करें और पूछें: क्या यह follow करता है, या missing link मैं supply कर रहा हूँ? |
| False confidence | Uncertain information को certain tone में state करना। | सबसे fluent paragraphs. Hedging language ("may," "could") signal है कि AI जानता है वह thin ice पर है; contested topic पर उसका absence red flag है। |
| Missing context | Crucial factor omit किया गया जो analysis बदल देगा। | आपका subject-matter expert सबसे पहले जो पूछेगा। अगर आप पूछेंगे, "रुकिए, X consider किया?", तो AI ने शायद नहीं किया। |
| Fabricated source | Citation, library function, या API जो exist नहीं करती, या exist करती है लेकिन वह नहीं कहती जो AI ने claim किया। | हर citation, हर quoted statistic, हर external function call. Forward या run करने से पहले verify करें। |
| Stale fact | कभी true था, अब true नहीं। | Time-sensitive चीज़ें: prices, leadership, laws, API versions, tool की capabilities itself. |
Real documents पर हर type को name से scan करें। नीचे exercise में हम 2 named scans करेंगे (Factual और Fabricated Source से शुरू करें) ताकि move feel हो; full 6-row pass 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, उन्होंने 6-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 को first check बनाया। |
| 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 write-up में 6 में से 5 categories trigger हुईं। Fake Consumer Reports line वही थी जिसे वे लगभग miss कर देते, क्योंकि वह बिल्कुल वैसी लगती थी जैसी reviewer लिखेगा। Parent car देखने गए तो real mileage, belt question और true price जानते थे। उन्होंने facts के साथ negotiate किया। जो version वे लगभग forward करने वाले थे, वह उनके partner को wrong price, missed repair और ऐसी magazine का quote भेजता जिसने वह बात कभी लिखी ही नहीं।
Name से scan किए बिना वही person यह खरीदता:
| Reader habit | क्या miss होता है | यह fail क्यों होता है |
|---|---|---|
| Top-to-bottom पढ़ना, पूछते हुए "क्या यह car अच्छी लगती है?" | Specific numbers. Smooth paragraph के अंदर figures पर आँख slide कर जाती है। | 32,000-mile figure पर nod कर देना आसान है। "Factual" को name से scan करना हर number पर stop force करता है, odometer समेत। |
| Quote trust करना क्योंकि वह known brand name करता है | Consumer Reports line. Real magazine, believable claim, ऐसा note नहीं। | "Sounds credible" ही trap है। "Fabricated Source" को name से scan करना हर quote को trust करने से पहले check force करता है। |
| "therefore" को सिर्फ connecting word की तरह पढ़ना | Clean-history logical gap. "therefore" word छिपाता है कि link सच में hold करता है या नहीं। | General story पढ़ने से connecting word claim को unchecked carry कर लेता है। हर "therefore" bracket करने से link को खुद prove करना पड़ता है। |
| Missing चीज़ को तभी notice करना जब वह jump out करे | 60,000 miles पर due timing belt. वह write-up में है ही नहीं, इसलिए page पर कोई warning नहीं। | Missing context page पर flag नहीं उठाता। आपको actively पूछना पड़ता है कि mechanic क्या पूछेगा जो model नहीं पूछ सका। |
Same person, same listing, same hour. फ़र्क smarts नहीं है। फ़र्क है कि आप name से scan करते हैं या feel से।
खुद try करें
आप इस weekend used car खरीद रहे हैं। Seller के पास already दूसरा interested buyer है, इसलिए सोचने के लिए days नहीं हैं। आपने AI से shortlist की 2 cars compare करके बताने को कहा कि कौन सी खरीदें। उसने यह लिखा। इसे 6 error types से name द्वारा scan करें, Factual और Fabricated Source से start करते हुए (miss करने पर सबसे महंगी 2 categories), और नीचे grid 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.
(अगर आप work पर practice करना चाहें, surface swap करें लेकिन shape रखें: कोई भी AI-drafted document जो आपसे senior person को जाने वाला है, fluent है, named claims से भरा है जिन्हें check किया जा सकता है, और जिसे 3 बार पढ़ने का time नहीं है। Grant report, board memo, vendor quote, clinical summary. 6 types topic की परवाह नहीं करते।)
Form से पहले 1 note. नीचे का feedback frontier model (Claude Sonnet 4.5+, Opus 4.7, GPT-5, Gemini 2.5 Pro) के लिए tuned था। Smaller models अक्सर आपके paste किए scan को confirm करते हैं, जिससे exercise defeat हो जाती है।
AI यह check करेगा:
- क्या आपने name से scan किया, या feel से पढ़कर बाद में label लगा दिया? 1-10 rate करें। मेरी grid की वह row quote करें जो decide करती है। Real named scan हर row पर verdict produce करता है, even "actively scanned, found nothing." उस note के बिना blank row tell है।
- क्या आपके quoted sentences वही हैं जो wrong हों तो कौन सी car खरीदनी है यह बदलेंगे, या आपने easy lines flag कीं? 1-10 rate करें। जिस row में मैंने sentence quote किया है, उसी write-up से 1 stronger candidate name करें (अगर mine contains one) जो मुझे पहले पकड़ना चाहिए था।
मेरे काम को rewrite न करें। Writing style पर grade न करें। अगर कोई row "actively scanned, none found" note के बिना empty है, तो 1 line में साफ़ कहें।
आपका 6-row scan grid (हर row में exact AI sentence quote करें; row blank सिर्फ तब छोड़ें जब आपने actively scan करके कुछ नहीं पाया, और उस row में "actively scanned, none found" लिखें):
हर row पर आपका confidence (हर error type पर 1-10; why पर 1 sentence):
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार 8-15 minutes plan करें। उसके बाद faster. AI feedback के साथ सबसे useful चीज़: ऐसी 1 जगह खोजें जहाँ AI आपके scan से disagree करता है। वही disagreement है जहाँ आपके judgment का अगला round बनता है।
जो आपने अभी किया, वह आपके पास मौजूद output में local errors पकड़ता है। जो यह नहीं पकड़ता: आपके output से downstream trigger होने वाले second-order effects, जैसे recommendation land होने पर morale hit, policy ship होने पर customer behavior change, वह loop जहाँ cost savings से service quality drop होती है और customers leave करते हैं। वह cascade map है, Discipline 4.
Compare करने के लिए strong sample चाहिए? (अपना submit करने के बाद खोलें।)
Used-car scenario चलाने वाले reader ने यह grid produce की। यह अकेला good answer नहीं है; बस shape दिखाता है।
| Error type | AI write-up से quoted sentence | यह category क्यों trigger करती है |
|---|---|---|
| Factual error | "The Corolla gets 47 mpg combined." | Specific number जिसे check किया जा सकता है। उस Corolla की real combined rating लगभग 33 mpg है। Figure simply wrong है, और cost math बदलता है। |
| Logical gap | "The Civic has lower mileage, therefore it is the more reliable choice." | "Therefore" low miles को reliability का proof treat करता है। Lower mileage help करता है, लेकिन अपने आप car को more reliable नहीं बनाता। Link asserted है, shown नहीं। |
| False confidence | "Either car will run for another decade without a major repair." | No "should," no "likely," no condition. Used car के future पर flat promise fact की तरह dressed guess है। Missing hedge red flag है। |
| Missing context | (Write-up से missing.) 2019 Civic model-year पर open airbag recall है। | Page पर न होना ही इस row का point है। आप scan करते हैं कि क्या नहीं है। Safety recall खरीदने से पहले exactly named चाहिए, और model ने नहीं कहा। |
| Fabricated source | "According to the CarReliability Index 2026 rankings, the Corolla scores 9.4 out of 10." | Confident, specific, और made up. "CarReliability Index" नहीं है। ऐसा named source जो मिल न सके, वही failure है जिसे यह row पकड़ती है। |
| Stale fact | "Both still qualify for the $2,000 state clean-vehicle rebate." | कभी true था, अब नहीं। Rebate 2025 में expire हो चुका है। Price, law, या deadline से tied anything stale होता है, इसलिए named check पाता है। |
जो इसे काम कराता है: हर row में verdict है, और हर quoted line सच में change करेगी कि कौन सी car खरीदनी है। ये throwaway picks नहीं हैं। Missing Context row act करने लायक specific है (named model-year, named recall). Fabricated Source row exact sentence quote करती है और बताती है कि fail क्यों है (ऐसा index exist नहीं करता)।
यह क्या करने की कोशिश नहीं करता: exhaustive होना। Taxonomy scan है, audit नहीं। 15 minutes में 6 rows target है। 30 performative catches से 3 real catches better हैं।
अगर इस move के नीचे की cognitive science चाहिए (click to expand)
Taxonomy, confident prose scrutiny को कैसे disarm करता है इस पर पुराने work का 2026 application है।
- Alter, A. L. & Oppenheimer, D. M. (2009). "Uniting the tribes of fluency to form a metacognitive nation." Personality and Social Psychology Review 13(3), 219-235. Processing fluency का canonical review: fluent, easy-to-process information को actual accuracy से independent ज़्यादा credible judge किया जाता है। (Popular treatment के लिए देखें Kahneman, D. (2011). Thinking, Fast and Slow, Chapter 5: "Cognitive Ease." Farrar, Straus and Giroux.) Polished AI prose उस effect का modern industrial-scale version है। Named category से scan करना ease-equals-truth shortcut interrupt करता है, क्योंकि reader को credibility की overall vibe के बजाय specific failure shapes खोजने पड़ते हैं।
- Silver, N. (2012). The Signal and the Noise: Why So Many Predictions Fail, but Some Don't. Penguin Press. Silver का central argument है कि confidence और calibration independent traits हैं। जो forecasters सबसे certain sound करते हैं, वे routinely least calibrated होते हैं, और pattern pundits, models और अब generative AI में repeat होता है। Taxonomy की False Confidence row, AI output के लिए उसकी thesis का operationalization है।
- Gigerenzer, G. (2002). Calculated Risks: How to Know When Numbers Deceive You. Simon & Schuster. (UK में Reckoning with Risk के रूप में published.) Gigerenzer के calibration work ने subjective confidence और observed accuracy के gap को formalize किया, और दिखाया कि calibration तब improve होती है जब forecasters written predictions commit करते हैं और outcomes against check करते हैं। Error-taxonomy scan, AI के लिए equivalent है: यह आपको draft as a whole accept करने के बजाय हर category पर verdict commit करने को force करता है। Academic foundation के लिए देखें Gigerenzer, G., Hoffrage, U. & Kleinbölting, H. (1991). "Probabilistic mental models: A Brunswikian theory of confidence." Psychological Review 98(4), 506-528.
Named taxonomy AI-error detection को specifically कितना improve करती है, यह measure करने वाला कोई single trial नहीं है। Cognitive pattern well-studied है; AI output पर application obvious extension है।
Go deeper: Part 0 Chapter 2: Detecting Broken Reasoning. Full version (8-category taxonomy, dual-AI cross-check, prediction-vs-actual calibration; 60-75 min) इसे system बनाता है।
Discipline 4: Thinking in Systems
1 paragraph में: decision के बारे में पूछने पर ज़्यादातर AI tools effects की list देते हैं। जो वे miss करते हैं, वे feedback loops हैं, जहाँ effects circle back करके original decision को amplify या undo करते हैं। Cascade Map consequences को multiple stakeholder groups में trace करता है और clean answer ship करने से पहले आपसे कम से कम 1 loop name करवाता है।
Trap आप जानते हैं। आपने AI से staffing change analyze करने को कहा, answer clean आया, 3 bullet points और crisp recommendation. आपने उसी afternoon ship कर दिया।
3 months बाद next-door team का morale collapse हो गया, 2 clients आपके group को route around करने लगे, displaced work quietly लेने वाला manager burn out हो गया, और जब leadership ने पूछा कि क्या हुआ, आप explain नहीं कर सके। First-order answer correct था। Second-order effects ने उसे खा लिया। Third-order effects वही हैं जो अभी भी room में हैं।
Fix यह है। पहली बार 20 minutes, बाद में 10. Meeting लायक किसी भी decision पर AI खोलने से पहले 5 lines draw करें।
- Decision center में। 1 sentence, no hedging. "Consider raising prices" नहीं, बल्कि "raise list prices 18% on new contracts starting next quarter."
- 5 domains outward spokes में। Employees, customers, competitors, regulators, internal knowledge. हर domain की 1 branch.
- हर domain में 3 "and then what?" layers. First-order effect. फिर उस effect का consequence. फिर उस consequence का consequence.
- कम से कम 1 feedback loop name करें। वह जगह खोजें जहाँ downstream effect circle back करके original decision बदलता है। Mechanism state करें, label नहीं। "Customers leave" नहीं, बल्कि "customers leave क्योंकि new automated tier human तक नहीं पहुँच सकता, जबकि previous provider 10 seconds में पहुँचाता था।"
- तभी finish करें जब map messy लगे। अगर neat है, तो आपने बहुत जल्दी stop किया। ज़्यादातर strategic disasters वे loops हैं जिन्हें किसी ने map नहीं किया।
इस drawing को Cascade Map कहा जाता है। Point future predict करना नहीं है। Point है clean answer ship करने से इंकार करना।
AI वह variable optimize करता है जिसके बारे में आपने पूछा; वह उन 3 variables के बारे में reason नहीं करता जिन्हें वह variable disturb करता है। Humans breadth miss करते हैं (दूसरा domain, वह stakeholder जिसे आपने name नहीं किया)। AI loops miss करता है (वह feedback जो 6 months बाद circle back करके gain unwind करता है)। Blind spots complementary हैं। इसलिए map पहले draw करते हैं और फिर branches stress-test करने के लिए AI लाते हैं।
Meeting लायक real decision पर map 20-30 minutes ले सकता है। नीचे की exercise smaller scope use करती है ताकि muscle feel हो।
5 domains, consequence की 3 layers, 1 named feedback loop. Mess feature है, bug नहीं।
Real life में यह कैसा दिखता है।
एक city planner के पास 6-week window थी कि downtown commercial corridor के 2.3-mile हिस्से पर protected bike lanes add करने की recommendation दे या नहीं। First-order case clean था: bike lanes से ज़्यादा लोग driving के बजाय cycling करेंगे, emissions lower होंगे, cyclist injuries कम होंगी। Corridor का cyclist-injury rate city average का 2x था। Advocacy coalition organized और patient थी। AI ने cheerfully case validate कर दिया।
Memo forward करने से पहले उसने cascade map draw किया। Central decision: install protected bike lanes; remove one vehicle lane each direction; remove 40% of curbside parking. 5 domains में 3 layers. ज़्यादातर second-order effects predictable थे (cyclists happy, drivers grumpy, कुछ parking displacement)। Third layer ने recommendation को खोल दिया।
Named loop वही था जिसने memo बदल दिया: corridor businesses weekend visitor revenue खोते हैं, local tax base shrink होता है, council pressure बढ़ता है, next session में policy weak होती है, cycling instead of driving का original gain erode होता है, और town के next corridor का case मर जाता है। इस corridor को करने का पूरा reason अगले 10 corridors का case जीतना था।
उसने project kill नहीं किया। उसने 12-month loading-zone trial, guaranteed bus-stop redesign budget, quarterly revenue threshold (>15% sustained drop triggers revisit), और transit agency के साथ bus-stop access पर written agreement add किया। वह version council में 7-2 survive कर गया। Clean AI version में इनमें से कोई provision नहीं था, और अलग city में colleague की similar recommendation (no cascade, no provisions) 14 months के अंदर repeal हो गई।
| Domain | 1st-order | 2nd-order | 3rd-order |
|---|---|---|---|
| Employees | Public-works curbs repaint करता है | Loading conflicts cover करने के लिए parking enforcement budget बढ़ता है | Relocated stops पर buses cleanly pull नहीं कर पातीं, transit drivers grievance file करते हैं |
| Customers | Cyclists को protected route मिलता है | Delivery drivers bike lane में double-park करते हैं | Corridor businesses weekend revenue dip देखते हैं; 3 relocation threaten करते हैं |
| Competitors | Adjacent corridor car-friendly रहता है | वह corridor threatened businesses को court करता है | 18 months में tax base neighborhood shift करता है |
| Regulators | State transport-grant terms apply होते हैं | Disability-access review bus-stop curb cuts flag करता है | Required fixes timeline 6 months push करती हैं और cost add करती हैं |
| Internal knowledge | Driving-vs-cycling shift पर old study (3 yrs) | Assumptions stale हैं; weekend traffic pattern shift हो गया | Planning dept forecast refresh के बिना defend नहीं कर पाता |
Named loop: corridor revenue loss → tax-base reduction → council pressure → next session में policy weakened → cycling-vs-driving gains erode → defenders next corridor का case lose करते हैं। यही loop recommendation में teeth जोड़ने की वजह है।
Cascade के बिना वही person कुछ ऐसा लिखता है:
| Domain | 1st-order | यह fail क्यों होता है |
|---|---|---|
| Cyclists | Safer rides | 1 domain, 1 layer. No loop. Delivery-driver double-parking dynamic entirely miss हो गया। |
| Emissions | Lower CO2 per mile | Metric, stakeholder नहीं। Corridor-business revenue loop और council feedback miss. Mechanism named नहीं, बस outcome asserted. |
Same person, same hour. फ़र्क smarts नहीं है। फ़र्क है कि आपने messy map किया या clean ship किया।
खुद try करें
आप 200-person HR software company में head of revenue हैं (yearly revenue लगभग $32M; 280 customers, जिनमें top 20 revenue का 55% produce करते हैं; 18-month average contract length; 11-week average sales cycle; last quarter existing customers ने year before से लगभग 8% ज़्यादा spend किया)। Next quarter, leadership सभी new contracts पर sticker prices 18% raise करना चाहती है और salespeople जो discounts offer कर सकते हैं उन्हें 0-to-30% range से घटाकर 0-to-15% करना चाहती है। आप decision-recommender हैं। Thursday के leadership read-out से पहले इस pricing change को cascade करें। 5 domains directly apply होते हैं: salespeople (currently sales target का 74% hit कर रहे हैं), existing customers जिनकी renewal next 6 months में है, 2 named competitors (1 slightly cheaper, 1 slightly more expensive but stronger reporting), आपके top accounts की buying teams (ज़्यादातर हर साल formal bidding process run करती हैं), और आपकी अपनी sales materials.
(अगर pricing आपका काम नहीं है, surface swap करें लेकिन shape रखें: ऐसा leadership decision जो कई groups को एक साथ affect करता है, real deadline है, और कम से कम 1 जगह है जहाँ second-order effects first-order outcome में वापस feed करते हैं। या इस week का real decision pull करें। वही इसे stick कराता है।)
Form से पहले 1 note. नीचे का feedback frontier model (Claude Sonnet 4.5+, Opus 4.7, GPT-5, Gemini 2.5 Pro) के लिए tuned था। Smaller models input quality जैसी भी हो, अक्सर handwave करते हैं।
AI यह check करेगा:
- क्या आपका map 5 domains wide और 3 layers deep गया, हर link पर mechanism (label नहीं) के साथ? 1-10 rate करें। Thinnest domain name करें और उसमें 1 specific effect जो मैंने miss किया।
- क्या आपका feedback loop real loop है, जिसमें mechanism causal sentence की तरह stated है? 1-10 rate करें। अगर loop सिर्फ label है ("regulators react"), उसे flag करें और 1 additional loop propose करें जिसे मैंने name नहीं किया, mechanism written out के साथ ("regulators react" नहीं, बल्कि "regulators react because X triggers Y which forces Z").
मेरा map redraw न करें। Style पर rate न करें। अगर field empty या vague है, 1 line में साफ़ कहें।
आपका cascade map (central decision, फिर 5 domains x 3 layers; rough text fine है, बस structure visible रखें):
आपका feedback loop, 1 causal sentence की तरह stated (label नहीं):
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार 15-20 minutes plan करें। Cascade maps, Prediction Lock से longer चलते हैं क्योंकि value messy middle layers में है, और पहले 3 या 4 "and then what?" questions forced feel होते हैं, real ones surface होने से पहले। Fourth या fifth आमतौर पर वह जगह है जहाँ third-order effect सच में matter करता है। Muscle बन जाने पर faster; experienced cascaders full map 8 से 12 minutes में run करते हैं।
AI feedback के साथ सबसे useful चीज़: वह 1 जगह खोजें जहाँ AI ने ऐसा domain add किया जिसे आपने miss किया। वही आपका blind spot है, और यही इस week का सबसे cheap lesson होगा। अगर AI ने ऐसा loop add किया जिसे आपने miss किया, उसे separate find mark करें। Loops move-the-needle होते हैं क्योंकि वे बताते हैं कि announced decision (18% sticker-price increase) world में कुछ काफी अलग की तरह show up होगा (customers जो actual price pay करते हैं उसमें 4-6% increase).
जो आपने अभी किया, वह existing plan के second- और third-order effects stress-test करता है। जो यह नहीं करता: यह question नहीं करता कि plan सही assumptions पर rested है या नहीं।
Wrong premise पर built perfectly cascaded plan भी wall hit करता है, बस बाद में और better documentation के साथ। यही Discipline 5 है।
Compare करने के लिए strong sample चाहिए? (अपना submit करने के बाद खोलें।)
Pricing scenario चलाने वाले reader ने यह लिखा। यह अकेला good answer नहीं है; shape दिखाता है।
Central decision: Q3 से effective new contracts पर sticker prices 18% raise करें; salespeople जो discount levels offer कर सकते हैं उन्हें 7 से घटाकर 4 करें।
| Domain | 1st-order | 2nd-order | 3rd-order |
|---|---|---|---|
| Salespeople | Mid-quarter sales-target math hard हो जाता है | Salespeople smaller deals पर concentrate करते हैं जहाँ discount approval faster है | Big accounts पर new leads slow; deal mix, किसी ने decide किए बिना, smaller customers की ओर drift करता है |
| Renewal customers | Renewal price new sticker price against judge होता है | Buying teams 3 top accounts में best-price-guarantee clauses reopen करती हैं | 2 largest accounts multi-year freezes negotiate करते हैं जो new sticker price से below lock-in करते हैं |
| Competitors | Competitor A hold करता है, Competitor B undercut करता है | Competitor B हमारे top 50 prospects को directly reach out करना start करता है | Competitive deals पर win rate 8-12 pts drop; customer जीतने की cost earn back करने का time full quarter stretch करता है |
| Buying teams | Approval workflow finance gate add करता है | Deal cycle average 11-18 days extend होती है | Q3 forecast सिर्फ deal-cycle slippage से miss होता है, किसी won-loss effect से पहले |
| Sales materials | Old pricing sheets अभी भी sales-tracking tools में saved हैं | Salespeople transition के दौरान 2-3 weeks stale prices quote करते हैं | कुछ contracts old price पर sign हो जाते हैं; legal flag करता है कि honor करें या renegotiate |
Named loop: New sticker price के तहत sales-target pressure, flagship deals पर deeper one-off discounts push करता है, जो buying teams के reference checks के through customers की renewal price expectations में leak होता है, जिससे real price sticker price से नीचे push होता है, यानी headline 18% increase customers की actual payment में 4-6% increase जैसा show up होता है, जो next year another pricing review trigger करता है जिसे lead करने की credibility team अब खो चुकी है।
जो इसे काम कराता है: 5 real domains, न कि 3 domains और 2 metrics tack on.
हर chain mechanism name करती है, सिर्फ outcome नहीं ("buying teams re-open best-price-guarantee clauses" न कि "buying teams react"). Loop सच में loop है: effect circle back करके original decision बदलता है (announced 18%, customers की actual payment में 4-6% increase बन जाता है)।
Map इतना messy है कि reader loading-zone-equivalent साफ़ देख सका: announced increase और customers की actual payment में increase के बीच का gap, जिसे leadership read-out में किसी ने name नहीं किया था।
यह क्या करने की कोशिश नहीं करता: exhaustive होना। इस scenario में कम से कम 3 और loops हैं (resellers के partners की margin, competitor price के पास वाले customers migrate करना, और renewal-cycle timing). Discipline है 1 real loop को real mechanism के साथ name करना, first map पर सब कुछ name करना नहीं।
अगर आपका map इससे ज़्यादा tidy दिखता है, तो signal यही है: अपने 2 weakest domains में 1 और "and then what?" deeper जाएँ और loop के लिए फिर देखें।
अगर इस move के नीचे की cognitive science चाहिए (click to expand)
किसी analyst (human या AI) से consult करने से पहले decision map करना well-studied move है। यह AI से decades पुराना है।
Cascade Map 2 lineages के intersection पर बैठता है: stakeholder breadth (Meadows, Sterman) और feedback-loop depth (Forrester). 5-domain spoke पहला enforce करता है; named-loop requirement दूसरा।
- Meadows, D. (2008). Thinking in Systems: A Primer. Chelsea Green. Canonical short text. Meadows का argument: किसी भी system में highest-leverage interventions लगभग कभी वे variables नहीं होते जिन पर managers obsess करते हैं। वे feedback loops और उन्हें govern करने वाले rules होते हैं, जिन्हें ज़्यादातर analyses name नहीं करते। Cascade Map उस argument का second half enforce करता है: जिस loop को आपने name नहीं किया, उस पर intervene नहीं कर सकते।
- Forrester, J. W. (1958). "Industrial Dynamics: A Major Breakthrough for Decision Makers." Harvard Business Review 36(4), 37-66. System dynamics का foundational paper. Forrester की industrial-supply studies ने दिखाया कि linear cause-and-effect reasoning operators को उन loops से blind कर देता है जो long-run behavior drive करते हैं। Bullwhip effect (बाद में Lee, H. L., Padmanabhan, V. & Whang, S. (1997). "The bullwhip effect in supply chains." MIT Sloan Management Review 38(3), 93-102 में formalized) सबसे famous example है; underlying point किसी भी multi-stakeholder decision पर generalize होता है।
- Sterman, J. (2000). Business Dynamics: Systems Thinking and Modeling for a Complex World. Irwin McGraw-Hill. Management decisions पर applied Meadows/Forrester lineage का textbook treatment. Sterman का empirical work (especially Beer Game) दिखाता है कि smart, motivated decision-makers भी loops miss करते हैं जब उन्हें draw करने के लिए force नहीं किया जाता। Cascade Map 5-minute forced-draw version है।
AI specifically के against Cascade Map test करने वाला कोई single trial नहीं है। Mechanism (humans breadth miss करते हैं, AI loops miss करता है, map draw करना दोनों gaps close करता है) extension है; underlying body of work established है।
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 नहीं कर सकता वह करना)
Foundations ने posture दिया। Detection ने AI के misses पकड़ने की training दी। Origination तीसरा arc है, और वह अलग question का answer देता है: कौन सा काम आपका है क्योंकि AI structurally उसे नहीं कर सकता? यहाँ 2 failure modes रहते हैं। पहला consensus drift: AI अपने training data का average answer वापस देता है, और आप उस average को test किए बिना ship कर देते हैं कि वह आपकी specific situation पर fit होता है या नहीं। दूसरा oracle reflex: आप judgment उस tool को outsource करना शुरू कर देते हैं जिसके पास अपना judgment है ही नहीं। Disciplines 5 और 6 दोनों gaps close करते हैं।
एक phrase Discipline 5 को carry करता है और इस part में कुछ बार आएगा: named threshold. Named threshold number, count, specific state, या named condition है जो बताता है कि कोई advice कब true होना बंद करती है। "जब team size 20 engineers से below हो" named threshold है। "Sometimes" नहीं। Phrase पकड़े रखें। एक minute में use करेंगे।
Discipline 5: First Principles
आप ऐसी software company चलाते हैं जो 1 industry को serve करती है। 3 competitors ने 1 quarter के अंदर prices 12% raise किए हैं। आपका board, 3 investors में से 2 और head of finance same line push करते हैं: move match करें, margin capture करें, wave ride करें। दूसरी company का CEO friend coffee पर वही कहता है। आप Claude खोलकर पूछते हैं। Summary agree करती है। Conversation के 5 days बाद आपको मिला हर signal same दिशा में point करता है।
यही convergence failure mode है। Consensus अपना काम कर रहा है (आपको obvious answer की ओर खींच रहा है) और obvious answer किसी और की company में, किसी और market में सही है। AI chorus की last और loudest voice है क्योंकि यह उन सभी पर average करता है जिन्होंने कभी pricing strategy पर लिखा। यह आपको नहीं बता सकता कि chorus आपकी situation पर कहाँ apply होना बंद करता है।
Move 1 beat में यह है। SaaS founder का इस consensus पर boundary लिखने का पहला attempt देखें: "Sometimes the competitive set is a bad reason to raise." यह gripe है। यह "sometimes" use करके disagree करता है, बिना यह कहे कि कब। वह वापस गया, अपनी situation में सच में क्या different था trace किया, और rewrite किया: "When competitors are reacting to a cost shock we've already protected ourselves against (we locked a multi-year infrastructure contract last year, so our costs didn't move), matching their hike sends a signal of weakness we don't actually have." Rewrite threshold name करता है (locked contract का existence), mechanism name करता है (signaling), और ऐसे decision की ओर point करता है जिसे consensus नहीं देखता। वह gap, gripe से threshold तक, पूरी discipline है।
Fix यह है। जिस consensus को follow करने को कहा जा रहा है, उसे चुनें। 3 rows लिखें। हर row specific condition name करती है जिसके तहत consensus काम करना बंद करता है, और उसे named threshold (number, count, specific state) वाले mechanism से trace करती है। अगर आप thresholds के साथ 3 rows तक नहीं पहुँच सकते, तो आप consensus follow कर रहे थे बिना उसे समझे।
| जिस consensus को आप examine कर रहे हैं | जहाँ यह काम करना बंद करता है, named threshold के साथ |
|---|---|
Threshold वाली row ("जब team size ~20 engineers से below हो, microservices coordination cost deploy-isolation benefit से ऊपर चली जाती है") boundary है। बिना threshold वाली row ("microservices sometimes wrong हैं") gripe है। Gripes decisions नहीं बदलते; thresholds बदलते हैं।
हर consensus की boundaries होती हैं। Exercise उन boundaries पर intentionally चलती है, bad decision उन्हें आपके लिए खोजे उससे पहले।
Full output कैसा दिखता है।
ऊपर वाले SaaS founder ने 1 sitting में 3 perfect rows नहीं लिखीं। करीब 90 minutes revision के बाद उसके पास यह था:
| Consensus: "Always match competitor price hikes." |
|---|
| Boundary 1. जब growth की real limit existing customers रखना हो (new ones जीतना नहीं), price hike के बाद customers leaving का हर percentage point long-term value में increase से ज़्यादा cost करता है, especially जब customers के लिए switch करना easy हो रहा हो (named threshold: new data-portability rules जिनसे switching prior decade की तुलना में easier हो गई है). |
| Boundary 2. जब competitor moves ऐसे cost shock पर reactive हों जिससे आपने already protect कर लिया है (आपने last year multi-year infrastructure contract lock किया, इसलिए costs move नहीं हुईं), तो उनकी hike match करना ऐसी weakness signal करता है जो आपके पास actually नहीं है। Named threshold locked contract का existence है। |
| Boundary 3. जब competitors merge और consolidate कर रहे हों, price hold करना positioning move है जो competitors की renewal lists से accounts खींचता है, और आप उन accounts को almost no cost पर win करते हैं क्योंकि वे already shopping around कर रहे होते हैं। Named threshold competitor-renewal window (~90 days out) है। |
उसने 3 boundaries board में रखीं। उन्होंने price hold किया। 6 months बाद existing customers year before से लगभग 4 points ज़्यादा spend कर रहे थे और उसने 3 accounts competitors की renewal lists से no cost पर जीत लिए थे। Consensus brief में 3 में से कोई boundary नहीं थी। AI की first summary में भी नहीं।
Named-threshold discipline के बिना वही founder, same hour में:
| Consensus: "Always match competitor price hikes." | यह fail क्यों होता है |
|---|---|
| Sometimes you shouldn't raise because customers will leave. | No threshold. "Sometimes" gripe है; जिस boundary की ओर यह point करता है वह 1% customers leave पर trigger हो सकती है या 30% पर। Consensus से indistinguishable. |
| Competitors don't always know what they're doing. | Competitors पर complaint है, practice की boundary नहीं। कोई decision नहीं बदलता। |
| It depends on the situation. | Row नहीं। "Context matters" restate करना यह नहीं बताता कि context कहाँ matter करता है। |
Same person, same hour, same situation. फ़र्क intelligence नहीं है। फ़र्क है कि आपने named threshold require किया या "it depends" accept किया।
खुद try करें
आप 35-person professional services firm के COO हैं (boutique strategy consulting; 12 senior consultants $350-$450/hr bill करते हैं, 3 partners, $14M annual revenue, 4 active practice areas). Key role (5th practice area lead करने वाला senior consultant, focused on hands-on AI-assisted delivery, month 18 तक annual revenue में ~$3M add करने का projection) 5 months से open है। 2 strong-on-paper candidates इस week other offers लेने वाले हैं। पूरी leadership team "hire slow, fire fast" को obviously correct मानती है (old founder-playbook line जिसका मतलब: hires पर time लें, लेकिन hire working न हो तो जल्दी cut करें)। आपका job: Friday की leadership meeting से पहले "hire slow, fire fast" की boundary walk करें। 3 rows लिखें।
(अगर hiring आपका काम नहीं है, consensus swap करें लेकिन move रखें: अपने domain में कोई widely-accepted best practice चुनें जिसे कोई बार-बार quote कर रहा है, और boundary खोजें। Discipline same है।)
Form से पहले 1 note. नीचे का feedback frontier model (Claude Sonnet 4.5+, Opus 4.7, GPT-5, Gemini 2.5 Pro) के लिए tuned था। Smaller models threshold check पर handwave करते हैं।
शुरू करने से पहले threshold checklist. Threshold number, count, specific state, या named condition है। "Sometimes," "often," और "it depends" thresholds नहीं हैं।
इस exercise का bold rule: अगर third row नहीं आ रही, तो जो consensus आपने चुना है उसे आप समझे बिना follow करते रहे हैं। Third row pad करने के बजाय different consensus चुनें। यह खुद finding है।
AI यह check करेगा:
- क्या हर row threshold name करती है (number, count, state, या specific condition)? 1-10 rate करें। Weakest row का threshold quote करें (या वह row जिसमें threshold नहीं है)।
- क्या हर row principle-based है (ऐसा mechanism जो same situation वाली companies across hold करता है) या example-based (एक company की story rule की तरह dressed up)? 1-10 rate करें। ऐसी किसी row को flag करें जो boundary के बजाय gripe है।
मेरी rows rewrite न करें। Personality पर grade न करें। अगर row empty या vague है, 1 line में साफ़ कहें।
जिस consensus practice को मैं examine कर रहा हूँ (1 sentence):
Boundary row 1 (specific condition + named threshold + mechanism):
Boundary row 2:
Boundary row 3:
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
पहली बार 15-25 minutes plan करें। D1 lock से slow है क्योंकि thresholds hard हैं। AI feedback के साथ सबसे useful चीज़: ऐसी 1 row खोजें जहाँ आपने "sometimes" या "it depends" लिखा, और उस row को specific threshold के साथ rewrite करें। वही rewrite है जहाँ discipline रहती है। अगर rewrite नहीं कर सकते, तो row शायद boundary नहीं है; उसे drop या replace करें।
जो आपने अभी किया, वह 1 practice की boundary खोजता है। जो यह नहीं करता: ऐसे problem पर AI के साथ collaborate करने में help जहाँ challenge करने के लिए obvious consensus न हो। वह Discipline 6 है।
Compare करने के लिए strong sample चाहिए? (अपना submit करने के बाद खोलें।)
"Hire slow, fire fast" scenario चलाने वाले reader ने यह लिखा। यह अकेला good answer नहीं है; यह अलग domain में thresholds का shape दिखाता है।
| Consensus: "Hire slow, fire fast." |
|---|
| Boundary 1. Small founder-led teams में (named threshold: under ~40 people), "slow" hiring quietly "no" hiring बन जाती है क्योंकि founder हर loop पर bottleneck होता है। Mechanism: हर additional interview round वह founder time खाता है जो shipping में जाना चाहिए था। Company कभी उस scale तक पहुँचती ही नहीं जहाँ "fast firing" वह corrective lever बन सके जिसका practice promise करता है। |
| Boundary 2. जब role 2 replacement cycles से longer open हो (named threshold: 4+ months), और "slow" careful नहीं रहता, careful दिखने की appearance बन जाता है। Mechanism: missing person का work week after week pile up होता है, और team ऐसा debt लेती है जिसे later fast-firing recover नहीं कर सकती। 4 months से आगे slowness, hiring discipline के रूप में dressed hiring inaction है। |
| Boundary 3. High-trust services markets में (named threshold: जब client tenure average 24+ months हो), "fast firing" वही trust relationships tear कर देता है जिनके लिए client ने firm hire की। Mechanism: clients partly firm में मौजूद लोगों के साथ काम करने के लिए hire करते हैं; senior staff को fast rotate करना implicit asset destroy करता है। Wrong hire की cost real है, लेकिन fast fire की cost कभी-कभी higher होती है। |
जो इसे काम कराता है: हर row threshold name करती है (40 people, 4 months, 24-month client tenure). हर boundary ऐसा mechanism point करती है जो same shape वाली किसी भी company पर hold कर सकता है, सिर्फ इस 1 पर नहीं। Third boundary strongest है क्योंकि practice को qualify नहीं, invert करती है।
यह क्या करने की कोशिश नहीं करता: brilliant होना। Mechanisms बस plausible हैं। Discipline thresholds में है, prose में नहीं।
अगर इस move के नीचे की cognitive science चाहिए (click to expand)
Consensus की boundary walk करना AI version से बहुत पुराना है।
- Gigerenzer, G., Todd, P. M. & the ABC Research Group (1999). Simple Heuristics That Make Us Smart. Oxford University Press. Closest direct ancestor. Team का ecological rationality framework हर heuristic (including "best practice") को ऐसे tool की तरह frame करता है जिसकी accuracy उस environment पर depend करती है जहाँ वह apply होता है। Practitioner का job है environment इतना जानना कि वह जान सके heuristic कहाँ ecologically valid होना बंद करता है। इस exercise की named-threshold requirement operational ecological rationality है।
- Klein, G. (1998). Sources of Power. Klein का Recognition-Primed Decision model दिखाता है कि experts पहले plausible script पर pattern-match करके run कर देते हैं। Defend the Opposite move उस pattern-match का deliberate interruption है: जिन conditions में script fail होता है उन्हें लिखने के लिए खुद को force करके आप boundary visible बनाते हैं, pattern-match run होने से पहले।
- Popper, K. (1959 English / 1934 German). The Logic of Scientific Discovery. Popper की falsifiability originally science को non-science से अलग करने वाला demarcation criterion था, meaning theory नहीं। यहाँ relevant move narrower है: claim operationally useful तभी है जब आप conditions state कर सकें जिनके तहत आप उसे abandon करेंगे। Named-threshold column boundary को stateable बनाता है।
AI specifically के लिए Defend the Opposite move test करने वाला कोई single trial नहीं है। Mechanism (practice accept करने से पहले boundary require करना) well-studied है; उसे AI के averaged-over-training-data answers पर apply करना obvious extension है, separately validated finding नहीं।
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 min) Part 0 में है। यह page row shape सिखाता है। वह page longform argument सिखाता है।
Discipline 6: Working WITH AI
आपने morning Claude के साथ strategy memo पर iterate करते हुए बिताई। Output polished है। Framing tight है। Numbers line up हैं। फिर CEO आपके shoulder के ऊपर से पढ़ता है और पूछता है, "आप यहाँ क्यों landed और दूसरे option पर क्यों नहीं?" आप mouth open करते हैं और realize करते हैं कि अपने judgment को model के judgment से अलग कर ही नहीं पा रहे। कुछ sentences आपके हैं। कुछ model के। ज़्यादातर blur हैं। Memo अच्छा है। बस आप नहीं जानते कि उसके कौन से parts defend कर सकते हैं।
Fix यह है। Board meeting लायक real memo पर, same task timed constraints में 3 ways run करें। फिर तीनों side by side पढ़ें।
- Solo. 45 minutes, no AI. बस आप और problem.
- AI-only. 20 minutes. आप prompt करते हैं, AI answer करता है, आप first response no edits accept करते हैं।
- Collaborative. 30 minutes. आप prompt करते हैं, evaluate करते हैं, push back करते हैं, override करते हैं, iterate करते हैं। AI as partner जो push back करता है, oracle नहीं।
हर draft को 4 axes पर rate करें: depth, breadth, originality, time-to-value. Collaborative version आमतौर पर wins, लेकिन win useful तभी है जब आप specific overrides point कर सकें जिन्होंने उसे win कराया। यही Three-Path Comparison है। Locked क्योंकि comparison diagnostic है, drafts themselves नहीं।
Board meeting लायक real memo पर full 95-minute comparison discipline है। नीचे की exercise में 10-minute on-ramp version (3-min Solo, 2-min AI-only, 5-min Collaborative, short email पर) आज करने लायक fast तरीके से felt difference सिखाता है।
Comparison ही वह तरीका है जिससे आप देखते हैं कि आपका judgment कहाँ irreplaceable है। Side-by-side के बिना, आप नहीं बता सकते कि आपने collaborate किया या surrender।
Real life में यह कैसा दिखता है।
एक medical-practice owner 14-provider primary-care group चलाती थी और partners के लिए 2-page memo लिखना था: largest regional insurer के साथ ऐसे contract पर shift propose करना जो practice को per visit pay करने के बजाय patients को healthy रखने के लिए pay करे। 3-year revenue implications. Culture component. Operational lift जो हर clinician को touch करता। Send करने से पहले उसने collaboration posture test करने का decide किया, इसलिए same task 3 ways run किया।
Solo, 45 minutes. उसने careful memo draft किया जो उन operational risks में grounded था जिन्हें वह best जानती थी। Specific, defensive और honest. लेकिन strongest financial point page 2 पर bury हो गया, और उसने उस partner को address नहीं किया जो पिछले 2 years से practice gets paid कैसे होता है इसमें हर change openly oppose कर चुका था। उसे gap पता था। Meeting से पहले उसे close करने का time नहीं था।
AI-only, 20 minutes. उसने model को brief दिया और first response no edits accept किया। Draft polished और structurally clean था। यह generic "benefits of getting paid for keeping patients healthy" framing से open हुआ, exactly वही framing जिसे 3 competing practices previous quarter use कर चुकी थीं। उसने कोई partner name नहीं किया। Market-specific कोई risk cite नहीं किया। यह industry brochure जैसा पढ़ा।
Collaborative, 30 minutes. उसने structural argument खुद लिखा, 3 financial assumptions name किए जिन पर पूरा memo rested था, और model से opposing partner के perspective से strongest counter-argument surface करने को कहा। Model ने एक objection propose किया जिसकी उसने anticipation नहीं की थी, और उसने memo rewrite करके उसे head-on address किया। उसने model से executive summary भी माँगी; model version ने ask soften कर दिया, इसलिए उसने वह paragraph rewrite किया क्योंकि ask ही पूरा point था। Memo landed. 3 partners में से 2 flip हुए। Opposing partner ने written objection भेजा जिसे memo page 1 पर already address कर चुका था। Collaborative draft जीता, और इसलिए जीता क्योंकि financial assumption और partner-specific counter-argument पर उसके overrides ने काम किया, model की prose ने नहीं।
जो person कभी 3 paths compare नहीं करता, वह सिर्फ Collaborative version लिखता है:
| क्या खोता है | यह fail क्यों होता है |
|---|---|
| Name नहीं कर सकता कि judgment ने कहाँ काम किया। | Solo और AI-only baselines के बिना हर sentence बराबर उसका लगता है। CEO का "why did you land here?" question answer नहीं पाता। |
| Show नहीं कर सकता कि Collaborative draft सच में better है। | "It feels better" defense नहीं है। 4-axis side-by-side evidence है। उसके बिना team polished draft को answer treat करती है। |
| Catch नहीं कर सकता कि वह oracle-mode में slide कर रहा था। | अंदर से surrender collaboration जैसा ही दिखता है। AI-only draft diagnostic है: अगर वह आपकी Collaborative के uncomfortably close है, तो आपने over-accept किया। |
Same person, same hour. फ़र्क smarts नहीं है। फ़र्क है कि आपने comparison run किया या सिर्फ comparison feel किया।
यह discipline किसके लिए है, इस पर note. इसे ऐसे work पर use करें जहाँ AI आपके जितना अच्छा नहीं कर सकता: judgment calls, novel problems, ऐसे decisions जो model के पास नहीं मौजूद context पर depend करते हैं। Routine work जहाँ AI already आपके जितना अच्छा (या better) करता है, वहाँ यह discipline run करना wasted effort है। AI productivity पर आज तक की biggest study (Brynjolfsson et al. 2025, नीचे cited) actually routine work पर opposite दिखाती है: AI less-experienced worker की सबसे ज़्यादा मदद करता है, क्योंकि model already वही लिखता है जो expert वैसे भी लिखता। इसलिए: यह discipline वहाँ run करें जहाँ आपका judgment AI से बेहतर है। बाकी पर AI को carry करने दें और आगे बढ़ें। आपके सामने कौन सा work है, यह जानना खुद skill का हिस्सा है।
खुद try करें
आप 400-person software company में VP of Strategy हैं (yearly revenue लगभग $72M, mid-sized businesses के लिए data-analytics product, 12% profit margin के साथ profitable). CEO ने executive team के लिए 1-page memo माँगा है: क्या smaller competitor acquire करना चाहिए? Competitor Forsight है, 90 people, yearly revenue लगभग $11M, last quarter तक 60% year over year grow कर रहा था, जब उसने अपना largest customer खो दिया (lost customer Forsight revenue का 22% था)। Forsight reportedly $40-$55M range में acquisition के लिए open है। Memo board pre-read में जाएगा। आपकी recommendation अगले 3 years तक आपको quote back की जाएगी।
Recommendation क्या है, और आपको कैसे पता है?
(अगर acquisition strategy आपका काम नहीं है, surface swap करें लेकिन shape रखें: 1-page memo, इस week आपके desk पर real decision, stakes जो आपके साथ travel करते हैं। Deliverable जितना real होगा, comparison उतना sharp होगा।)
On-ramp version के लिए, अगला email या short memo (under 200 words) चुनें जिसे आज AI से draft करवाते। उसे Solo करें (3 min), AI-only करें (2 min), फिर उस पर collaborate करें (5 min). तीनों side by side रखें। Point email नहीं है। Point felt difference है।
AI-only draft skip न करें। Drop करने के लिए यही सबसे tempting है ("मुझे already पता है AI क्या कहेगा") और keep करने के लिए सबसे diagnostic है। अगर आपकी Collaborative आपकी AI-only के uncomfortably close निकलती है, तो आपने over-accept किया। यह तभी सीखेंगे जब दोनों लिखेंगे।
Form से पहले 1 note. नीचे का feedback frontier model (Claude Sonnet 4.5+, Opus 4.7, GPT-5, Gemini 2.5 Pro) के लिए tuned था। Smaller models input quality जैसी भी हो, Collaborative draft को flatter करते हैं।
AI यह check करेगा:
- क्या आपकी 3 path summaries सच में 3 different drafts describe करती हैं, या same draft की 3 rephrasings? 1-10 rate करें। हर summary से 1 sentence quote करें जो decide करता है। अगर Solo और Collaborative summaries near-identical हैं, तो साफ़ कहें।
- क्या आपके 3 overrides इतने specific हैं कि उनमें से कोई 1 remove करने पर Collaborative draft visibly weaken होगा? 1-10 rate करें। 3 overrides में से हर एक के लिए name करें कि उसके बिना draft कैसा दिखेगा। अगर कोई override generic है ("I added more detail"), तो साफ़ कहें।
मेरे काम को rewrite न करें। Human-edited version को flatter न करें। अगर field empty या vague है, 1 line में साफ़ कहें।
आपकी 3 path summaries (हर path पर 1 paragraph: आपने क्या लिखा, क्या surprising था, और कहाँ short पड़ा):
आपके 3 key overrides (Collaborative draft में 3 specific places name करें जहाँ आपके judgment ने काम किया, meaning उस override के बिना draft fail होता):
तीनों drafts में से कौन सा आप actually recipient को भेजेंगे, और क्यों:
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
10-minute on-ramp version के लिए reflection सहित 15-20 minutes plan करें। 95-minute full version वही है जो आप इस week real high-stakes work पर run करेंगे। AI feedback के साथ सबसे useful चीज़: वह जगह खोजें जहाँ AI कहता है कि Solo draft किसी axis पर stronger था। यह signal है कि आपके overrides कहाँ load carry नहीं कर रहे थे। अगर AI कोई जगह नहीं ढूँढ पाता, उसे harder push करें; अगर ढूँढ ले, तो आपने सीख लिया कि collaboration posture अभी कहाँ soft है।
जो आपने अभी किया, वह पूरे crash course को miniature में करता है। आपने AI से पहले position form की (D1), हर claim पर verdict document किया (D2), outputs को fabrications के लिए scan किया (D3), recommendation के second-order effects trace किए (D4), test किया कि consensus framing कहाँ break होती है (D5), और judgment को human के पास रखा जब model oracle mode में drift करना चाहता था (D6)। Deliverable कभी answer नहीं होता। Deliverable सोच का documented evidence है, और अब आपके पास 6 disciplines हैं जो demand पर वह evidence produce करती हैं।
Compare करने के लिए strong sample चाहिए? (अपना submit करने के बाद खोलें।)
Same VP-of-Strategy acquisition scenario चलाने वाले reader ने यह लिखा। यह अकेला good answer नहीं है; बस shape दिखाता है।
| Path | उनकी summary |
|---|---|
| Solo (45 min) | Acquisition के against recommend किया। Customer-concentration risk पर strong (target ने overnight 38% revenue खोया)। Integration thesis पर weak: कभी name नहीं किया कि acquirer की product team engineering hires के साथ actual में क्या करेगी। Page 1 की last line में recommendation bury हो गई। |
| AI-only (20 min) | "structured acquisition with earn-out triggers" recommend किया (earn-out: seller को price का हिस्सा बाद में मिलता है, सिर्फ अगर business targets hit करे)। Polished. इसमें 2 phrases ("strategic optionality," "tuck-in upside") थे जिन्हें CEO ने last all-hands में publicly criticize किया था। इसने address नहीं किया कि target के remaining customers उस region में clustered थे जहाँ acquirer की कोई presence नहीं थी। |
| Collaborative (30 min) | Acquisition के against recommend किया लेकिन 60-day pause-and-license deal propose किया (talent hire करें + उनकी technology license करें) जिसने strategic value का 70% cost के 15% पर capture किया। Pause-and-license framing model से आई। 60-day window और technology license करने का carve-out user के overrides थे। Opening line में recommendation user की थी। |
Collaborative draft में 3 key overrides:
- Model की "strategic optionality" framing reject की। Model ने phrase 3 बार use किया। User ने हर instance replace किया क्योंकि यह paragraph 1 में CEO की known objection trigger कर देता। इसके बिना memo dead on arrival होता।
- Geographic-concentration point add किया। Model ने इसे कभी raise नहीं किया। User last quarterly review से जानता था कि target का remaining customer base 80% ऐसे region में है जहाँ acquirer की sales presence नहीं है। Acquisition का revenue model collapse होने की central वजह यही थी। इसके बिना recommendation weak grounds पर "no" होती।
- Model की earn-out structure override की। Model ने 3-year earn-out propose किया (seller को price का हिस्सा बाद में मिलता है, revenue targets hit करने से tied)। User ने उसे 60-day pause-and-license deal से replace किया क्योंकि firm की own past deal history दिखाती थी कि 18 months से ऊपर earn-outs में 80%+ founder-departure rates थे। इसके बिना alternative proposal वही risk inherit करता जिसे avoid करने की कोशिश थी।
जो इसे काम कराता है: हर override model के पास नहीं मौजूद context के specific piece तक trace करता है (CEO की language, last quarterly review का geographic data, deals पर firm का own track record)। User हर override पर point करके कह सकता है, "यह वह है जो मैं जानता था और model नहीं जानता था, और यह मैंने उससे किया।" यही sentence test है। अगर आप Collaborative draft में कम से कम 3 जगहों पर यह नहीं कह सकते, तो आपने collaborate नहीं किया; आपने edit किया।
यह क्या करने की कोशिश नहीं करता: अपने आप brilliant होना। Pause-and-license structure model से आया। उसे कब use करना है और कैसे bound करना है, यह judgment user से आया। पूरी posture यही है।
अगर इस move के नीचे की cognitive science चाहिए (click to expand)
Collaboration posture नई theory नहीं है। यह LLM era से 2 decades से भी ज़्यादा पुरानी है।
- Kasparov, G. (2017). Deep Thinking: Where Machine Intelligence Ends and Human Creativity Begins. 1997 में Deep Blue से हारने के बाद, Kasparov ने 1998 में "advanced chess" coin किया: human-plus-engine teams systematically stronger humans alone और stronger engines alone दोनों को beat करती हैं, जब human positional calls करता है जो game decide करते हैं। Pattern अब textbook है: productivity lift human के selective override से आती है, engine की raw speed से नहीं।
- Brynjolfsson, E., Li, D. & Raymond, L. R. (2025). "Generative AI at Work." The Quarterly Journal of Economics 140(2), 889-942. (Originally NBER Working Paper 31161, 2023.) Fortune 500 customer-support firm की 5,179-agent study में LLM assistance ने productivity average 14% raise की, lift heavily less-experienced workers में concentrated था; experienced workers को little gain मिला, क्योंकि model suggestions पहले से उनके लिखने के close थे। Knowledge work के लिए implication: collaboration की value human के उस context लाने पर depend करती है जो model के पास नहीं है। जब model के पास already context है, collaboration सिर्फ typing है।
- Daugherty, P. & Wilson, H. J. (2018). Human + Machine: Reimagining Work in the Age of AI. Human-AI work की "missing middle" catalog की: वे tasks जहाँ pure automation और pure human judgment दोनों नहीं जीतते, और value loop में होती है। Book का central claim, कि highest-leverage roles वे हैं जो AI के judgment को train, explain और sustain करते हैं, override discipline को 5 years पहले anticipate करता है।
- Noy, S. & Zhang, W. (2023). "Experimental evidence on the productivity effects of generative artificial intelligence." Science 381(6654). Professional writing tasks पर controlled study: ChatGPT ने average output quality raise की, लेकिन quality dispersion sharply narrow हुई: low-skill writers सबसे ज़्यादा improve हुए, high-skill writers सबसे कम, और writers across variance collapse हुआ। Selective override के बिना, AI-assisted output competent mean की ओर regress करता है, जो Three-Path Comparison के AI-only draft में दिखता है।
Three-Path Comparison को named protocol के रूप में test करने वाला कोई single trial नहीं है। Underlying finding (human-AI complementarity selective human override पर depend करती है) LLM-productivity literature की most-replicated results में से एक है। Comparison सबसे simple forcing function है जो override को काम कर रहे person के लिए visible बनाता है।
इस 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 move सिखाता है। वह page working week उसके around build करता है।
Capstone: 1 decision, 6 disciplines
12-person consulting firm के पास fiscal year खत्म होने से पहले spend करने के लिए $180,000 हैं। CEO को 2 options दिखते हैं। Option A: 1 senior strategy lead hire करें, partner-track hire जो 1 या 2 large accounts carry करेगा और bench mentor करेगा। Option B: same $180,000 licenses, infrastructure और design time में invest करें, ऐसी AI workforce के लिए जो हर existing consultant को augment करे, staff पर already मौजूद 11 लोगों को ज़्यादा काम करने में help करे। दोनों options defensible हैं। 2 board members hire favor करते हैं। 2 AI workforce favor करते हैं। 5th undecided है। CEO को next Thursday की board meeting में recommendation और उसके पीछे reasoning के साथ जाना है। उसके पास 5 business days हैं। इन 5 दिनों में 6 disciplines कैसे show up होती हैं, यह रहा।
Discipline 1, Prediction Lock. कोई AI tool खोलने से पहले, कोई vendor pitch pull करने से पहले, CEO अपने page पर 4-line lock लिखती है। Diagnosis: firm की growth की real limit यह है कि हर consultant कितना काम कर सकता है, न कि consultants कितने हैं। 3 diagnostic questions, हर एक के साथ predicted answer और confidence number: क्या Option B existing 11 को सच में ज़्यादा काम करवाने में help करता है (predicted answer: उनमें से 6 के लिए yes, 5 के लिए no, confidence 55%)? क्या Option A ऐसा account-level gap cover करता है जो B नहीं कर सकता (predicted answer: 1 specific account के लिए yes, confidence 70%)? अगर हर spend underperform करे, तो 18 months के अंदर पैसा कितना recover हो सकता है (predicted answer: B more recoverable है, confidence 65%)? वह page time-stamp करती है। Claude नहीं खोलती। ChatGPT नहीं खोलती। Prediction पहले lock करती है।
Discipline 2, Reasoning Receipt. 2 दिनों में वह decision को Claude और ChatGPT से run करती है, vendor comparison माँगती है, peer-firm benchmark pull करती है, और 2 analyst notes पढ़ती है। हर decisive claim 5-column receipt में land करता है। AI claim करता है कि AI-workforce option consultants को 22% more productive बनाता है: वह MODIFY mark करती है, क्योंकि cited study उसकी firm से 3 गुना बड़े firms cover करती थी; gain के size पर उसका confidence drop होता है, direction पर hold करता है। AI claim करता है कि senior hire speed में आने में 9 months लेता है: वह SURFACED mark करती है, क्योंकि वह 6 months assume कर रही थी और receipt अब उसका own optimism पकड़ती है। Wednesday morning तक receipt में 14 rows हैं। Empty receipt का मतलब होता कि उसने consensus absorb कर लिया। 14 rows का मतलब है कि decision अभी भी उसका है।
Discipline 3, Error Taxonomy. वह हर vendor pitch और AI summary को 6-row error scan से run करती है। AI-workforce vendor की ROI deck में 2 False Confidence flags हैं (numbers पर precision जिसे vendor measure नहीं कर सकता), 1 Stale Fact (3 months old license-pricing change जिसने unit economics flip कर दिए), और 1 Fabricated Source ("McKinsey 2025" citation जो search करने पर किसी McKinsey publication तक resolve नहीं होती)। Recruiter से senior-hire pitch में 1 Logical Gap है (ramp-time claim firm की actual onboarding cadence account नहीं करता) और 1 Missing Context (recruiter ऐसे firms against benchmark करता है जिनके पास established mentor pools हैं, उसकी firm के पास नहीं)। Errors किसी option को kill नहीं करते। वे उसके head में option costs re-rank करते हैं।
Discipline 4, Thinking in Systems. वह दोनों options को 5 domains across cascade करती है। Employees: A people में investment signal करता है, B process में investment; bench दोनों को अलग पढ़ता है। Customers: A 1 named account pick करता है, B existing 12 के सामने firm को more capable दिखाता है। Competitors: A उनके लिए invisible है, B firm की bet को 2 regional rivals के सामने announce करता है जो similar moves evaluate कर रहे हैं। Regulators: B में new client-data rules के under data-handling implications हैं जो A trigger नहीं करता। Internal knowledge: A senior judgment को 1 person में concentrate करता है, B उसे उन tools through spread करता है जिन्हें सब use करते हैं। वह 1 feedback loop circle करती है: Option B में junior consultants जो tools fastest pick करते हैं, वही leave करने की सबसे ज़्यादा संभावना वाले बनते हैं, क्योंकि अब जो extra काम वे कर सकते हैं वह उनके साथ जाता है। वह loop option का risk profile बदलता है।
Discipline 5, First Principles. वह consensus के against 500 words लिखती है कि "more senior staff equals more capacity." Boundary 1: जब real limit work flow है, new work जीतना नहीं, तो senior hire broken process fix करने के बजाय उस पर और work pile करता है। Boundary 2: जब junior staff से ज़्यादा output निकालना same hourly output तक lower-cost path है, senior hire next 4 quarters में जितना return करता है उससे ज़्यादा cost करता है। Boundary 3: जब firm की reputation better tools से lead करने पर built है (उसकी है), senior hire उस चीज़ से backward step दिखता है जिसके लिए firm already stand करती है। Consensus अलग limit वाली firm के लिए सही है। उसकी firm की limit यह है कि हर person कितना काम कर सकता है, seniority नहीं।
Discipline 6, Working WITH AI. वह final recommendation 3 ways run करती है। Solo (45 min): Option B defend करने वाला careful memo, cultural risk पर light. AI-only (20 min): polished memo जो 2 options के बीच difference split करता है और McKinsey brief जैसा पढ़ता है। Collaborative (30 min): वह structural argument लिखती है, model से ऐसे partner का strongest argument for Option A surface करने को कहती है जिसने historically hiring favor की है, और Option B के cultural risk address करने के लिए 3 specific guardrails propose करने को कहती है। Model 2 guardrails propose करता है जिन पर उसने consider नहीं किया था। Collaborative draft वही है जिसके साथ वह board में जाती है। Recommendation Option B है, 3 named guardrails और 6-month checkpoint के साथ, जो productivity move न हो तो partial reversal trigger करता है।
Board, 3 में से 2 guardrails के साथ Option B adopt करता है। Third renegotiate होती है। CEO meeting से ऐसे decision के साथ निकलती है जिसे वह every line पर defend कर सकती है।
Notice करें कि 6 disciplines ने क्या किया। उन्होंने answer produce नहीं किया। उन्होंने trail produce की: ऐसी prediction जिसे CEO compare कर सकती है, ऐसी receipt जिसे partners audit कर सकते हैं, error scan जिसने vendor pitches re-rank किए, cascade map जिसने retention loop surface किया, boundary list जिसने consensus framing तोड़ी, और three-path comparison जिसने guardrails खोजे। 6 disciplines के बिना, वही CEO Thursday को 1-page memo और split board के साथ जाती जिसे वह move नहीं कर सकती। 6 disciplines के साथ, वह ऐसे decision के साथ जाती है जिसे board stress-test कर सकता है और paper trail के साथ जिसे firm 2 quarters बाद वापस देख सकती है। Deliverable कभी answer नहीं होता। Deliverable सोच का documented evidence है।
इन moves का use किसके लिए NOT है, इस पर last note. ये disciplines सबसे common तरीके से over-application से fail होती हैं: lunch लेने पर Cascade Map, हर internal Slack message पर Reasoning Receipt, ऐसे decision पर Prediction Lock जो आप already बना चुके हैं। इन्हें meeting लायक work के लिए reserve करें। बाकी सब पर, उस experience पर trust करें जिसे बनाने में आपने years लगाए हैं।
आगे कहाँ जाएँ
6 disciplines में से किसी पर deeper practice के लिए, इस book का Part 0 long-form treatment है:
- Part 0 Ch 1: Asking Better Questions. Prediction Lock और Position Lock, 4 exercises और Question Quality Portfolio across expanded.
- Part 0 Ch 2: Detecting Broken Reasoning. Error Taxonomy confidence calibration और domain-expertise stress test के साथ extended.
- Part 0 Ch 3: Thinking in Systems. Cascade maps 4 real decisions पर applied, 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. Three-Path Comparison, collaboration logs, और override tests across a working week.
इस crash course ने जिन 4 thinking skills को cover नहीं किया, Part 0 में उनका full treatment है:
- 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.
इस book में आपका next move, mode चुनें:
- अगर आप code लिखते हैं, Claude Code & OpenCode पर जाएँ। Mode 1 problem-solving के लिए engineering surface.
- अगर आप knowledge work करते हैं (legal, finance, marketing, operations, healthcare, education, leadership), Cowork पर जाएँ। Mode 1 problem-solving के लिए domain-expert surface.
- अगर आप अपने दम पर run करने वाले AI Workers बनाना चाहते हैं (Mode 2 manufacturing), Build AI Agents पर जाएँ।
Disciplines हर tool, हर mode, हर domain across transfer होती हैं। यही चीज़ है जिसे आप यहाँ से anywhere carry करते हैं।
Deliverable कभी answer नहीं होता। Deliverable सोच का documented evidence होता है।
क्या यह AI को आपके हाथों में more powerful tool बनाता है, या आपको tool का slower version बना देता है?