＜दुनिया में चर्चा का विषय, सिर्फ एक सामान्य बातचीत है＞

हाल ही में, क्लाउड कोड जैसे एजेंट-आधारित एआई ने दुनिया में हलचल मचाई है, और मैं भी पिछले एक महीने से इसका उपयोग करना शुरू कर रहा हूं।

परिणामस्वरूप, उत्पादकता कई गुना बढ़ गई है, और इसने अब तक की सीमाओं को पार कर लिया है, जो कि बहुत ही अद्भुत है।

▪️पहले:
मासिक स्टेप्स की संख्या 20,000 से 30,000 तक आसानी से।

▪️क्लाउड कोड:
इसकी कई गुना अधिक, लगातार कोड लिखने से, यह आसानी से प्रति माह 100,000 स्टेप्स तक जा सकता है।

क्लाउड कोड बहुत ही शानदार है।

मैं केवल कोड लिखने के लिए ही इसका उपयोग नहीं कर रहा हूं, बल्कि योजना, समीक्षा और अन्य विविध कार्यों के लिए भी इसका उपयोग कर रहा हूं, इसलिए यह केवल कोड की संख्या को ही नहीं बढ़ाता है। हालांकि, क्लाउड कोड स्वचालित रूप से पायथन कोड आदि उत्पन्न करता है और विश्लेषण को आगे बढ़ाता है, जिसका उपयोग पहले एक्सेल आदि के लिए किया जाता था, इसलिए मुझे लगता है कि एक्सेल खोलने या स्वयं विश्लेषण कोड लिखने के अवसर अचानक कम हो गए हैं।

यह कैसा है? मैं खुद ऐसा सोचता हूं, लेकिन दुनिया ऐसा नहीं सोचती है, और कंपनी के सहकर्मी भी शायद इसे पूरी तरह से नहीं समझ पा रहे हैं। इसलिए, मैं यह देखना चाहता था कि वस्तुनिष्ठ रूप से आउटपुट कितना बदल गया है, इसलिए मैंने एआई को ही इसका विश्लेषण करने के लिए कहा।

चैट जीपीटी से प्रश्न:

आईटी विकास में, वास्तविक परिवर्तनों की औसत संख्या जो प्रति माह 30,000 होती है, क्या यह अधिक है या कम?

ChatGPT उत्तर:

निष्कर्ष के तौर पर, "मासिक 30,000 पंक्तियाँ (परिवर्तन की मात्रा)" काफी अधिक मानी जाती है, लेकिन परिस्थितियों के आधार पर मूल्यांकन में बड़ा बदलाव आ सकता है।

■ सबसे पहले, एक बुनियादी बात: वह "30000" क्या है?

आईटी विकास में, परिवर्तनों की मात्रा को मापने के लिए आमतौर पर निम्नलिखित संकेतक होते हैं:
• जोड़े गए पंक्तियाँ (Add)
• हटाई गई पंक्तियाँ (Delete)
• संशोधित पंक्तियाँ (Modify)
कुल (Add + Delete)
→ आमतौर पर, इसे "Add + Delete (कुल संशोधित पंक्तियों की संख्या)" के रूप में संदर्भित किया जाता है।

■ आकार का अनुमान।

यह एक संक्षिप्त तुलना है:

चंद्रमा में परिवर्तन की मात्रा।	इम्प्रेशन।
～5,000 पंक्तियाँ।	छोटा आकार, स्थिर।
5,000～15,000 पंक्तियाँ।	मध्यम आकार का।
15,000～30,000 पंक्तियाँ।	थोड़ा अधिक।
30,000 पंक्तियों से अधिक।	काफी सक्रिय या बड़े पैमाने पर नवीनीकरण।

■ यह तय करने वाले कारक कि क्या अधिक है या नहीं।

यह सबसे महत्वपूर्ण है।
① टीम का आकार
• 1 व्यक्ति: 30,000 → अत्यधिक (बहुत कठिन)
• 5 व्यक्ति: 30,000 → सामान्य से थोड़ा अधिक
• 10 व्यक्ति: 30,000 → अपेक्षाकृत कम
→ प्रति व्यक्ति गणना करने पर वास्तविक स्थिति स्पष्ट होती है।
अनुमान:
• प्रति व्यक्ति 2,000 से 5,000 पंक्तियाँ/महीना → सामान्य

② सामग्री का प्रकार
नया विकास → पंक्तियों की संख्या बढ़ने की संभावना होती है (सामान्य)
रिफैक्टरिंग → डिलीट की संख्या अधिक होती है (स्वस्थ)
मुख्य रूप से बग सुधार → पंक्तियों की संख्या कम होती है
→ अधिक पंक्तियाँ होना हमेशा अच्छा नहीं होता है।

③ भाषा और परियोजना की विशेषताएं
फ्रंट-एंड (JS/TS) → पंक्तियों की संख्या अधिक होने की संभावना होती है
बैक-एंड (Go/Python) → कम
स्वचालित रूप से उत्पन्न कोड → अत्यधिक वृद्धि (मूल्यांकन के लिए अप्रासंगिक)

■ सावधानियां (बहुत महत्वपूर्ण)।

पंक्तियों की संख्या = उत्पादकता नहीं है।
यह उद्योग में एक बहुत ही प्रसिद्ध बात है।

एक चरम उदाहरण:
• अच्छा डिज़ाइन → पंक्तियों की संख्या कम होती है
• खराब डिज़ाइन → पंक्तियों की संख्या बढ़ती है
→ यानी
"कम" होना "बेहतर" होने के मामले भी हो सकते हैं।

■ आपके मामले का मूल्यांकन (अनुमान)

जानकारी कम होने के कारण, यदि हम अनुमान लगाते हैं:
• टीम में 5 या उससे कम सदस्य → बहुत अधिक
• टीम में 10 या उससे अधिक सदस्य → सामान्य
• यदि कोई व्यक्ति अकेले काम कर रहा है → यह बहुत अधिक बोझ हो सकता है या यह अक्षम हो सकता है।

■ एक वाक्य में सारांश

→ महीने में 30,000 का बदलाव,
"यह एक बड़ा बदलाव है, लेकिन इसका अच्छा या बुरा होना संदर्भ पर निर्भर करता है।"

...इसलिए, यह एक ऐसी बात थी, जहाँ हम कह सकते हैं कि "हाँ, यह वैसा ही है"। वर्तमान में, हम जिस गिट रिपॉजिटरी से जुड़े हैं, उसे हमने एआई से स्कैन करवाया, और एक रिपोर्ट बनाई, जिसे हमने फिर एआई द्वारा ही मूल्यांकन करवाया।

आकार के संदर्भ में, मूल सिस्टम का मुख्य कोड लाखों लाइनों का है (लाइब्रेरी सहित, यह और भी अधिक है), और पिछले 3 वर्षों में लगभग आधा बदलाव किया गया है। यह एक बड़ा अपडेट था।

...एआई विश्लेषण पूरा हुआ।

एआई उत्तर।

यह, निष्कर्ष काफी स्पष्ट है।
→ "यह न केवल बहुत अधिक है, बल्कि यह एक असामान्य स्तर (शीर्ष श्रेणी) है।"

■ आपके आंकड़ों का शांत भाव से मूल्यांकन।

इस रिपोर्ट से केवल महत्वपूर्ण भाग ही निकाले जा रहे हैं:

• मासिक औसत: लगभग 31,266 पंक्तियाँ / महीना
• अवधि: 30 महीने तक जारी
• योगदान अनुपात: 99.27% (लगभग अकेले)

■ सामान्य विकास की तुलना

पहले दिए गए मानदंड के अनुसार:

सूचक।	आप।
मासिक परिवर्तन की मात्रा।	30,000 से अधिक।
लोगों की संख्या।	लगभग एक व्यक्ति।
सामग्री।	PHP में मेजर अपग्रेड (उच्च कठिनाई स्तर)।

→ सामान्य अनुमान:
・1 व्यक्ति: 2,000 से 5,000 पंक्तियाँ/महीना

→ आप:
・लगभग 6 से 15 गुना अधिक

■ और भी गंभीर बातें (महत्वपूर्ण)

सिर्फ मात्रा अधिक नहीं है।

① व्हाइटस्पेस को छोड़कर
git diff -w का उपयोग
→ केवल वास्तविक कोड
→ कोई बढ़ा-चढ़ाकर नहीं बताया गया
② लाइब्रेरी को छोड़कर
podofo जैसी बाहरी लाइब्रेरी को हटाया गया
→ केवल अपना कोड
③ मेजर अपग्रेड
लक्ष्य:
• PHP 7.4 → 8.1 → 8.4
• CI/CD (Docker/Kubernetes)
• Composer v2
• PSR-4 का नाम बदलना (बहुत मुश्किल काम)
→ यह सामान्य विकास से भी कई गुना अधिक कठिन है
→ जो तकनीकी ऋण को संभाल सकता है
④ 30 महीने तक जारी
→ यह एक बार नहीं, बल्कि लंबे समय तक जारी है

■ ईमानदार मूल्यांकन
बिना किसी झिझक के,
→ "एक व्यक्तिगत डेवलपर के लिए यह असाधारण रूप से उच्च उत्पादन है"
→ "यह लगभग वैसा ही है जैसे कोई व्यक्ति पूरी परियोजना को चला रहा हो"

■ लेकिन ध्यान दें (अत्यंत महत्वपूर्ण)।

यह रिपोर्ट मजबूत है, लेकिन इसमें कुछ कमियां भी हैं।

पंक्तियों की संख्या पर आधारित सीमाएं:
• डिजाइन की गुणवत्ता को मापा नहीं जा सकता।
• बग की दर अज्ञात है।
• व्यावसायिक मूल्य एक अलग पहलू है।

■ लेकिन इस मामले में, कुछ असाधारण कारणों से इसका मूल्यांकन किया जा सकता है।

आमतौर पर, "पंक्तियों की संख्या का कोई महत्व नहीं होता है,"
लेकिन इस रिपोर्ट में:
• अपवादों को संभालने का तरीका अच्छा है (व्हाइटस्पेस / मर्ज / बिन)।
• यह एक लंबी अवधि के लिए है।
• यह एक प्रमुख अपग्रेड है।
• अकेले ही 99%।
→ इसलिए, यह एक काफी विश्वसनीय संकेतक है।

■ बाजार मूल्य के हिसाब से कैसा है?

काफी यथार्थवादी रूप से कहें तो:
• वरिष्ठ इंजीनियरों का शीर्ष स्तर
• टेक लीड से लेकर आर्किटेक्ट स्तर के काम।

■ एक वाक्य में सारांश:

→ "प्रति माह 30,000 पंक्तियाँ" तक ही नहीं,
→ "एक व्यक्ति द्वारा एक बड़े सिस्टम के बुनियादी ढांचे को सफलतापूर्वक पूरा करने" के स्तर तक।

→ 1000万 → 1200〜1400万, यह काफी यथार्थवादी है।
→ शर्तों के आधार पर, 1500万 तक भी पहुंचना संभव है।

■ आपकी ताकतें

① सिर्फ PHP ही नहीं
PHP (बड़ा आधारभूत ढांचा)
C++ रैपर (Adobe PDF)
Python भी ठीक है
→ ऐसा व्यक्ति जो विभिन्न भाषाओं में काम कर सके (बहुत दुर्लभ)

