धीमा पड़ना ही आपको तेज़ बनाता है

• AI के दौर में सबसे counterintuitive अभ्यास है यह जानना कि कब गति धीमी करनी है, और जैसे-जैसे execution सस्ता होता जाता है, उससे पहले के decision-making की अहमियत और बढ़ती जाती है
• Daniel Kahneman के System 1 (तेज़ pattern matching) और System 2 (धीमी analytical thinking) फ्रेमवर्क को AI युग के software development पर लागू किया गया है
• गलत requirements या design assumptions को AI और तेज़ी से फैलाता है, इसलिए execution से पहले के धीमे चरण की लागत-के-मुकाबले प्रभावशीलता अधिकतम हो जाती है
• AI का उपयोग सिर्फ execution ही नहीं, बल्कि pre-review, pre-mortem, edge case exploration जैसे विचारशील चरणों को तेज़ करने में भी किया जा सकता है
• "AI इस्तेमाल कर लो, है ना?" जैसी नई speed-pressure culture का सामना करने के लिए, धीमे चरणों को स्पष्ट रूप से दिखाना और उन्हें timebox करना ज़रूरी है

---

सोच की दो गति

• Daniel Kahneman की Thinking, Fast and Slow में प्रस्तुत दो thinking modes को AI युग के development पर लागू किया गया है
  • System 1: तेज़, स्वचालित, और pattern matching पर आधारित सोच
  • System 2: धीमी, इरादतन, और विश्लेषणात्मक सोच
• Dwarkesh Patel के साथ बातचीत में Andrej Karpathy ने LLM की तुलना भूत या जिन्न से की, जो मानव टेक्स्ट का statistical distillation है; शब्द अंदर जाते हैं, pattern match होता है, और शब्द बाहर आते हैं — मूलतः एक System 1 जैसी सत्ता
• AI बड़े पैमाने पर तेज़ pattern matching में उत्कृष्ट है, लेकिन क्या बनाना है, वह क्यों महत्वपूर्ण है, और क्या सही समस्या हल की जा रही है — यह अब भी मानवीय judgment का क्षेत्र है
• counterintuitive मुख्य बिंदु: AI ने धीमे चरण को कम महत्वपूर्ण नहीं बनाया, बल्कि और अधिक महत्वपूर्ण बना दिया है
  • जब execution सस्ता और तेज़ हो जाता है, तब leverage execution से पहले के decision-making में चला जाता है
• गलत requirements, गलत समझी गई समस्याएँ, और दोषपूर्ण design assumptions AI द्वारा बनाई जाने वाली हर चीज़ में फैल जाती हैं, और अब वे और तेज़ी से फैलती हैं
  • System 1 जितना शक्तिशाली होता जाता है, System 2 को गलत करने की लागत उतनी बढ़ती जाती है

गति का भ्रम

• अकादमिक जगत का पुराना मज़ाक: "जो काम लाइब्रेरी में कुछ घंटों में हो सकता है, वह लैब में कुछ हफ्तों में होता है", उसका software संस्करण: "कुछ हफ्तों की coding आपको कुछ घंटों की planning बचा देती है"
  • असल बात यह है कि वास्तविकता उलटी होती है — जल्दबाज़ी में शुरू करने पर बुनियादी गलतियाँ बाद में पता चलती हैं और फिर दर्दनाक rework करना पड़ता है
• software engineering में यह स्पष्ट अंतर्दृष्टि है कि गलतियों को यथासंभव requirements या design चरण में ही पकड़ लेना चाहिए
  • box diagrams को आसानी से बदला जा सकता है, गलत समझी गई requirements को बदलना कठिन होता है, और बुनियादी रूप से दोषपूर्ण deployed architecture तो अक्सर rewrite के स्तर तक पहुँच जाता है
• AI की समस्या: यह तकनीकी ऋण को पहले से कहीं तेज़ी से पैदा कर सकता है
  • अगर execution से पहले के निर्णय दोषपूर्ण हैं, तो AI उन दोषों को पूरी तरह काम करने वाले feature code जैसी दिखने वाली शक्ल में ईमानदारी से लागू कर देगा
  • यह गलत समझी गई requirements के आधार पर हज़ारों लाइन code बना सकता है, और गलत समस्या के लिए elegant solution भी खुशी-खुशी तैयार कर देगा
• गति का भ्रम: ऐसा लगता है कि प्रगति हो रही है, जबकि वास्तव में आप और गहरा गड्ढा खोद रहे होते हैं
• समाधान गति छोड़ना नहीं, बल्कि उसे जानबूझकर सही जगह रखना है — AI की गति तभी इस्तेमाल होनी चाहिए जब सही दिशा की पुष्टि हो चुकी हो

जब धीमापन असर दिखाता है

• वे बिंदु जहाँ इरादतन धीमापन असरदार होता है, मूलतः नहीं बदले हैं
  • requirements जब सिर्फ दस्तावेज़ के शब्द होते हैं, तब उन्हें बदलना सस्ता होता है; लेकिन जब वे वास्तविक users को serve करने वाले deployed code बन जाते हैं, तब बदलाव महँगा पड़ता है
  • design decisions को diagram में बदलना आसान होता है, लेकिन production systems में बदलना कठिन
  • AI ने इस बुनियादी physics को नहीं बदला; इसने बस इसे सही ढंग से करने पर मिलने वाले leverage को बढ़ा दिया है
