मैं अक्सर गलत होता हूँ
एक टेक लीडर की ब्लॉग पोस्ट, जिसमें छह-चरणीय, “act with urgency” समस्या-समाधान फ़्रेमवर्क और गलत होने को लेकर घोषित प्रेम बताया गया है, ने AI कंपनियों में आधुनिक प्रबंधन संस्कृति की एक व्यापक आलोचना को जन्म दिया है। टिप्पणीकारों का तर्क है कि यह तरीका सतही, निर्देशात्मक है, और शक्ति-संतुलन तथा बर्नआउट के जोखिमों की अनदेखी करता है; वे इसे buggy AI tooling, और craftsmanship की जगह agents और process पर अत्यधिक निर्भरता से जुड़ी निराशाओं से जोड़ते हैं। एक अल्पसंख्या इस फ़्रेमवर्क का बचाव स्थापित निर्णय-निर्माण मॉडलों के एक उचित रूपांतर के रूप में करती है, लेकिन कई लोग इसे corporate platitudes मानते हैं जो व्यक्तिगत कामकाजी शैलियों या वास्तविक psychological safety को ध्यान में नहीं रखते।
फ़्रेमवर्क का महसूस किया गया मूल्य
- कुछ लोग छह-चरणीय प्रक्रिया को पूरी तरह उचित, काफ़ी मानक समस्या-समाधान लूप मानते हैं, जो OODA, PDCA, Polya के “How to Solve It,” या Amazon-शैली के निर्णय दस्तावेज़ों जैसा है।
- समर्थकों का कहना है कि यह स्पष्ट रूप से दस्तावेज़ करना कि कोई कैसे सोचता है, अपेक्षाओं को लेकर भ्रम कम कर सकता है और निर्णयों को बेहतर बना सकता है, खासकर जब लिखित तर्कों के साथ हो।
- एक अल्पसंख्या इसे “bias for action” वाले वातावरण में प्रेरक पाती है: स्थिति को समझो, फिर निर्णायक ढंग से निष्पादन करो।
लहजे, विनम्रता और मौलिकता पर आलोचनाएँ
- कई लोग इस फ़्रेमवर्क को सामान्य, “मिडिल-स्कूल” स्तर का, या सिलिकॉन वैली की घिसी-पिटी बातें मानते हैं जिन्हें अंतर्दृष्टि के रूप में सजाया गया है।
- शीर्षक “I am often wrong” को व्यापक रूप से humblebrag के रूप में पढ़ा जाता है; टिप्पणीकार वास्तविक रूप से गलत होने या व्यवहार में निर्णय बदलने के ठोस उदाहरणों की कमी नोट करते हैं।
- कुछ लोग आत्म-केंद्रित प्रस्तुति (“my framework,” “my approach”) और इसे आंतरिक मार्गदर्शन के बजाय बाहरी रूप से प्रकाशित करने पर नकारात्मक प्रतिक्रिया देते हैं।
नेतृत्व, शक्ति-संतुलन, और फ़ीडबैक संस्कृति
- दूसरों को व्यक्तिगत फ़्रेमवर्क का पालन “अनिवार्य” करने और न करने पर उन्हें “फ़ीडबैक” देने के विचार के खिलाफ़ तेज़ विरोध है।
- कई लोगों का तर्क है कि अच्छा नेतृत्व व्यक्तियों की ताक़तों के अनुसार ढलता है, उनकी प्रतिकृतियाँ नहीं बनाता; फ़्रेमवर्क उपकरण होने चाहिए, प्रवर्तन तंत्र नहीं।
- अन्य लोग जवाब देते हैं कि हर नेता परोक्ष रूप से कुछ प्रक्रिया थोपता ही है; उसे स्पष्ट करना मददगार हो सकता है।
- यह चिंता भी है कि psychological safety और “ईमानदार फ़ीडबैक” को मान लिया गया है, सुनिश्चित नहीं किया गया—खासकर वरिष्ठ ICs से आने पर, जिनका फ़ीडबैक फिर भी भारी असर रखता है।
तात्कालिकता, प्राथमिकता-निर्धारण, और समस्या-परिभाषा
- “Act with urgency” की काफ़ी आलोचना होती है, क्योंकि इसे बर्नआउट, लापरवाह काम, और यह भावना कि सब कुछ हमेशा आग में है, का नुस्खा माना जाता है।
- समर्थक इसे “सोच-विचार कर लेने के बाद जल्दी निष्पादन करो” के रूप में, या बड़ी कंपनियों की जड़ता के प्रतिकार के रूप में देखते हैं।
- कई टिप्पणीकार कहते हैं कि चरणों का क्रम भ्रमित है: लक्ष्य-परिभाषा बहुत देर से आती है, जानकारी-संग्रह स्पष्ट समस्या-परिभाषा से पहले होता है, और पुनरावृत्ति/प्रयोग पर कम ज़ोर है।
Claude Code और उत्पाद-गुणवत्ता का प्रसार प्रभाव
- एक बड़ा उप-थ्रेड Claude Code की स्थिति को एक परीक्षण मामले के रूप में उपयोग करता है: कई लोग इसे buggy, असंगत, धीमा, और अजीब तरह से लागू किया गया बताते हैं (जैसे React/JS विकल्प, terminal-in-sidebar UX)।
- GitHub issue की भारी संख्या, लंबे समय से चले आ रहे बग (जैसे गायब संदेश), और auto-closed issues को इस बात के प्रमाण के रूप में उद्धृत किया जाता है कि यह प्रक्रिया गुणवत्ता नहीं दे रही।
- अन्य लोग जवाब देते हैं कि विशाल उपयोगकर्ता-स्तर और व्यापक सतही क्षेत्र कई समस्याओं की व्याख्या करते हैं, और सभी खुले मुद्दे पुष्टि किए गए बग नहीं हैं।
LLMs, संस्कृति, और संचार
- कुछ लोगों को चिंता है कि एजेंटों का भारी आंतरिक उपयोग “लोगों की आवाज़ों को चिकना” कर रहा है, संचार को LLM आउटपुट जैसा बना रहा है और मानव-से-मानव सहयोग को कमज़ोर कर रहा है।
- अन्य लोग नोट करते हैं कि सभी मानवीय सोच पहले से ही कुछ हद तक “faulty narrator” जैसी है; LLMs शायद इसे सिर्फ़ और अधिक स्पष्ट बना रहे हैं।