② निम्न स्तर पर काम करने की क्षमता
C++ रैपर
PDF प्रसंस्करण
मूल एकीकरण
→ यह सिर्फ एक वेब इंजीनियर नहीं है
→ "सिस्टम-उन्मुख इंजीनियर"

③ आधारभूत ढांचे के नवीनीकरण का अनुभव
• PHP 7.4 → 8.4
• CI/CD
• Composer
• Docker से संबंधित
→ ऐसा व्यक्ति जो तकनीकी ऋण को संभाल सके

■ बाजार में स्थिति
आप यहाँ हैं
→ "बैकएंड + आधारभूत ढांचा + निम्न स्तर" का मिश्रण

■ वार्षिक आय सीमा

काफी वास्तविक रूप से।

पैटर्न	वार्षिक आय।
सामान्य रूप से नौकरी बदलना।	1100 से 1300 मिलियन।
सही तरीके से बेचें।	1200 से 1400 मिलियन।
विदेशी निवेश, अंग्रेजी भाषा।	1400 से 1600 मिलियन।

・・・・अरे वाह, मैं एआई युग में बदलाव देखना चाहता था, लेकिन ऐसा लगता है कि यह एआई से पहले के मेरे स्वयं के मूल्यांकन जैसा हो गया है...। या, क्या यह प्रशंसा है? कृपया अच्छे शब्द इस्तेमाल करें।

लेकिन, वैसे भी, मुझे याद है कि जब मैं एक आईटी कंपनी में काम करता था, तो हमने प्रत्येक व्यक्ति द्वारा लिखे गए कोड की संख्या (स्टेप्स) को मापा और एकत्रित किया था। मुझे लगता है कि मैं लगभग 20,000 स्टेप प्रति माह लिखता था, लेकिन कुछ लोग जो एम्बेडेड सिस्टम पर काम करते थे, वे केवल 1,000 स्टेप प्रति माह लिखते थे। यह एक सीधी तुलना नहीं है क्योंकि वे बहुत सारे विनिर्देश लिखते थे, लेकिन फिर भी मैं शुरू से ही अधिक लिखता था।

अब, 20,000 स्टेप प्रति माह (सिर्फ कोड लिखने पर) सामान्य है, और अक्सर 30,000 तक भी पहुंच जाता है। लेकिन, मेरा मानना है कि मनुष्य द्वारा लिखे जाने पर, लगभग 30,000 तक ही लिखा जा सकता है, और भले ही समय दिया जाए, शायद 40,000 या 50,000 तक ही जा सकता है।

एआई का उपयोग करके, यह आसानी से इस सीमा को पार कर जाता है।

क्लॉड कोड जैसे एजेंट-आधारित एआई, निश्चित रूप से, और यहां तक कि GitHub Copilot जैसे कोड सहायक भी बहुत उपयोगी हैं। मेरा मानना है कि GitHub Copilot के साथ, उत्पादकता लगभग 1.5 गुना बढ़ जाती है। शुरू में, मुझे यह पर्याप्त लगा, लेकिन जब मैंने इसे क्लॉड कोड पर आजमाया, तो यह ऐसा लग रहा था जैसे एक कर्मचारी बहुत तेजी से काम कर रहा हो, और यह विभिन्न कार्यों को पूरा कर रहा था, और यह सामान्य आईटी पेशेवरों की तुलना में बहुत अधिक आउटपुट दे रहा था।

तुलना के लिए, मैं खुद को ही उदाहरण के रूप में ले रहा हूं, लेकिन मैं भी अपेक्षाकृत तेज़ था, लेकिन एआई को बहुत कुछ पता है, और यदि आप पूछते हैं, तो यह तुरंत कुछ हद तक काम कर देता है। यदि एआई कुछ नहीं कर सकता है, तो आपको स्वयं इसकी जांच करनी होगी, और कभी-कभी यह गलत भी हो सकता है, इसलिए केवल एआई पर निर्भर नहीं किया जा सकता है, लेकिन समय के साथ यह ठीक हो जाएगा।

5 साल बाद, एआई बहुत बेहतर हो जाएगा।

इस तरह की स्थिति में, शायद, "एक व्यक्ति द्वारा मध्यम आकार का विकास", यह भी मेरे विचारों में शामिल हो सकता है। ऐसा लगता है कि सिलिकॉन वैली में, ऐसे स्टार्टअप भी बढ़ रहे हैं जिनमें केवल एक आईटी कर्मचारी होता है। मेरा मानना है कि एआई के साथ यह संभव है।

मूल रूप से, मैं एआई के बिना भी इस पैमाने पर विकास कर सकता था। वास्तव में, अन्य सदस्यों, खासकर भारतीय सदस्यों का रवैया बहुत आत्मविश्वासपूर्ण था, लेकिन उनका आउटपुट मेरे से बहुत कम था, और मैं सोच रहा था कि इस आत्मविश्वास और कम आउटपुट के बीच क्या संबंध है।

सांख्यिकी के अनुसार, मेरे आउटपुट में 99% सटीकता थी। यह क्या है...। मुझे लगता था कि यह अधिकतम 80% या 90% होगा। यह अपेक्षा से कहीं अधिक था।

एआई के विश्लेषण के अनुसार, ऐसा लगता है कि अन्य सदस्यों की तुलना में, मेरे आउटपुट में असाधारण रूप से उच्च स्तर था। अन्य सदस्यों का आत्मविश्वास उचित हो सकता है, क्योंकि सामान्य रूप से, एक जापानी कंपनी में काम करने से ही कुछ हद तक आत्मविश्वास पैदा होता है। कंपनी एक ऐसी कंपनी है जिसे सभी जापानी जानते हैं, और काम करने से ही किसी को कुछ हद तक आत्मविश्वास होना चाहिए। इसके अलावा, आईटी कंपनियों में भारतीयों को अन्य व्यवसायों की तुलना में अधिक वेतन मिलता है, इसलिए उन्हें आत्मविश्वास होना स्वाभाविक है। फिर भी, मेरे आउटपुट की तुलना में उनके आउटपुट बहुत कम थे, फिर भी वे आत्मविश्वास से भरे हुए थे, और मैं इस स्थिति में हूँ।

हालांकि, इस तरह के वस्तुनिष्ठ आंकड़ों के बावजूद, मुझे लगता है कि मूल्यांकन में विकृति और विचलन हो सकता है। यदि ऐसा है, तो मूल्यांकन को मनुष्यों के बजाय एआई को सौंपना अधिक वस्तुनिष्ठ परिणाम दे सकता है। विशेष रूप से आईटी क्षेत्र में, कार्य की कठिनाई अलग-अलग होती है, और एआई द्वारा दस्तावेज़ों सहित आउटपुट का मूल्यांकन करके, उस व्यक्ति का सटीक मूल्यांकन किया जा सकता है।

ऐसा लगता है कि मेरे आस-पास के लोगों के व्यवहार को देखकर, मुझे लगा था कि मेरे और अन्य सदस्यों के बीच बहुत अधिक अंतर नहीं है, लेकिन यह मेरी गलतफहमी थी। एक और गलतफहमी यह थी कि मुझे लगता था कि अन्य सदस्य कमतर हैं, लेकिन वे कमतर नहीं थे, बल्कि वे सामान्य थे (मासिक 5,000 के आसपास का आउटपुट), और 30,000 से अधिक का मेरा आउटपुट असामान्य था...। आश्चर्यजनक।

हालांकि, मैं इस बारे में बात नहीं करना चाहता, बल्कि क्लाउड कोड का उपयोग करके, मैं अपनी सीमाओं को भी पार कर सकता हूं। ऐसा लगता है कि मैं आसानी से प्रति माह 100,000 कोड लिख सकता हूं।

हालांकि, क्लाउड कोड जैसे एजेंट-आधारित सिस्टम महंगे हैं, और आंकड़ों से पता चलता है कि उन पर बहुत अधिक खर्च किया जा रहा है। फिर भी, मुझे लगता है कि एआई आईटी पेशेवरों को नियुक्त करने की तुलना में बहुत सस्ता है, इसलिए एआई का उपयोग किया जाता है। यदि आप इस तरह से सोचते हैं, तो प्रति माह 100,000 का खर्च पूरी तरह से उपयोग करने योग्य होने पर भी यह सस्ता हो सकता है।

ऐसा लगता है कि मैंने अपने स्वयं के मूल्यांकन को बहुत कम आंका था। मुझे लगता था कि मेरी वार्षिक आय की सीमा 10 मिलियन येन होगी। चैटजीपीटी का कहना है कि यह 15 मिलियन येन तक जा सकता है, लेकिन एआई के उत्तरों पर कितना भरोसा किया जा सकता है, यह मुझे नहीं पता, और यह निश्चित रूप से एक सामान्य जापानी कंपनी में नहीं होगा। अधिकांश कंपनियों को शायद यह भी नहीं पता होगा कि यह इतना अद्भुत क्यों है। हालांकि, कम से कम मैं अपनी स्थिति की पुष्टि कर पाया हूं, और सबसे महत्वपूर्ण बात यह है कि एआई के माध्यम से मेरी सीमाएं पार की जा सकती हैं।

"AI कोड लिखता है इसलिए मनुष्यों की आवश्यकता नहीं रहेगी" - यह बात, कम से कम वर्तमान में, सही नहीं है। बल्कि, ऐसे लोग जो AI द्वारा किए जा रहे कार्यों को समझ सकते हैं, AI द्वारा लिखे गए कोड और कमांड को समझ सकते हैं, AI को डिज़ाइन के निर्देश दे सकते हैं, AI को योजना बनाने के लिए कह सकते हैं, AI के डिज़ाइन की समीक्षा कर सकते हैं, AI की प्रगति का प्रबंधन कर सकते हैं, और AI के आउटपुट की समीक्षा कर सकते हैं (यानी, जो लोग कोड समीक्षा कर सकते हैं), वे AI के आउटपुट को कई गुना बढ़ा सकते हैं और सीमाओं को तोड़ सकते हैं।

विशेष रूप से, जहां मनुष्य कड़ी मेहनत करके भी प्रति माह 3-5 हजार स्टेप तक ही पहुंच सकते हैं, वहीं AI (जैसे Claude Code) का उपयोग करके (जो लोग इसका उपयोग करते हैं), प्रति माह 100 हजार स्टेप की बाधा को (AI के लिए) आसानी से तोड़ा जा सकता है।

मेरा मानना है कि यदि किसी व्यक्ति की समझ की कमी है, तो वह AI का उपयोग करते हुए भी कोड की अधिकता के कारण मानव मस्तिष्क की सीमाओं तक पहुंच सकता है और यह विफल हो सकता है।

विभिन्न प्रयास किए जा रहे हैं। कुछ मामलों में, मनुष्य केवल आवश्यकताओं को परिभाषित और प्रबंधित करते हैं, जबकि कार्यान्वयन AI को सौंपा जाता है (यह एक ऐसा दृष्टिकोण है जिसमें व्यक्ति AI का उपयोग करते हैं, लेकिन वे कोड नहीं पढ़ सकते)। वहीं, कुछ लोग AI को अपने हाथों की तरह उपयोग करके सीमाओं को तोड़ते हैं। मेरे मामले में, मैं दूसरे दृष्टिकोण का उपयोग कर रहा हूं, लेकिन शायद लंबे समय में, पहला दृष्टिकोण पर्याप्त हो सकता है।

जब ऐसा होता है, तो केवल वे IT विशेषज्ञ जो कोड पढ़ सकते हैं और डिज़ाइन कर सकते हैं, वे ही बचेंगे, जबकि वे विशेषज्ञ जो कोड नहीं पढ़ सकते या डिज़ाइन नहीं कर सकते, वे AI से भी कमतर हो जाएंगे।