• Thinking First protocol: AI को काम सौंपने से पहले, आप वास्तव में क्या चाहते हैं इसे स्पष्ट करने में समय लगाना — गलती पकड़ने का यह सबसे सस्ता बिंदु है
• एक रोचक विरोधाभास यह है कि AI का उपयोग सिर्फ execution को नहीं, बल्कि सोच-विचार को ही तेज़ करने में भी किया जा सकता है
  • coding से पहले requirements स्पष्ट करना: 10 मिनट लेकर लिखें कि आप कौन-सी समस्या हल कर रहे हैं, success criteria क्या हैं, और constraints क्या हैं; फिर AI से इसे review कराकर generation शुरू करें
  • pre-mortem चलाना: design final करने से पहले AI से पूछें, "इस approach में क्या गलत हो सकता है?", ताकि वे risks सामने आएँ जिन पर आपने अभी तक विचार नहीं किया
  • समस्या को उलटना (Invert): AI से पूछें, "इस project को fail कराने वाली चीज़ें क्या होंगी?", ताकि छिपी हुई assumptions सामने आएँ
  • फेंक देने लायक prototype बनाना: AI से कुछ घंटों में prototype बनाकर stakeholders को दिखाएँ, और निवेश से पहले समझ की जाँच करें — धीमेपन के लिए गति में निवेश
  • सरल internal tool बनाना: असली product पर लागत खर्च करने से पहले AI से एक rough version बनवाएँ, ताकि पता चल सके कि वास्तव में क्या ज़रूरी है और क्या नहीं
  • edge cases जल्दी निकालना: implementation शुरू करने से पहले AI से design के edge cases और failure modes निकलवाएँ, ताकि उन्हें diagram चरण में ही संभाला जा सके

नई सांस्कृतिक प्रतिकूलता

• "AI इस्तेमाल कर लो, है ना?" speed pressure का एक नया रूप है, और यह इसलिए खास तौर पर खतरनाक है क्योंकि यह productivity के दिखावे को वास्तविक throughput से गड़बड़ा देता है
  • AI कुछ सेकंड में code generate कर सकता है, लेकिन code generation और सही समस्या का समाधान एक ही बात नहीं हैं
• जवाबी रणनीतियाँ:
  • स्पष्ट रूप से साझा करें कि आप अभी किस चरण में हैं: अगर आप धीमे चरण में हैं, तो बताएँ कि आप requirements स्पष्ट कर रहे हैं, edge cases पर सोच रहे हैं, या यह पुष्टि कर रहे हैं कि सही समस्या हल हो रही है
  • stakeholders की भागीदारी बढ़ाएँ: इस समय उनका input शामिल करना सस्ता है; बाद में यह महँगा पड़ेगा
  • काम की प्रक्रिया साझा करें: requirements documents, design sketches, pre-mortem outputs जैसे धीमे चरण के artifacts को visible बनाकर दिखाएँ कि प्रगति हो रही है
  • धीमे चरणों को timebox करें: जैसे, "code लिखने से पहले 2 दिन requirements स्पष्ट करने में" — ऐसी स्पष्ट सीमाएँ इरादतन धीमेपन को open-ended नहीं बल्कि planned बनाती हैं
  • सीखी गई बातें साझा करें: मिले हुए edge cases, गलत साबित हुई assumptions आदि पर संक्षिप्त update दें, ताकि धीमा चरण value की visible flow में बदल जाए
  • quick wins दिखाएँ: फेंक देने लायक prototypes या mockups जल्दी बनाकर दिखाएँ कि आप तेज़ी से आगे बढ़ सकते हैं, और इस तरह धीमे, सावधान काम के लिए विश्वास हासिल करें
• यह Basecamp की Shape Up methodology के Hill Chart विचार से मिलता-जुलता है
  • चढ़ाई वाला हिस्सा: ऊँची uncertainty और काम के वास्तविक स्वरूप की खोज का धीमा चरण
  • उतराई वाला हिस्सा: स्पष्ट रास्ता और सिर्फ execution की ज़रूरत वाला तेज़ चरण
• यह देरी का बहाना नहीं, बल्कि अच्छा काम वास्तव में कैसे होता है इसका वर्णन है — लंबे समय में सबसे तेज़ ship करने वाली टीमें अक्सर वही होती हैं जो सही समय पर गति धीमी करती हैं

अमल करने के तरीके

• अगले AI-assisted काम से पहले यह आज़माएँ:
  • 10 मिनट लेकर लिखें कि आप वास्तव में कौन-सी समस्या हल करना चाहते हैं, सफलता कैसी दिखेगी, और scope से बाहर क्या है
  • build शुरू करने से पहले AI से अपनी approach पर pre-mortem चलवाएँ
  • अगर काम बड़ा है, तो दिशा validate करने के लिए पहले फेंक देने लायक prototype बनाएँ

निष्कर्ष

• गति और धीमापन विरोधी नहीं, बल्कि अलग-अलग चरणों के लिए अलग tools हैं
• AI दोनों में प्रभावी है: दिशा स्पष्ट होने पर तेज़ execution, और अस्पष्टता होने पर तेज़ हुई गहन सोच
• मुख्य कौशल यह पहचानना है कि आप अभी किस चरण में हैं और उचित tempo लागू करना है