- यह दावा कि AI इंजीनियरों की प्रोडक्टिविटी 10~100 गुना बढ़ा देता है वास्तविकता से दूर है
- असल AI coding tools का गहराई से उपयोग करने पर पता चलता है कि efficiency में सुधार सीमित है, और प्रोडक्टिविटी में अस्थायी उछाल केवल दोहराए जाने वाले और सरल कामों में होता है
- software development के bottlenecks (code review, collaboration, planning आदि) को AI से पार नहीं किया जा सकता, इसलिए पूरे काम में 10 गुना सुधार असंभव है
- 10x engineer मिथक कई तरह की प्रेरणाओं से पैदा होता है, जैसे distorted metrics, industry stakeholders, या संगठन के भीतर असुरक्षा पैदा करना
- अपना विकास करने का तरीका और काम का आनंद बनाए रखना लंबे समय में बेहतर नतीजे और स्वस्थ संगठनात्मक संस्कृति बनाता है
AI 10x engineer मिथक पर संदेह
प्रोडक्टिविटी को लेकर असुरक्षा और AI tools के वास्तविक उपयोग का अनुभव
- LinkedIn, Twitter आदि पर AI इंजीनियरों की प्रोडक्टिविटी 10~100 गुना बढ़ा देगा जैसी चर्चा फैलने से कई developers को पीछे छूट जाने का डर महसूस हो रहा है
- लेखक ने भी AI code generation agents (Claude Code, Cursor, Roo Code, Zed आदि) को वास्तविक काम में अलग-अलग तरह से इस्तेमाल किया, लेकिन सरल दोहराव वाले कामों में सुविधा होने के बावजूद जटिल वास्तविक काम में कोई बुनियादी बदलाव नहीं मिला
- JavaScript (खासकर React) में repetitive code (boilerplate) जल्दी लिखा जा सकता है
- लेकिन अपने codebase standards या असामान्य libraries के मामले में AI ठीक से साथ नहीं दे पाता
- Terraform जैसी भाषाओं में AI कम परिचित होने के कारण प्रदर्शन गिर जाता है
- hallucination की वजह से यह ऐसी libraries भी बना सकता है जो वास्तव में मौजूद नहीं हैं, और इससे security vulnerabilities तक पैदा हो सकती हैं
- AI की context समझने की क्षमता अभी भी सीमित है। codebase जितना जटिल होता है, उतना ही बार-बार prompting, errors और समय की बर्बादी बढ़ती है
- नतीजतन, लेखक AI का उपयोग छोटे scripts या गैर-महत्वपूर्ण कामों में करते हैं, जबकि जटिल या महत्वपूर्ण काम अब भी खुद करते हैं
software development की प्रोडक्टिविटी को संख्या में मापने की समस्या
- यह दावा कि AI से प्रोडक्टिविटी 10~100 गुना बढ़ सकती है, वास्तविकता से कटा हुआ है
- 10x, 100x productivity का मतलब सिर्फ code lines की संख्या नहीं है, बल्कि 3 महीने का काम (पूरा development, code review, QA आदि) 1.5 हफ्ते में खत्म हो जाना है
- software development में planning, story point estimation, bug fixing, code review, deployment wait time, testing, QA जैसे कई bottlenecks होते हैं
- लक्ष्य तभी संभव है जब इन सभी प्रक्रियाओं की रफ्तार एक ही अनुपात में 10 गुना बढ़े
- हकीकत में coding पर लगने वाला समय कम होता है, और बहुत समय समझने, design, review और communication में जाता है
- वास्तविक रूप से code review, collaboration, communication, QA आदि को AI से छोटा नहीं किया जा सकता
- असली engineering काम में bottleneck लोग, process और communication हैं
- LLM (large language model) keyboard typing का समय कम कर सकता है, लेकिन code quality, testing और review का समय फिर भी चाहिए
- भले ही AI थोड़े समय के लिए code लिखने की रफ्तार बढ़ा दे, लेकिन errors की बढ़ी हुई दर, code standards की कमी और re-prompting की वजह से कुल प्रोडक्टिविटी में निर्णायक सुधार नहीं होता
- 10 गुना प्रोडक्टिविटी वास्तविक रूप से लगभग असंभव लक्ष्य है
10x engineer की वास्तविकता और सीमाएँ
- "10x engineer" का अस्तित्व लेखक की नज़र में अस्थायी और सीमित रूप में संभव है
- इसकी सबसे बड़ी वजह अनावश्यक काम को पहले ही रोक देने की क्षमता है (planning चरण में अनावश्यक development रोकना, developer experience सुधारना, documentation आदि)
- लेकिन हर engineer को हर बार ऐसी स्थिति नहीं मिलती
- बेहद उत्कृष्ट engineers अनावश्यक काम रोककर या system सुधारकर पूरे संगठन की efficiency बढ़ा सकते हैं, लेकिन वास्तव में लगातार 10 गुना परिणाम देने के उदाहरण लगभग नहीं मिलते
- AI coding tools अनावश्यक काम को रोकने में खास मदद नहीं करते
- उल्टा AI की सिफारिशों से overengineering हो सकता है या गलत architecture सुझाया जा सकता है
- तेज coding हमेशा अच्छे engineer का संकेत नहीं होती
10x AI मिथक की पृष्ठभूमि और प्रेरणाएँ
ज़्यादातर "10x productivity" दावे निम्न कारणों से पैदा होते हैं
- अच्छी नीयत वाले engineers की measurement errors
- AI tools की मदद से कभी-कभी कम समय में धमाकेदार efficiency का अनुभव हो सकता है (उदाहरण: ESLint custom rules अपने-आप लिख जाना)
- लेकिन जब ऐसे काम दोहराए जाते हैं तो अंततः प्रोडक्टिविटी का अंतर तेजी से घट जाता है
- तकनीकी नवीनता, नए environment के प्रति अनुकूलन आदि शुरुआती दौर में जरूरत से ज्यादा efficiency का भ्रम पैदा कर सकते हैं
- incentives और stakeholders
- AI startup founders, investors आदि व्यावसायिक सफलता के लिए बढ़ा-चढ़ाकर बताए गए आंकड़े अक्सर उद्धृत करते हैं
- engineers या management भी संगठन के भीतर अपेक्षाओं पर खरा उतरने के लिए बढ़ी हुई प्रोडक्टिविटी का उल्लेख कर सकते हैं
- दुर्भावनापूर्ण उद्देश्य
- कुछ management लोग इंजीनियरों में असुरक्षा पैदा करके job switching, वेतन वृद्धि की मांग आदि से संगठन के भीतर होने वाली हलचल को रोकने के इरादे से बढ़ा-चढ़ाकर दावे फैलाते हैं
- AI के कारण हर किसी के आसानी से replace हो जाने का डर समय-समय पर लौटता रहता है (पुरानी coding bootcamp बहस की तरह)
वास्तविक open source और प्रैक्टिकल projects में AI का प्रदर्शन
- AI प्रोडक्टिविटी सुधार से जुड़ी अधिकांश वास्तविक कहानियों में लिखने वाले और वह engineer जिसके बारे में कहा जा रहा है कि उसकी प्रोडक्टिविटी बढ़ी, इन दोनों के बीच दूरी होती है
- जिन मामलों में engineers ने खुद AI tools के उपयोग को साबित किया है, वहाँ बिना बढ़ा-चढ़ाकर दिखी हुई यथार्थवादी तस्वीर सामने आती है
- open source projects में AI के उपयोग के परिणाम कई बार उम्मीद से कम या असफल भी दिखते हैं
- public demos या वास्तविक engineers के उदाहरणों में AI कभी-कभी जादुई लग सकता है, लेकिन ज्यादातर मामलों में यह पुराने "text generator" से बहुत अलग नहीं होता
"प्रोडक्टिविटी" से अधिक महत्वपूर्ण मूल्य - अपने तरीके से development जारी रखें
- AI की मदद से कभी-कभी code जल्दी लिखा जा सकता है, लेकिन लेखक अब भी coding के आनंद को ज्यादा महत्व देते हैं
- अगर AI coding पसंद नहीं है या उसमें मज़ा नहीं आता, तो कुछ प्रोडक्टिविटी छोड़ देना भी ठीक है
- कुछ हद तक inefficiency स्वीकार करके भी अपने लिए उपयुक्त तरीके से काम करना लंबे समय में अधिक स्वस्थ और बेहतर परिणाम देता है
- आनंद लेकर काम करने पर बेहतर problem solving, design और teammates के साथ collaboration संभव होता है
- आनंद और गहरे ध्यान की अवस्था लंबे समय की प्रोडक्टिविटी और code quality के लिए अधिक महत्वपूर्ण हैं, और अगर सिर्फ प्रोडक्टिविटी का पीछा किया जाए तो burnout का खतरा बढ़ता है
- इसके उलट, अगर AI coding सच में मज़ेदार और उपयोगी लगे तो उसका सक्रिय रूप से उपयोग करना भी अच्छा है
स्वस्थ संगठनात्मक संस्कृति के लिए सलाह
- AI tools लागू करते समय सभी engineers में अवास्तविक अपेक्षाएँ और असुरक्षा पैदा करना संगठन की प्रोडक्टिविटी के लिए हानिकारक है
- प्रोडक्टिविटी को अधिकतम करने का जुनून quality में गिरावट, codebase के बिगड़ने और लंबे समय के नुकसान की ओर ले जाता है
- engineers को पर्याप्त autonomy और trust देना, और AI का उपयोग हर व्यक्ति अपनी उपयुक्त शैली के अनुसार चुने यह अधिक उचित है
- संगठन को AI उपयोग के अवसर देने चाहिए, लेकिन autonomy सुनिश्चित करने वाला माहौल ज्यादा महत्वपूर्ण है
- अगर LLM और AI coding innovation सच में 10 गुना प्रोडक्टिविटी देंगे, तो developers उसे स्वाभाविक रूप से खुद ही अपना लेंगे
निष्कर्ष
- AI से आने वाली 10x engineer क्रांति एक मिथक के ज्यादा करीब है, और वास्तव में कोई छिपी हुई गुप्त recipe नहीं है
- अपनी क्षमता और अपने काम करने के तरीके पर विश्वास सबसे महत्वपूर्ण है
- SNS (खासकर LinkedIn, Twitter) बढ़ा-चढ़ाकर पेश किए गए मिथकों को फैलाते हैं, इसलिए उन्हें नज़रअंदाज़ करना ठीक है
अभी कोई टिप्पणी नहीं है.