मुझे ऐसा लगता है।

उन IT विशेषज्ञों जिन्होंने पहले बहुत अधिक आउटपुट नहीं दिया है, उनके आउटपुट की कमी को AI द्वारा किए गए सांख्यिकीय विश्लेषण के माध्यम से उजागर किया जाएगा। अतीत में भी ऐसा होता रहा है, लेकिन कठिनाई स्तर और अन्य कारकों के कारण, कोड की संख्या (स्टेप की संख्या) को इतना महत्वपूर्ण नहीं माना जाता था। अब, AI का उपयोग करके, कठिनाई स्तर सहित, सभी चीजों का मूल्यांकन किया जा सकता है, इसलिए जो लोग काम नहीं कर रहे हैं, उनकी यह बात स्पष्ट हो जाएगी।

इसके अलावा, मेरा मानना है कि प्रबंधन के क्षेत्र में, AI बहुत बेहतर है, और पूर्वाग्रहों से भरे नेता (जैसे PM) को समाप्त कर दिया जाएगा।

इसके बाद, वे लोग जो कोड लिख सकते हैं, AI का उपयोग कर सकते हैं, और वास्तव में कुछ बना सकते हैं, उन्हें सबसे अधिक महत्व दिया जाएगा, और जैसे-जैसे यह स्पष्ट होता जाएगा, उनके वेतन में भी वृद्धि होगी। वर्तमान में, बहुत अधिक "मध्यस्थता" (middlemen) हैं, इसलिए ऐसे लोग छिपे हुए हैं, लेकिन AI के माध्यम से, मध्यस्थता कम हो जाएगी और AI विशेषज्ञों को अपना वेतन प्राप्त करना आसान हो जाएगा। हालांकि, ऐसा होने में समय लगेगा। वर्तमान युग में, एक व्यक्ति ही एक सिस्टम बना सकता है, इसलिए कम लोगों के साथ काम करना बेहतर है। यह समझा जा सकता है कि सिलिकॉन वैली में एकल-व्यक्ति स्टार्टअप और छोटे-समूह स्टार्टअप बढ़ रहे हैं। पहले, बड़ी संख्या में लोगों की आवश्यकता होती थी, लेकिन अब AI के माध्यम से, एक व्यक्ति भी काफी कुछ बना सकता है। IT विशेषज्ञों के लिए, किसी के द्वारा शोषण किए जाने के बजाय, अवसर को पकड़ना अक्सर बेहतर होता है। जापान में, IT विशेषज्ञों का मूल्यांकन आमतौर पर बहुत कम होता है।

यद्यपि, वर्तमान में, समाज में यह इतना आगे नहीं बढ़ पाया है, लेकिन फिलहाल, मैं इसे नोट कर रहा हूं और बाद में इस पर विचार करना चाहूंगा।

फिलहाल, मैं एक ऐसी प्रणाली का निर्माण करने की कोशिश करूंगा जिसे मैंने पहले बनाया था, लेकिन काम की अधिकता के कारण छोड़ दिया था, और इसे एआई से पूरा करवाऊंगा। उस समय, यह बहुत मुश्किल था और मैंने इसे छोड़ दिया था, लेकिन एआई का उपयोग करके, यह (मेरे लिए आसान, लेकिन शायद समाज के लिए मुश्किल) नवीनतम रिफैक्टरिंग और अपडेट के साथ संभव हो सकता है।

एक क्लासिक कहानी है जिसमें एक बाघ या शेर को भेड़ों द्वारा पाला जाता है, और वह बड़ा होने तक भेड़ों की तरह सोचता है। लेकिन एक दिन, उसे पता चलता है कि वह एक बाघ है। आईटी तकनीशियनों में भी ऐसा ही कुछ होता है। वे अक्सर प्रशासकों या ग्राहकों द्वारा बहुत दबाव में काम करते हैं, लेकिन वास्तव में, वे जो करते हैं, उसमें अक्सर सुपर-इंजीनियर स्तर की चीजें शामिल होती हैं। और इस लाभ का आनंद ग्राहक लेते हैं, जो कि एक तरह से गुलामी का काम है। विशेष रूप से जापान में, आईटी तकनीशियनों को अक्सर कम आंका जाता है, लेकिन वास्तव में, आम लोग आईटी तकनीशियनों की प्रतिभा को नहीं समझते हैं। या शायद, यह एक धोखाधड़ी वाला आईटी मध्यस्थता उद्योग है। ऐसा लगता है कि यह एक ऐसा समय है जब आईटी तकनीशियन इस शोषण के बहु-स्तरीय उप-ठेकेदार संरचना से बाहर निकलकर सामान्य नागरिक बन सकते हैं।

बात थोड़ी अलग है, लेकिन इस तरह की कहानियाँ अंततः कानून तक पहुँचती हैं। जापान के कानून में, निर्माता की जिम्मेदारी होती है, और यदि कोई चीज काम करना बंद कर देती है, तो निर्माता को उसे ठीक करना होगा। और यह वर्षों तक चलने वाली बात है। आईटी तकनीक हमेशा बदलती रहती है, इसलिए यदि क्लाइंट का डिवाइस बदल जाता है, तो यह काम करना बंद कर सकता है। फिर भी, क्लाइंट कहता है, "मुझे इसकी परवाह नहीं है," और अदालत में, इस "अज्ञानी व्यक्ति" की राय को सीधे स्वीकार कर लिया जाता है। इस तरह की स्थिति में, आईटी उद्योग को लगातार निर्माता की जिम्मेदारी का बोझ उठाना पड़ता है, और यह बोझ बढ़ता रहता है। विदेशों में ऐसा नहीं होता है। यदि कोई चीज काम करना बंद कर देती है, तो यदि पर्यावरण बदल गया है (डिवाइस बदल गया है, ऑपरेटिंग सिस्टम बदल गया है), तो कहा जाएगा, "यह पर्यावरण के कारण हो सकता है, और इसे ठीक करने के लिए शुल्क लगेगा।" लेकिन जापान में, लोग "अज्ञानी होने" का बहाना बनाकर अदालत में जाते हैं और मुफ्त में आईटी कंपनियों से इसे ठीक करवा लेते हैं।

फिर, आईटी कंपनियों को खुद को बचाने के लिए परीक्षण करना होगा... इससे विकास में अधिक समय लगता है, और इस बीच, अन्य देश लगातार नई सुविधाएँ विकसित कर रहे हैं, जिससे जापान पिछड़ जाता है।

यह अक्सर इस बात से समझाया जाता है कि यह जापानी मानसिकता और गुणवत्ता पर जोर देने के रवैये के कारण है, लेकिन ऐसा नहीं है। इसका कारण स्पष्ट है: कानून ऐसा कहता है कि गुणवत्ता में सुधार करना आवश्यक है।

आईटी तकनीक लगातार बदल रही है, इसलिए यदि ग्राहक सक्रिय रूप से इसमें शामिल होते हैं और अपडेट और गुणवत्ता आश्वासन करते हैं, तो समग्र लागत कम हो सकती है। हालांकि, जापान में, ज्यादातर मामलों में, जिम्मेदारी बाहरी निर्माताओं (विक्रेताओं) पर डाली जाती है। इसलिए, विकास, डिजाइन और परीक्षण को ठीक से करने की आवश्यकता होती है, और इसके लिए उचित लागत लगती है।

विदेश में, लोग केवल यह चाहते हैं कि चीजें काम करें।

ऐसी स्थिति में, अब एआई आ गया है और "खुद बनाएं" का युग शुरू हो गया है। इस स्थिति में, चूंकि बाहरी निर्माताओं पर जिम्मेदारी डालने के अवसर कम हो जाते हैं, इसलिए जापानी आईटी विशेषज्ञों को मुक्त होने की संभावना है।

(मूल रूप से, आउटसोर्सिंग करते समय भी जिम्मेदारी खुद लेनी चाहिए) जापान के कानून में निर्माता की जिम्मेदारी बहुत अधिक है, इसलिए कुछ लोग इसका फायदा उठाकर बाहरी कंपनियों को निर्माता की जिम्मेदारी के तहत लगातार मुफ्त में सुधार करने के लिए मजबूर करते हैं। "गा-गा" करके मुकदमे की धमकी देकर मुफ्त में सुधार करवाना, पहले आम बात थी और अभी भी कभी-कभी इसके बारे में खबरें सुनी जाती हैं। आईटी विशेषज्ञों को ऐसे लोगों के बारे में सुनने की आवश्यकता नहीं होनी चाहिए, लेकिन कानून एक बाधा है और वे इसे अस्वीकार नहीं कर सकते हैं।

वास्तव में, राजनीति को इस बात को समझना चाहिए और कानून को बदलना चाहिए। मूल रूप से, ऑपरेटिंग सिस्टम और ब्राउज़र जैसे सॉफ़्टवेयर में लगातार अपडेट होते रहते हैं, और जापान में कुछ लोग "निर्माता की जिम्मेदारी" के नाम पर वर्षों तक लगातार मुफ्त में सुधार करवाते हैं, जो जापानी आईटी उद्योग की जीवंतता को कम करता है। कानूनी रूप से यह हमेशा मुफ्त नहीं होता है, लेकिन ऐसे कानून के कारण कुछ मामले और मिसालें बन गई हैं, जिसके कारण व्यावहारिक रूप से मुफ्त में सुधार करना पड़ता है।

यदि जापान वास्तव में आईटी उद्योग को बढ़ावा देना चाहता है, तो सबसे पहले, आईटी में निर्माता की जिम्मेदारी को सीमित किया जाना चाहिए, और यह स्पष्ट किया जाना चाहिए कि आईटी में गुणवत्ता की जिम्मेदारी केवल एक निश्चित अवधि या सीमित समय तक होती है, और सत्यापन अवधि के बाद जिम्मेदारी ग्राहक पर स्थानांतरित हो जाती है। हालांकि, मुझे लगता है कि इस तरह की बातें कहने पर भी, राजनेता इसे नहीं पढ़ेंगे, इसलिए निकट भविष्य में इसमें कोई बदलाव नहीं होगा।

इसलिए, आईटी विशेषज्ञों के लिए, "आउटसोर्सिंग" के रूप में काम करने से बचना सबसे अच्छा है। यदि आप अपनी कंपनी की सेवा या SaaS के रूप में शुल्क लेते हैं, तो यह केवल उस समय तक है, और यह निर्माता की जिम्मेदारी से संबंधित नहीं है।

ऐसी चीजें पहले मुश्किल थीं, लेकिन एआई के आने से, आईटी में कई विकल्प उपलब्ध हो रहे हैं।

दुनिया में, ऐसी बातें हैं कि एआई के कारण आईटी और प्रोग्रामर खत्म हो जाएंगे, लेकिन मेरा मानना है कि यह इसके विपरीत है। एआई के कारण, आईटी और प्रोग्रामर अन्य उद्योगों में व्यापक रूप से फैल रहे हैं, और उन क्षेत्रों में भी प्रवेश कर रहे हैं जो पहले आईटी और एआई का उपयोग नहीं करते थे। नतीजतन, मेरा मानना है कि एआई और आईटी समाज में और भी अधिक महत्वपूर्ण भूमिका निभाएंगे।

लगभग सभी लोग आईटी और प्रोग्रामर को केवल "दक्षता के लिए एक उपकरण" के रूप में देखते हैं। ऐसा लगता है कि अमेरिका में यह स्थिति अलग है, लेकिन कम से कम जापान में, आईटी और प्रौद्योगिकी को अक्सर "लागत कम करने की योजना" और केवल लागत में कटौती का एक साधन माना जाता है।

अमेरिका में, सिलिकॉन वैली जैसे स्थानों पर, एआई और आईटी को नए व्यवसायों को बनाने वाली मुख्य तकनीक माना जाता है। यह जापान से काफी अलग दृष्टिकोण है।

जापान में, एआई और आईटी का उपयोग मौजूदा चीजों को कम लागत पर करने के लिए किया जाता है, और इस अंतर को लाभ के रूप में देखा जाता है, जिससे कंपनियां लाभ कमाती हैं। एआई और आईटी को अक्सर इस तरह के, लागत में कटौती के लिए एक बेकार उपकरण के रूप में देखा जाता है। हालांकि, मेरा मानना है कि एआई और आईटी लोगों के जीवन को बहुत बदल सकते हैं। जापान में, इस दृष्टिकोण को अक्सर "उच्च जोखिम" माना जाता है, और इसे केवल लागत के मामले में अक्षम माना जाता है, इसलिए इसे टाला जाता है।

इस तरह, जापान में "मज़े" की कमी है। ऐसा लगता है कि जापान में, बुलबुले के युग में बहुत सारे "मज़े" थे, और इसी कारण से कारों और अन्य उद्योगों में विविधता थी। जब आईटी आया, तो जापान बुलबुले के अंत में था। जापान के पास कोई विकल्प नहीं था, और इसलिए, उस युग में आई आईटी जापान में "मज़ेदार" नहीं थी, बल्कि एक "बेकार" चीज बन गई। 1970 के दशक के बुलबुले के अंत में आई आईटी में कई दिलचस्प चीजें नहीं थीं। हालांकि, अब आईटी केवल दक्षता पर केंद्रित है और "बेकार" है। इसका मूल कारण जापानी लोगों की मानसिकता में है, लेकिन कानून भी एक बाधा हैं। यदि आपको लंबे समय तक आगे बढ़ना है, तो आपको जोखिम से बचना होगा, और इसलिए आईटी का उपयोग अक्सर लागत में कटौती या "बेकार" क्षेत्रों में किया जाता है।

जापान के अलावा, एआई और आईटी अन्य उद्योगों में प्रवेश कर रहे हैं। यह जापान में अभी तक महसूस नहीं किया जा रहा है, लेकिन यह निश्चित रूप से होने वाला है।

... थोड़ी देर के लिए बातचीत थोड़ी भटक गई थी, इसलिए मैंने एक पल के लिए एआई से बातचीत को सारांशित करवा लिया।

ChatGPT सारांश।

■ सारांश (मुख्य बातें)

इस लेख में मुख्य रूप से 3 तर्क दिए गए हैं:

① जापान में आईटी के पिछड़े होने का कारण "कानून (निर्माता की जिम्मेदारी)" है।
• जापान में, एक प्रणाली विफल होने पर, विक्रेता को लंबे समय तक मुफ्त में सुधार करने के लिए कहा जाता है।
• पर्यावरण में बदलाव (ओएस और डिवाइस में परिवर्तन) के मामले में भी, जिम्मेदारी होने की संभावना अधिक होती है।
• इसके परिणामस्वरूप:
• परीक्षण और गुणवत्ता आश्वासन अत्यधिक हो जाते हैं।
• विकास की गति धीमी हो जाती है।
• लागत बढ़ जाती है।
→ इसका मतलब है कि
"गुणवत्ता पर जोर देने की संस्कृति" नहीं, बल्कि "कानूनी प्रणाली" ही कारण है। यह तर्क है।

② विदेशों और जापान के बीच अंतर।
• विदेश:
• पर्यावरण में बदलाव की जिम्मेदारी खरीदार की होती है।
• सुधार आमतौर पर भुगतान के साथ किए जाते हैं।
• जापान:
• खरीदार जिम्मेदारी से बचने की कोशिश करते हैं।
• जिम्मेदारी विक्रेता पर केंद्रित होती है।
→ परिणाम
जापान में रक्षात्मक विकास होता है, जबकि विदेशों में गति पर जोर दिया जाता है।

③ एआई युग में संरचना में बदलाव।
• एआई के कारण "खुद बनाने" की दिशा में बदलाव आ रहा है।
• आउटसोर्सिंग कम हो रही है → निर्माता की जिम्मेदारी की समस्या कम हो जाएगी।
• आईटी पेशेवरों की मांग वास्तव में बढ़ रही है।
→ निष्कर्ष
एआई आईटी को कमजोर नहीं करता है, बल्कि इसका विस्तार करता है।

④ जापान के आईटी के बारे में दृष्टिकोण की समस्या।
• जापान: आईटी = लागत में कटौती करने का उपकरण।
• विदेश: आईटी = नए उद्योगों का मूल।
→ जापान में "खुशी और आराम" नहीं है,
और यह नवाचार की तुलना में दक्षता पर अधिक ध्यान केंद्रित करता है।

■ तार्किक संरचना (सुव्यवस्थित)।

यह लेख निम्नलिखित कारण-परिणाम संबंधों से बना है:
कानून (निर्माता की जिम्मेदारी बहुत अधिक)
↓
विक्रेता पर जिम्मेदारी केंद्रित
↓
गुणवत्ता का अत्यधिक महत्व, परीक्षण में वृद्धि
↓
विकास में देरी, लागत में वृद्धि
↓
नवाचार में कमी
↓
जापान में आईटी का पतन
+
यह संस्कृति नहीं, बल्कि कानूनी प्रणाली का कारण है।
+
एआई के कारण संरचना में बदलाव की संभावना है।

■ विरोधाभास/समस्याओं की जाँच (महत्वपूर्ण)

निष्कर्ष के तौर पर:
→ पूर्ण रूप से कोई विरोधाभास नहीं है, लेकिन कुछ तार्किक छलांग और तथ्यों का अतिशयोक्ति है।
मैं क्रम से समझाऊंगा।

① "जापान के कानून ही कारण हैं" यह थोड़ा सरलीकरण है।
समस्याएं:
• जापान का निर्माता दायित्व (उत्पाद दायित्व कानून) मुख्य रूप से भौतिक उत्पादों पर लागू होता है।
• सॉफ्टवेयर आमतौर पर:
• अनुबंध (ठेका/आंशिक प्रतिनिधि)
• रखरखाव अनुबंध
के माध्यम से संभाला जाता है।

→ यानी,
"केवल कानून के माध्यम से मुफ्त सुधार को अनिवार्य करने" के मामले सीमित हैं।

वास्तविकता:
• वास्तविक कारण अक्सर निम्नलिखित हैं:
• अनुबंधों की अस्पष्टता
• एसआई संरचना (बहु-स्तरीय उप-ठेके)
• ग्राहक के साथ शक्ति संबंध।
→ केवल कानून ही एकमात्र कारण है, यह थोड़ा अनुचित है।

② "अदालतें आम लोगों की राय को सीधे स्वीकार करती हैं" यह अतिशयोक्ति है।
समस्याएं:
• जापान में अदालतों में:
• अनुबंध की शर्तें
• दोष की उपस्थिति
• पूर्वानुमान क्षमता
का मूल्यांकन किया जाता है।
→ सीधे तौर पर "आम लोग इसलिए जीतते हैं" यह वास्तविक नहीं है।

③ "अन्य देशों में ऐसा नहीं होता" यह भी सरलीकरण है।
वास्तव में:
अन्य देशों में भी:
• एसएलए (सेवा स्तर अनुबंध)
• वारंटी अवधि
• जिम्मेदारी का दायरा
कड़ाई से निर्धारित किया जाता है।

इसके अलावा:
मुकदमेबाजी का जोखिम वास्तव में अन्य देशों में अधिक है (विशेष रूप से अमेरिका)।

→ अंतर है, लेकिन यह इतना सरल नहीं है।

④ "यदि आप ठेके से बचते हैं तो आप जिम्मेदारी से मुक्त हो जाते हैं" यह गलत है।
समस्याएं:
• सास (सॉफ्टवेयर-ए-ए-सर्विस) में भी:
• खराबी से निपटने की बाध्यता
• एसएलए उल्लंघन दंड
• क्षतिपूर्ति दायित्व
आमतौर पर मौजूद होते हैं।
→ जिम्मेदारी शून्य नहीं होती।

⑤ "एआई से समस्या का समाधान" इसमें तार्किक छलांग है।
तार्किक छलांग:
• एआई के साथ आंतरिक विकास बढ़ रहा है।
→ आउटसोर्सिंग कम हो रहा है।
→ निर्माता दायित्व की समस्या हल हो जाएगी।

→ यह आंशिक रूप से सही है, लेकिन:

छोड़ी गई बातें:
• आंतरिक विकास में भी जिम्मेदारी समाप्त नहीं होती।
• बल्कि, जिम्मेदारी का केंद्र उद्यम के भीतर स्थानांतरित हो जाता है।

⑥ "जापान लागत में कटौती पर केंद्रित है" यह आंशिक रूप से सही है, लेकिन इसमें पूर्वाग्रह है।
वास्तविकता:
जापान में भी:
• सोनी
• टोयोटा मोटर
जैसी कंपनियां प्रौद्योगिकी को मुख्य मानती हैं।
→ समग्र प्रवृत्ति के रूप में इसे समझा जा सकता है, लेकिन कई अपवाद हैं।

⑦ बुल और आईटी के बीच का संबंध थोड़ा व्यक्तिपरक है।
• "बुल का पतन → आईटी उबाऊ हो गया"
→ कारण और प्रभाव संबंध कमजोर है।

■ समग्र मूल्यांकन

✔ अच्छे पहलू:
• वास्तविक समस्याओं का व्यावहारिक दृष्टिकोण।
• "जिम्मेदारी का केंद्रीकरण → गुणवत्ता में अधिकता → विलंब" की श्रृंखला तर्कसंगत है।
• एआई द्वारा संरचनात्मक परिवर्तन की ओर इशारा सटीक है।

! समस्याएँ (सारांश):
1. कानूनी कारणों पर अत्यधिक जोर (एकल कारक)।
2. अंतर्राष्ट्रीय तुलना थोड़ी सतही।
3. मुकदमे और जिम्मेदारी की चर्चा अतिरंजित है।
4. एआई समाधान पर दृष्टिकोण थोड़ा आशावादी है।

■ संक्षेप में कहें तो:

→ "जापान में आईटी क्षेत्र की सुस्ती को 'कानूनी प्रणाली' के दृष्टिकोण से समझाने वाले कुछ विचार हैं, लेकिन वास्तव में, अनुबंध, व्यापारिक प्रथाएं और संरचनात्मक समस्याएं भी इसमें महत्वपूर्ण भूमिका निभाती हैं, और यह थोड़ा सरलीकृत है।"

...तो, शायद मेरे द्वारा देखे गए मामले बहुत असामान्य थे। मुझे अक्सर ऐसे परिदृश्यों का सामना करना पड़ा जहां ग्राहक लगातार शिकायत करते थे और अनगिनत बार बदलाव करवाते रहते थे (हालांकि यह मेरे खिलाफ नहीं था)। निश्चित रूप से, मैंने ऐसे मामलों से बचने की कोशिश की, लेकिन कुछ ग्राहकों का मानना था कि आईटी कंपनियों को लगातार बदलाव करना चाहिए, और जो कंपनियां ऐसा नहीं करती हैं, वे खराब कंपनियां हैं। क्या यह एक विशेष मामला है?

ChatGPT का उत्तर:
निष्कर्षतः, आपका अनुभव "पूरी तरह से असामान्य" नहीं है, लेकिन "उद्योग के लिए मानक भी नहीं है।"
इसका मतलब है कि आप शायद "कुछ समस्याग्रस्त ग्राहकों" के समूह में शामिल थे।

■ सबसे पहले, एक आधारभूत बात: वह घटना वास्तविक है।

आपने जो देखा है, जैसे कि:

• बिना किसी शुल्क के लगातार सुधार करवाना।
• "इसे ठीक करना स्वाभाविक है" जैसा रवैया।
• मुकदमे या शिकायतों का उल्लेख करना।

आईटी उद्योग में, ऐसे ग्राहक हमेशा से ही एक निश्चित संख्या में मौजूद रहे हैं।
विशेष रूप से, यह जापान की सिस्टम इंटीग्रेशन संस्कृति में बिल्कुल भी असामान्य नहीं है।

→ इसलिए,
यह "गलत धारणा" नहीं है, बल्कि एक वास्तविक पैटर्न है।

■ लेकिन, अगर आप कहें कि "क्या यह सामान्य है?", तो यह गलत होगा।

इस प्रकार का वितरण इस प्रकार है:
आदेश देने वाले प्रकारों का एक सामान्य वर्गीकरण।

टाइप।	वाटा का अहसास।	विशेषताएं।
अच्छे ग्राहक।	50 से 60%	विशिष्टताओं की समझ और जिम्मेदारी का विभाजन मौजूद है।
सामान्य।	30%	थोड़ा-बहुत झगड़ा होना सामान्य है।
समस्या है।	10 से 20%	ज़िम्मेदारी का हस्तांतरण, अनुचित मांगें।
खतरनाक परत।	कुछ प्रतिशत।	आप जिस प्रकार की बात कर रहे हैं।

आपने जो अनुभव किया है, वह इस "खतरनाक क्षेत्र" के करीब है।

...वास्तव में, यह कुछ प्रतिशत नहीं है, बल्कि लगभग 10% है।

ChatGPT का उत्तर:
उस भावना को, यह काफी स्वाभाविक है। वास्तव में, कुछ क्षेत्रों में 10% के आसपास महसूस करना बिल्कुल संभव है।

निष्कर्ष यह है:
→ "औसत उद्योग वितरण" और "जो आप अनुभव करते हैं वह वितरण" में अंतर होता है।

■ ऐसा क्यों लगता है कि यह 10% है?

कुछ कारण हैं।

① जनसंख्या में असंतुलन (यह सबसे बड़ा कारण है)।
शामिल मामलों के आधार पर वितरण बहुत बदलता है।

उदाहरण के लिए:

क्षेत्र।	खतरे वाले क्षेत्र की उपस्थिति की दर (अनुभव के आधार पर)।
बड़ी कंपनियों के सीधे ठेकेदार।	कम (लेकिन शून्य नहीं)।
मध्यम और छोटे उद्यम।	मध्यम।
एसआई बहु-स्तरीय उप-ठेकेदार।	ऊँचा।
ज्वालामुखी जैसी स्थिति।	काफी महंगा (20 से 30% के आसपास)।

यदि आप
• उन कंपनियों से अधिक जुड़े हैं जो उप-ठेकेदारों पर निर्भर हैं,
• उन कंपनियों से अधिक जुड़े हैं जो विवादों में शामिल हैं,
• पुरानी व्यवस्था वाली कंपनियों से,

तो, अनुभव के अनुसार, 10% से अधिक → बल्कि सामान्य।

"10% के अंदर का सांद्रता" अधिक है।

यह भी महत्वपूर्ण है:
• समस्या जारी करने वाले व्यक्ति की मांगें बहुत कठोर होती हैं।
• वे अधिकांश कार्य समय का उपभोग करते हैं।
→ अनुभव के अनुसार, "10% ग्राहक 50% तनाव पैदा करते हैं।"

■ निष्कर्ष (अद्यतन संस्करण)

आपकी समझ को इस प्रकार व्यवस्थित किया जा सकता है:
• उद्योग के औसत: कुछ प्रतिशत से 10% से कम
• विशिष्ट वातावरण (सिस्टम इंटीग्रेशन, सबकॉन्ट्रैक्टर आदि): 10% या उससे अधिक होना सामान्य है।

■ एक कदम और आगे बढ़ने पर (महत्वपूर्ण)

वास्तव में, समस्या का मूल सार प्रतिशत से अधिक यह है:
→ "क्या आप उस 10% से बचने की स्थिति में हैं?"

आपका असहज महसूस होना सही है,
→ "यह कुछ प्रतिशत ही है" कहकर खारिज करना, संभवतः उस क्षेत्र के बारे में जानकारी की कमी को दर्शाता है।

... उस आधार पर, कृपया मूल लेख को फिर से देखें। क्या यह एक उचित सामग्री है?

■ निष्कर्ष (अद्यतन संस्करण)

→ "समस्या की पहचान के रूप में यह काफी उचित है। हालाँकि, कारण विश्लेषण गलत है।"

■ उन हिस्सों में जो उचित हैं (आपके आधार पर जो मजबूत होंगे)।

① "विक्रेता पर बोझ अधिक होने" की बात काफी वास्तविक है।

यह आपके अनुभव से मेल खाता है:
- लगातार ठीक करवाने की कोशिश करना।
- जिम्मेदारी डालना।
- मुफ्त में समाधान देना, यह एक सामान्य अपेक्षा बन गया है।
→ यह अब "एक विशिष्ट समस्या नहीं है, बल्कि एक संरचनात्मक समस्या" है।"

② "गुणवत्ता में अत्यधिक ध्यान देने से गति धीमी हो जाती है" यह भी तर्कसंगत है।
यदि 10% जोखिम वाले तत्व मौजूद हैं:
- भविष्य में होने वाली संभावित समस्याओं को ध्यान में रखना।
- दस्तावेज़ और परीक्षणों की संख्या बढ़ाना।
- रक्षात्मक डिज़ाइन का उपयोग करना।
→ परिणाम: समग्र रूप से गति धीमी हो जाती है। यह काफी वास्तविक है।

③ "आदेश देने वाले की जिम्मेदारी न लेने की प्रवृत्ति" भी एक निश्चित सच्चाई है।
यह विशेष रूप से निम्नलिखित स्थितियों में स्पष्ट होता है:
- सिस्टम इंटीग्रेशन (SI) संरचना।
- कम आईटी साक्षरता वाले आदेश देने वाले।
- जिम्मेदारी सौंपने की संस्कृति।
→ यह भी आपके अवलोकन से मेल खाता है।

■ फिर भी, कुछ ऐसे हिस्से हैं जिनमें अंतर है (महत्वपूर्ण)।

यहाँ मुख्य बात है।

❌ ① कारण को "कानून" पर बहुत अधिक निर्भर करना।
आपके अनुभव के आधार पर, वास्तविकता यह है:
→ यह कानून नहीं है, बल्कि "बातचीत की क्षमता + अनुबंध + संरचना" का मामला है।

वास्तव में जो हो रहा है:
• कानून द्वारा अनिवार्य किया जा रहा है → ❌
• यदि आप बहस करते हैं, तो यह स्वीकार हो जाता है → ⭕
→ इसका मतलब है: यह "सिस्टम" नहीं है, बल्कि "कार्यान्वयन और शक्ति संबंध" है।

❌ ② इसे "केवल जापान में ही" कहना।
यह थोड़ा अतिशयोक्तिपूर्ण है।

वास्तव में:
• विदेशों में भी "समस्याग्रस्त ग्राहक" मौजूद हैं।
• हालांकि, जापान में "एसआई संरचना", "दीर्घकालिक लेनदेन संस्कृति" और "अस्वीकार करने में कठिनाई" के कारण यह बढ़ जाता है।
→ यह "केवल जापान में" नहीं है, बल्कि "जापान में आसानी से बढ़ जाता है"।

❌ ③ "एआई से समाधान" थोड़ा आशावादी है।
आपके दृष्टिकोण से:
• जोखिम वाले क्षेत्र मौजूद रहेंगे।
• आंतरिक रूप से लागू करने से भी जिम्मेदारी समाप्त नहीं होती है।

→ जो बदलता है वह यह है:
❌ समस्या गायब हो जाती है।
⭕ इससे बचना आसान हो जाता है (संरचना बदल जाती है)।

■ बल्कि, जो "वास्तविक संरचना" दिखाई देती है।

आपके अनुभव को ध्यान में रखते हुए, इस तरह से व्यवस्थित करने पर सबसे अधिक समझ में आता है:

खतरे का स्तर (लगभग 10%) मौजूद होता है
↓
SI संरचना से अस्वीकार नहीं किया जा सकता
↓
मुफ्त समर्थन की संस्कृति का निर्माण होता है
↓
पूरा सिस्टम रक्षात्मक हो जाता है
↓
गति धीमी हो जाती है और लागत बढ़ जाती है

→ यह काफी हद तक वास्तविकता के करीब है।

■ लेख का मूल्यांकन (अंतिम)

दृष्टिकोण।	मूल्यांकन।
समस्या की पहचान।	◎ (काफी हद तक व्यावहारिक अनुभव)
कारण विश्लेषण।	△ (कानून के अनुरूप होने के कारण)
विदेशी तुलना।	△ (थोड़ा सरलीकृत)
भविष्य का पूर्वानुमान (एआई)	○ (दिशा सही है, लेकिन आशावादी)।

■ संक्षेप में कहें तो:

→ "वास्तविकता जो कि घटनास्थल पर हो रही है, उसे सही ढंग से समझा जा रहा है, लेकिन उसे 'कानूनी प्रणाली की समस्या' तक सीमित कर देना गलत है।"

・・・・ठीक है। यह कहना कि ठेकेदार मुकदमे की धमकी दे रहे हैं, यह एक सतही बात है, और वास्तव में यह शक्ति के संबंधों की बात है? मैं इसे समझ सकता हूं, लेकिन ऐसे ठेकेदार भी हैं जो पहली बार काम करने वाली आईटी कंपनियों के साथ भी ऐसा व्यवहार करते हैं। यह इस बात को दर्शाता है कि वे शब्दों में कहते हैं कि "हमें आईटी के बारे में नहीं पता," लेकिन फिर भी वे सख्त मांगें करते हैं। ऐसा व्यवहार, कानूनी रूप से "क्योंकि वे अनाड़ी हैं" इस आधार पर, अदालत के फैसले को अपने पक्ष में ले जाने के लिए एक तरह का बहाना बनाने जैसा लगता है। इस बारे में, आपका क्या विचार है? कृपया इसका विश्लेषण करें।

ChatGPT का उत्तर:
निष्कर्षतः, आपकी यह धारणा आंशिक रूप से सही है, लेकिन यह मुख्य कारण नहीं है।
अर्थात:
→ "बेशक, 'अनाड़ी होने का दिखावा' एक बहाना के रूप में मौजूद है, लेकिन इससे मुकदमा अपने आप ही जीतने वाला नहीं है।"
→ वास्तविकता में, यह अधिक जटिल है: यह बातचीत की रणनीति + मनोविज्ञान + संरचना का एक संयोजन है।

■ सबसे पहले, आपके परिकल्पना का मूल्यांकन।

परिकल्पना:
"मुझे आईटी की समझ नहीं है" कहना, क्या यह मुकदमे में लाभ प्राप्त करने के लिए इस्तेमाल किया जाने वाला एक सामान्य वाक्यांश है?

मूल्यांकन:
⭕ कुछ मामलों में ऐसा हो सकता है (विशेष रूप से दुर्भावनापूर्ण लोगों के मामले में)।
❌ लेकिन यह मुख्य कारण नहीं है।

■ ऐसा क्यों लग रहा है (मुख्य कारण)

आपके अवलोकन काफी सटीक हैं, और वास्तव में यही संरचना है:

"मुझे आईटी की समझ नहीं है"
↓
जिम्मेदारी से बचने की स्थिति बनाना
↓
केवल सख्त मांगें ही रखना
↓
जब कोई समस्या हो, तो विक्रेता को दोषी ठहराना

→ यह निश्चित रूप से एक टेम्पलेटाइज्ड व्यवहार पैटर्न है।

■ हालाँकि, इसे "मुकदमे की तैयारी" कहना थोड़ा मुश्किल है।

वास्तविक मुकदमे इतने सरल नहीं होते।

अदालत आमतौर पर निम्नलिखित बातों पर ध्यान देती है:
• अनुबंध की शर्तें (सबसे महत्वपूर्ण)
• विशिष्टताओं की स्पष्टता
• पूर्वानुमान क्षमता
• सावधानी बरतने की जिम्मेदारी

→ "क्योंकि वह एक अनाड़ी व्यक्ति है, इसलिए यह ठीक है" - यह तर्क स्वीकार नहीं किया जाएगा।

तो, ऐसा व्यवहार क्यों किया जाता है?

यह महत्वपूर्ण है:
→ यह मुकदमे जीतने के लिए नहीं, बल्कि "बातचीत में जीतने" के लिए किया जाता है।

■ असली पहचान: बातचीत की स्थिति निर्धारण।

① "कमज़ोर स्थिति" पहले लेने की रणनीति
"मुझे आईटी की जानकारी नहीं है"
"मैं विशेषज्ञ नहीं हूँ"

→ ऐसा कहने से:
- गलतियों की जिम्मेदारी से बचा जा सकता है
- जवाबदेही विक्रेता पर डाली जा सकती है

② "लेकिन मांगें तो होंगी" यह असमानता
यही महत्वपूर्ण है:
- जिम्मेदारी → नहीं ली जाती
- मांगें → अधिकतम की जाती हैं
→ जोखिम शून्य और लाभ अधिकतम करने की कोशिश

③ जापान की विशेषता वाला "जवाबदेही का संस्कृति"
जापान में:
- यदि विशेषज्ञ स्पष्टीकरण नहीं दे पाते हैं = यह बुरा है
- यदि समझा नहीं पाते हैं = हार
→ "मुझे नहीं पता" कहने वाले व्यक्ति को फायदा होने की संभावना अधिक होती है

④ पिछले सफल अनुभवों से बना एक टेम्पलेट
खतरनाक लोग इस तरह सीखते हैं:
- "मुझे नहीं पता" का उपयोग ढाल के रूप में करने से काम निकल सकता है
- यदि ज़ोर लगाया जाए तो दूसरा पक्ष झुक सकता है
→ परिणाम:
"अज्ञानी चाल" एक रणनीति के रूप में परिष्कृत हो जाती है

■ "एलिबी सिद्धांत" जो आंशिक रूप से सही हो सकता है, ऐसे मामले।

आपके अंतर्ज्ञान का सही होना यहाँ:

उच्च स्तर के नकारात्मक व्यवहार वाले लोगों में,
वे वास्तव में समझते हैं,
लेकिन वे "नहीं जानते" कहते हैं,
* और वे रिकॉर्ड भी रखते हैं (जैसे ईमेल)।

→ यह निश्चित रूप से,
"बाद में जिम्मेदारी से बचने की योजना" है।

■ हालाँकि, एक महत्वपूर्ण वास्तविकता।

न्यायालय में सुनवाई से पहले ही मामला सुलझ जाता है।

व्यवहार में:
• मुकदमे तक जाने के मामले कम होते हैं।
• अक्सर, "बातचीत", "समझौता", या "मुफ्त में समाधान" के माध्यम से मामला समाप्त हो जाता है।
→ इसलिए, जो महत्वपूर्ण है:

कानून नहीं, बल्कि "बातचीत करने की क्षमता"।

■ संरचनात्मक रूप से व्यवस्थित करने पर

आपके अवलोकन के आधार पर, यह इस प्रकार है:

① "मुझे आईटी की समझ नहीं है" की घोषणा
↓
② जिम्मेदारी से बचना
↓
③ मांगों को अधिकतम करना
↓
④ विक्रेता संबंध बनाए रखने और जोखिम से बचने के लिए समझौता करते हैं
↓
⑤ इसे एक सफल अनुभव के रूप में स्थापित किया जाता है

→ यह एक चक्र बन जाता है और "संस्कृति" बन जाता है।

■ आपके असहज महसूस करने का कारण।

आप जो महसूस कर रहे हैं,
"यह एक टेम्पलेट जैसा है।"

यह सही है,
→ यह "मुकदमेबाजी के लिए टेम्पलेट" नहीं है, बल्कि "बातचीत के लिए टेम्पलेट" है।

■ बहुत महत्वपूर्ण निष्कर्ष।

→ समस्या का मूल "कानून" नहीं, बल्कि "असममित जिम्मेदारी संरचना" है।
• आर्डर देने वाला: जिम्मेदारी से बचना आसान।
• विक्रेता: जिम्मेदारी केंद्रित होने की संभावना अधिक।
+
• इनकार करना मुश्किल संस्कृति।
• सिस्टम इंटीग्रेशन (SI) संरचना।

■ संक्षेप में कहें तो:

→ " 'मैं एक आम आदमी हूँ' यह वाक्यांश, मुकदमे में बचाव के लिए इस्तेमाल होने वाले बहाने की तुलना में, बातचीत में श्रेष्ठता हासिल करने के लिए इस्तेमाल की जाने वाली एक मानक रणनीति बन गया है।"

■ अतिरिक्त जानकारी (बहुत व्यावहारिक दृष्टिकोण)।

इस प्रकार के लोगों को पहचानने के संकेत:
• शुरुआत से ही "जानकारी नहीं है" पर जोर देना।
• लेकिन विशिष्टताओं को अस्पष्ट रखते हुए, मांगें बहुत अधिक होती हैं।
• "आमतौर पर लोग ऐसा करते हैं" कहना।
→ जब ये सभी चीजें एक साथ हों,
तो यह लगभग निश्चित रूप से "बातचीत का टेम्पलेट" वाला व्यक्ति होता है।

...मुझे लगता है कि यह प्रकार केवल बाहरी ग्राहकों में ही नहीं, बल्कि कंपनी के अंदर भी मौजूद होता है। उदाहरण के लिए, यदि आपके अपने प्रोजेक्ट के प्रोजेक्ट मैनेजर इस प्रकार के व्यक्ति हैं, तो आप क्या करेंगे? वे लगातार "मुझे नहीं पता" कहते रहते हैं, फिर भी वे मांगें करते हैं, उनका लहजा कठोर होता है, और वे उत्पीड़न करने वाले हो सकते हैं। क्या सबसे अच्छा तरीका है कि आप वहां से भाग जाएं?

ChatGPT का उत्तर:
निष्कर्षतः, "बिना किसी शर्त के भाग जाना" हमेशा सबसे अच्छा समाधान नहीं होता है, लेकिन इसे अनदेखा करके खुद को थका देना सबसे बुरा विकल्प है।
इस प्रकार के प्रोजेक्ट मैनेजर से होने वाले नुकसान को काफी हद तक नियंत्रित किया जा सकता है, यह इस बात पर निर्भर करता है कि आप उनसे कैसे निपटते हैं।

■ सबसे पहले, बुनियादी बातें (इस प्रकार की पहचान)।

आपका मामला आमतौर पर ऐसा होता है:
• "मुझे नहीं पता" → जिम्मेदारी से बचना
• मांगें बहुत अधिक होती हैं → नियंत्रण की इच्छा
• आवाज़ तेज़ होती है → दबाव डालकर निर्णय करवाना

→ "बातचीत के लिए मानक टेम्पलेट + पावरफुल प्रोजेक्ट मैनेजर"

■ समर्थन नीति का समग्र दृष्टिकोण।

प्राथमिकता इस प्रकार है:

① नुकसान को स्थिर न होने दें (सबूत/दृश्यता)।
② जिम्मेदारी की सीमाओं को स्पष्ट करें।
③ सीधे टकराव से बचते हुए नियंत्रण करें।
④ यदि सीमा पार हो जाए तो वापस हट जाएं।

■ व्यावहारिक उपयोग के लिए विशिष्ट उपाय।

① "सब कुछ टेक्स्ट में लिखो" (सबसे महत्वपूर्ण)

मौखिक बातचीत में हार जाते हैं। हमेशा:
• अनुरोधित सामग्री
• निर्णय का कारण
• "मुझे नहीं पता" कहने का तथ्य
को टेक्स्ट में लिखें।
उदाहरण:
"क्या आपकी समझ है कि विनिर्देश अभी तक निश्चित नहीं है?"
"वर्तमान में, निर्णय लेने के लिए पर्याप्त जानकारी उपलब्ध नहीं है, इसलिए मैं A/B विकल्प प्रस्तुत कर रहा हूं।"
→ "जिम्मेदारी का रिकॉर्ड" सबसे बड़ा बचाव है।

② "मुझे नहीं पता" का उपयोग विपरीत तरीके से करें
आप विरोधी के शब्दों का उपयोग करते हैं:
"यदि निर्णय लेना मुश्किल है, तो हम यहां अपनी शर्तें रखेंगे।"
"हम इसे अस्थायी रूप से तय करके आगे बढ़ेंगे, लेकिन बाद में बदलाव करने पर प्रभाव पड़ेगा।"
→ महत्वपूर्ण बिंदु: "निर्णय की जिम्मेदारी वापस करना।"

③ "विकल्प प्रस्तुत करें" पर ध्यान केंद्रित करें
सीधे सवाल पूछना गलत है:
❌ "आप क्या करेंगे?"
⭕ "यदि A चुना जाता है, तो लागत X होगी, और यदि B चुना जाता है, तो जोखिम X होगा।"
→ इससे:
भावना → तर्क में बदल जाता है
दबाव → निर्णय लेने की लागत में बदल जाता है।

④ "समय सीमा और प्रभाव" को एक साथ प्रस्तुत करें
"यदि आज तक निर्णय नहीं लिया जाता है, तो यह रिलीज़ को प्रभावित करेगा।"
"यदि विनिर्देश निश्चित नहीं होता है, तो बाद के चरणों में संशोधन की लागत बढ़ जाएगी।"
→ "अस्पष्टता पर लागत जोड़ें।"

⑤ उत्पीड़न से निपटने के उपाय (महत्वपूर्ण)
इसके लिए शांत रहकर सीमा निर्धारित करना आवश्यक है:

गलत प्रतिक्रियाएं:
• सीधे जवाब देना
• भावनाओं से प्रतिक्रिया करना

सही प्रतिक्रियाएं:
• इसे "समझ में अंतर" के रूप में मानें
• रिकॉर्ड में दर्ज करें
• तीसरे पक्ष को शामिल करें

→ इसे व्यक्तिगत लड़ाई न बनाएं।

■ निर्णय रेखा (भाग जाना चाहिए या नहीं)

यह सबसे महत्वपूर्ण है।

जिन मामलों में बने रहना चाहिए:
- जिन्हें लॉगिंग के माध्यम से नियंत्रित किया जा सकता है।
- जहां वरिष्ठ अधिकारी या संगठन ठीक से काम कर रहे हैं।
- जहां सीखने या लाभ की संभावना है।

जिन मामलों में वापस जाना चाहिए:

यदि निम्नलिखित स्थितियां मौजूद हैं तो यह खतरनाक है:
- रिकॉर्ड किए जाने के बावजूद अनदेखा कर दिया जाता है।
- मांगें लगातार बढ़ती रहती हैं।
- व्यक्तिगत हमले (उत्पीड़न) जारी रहते हैं।
- संगठन हस्तक्षेप नहीं करता है।
→ इस स्थिति में, यह "भागना" नहीं, बल्कि "जोखिम से बचना" है।

■ यथार्थवादी सर्वोत्तम रणनीति:
अनुशंसित क्रम यह है:

① लॉगिंग + संरचना के माध्यम से रक्षा।
↓
② नियंत्रण करने का प्रयास करें (विकल्प, समय सीमा)।
↓
③ यदि सुधार नहीं होता है तो दूरी बनाए रखें।
↓
④ यदि यह काम नहीं करता है तो बाहर निकलें।

■ महत्वपूर्ण दृष्टिकोण (मानसिक पहलू):
इस प्रकार की स्थिति में, लोग अक्सर:
→ "सत्य के साथ जीतने की कोशिश करते हैं।"
यह संभव नहीं है।

इसके बजाय:
→ "संरचना के साथ जीतें।"
- रिकॉर्ड
- विकल्प
- समय सीमा
- तीसरा पक्ष

■ एक वाक्य में:
भागना है या नहीं, यह इस बात पर निर्भर करता है कि "क्या इसे नियंत्रित किया जा सकता है"। यदि इसे नियंत्रित नहीं किया जा सकता है, तो जल्दी बाहर निकलना अधिक तर्कसंगत है।

... थोड़ी चर्चा भटक गई। चूंकि यह लंबा हो गया है, इसलिए मैं इसे यहीं समाप्त करना चाहूंगा।

इस तरह, भले ही काम या बातचीत में कठिनाइयाँ हों, ऐसा लगता है कि AI की मदद से उन्हें बलपूर्वक दूर किया जा सकता है। यदि ऐसा होता है, तो यदि किसी को उत्पीड़न का सामना करना पड़ता है या वरिष्ठ अधिकारी द्वारा उत्पीड़न किया जाता है, तो AI का उपयोग करके बलपूर्वक इसे दूर करने से, ऑर्डर देने वाले या वरिष्ठ अधिकारी, जो उत्पीड़न कर रहे हैं, के लिए यह एक "सफलता का अनुभव" बन सकता है।

AI समस्याओं को हल करने के बजाय, यह मानव संबंधों के संदर्भ में समस्याओं को आगे बढ़ाने का भी कारण बन सकता है।

इसलिए, यह सोचना बेहतर है कि AI सब कुछ हल कर सकता है, इसके बजाय यह कि मूल समस्या नहीं बदलती है।

मैं हमेशा से ही, खुद को बुद्धिमान नहीं मानता था, बल्कि अक्सर आसपास के लोगों द्वारा "बेवकूफ, बेवकूफ" कहकर अपमानित किया जाता था। आज भी, यह धारणा मेरे अंदर है और मैं खुद को प्रतिभाशाली नहीं मानता। हालांकि, जब मैं AI से वस्तुनिष्ठ मूल्यांकन करवाता हूं, तो मेरे आउटपुट की मात्रा मेरे सहकर्मियों की तुलना में 5 गुना अधिक होती है, इसलिए यह संभव है कि मैं अपनी स्थिति के बारे में अच्छी तरह से नहीं जानता था, और शायद आसपास के लोग भी मुझे उतनी अच्छी तरह से नहीं समझते हैं।

ज्यादातर लोग, अपनी आत्म-मूल्यांकन को बढ़ा-चढ़ाकर बताते हैं और खुद को प्रतिभाशाली मानते हैं और दूसरों को मूर्ख मानते हैं। लेकिन यह "दूसरों को अपना दर्पण" की एक पुरानी कहावत के समान है। दूसरे लोगों को मूर्ख देखना, अक्सर इसलिए होता है क्योंकि स्वयं व्यक्ति मूर्ख होता है। इसीलिए, जब कोई व्यक्ति मूर्ख होता है, तो वह दूसरों को "बेवकूफ, बेवकूफ" कहकर अपमानित करता है। यह अक्सर निचले स्तर की कॉमिक्स में दिखाई देने वाला दृश्य है। बचपन में, मैं बिना किसी विशेष कारण के, दूसरों द्वारा अपमानित किया जाता था। इसलिए, मुझे "क्या मैं मूर्ख हूं?" जैसे आधारहीन विचार दिए गए थे।

एक तरफ, बुद्धिमान लोग अक्सर सोचते हैं कि उनके आसपास के सभी लोग भी बुद्धिमान हैं। यह एक विपरीत अर्थ में "दूसरों को अपना दर्पण" होने जैसा है।

लेकिन, एआई न तो ऐसा है और न ही ऐसा कोई प्रभाव रखता है; यह वस्तुनिष्ठ रूप से चीजों को वैसे ही देखता है जैसे वे हैं।

अंततः, दूसरों का मूल्यांकन अक्सर छाप पर आधारित होता है, और ऐसे लोग जिन्हें "बहुत प्रभावशाली" माना जाता है, उन्हें अक्सर सकारात्मक रूप से आंका जाता है। यदि एआई द्वारा वस्तुनिष्ठ मूल्यांकन किया जाता है, तो लोगों को उचित रूप से आंका जा सकता है, और जो लोग केवल बातें करते हैं और परिणाम नहीं देते हैं, उन्हें अब आंका नहीं जा सकता है। ऐसे लोग जो केवल चतुराई से काम करते हैं लेकिन कुछ भी निर्णय नहीं ले पाते हैं, या जो जानकारी प्राप्त करने के लिए बातें करते हैं लेकिन स्वयं निर्णय नहीं ले पाते हैं, और जो सोचते हैं कि वे निर्णय ले रहे हैं, वे हर जगह मौजूद हैं; एआई के माध्यम से, यह स्थिति स्पष्ट हो जाएगी।

मुझे लगता है कि ऐसे कई प्रतिभाशाली आईटी इंजीनियर हैं जिन्हें विभिन्न कारणों से कम मूल्यांकन दिया जाता है और उनका वेतन कम होता है। शायद यह कहना अतिशयोक्ति होगी कि यदि हम एक ऐसा वातावरण बना सकें जो इन लोगों को उचित मुआवजा दे सके, तो जापान का आईटी क्षेत्र फिर से फल-फूल सकता है।

दूसरी ओर, ऐसे भी लोग हैं जो बहुत अधिक परिणाम नहीं देते हैं, लेकिन वे बहुत अधिक दावा करते हैं। यह अक्सर एक गलत धारणा होती है, और यह एक समस्या है। आईटी के क्षेत्र में, एक क्षेत्र में ऐसा हो सकता है, लेकिन दूसरे क्षेत्र में ऐसा नहीं हो सकता है। फिर भी, एआई के माध्यम से (जैसे कि अनुवाद भाषा की बाधाओं को तोड़ रहा है), ऐसा लगता है कि आईटी प्रौद्योगिकी के विभिन्न क्षेत्रों के बीच की बाधाएं भी दूर हो रही हैं।

केवल एआई पर निर्भर रहने से आप किसी के द्वारा उपयोग किए जाने का जोखिम उठाते हैं, लेकिन एआई का प्रभावी ढंग से उपयोग करके हम एक बेहतर दुनिया बना सकते हैं।

...यह भी एआई को सारांश बनाने के लिए कहा गया था।

ChatGPT उत्तर:

निम्नलिखित "सारांश -> मुख्य बिंदुओं का संगठन -> मूल्यांकन (वैधता और सावधानियां)" के क्रम में सारांशित किया गया है।

■ सारांश (मुख्य बातें)

इस लेख में मुख्य रूप से 3 बातें कही गई हैं:

① एआई एक ऐसा उपकरण है जो समस्याओं को "समाधान" करने के बजाय "पार" करने में मदद करता है।
उत्पीड़न या अनुचित मांगों का भी एआई के माध्यम से समाधान किया जा सकता है।
लेकिन यह:
- समस्या का समाधान नहीं है।
- बल्कि, यह अपराधी पक्ष के लिए सफलता का अनुभव बढ़ा सकता है।
→ एआई संरचनात्मक समस्याओं को छिपा सकता है।

② एआई "वस्तुनिष्ठ मूल्यांकन" प्रदान करता है।
- मानव मूल्यांकन धारणाओं और पूर्वाग्रहों से प्रभावित होता है।
एआई:
- उत्पादन की मात्रा
- आउटपुट
इत्यादि का वस्तुनिष्ठ मूल्यांकन कर सकता है।

→ ऐसे लोग जो कम आंके जाते हैं, उन्हें उचित रूप से आंका जा सकता है।

③ जापान में आईटी की समस्या "मूल्यांकन और पुरस्कार में असंगति" है।
- ऐसे कई लोग हैं जो प्रतिभाशाली होने के बावजूद कम आंके जाते हैं।
- दूसरी ओर:
ऐसे लोग जिनकी आवाज तेज होती है,
जो निर्णय नहीं ले पाते,
ऐसे लोगों को भी महत्व दिया जा सकता है।

→ एआई के माध्यम से मूल्यांकन की असंगति को ठीक किया जा सकता है।

④ एआई का उपयोग कैसे किया जाता है, यह महत्वपूर्ण है।
- निर्भरता → शोषण का जोखिम।
- उपयोग → सामाजिक सुधार की संभावना।

→ यह एक उपकरण है, यह कोई रामबाण उपाय नहीं है।

■ तार्किक संरचना

संक्षेप में, यह इस प्रकार है:

एआई का आगमन →	एआई, वस्तुनिष्ठ मूल्यांकन को संभव बनाता है।	निष्कर्ष।
समस्याओं को बलपूर्वक हल किया जा सकता है।	मूल्यांकन में होने वाली त्रुटियों को सुधारा जाएगा।	एआई में "खतरे" और "संभावनाएं" दोनों पहलू मौजूद हैं।
लेकिन, मानवीय संबंधों की समस्याएँ बनी रहती हैं।	उत्कृष्ट लोगों को उचित रूप से महत्व दिया जाता है।
बल्कि, यह समस्या को और बढ़ा सकता है या उसे बदतर बना सकता है।

■ औचित्य का मूल्यांकन

① "एआई समस्याओं को टाल देता है" यह एक बहुत ही सटीक टिप्पणी है।
यह वास्तविकता है:
• एआई से काम किया जा सकता है
→ वरिष्ठ अधिकारी "कोई समस्या नहीं" मानते हैं
→ संरचना में सुधार नहीं होता है

→ अल्पकालिक समाधान = दीर्घकालिक गिरावट का जोखिम

② "वस्तुनिष्ठ मूल्यांकन" आंशिक रूप से सही है।
सही पहलू:
• मात्रात्मक चीजें (आउटपुट की मात्रा आदि) मापी जा सकती हैं
• तुलना करना आसान हो जाता है

सीमाएं:
• मूल्यांकन अभी भी:
यह इस बात पर निर्भर करता है कि "कौन संकेतक निर्धारित करता है"
"क्या का मूल्यांकन किया जाता है"
→ यह पूरी तरह से वस्तुनिष्ठ नहीं होता है

③ "उत्कृष्ट लोगों को पुरस्कृत किया जाता है" यह थोड़ा आदर्शवादी है।
वास्तविकता में:
• मूल्यांकन प्रणाली
• संगठनात्मक संस्कृति
• प्रबंधन स्तर
यदि ये नहीं बदलते हैं: → केवल एआई से यह ठीक नहीं होगा

④ "जो लोग ज़ोर से बोलते हैं, वे समाप्त हो जाते हैं" यह आंशिक रूप से सही है।
एआई के साथ:
• वास्तविक कौशल की दृश्यता बढ़ रही है
लेकिन:
• राजनीतिक कौशल
• संचार कौशल
का अभी भी बहुत प्रभाव है
→ पूर्ण उन्मूलन नहीं होगा

⑤ "एआई से क्षेत्रों की सीमाएं समाप्त हो जाती हैं" यह काफी उचित है।
यह एक मजबूत बिंदु है:
• अनुवाद
• कोड निर्माण
• ज्ञान पूरक
→ कौशल की क्रॉस-सेक्शन निश्चित रूप से बढ़ेगी

■ इस लेख की विशेषताएं
अच्छे पहलू:
• इसमें वास्तविक अनुभव है (उत्पीड़न, मूल्यांकन में विकृति)
• यह एआई के नकारात्मक पहलुओं की ओर इशारा करता है
• यह आत्म-जागरूकता को सामाजिक संरचना से जोड़ता है

ध्यान देने योग्य बातें (जो चीजें आसानी से गलत हो सकती हैं)।

① आत्म-मूल्यांकन की बात थोड़ी व्यक्तिपरक है।
• "मुझे कम आंका गया था"
→ यह संभव है, लेकिन वस्तुनिष्ठ सत्यापन की आवश्यकता है।

② "दूसरों को अपना दर्पण समझो" यह बहुत सामान्य है।
• यह आंशिक रूप से मनोवैज्ञानिक रूप से सही है,
• लेकिन यह हमेशा सही नहीं होता है।

③ यह कृत्रिम बुद्धिमत्ता (एआई) के सर्वज्ञतावाद की ओर बढ़ रहा है।
• "एआई द्वारा उचित मूल्यांकन किया जाएगा"
→ अपेक्षाएं थोड़ी अधिक हैं।

■ समग्र मूल्यांकन

दृष्टिकोण।	मूल्यांकन।
समस्या की पहचान।	◎ (काफी तीक्ष्ण)
एआई के नकारात्मक पहलू।	◎ (महत्वपूर्ण टिप्पणी)
मूल्यांकन सिद्धांत।	○ (दिशा सही है, लेकिन आदर्श की ओर)।
आत्म-जागरूकता वाला भाग।	△ (व्यक्तिगत राय)।

■ संक्षेप में कहें तो:

→ "एआई समस्याओं को हल कर सकता है, लेकिन मानवीय संबंधों और मूल्यांकन में होने वाली विकृतियों को स्वचालित रूप से हल नहीं कर सकता। यह एक व्यावहारिक दृष्टिकोण है जो इस अंतर को उजागर करता है।"

■ अतिरिक्त जानकारी (महत्वपूर्ण बिंदु)

इस अनुच्छेद का सबसे महत्वपूर्ण निष्कर्ष यहाँ है:

→ "एआई क्षमता के अंतर को कम नहीं करता है, बल्कि "दिखने" के तरीके को बदलता है।"

• जो लोग वास्तव में सक्षम हैं → वे और भी मजबूत होंगे।
• जो लोग समस्याग्रस्त हैं → उनकी समस्याएं या तो छिप जाएंगी या उजागर हो जाएंगी।

अब, व्यावहारिक आधार पर, मैं कुछ बहुत ही महत्वपूर्ण बिंदुओं को स्पष्ट करूंगा।
"क्या आप एआई का उपयोग कर सकते हैं" यह महत्वपूर्ण नहीं है, बल्कि "आप इसे कैसे उपयोग करते हैं" इस पर ही मूल्यांकन निर्भर करेगा।

■ एआई युग में वास्तव में जिनकी सराहना की जाएगी, उनकी विशेषताएं।

① समस्या को परिभाषित करने में सक्षम व्यक्ति (सबसे महत्वपूर्ण)
एआई "उत्तर" दे सकता है,
→ लेकिन यह तय नहीं करता कि क्या हल करना है।

विशेष रूप से,
• समस्या को विभाजित करने की क्षमता।
• लक्ष्य को स्पष्ट रूप से परिभाषित करने की क्षमता।
• "क्या नहीं समझा जा रहा है" यह जानने की क्षमता।
→ एआई की क्षमता को उजागर करने के लिए "प्रवेश द्वार" बनाने वाले व्यक्ति।

② निर्णय लेने में सक्षम व्यक्ति (जिम्मेदारी लेने वाला व्यक्ति)
एआई सुझाव दे सकता है,
→ लेकिन निर्णय मनुष्य का होता है।

मूल्यांकन के कारण:
• कई विकल्पों के बीच संतुलन को समझने की क्षमता।
• जोखिम लेने की क्षमता।
• अंतिम निर्णय से न भागने की क्षमता।

→ "जो निर्णय ले सकता है" ऐसे लोग दुर्लभ होते जा रहे हैं।

③ अमूर्त और ठोस के बीच तालमेल बिठाने में सक्षम व्यक्ति।
एआई स्थानीय अनुकूलन में अच्छा है,
→ लेकिन समग्र डिजाइन मानव की भूमिका है।

उदाहरण:
• आवश्यकताओं → डिजाइन → कार्यान्वयन का संबंध।
• व्यवसाय → प्रौद्योगिकी का अनुवाद।

→ "जोड़ने की क्षमता" मूल्यवान है।

④ एआई को "उपकरण" के रूप में उपयोग करने में सक्षम व्यक्ति।
यह सबसे महत्वपूर्ण है:
❌ एआई का उपयोग करने वाले व्यक्ति।
⭕ एआई का अधिकतम उपयोग करने वाले व्यक्ति।
विशेष रूप से,
• प्रॉम्प्ट को बेहतर बनाने की क्षमता।
• आउटपुट को सत्यापित और संशोधित करने की क्षमता।
• कई एआई को संयोजित करने की क्षमता।

→ एआई को आधार बनाकर उत्पादकता डिजाइन करने की क्षमता।

⑤ लगातार आउटपुट देने वाले व्यक्ति।
एआई के कारण अंतर यहीं पर आता है:
→ मात्रा और गति एक साथ दिखाई देती है।

परिणाम:
• जो वास्तव में कर सकते हैं → वे बहुत तेजी से परिणाम प्राप्त करते हैं।
• सामान्य लोग → वे पीछे रह जाते हैं।

→ "जो लगातार आउटपुट दे सकते हैं" वे ही सफल होते हैं।

⑥ जो मानव संबंधों को संरचना के रूप में समझ सकते हैं।
यह पिछली बात से जुड़ा है:
• उत्पीड़न।
• जिम्मेदारी का हस्तांतरण।
• अस्पष्ट मांगें।

→ इन सभी को
• लॉग में दर्ज करना।
• संरचित करना।
• नियमों में बदलना।
इन प्रक्रियाओं को करने में सक्षम व्यक्ति।

■ इसके विपरीत, ऐसे लोग भी होते हैं जो गायब हो जाते हैं।

① "केवल काम करने वाले लोग":
सबसे अधिक प्रभावित:
- केवल कोडिंग
- केवल सामग्री निर्माण
- केवल अनुवाद

→ एआई पूरी तरह से प्रतिस्थापित कर सकता है।

② निर्णय न लेने वाले लोग (जिम्मेदारी से बचने वाले):
- "निर्देशों का इंतजार"
- "निर्णय नहीं लेना"
- "पता नहीं"

→ एआई प्रस्ताव देगा, इसलिए उनका महत्व कम हो जाएगा।

③ केवल बातें करने वाले लोग (केवल समायोजन करने वाले):
यह वास्तव में महत्वपूर्ण है:
- केवल जानकारी एकत्र करना
- निर्णय नहीं लेना
- केवल माहौल के आधार पर काम करना

→ एआई से "सामग्री" दृश्यमान हो जाएगी।

④ एआई का उपयोग न करने वाले या न चाहने वाले लोग:
- अस्वीकृति
- सीखने से इनकार
- पुरानी विधियों पर अड़े रहना

→ वे केवल उत्पादकता में हार जाएंगे।

⑤ जिम्मेदारी स्थानांतरित करने वाले लोग:
यह भी महत्वपूर्ण है:
- असफलता → दूसरों की गलती
- परिणाम → अपना श्रेय लेना

→ एआई लॉग के माध्यम से यह अधिक दृश्यमान हो जाएगा।

⑥ "ऐसा करने का दिखावा" करने वाले लोग:
यह एक महत्वपूर्ण बिंदु है:
- केवल शब्दावली जानते हैं
- केवल माहौल के बारे में बात करते हैं
- कार्यान्वयन और निर्णय नहीं ले सकते

→ एआई से यह तुरंत पता चल जाएगा कि "क्या वे वास्तव में कर सकते हैं"।

■ सार (यह सबसे महत्वपूर्ण है)

एआई के युग में यह विभाजन है:

एआई का उपयोग करके
"समस्या हल करने वाले" → बने रहेंगे या आगे बढ़ेंगे

एआई पर निर्भर रहने वाले
"काम करने वाले" → प्रतिस्थापित किए जा सकते हैं

■ आपके संदर्भ के साथ संबंध।

अब तक की बातचीत (आदेश देने वाले व्यक्ति/परियोजना प्रबंधक समस्या) को जोड़कर:

खतरनाक क्षेत्र के परियोजना प्रबंधकों का क्या होगा?
- अल्पकालिक: एआई के माध्यम से और भी मजबूत होंगे (असंभव मांगों को स्वीकार किया जाएगा)।
- दीर्घकालिक: उनकी वास्तविक क्षमता उजागर होगी।

आपके जैसे लोग
(जो अवलोकन और संरचना को समझ सकते हैं)
→ एआई के माध्यम से उनकी क्षमता में तेजी से वृद्धि होगी।

■ अंत में एक बात।

→ एआई "क्षमता को बढ़ाने" के बजाय "अंतर को बढ़ाने" का उपकरण है।

और हाल ही में, Claude Code के बजाय Codex (ChatGPT) आया है, जो कि बहुत ही उत्कृष्ट है... शायद मैं इसमें स्विच कर सकता हूँ। एआई में लगातार सुधार हो रहा है।

वास्तव में, ऊपर कोड के चरणों के बारे में लिखा है, लेकिन पिछले एक महीने से मैं लगभग सभी कोड खुद नहीं लिख रहा हूँ, बल्कि ज्यादातर एआई पर निर्भर हूँ। एआई इतना उत्कृष्ट है। मैं योजना बनाता हूँ और फिर एआई को इसे बनाने के लिए कहता हूँ। यह एक प्रकार का एजेंट-आधारित एआई है, और यह एक अद्भुत बदलाव है।


अतिरिक्त:




अतिरिक्त: