- यह दावा कि 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) बढ़ा-चढ़ाकर पेश किए गए मिथकों को फैलाते हैं, इसलिए उन्हें नज़रअंदाज़ करना ठीक है
10 टिप्पणियां
क्या सच में किसी ने 10x का मतलब ठीक-ठीक 10 गुना समझा था? मुझे तो यह स्वाभाविक रूप से marketing/खुद की PR के लिए किया गया बढ़ा-चढ़ाकर कहा गया expression लगा था, लेकिन लोग इसे इतनी गंभीरता से ले रहे हैं, यह देखकर हैरानी हो रही है।
10x तक नहीं तो भी Nx को लेकर गंभीर भरोसा रखने वाले संगठन काफ़ी हैं। वे labor cost को AI cost से replace करके उससे भी ज़्यादा performance की उम्मीद करते हैं…
और यह पूरी तरह बेबुनियाद भ्रम भी नहीं है, क्योंकि जब कोई PM कहता है कि वह कोई simple PoC या repeat होने वाले काम के लिए tool बनाकर देखना चाहता है, तो ऐसी चीज़ें काफ़ी जल्दी बन जाती हैं।
इसलिए क्या developers में भी ऐसे लोग हैं जो इस पर भरोसा करते हैं... मेरी नज़र में, अपनी-अपनी स्थिति के हिसाब से काफ़ी anxiety महसूस करना स्वाभाविक है, क्योंकि industry का माहौल ऐसा ही फैला हुआ है।
मुझे लगता है कि non-developer roles और organizational leaders के साथ communication के लिए भी ऐसी गंभीर चर्चा ज़रूरी है।
बिल्कुल, मैं यह नहीं कह रहा कि productivity में मदद करने वाली चीज़ों को नकारा जाए। (AI के मौजूदा स्तर पर) मुझे लगता है कि 10x कहना स्वाभाविक रूप से तर्कसंगत नहीं है, और क्योंकि मूल पोस्ट का आशय ही यह था कि "10 गुना संभव नहीं है", उसी बात पर ज़ोर देना मुझे काफ़ी अजीब लगा, इसलिए मैंने यह टिप्पणी लिखी, लेकिन लगता है कि मेरी अभिव्यक्ति थोड़ी ठीक नहीं थी।
जैसे आप कह रहे हैं कि AI की productivity को marketing/खुद की PR के लिए बढ़ा-चढ़ाकर पेश किया जाता है, मुझे भी लगता है कि उस लेख में भी थोड़ी अतिशयोक्ति शामिल है.
इसलिए "10x" को सचमुच 10 गुना मानने वाला कोई था भी क्या—इस तरह की बात कुछ ज़्यादा ही नुक़्ता-चीनी जैसी लगती है, इसलिए शायद लोगों में उसके प्रति नकारात्मक प्रतिक्रिया हुई होगी.
लगता है आपने मूल लेख पढ़े बिना ही जवाब लिख दिया। मूल लेख में कहीं भी बात को इतना गंभीर बनाकर नहीं कहा गया था...
और लेखक द्वारा विकसित YouTube viral idea खोजने वाले DataTube.tv के Viewtrap के मुकाबले "कई दर्जन गुना" ज़्यादा उपयोग का दावा भी जाहिर है marketing/खुद के PR के लिए किया गया बढ़ा-चढ़ाकर कहा गया बयान ही होगा, है न?
शायद ऑनलाइन होने की वजह से, या शायद आप मूल रूप से ऐसे ही हैं, लेकिन ज़्यादातर टिप्पणियाँ काफ़ी आलोचनात्मक नज़रिए से लिखी गई थीं.
थोड़ा और खुले नज़रिए से देखते तो अच्छा होता।
मुझे लगता है कि AI को लेकर जितना हाइप है, उसका उल्टा पक्ष भी है, इसलिए मुख्य लेख पर मेरी कोई खास राय नहीं है...
यह टिप्पणी थोड़ी डरावनी लगती है, थरथर; पुराने लिखे पोस्ट तक ढूंढकर फिर से टिप्पणी करना, खासकर जब आपने तो आज ही अभी-अभी join kiya hai
आपकी टिप्पणी देखकर, अपनी history को भी देखूं तो मुझे नहीं लगता कि उसमें कोई भी शर्मनाक टिप्पणी है। क्या आलोचनात्मक नज़रिए से देखना ही समस्या है? क्या आपकी तरह कोई भी टिप्पणी न करना ही अच्छा जीवन जीना कहलाता है...
क्या? 10x वाले नंबर को महीनों की संख्या में बदलकर भी रखा था... अगर आपको
진지 빤다जैसा अभिव्यक्ति खटकी हो तो वह समझ सकता हूँ। Datatube का कई दर्जन गुना हिस्सा एक मात्रात्मक आँकड़ा है। खैर, वैसे भी अभी इसे ऑपरेट नहीं कर रहे हैं...Hacker News टिप्पणियाँ
समझ नहीं आता कि सिर्फ software engineering में ही "10x productivity" मिथक को लेकर इतनी आसक्ति क्यों है; mechanical, electrical, construction, chemical engineering में यह अवधारणा नहीं दिखती
एक बेहतरीन engineer वह है जो जोखिम कम करे और कई तरह की constraints के भीतर system design कर सके
design का मतलब models के ज़रिये domain को समझना, और model की validity range और limitations को पहचानना है
"10x" जैसा कुछ नहीं होता, बस अच्छे systems की ज़िम्मेदारी लेना होता है
अगर कोई "10x" software engineer है, तो वह शायद data leak जैसी घटनाओं को रोकने वाला होगा, और मैं ज़्यादा यह देखना चाहूँगा कि ऐसी घटनाएँ 10 गुना कम हों
मैं भी इस लेख के काफ़ी हिस्से से सहमत हूँ
मैं AI tools के साथ development का बहुत बड़ा समर्थक हूँ, लेकिन 10x productivity का दावा मुझे कभी ठोस नहीं लगा
LLM की वजह से code typing जैसे कुछ काम 2~5 गुना तेज़ हुए हैं, लेकिन यह पूरे काम का सिर्फ एक हिस्सा है
सच में बहुत से engineers मानते हैं कि कुछ specific tasks 20~50% तेज़ हो सकते हैं, लेकिन उससे कुल productivity में 20% बढ़ोतरी या 10x उछाल आ जाए, इस बात से मैं सहमत नहीं हूँ
हाँ, जो लोग AI का बहुत अच्छा इस्तेमाल करते हैं वे 0.2x से ज़्यादा productivity gain महसूस कर सकते हैं, लेकिन software development की मूल जटिलता के कारण 10x ज़्यादातर मामलों में अवास्तविक है
AI इस्तेमाल करते समय मुझे लगातार उसके साथ बैठे रहना पड़ता है, इसलिए यह बहुत efficient नहीं लगता
कभी-कभी copilot के suggestions मेरे सोच से पूरी तरह मेल खा जाते हैं और मैं दंग रह जाता हूँ, लेकिन कुल मिलाकर वह बहुत skilled junior developer से ज़्यादा "नशे में senior developer" जैसा लगता है जो ठीक से बात नहीं मानता
generated code का आधा हिस्सा compile भी नहीं होता, और compile हो जाए तो भी अक्सर सही से काम नहीं करता
मेरे अनुभव में AI creation वाले क्षेत्र में बहुत बड़ा productivity boost नहीं देता, लेकिन discovery, learning, blockers हटाने और repetitive code लिखने में बहुत मदद करता है
असली बदलाव side projects में आता है
पहले थकान के कारण मैं अपने extra projects पर समय नहीं दे पाता था, लेकिन अब भले ही perfect code न हो, मैं कम समय और कम mental effort में ideas को हक़ीक़त में बदल सकता हूँ
AI engineering skills के साथ deadlines, privacy, tools जैसी constraints के बिना खुलकर experiment भी कर सकता हूँ
जिन्हें लोग "10x engineer" कहते हैं, वे भी शायद AI से productivity gain को मामूली ही मानेंगे
मेरे जानने वाले सबसे बेहतरीन developers की दो मुख्य क्षमताएँ हैं: असाधारण memory और लगभग हर language/library की बारीकियों को याद रखना, और चमत्कारी creativity व problem-solving
formulas या theory जाने बिना भी वे किसी समस्या के लिए सबसे उपयुक्त, मौलिक और साफ़ समाधान तक पहुँच जाते हैं
AI के साथ pair programming करने पर वैसा ही solution पाने के लिए AI को अंतहीन trial-and-error करना पड़ता है, और उल्टा उस genius इंसान की गति धीमी हो जाती है
लेकिन skill spectrum इतना व्यापक है कि मेरे जैसे व्यक्ति के लिए AI की वजह से 10 गुना productivity gain संभव भी लग सकता है
मेरा background software में नहीं है और perfectionism के कारण मैं बहुत धीमा develop करता हूँ, इसलिए AI की मदद से जल्दी एक खराब-सा first version बना लेना ideas को मूर्त रूप देने में उपयोगी है
मैं भी AI assistants के पक्ष में हूँ, और मानता हूँ कि कुछ परिस्थितियों में 2~10x speedup हो सकता है
लेकिन ज़्यादातर बार "10x" productivity को ऐसे बढ़ा-चढ़ाकर इस्तेमाल किया जाता है जैसे शुरू से अंत तक पूरी feature delivery process 10 गुना तेज़ हो गई हो
हक़ीक़त में overall development process के कई हिस्से, खासकर coding के बाहर वाले, 10 गुना तेज़ नहीं होते
फिर भी बहुत small-scale या solo setups में काफ़ी सारे झंझट वाले steps छूट जाते हैं, इसलिए असल speedup बड़ा हो सकता है
इस नज़रिए से देखें तो small teams और solo development का समय अचानक ज़्यादा competitive हो गया है
Simon की टिप्पणी के लिए धन्यवाद
यही वह comment लगता है जिसे पढ़कर सच में महसूस होता है कि किसी ने लेख पढ़ा है
मैं मानता हूँ कि कुछ language/tool-specific roles में सचमुच 2x productivity gains हो रहे हैं
दशकों तक software development automation का सपना देखा गया, और लगता है LLM ने उसे बिल्कुल अलग तरीके से साकार कर दिया
CASE tools, UML, IDE वगैरह ने हमेशा वादा किया था कि वे "तुम्हें असली logic पर focus करने देंगे", लेकिन LLM तो सीधे natural language से executable code बना देता है
बहुत से developers को लग रहा है कि पुरानी दीक्षा-प्रक्रिया जैसी चीज़ें टूट रही हैं, और वे नए दौर में पीछे छूट जाने को लेकर anxious हैं, यानी impostor syndrome
अब फिर से यह सवाल उठ रहा है कि software engineering आख़िर है क्या
LLM पुराने CASE tools का अंतिम रूप है, लेकिन यह बदलाव बहुत तेज़, उलझाने वाला और disruptive रहा है
अब वे लोग भी ताकत पा रहे हैं जो software engineer की "पवित्र भाषा" नहीं जानते, और बहुत से engineers यह बुनियादी सवाल पूछ रहे हैं: "मैं अभी वास्तव में क्या कर रहा हूँ?"
अब जाकर मुझे समझ आता है कि stable diffusion देखकर artists को कैसा लगा होगा
AI द्वारा लिखा code अक्सर अंत में ग़लत, buggy, अजीब conventions और बेकार चीज़ों से भरा होता है
इन सबको ठीक करने में कभी-कभी उतना ही समय लग जाता है जितना खुद से बनाने में लगता
अलग-अलग models आज़माने या prompts refine करने पर भी, जो high-quality code मैं सच में चाहता हूँ वह अभी भी हाथ नहीं आता
जैसे stable diffusion में परवाह न करने वाला व्यक्ति समझ नहीं पाता कि क्या अजीब है, वैसे ही AI code को ठीक से न जानने वाला व्यक्ति यह नहीं समझता कि उसमें समस्या है
हाल में मैंने एक सहकर्मी का code देखा जो अजीब लग रहा था; debugger भी नहीं चल रहा था और कई तरह की समस्याएँ थीं, फिर उसने स्वीकार किया कि उसने "बस feeling के आधार पर coding की"
हाल की दुनिया को देखकर लगता है कि capital लगातार labor को तोड़ रहा है
कम वेतन, ख़राब कामकाजी माहौल, surveillance, metrics का दबाव, unethical कंपनियाँ, short-term contracts — ज़्यादातर workers की हालत बदतर होती जा रही है
अब तक हम शायद कुछ हद तक सुरक्षित थे, इसलिए इस वास्तविकता को पूरी तरह महसूस नहीं किया, लेकिन अब हम भी अस्थिर भविष्य के सामने खड़े हैं
आखिरकार "software engineering" शायद vibe ठीक करने का काम बन जाएगा
बहुत-सी नौकरियाँ software से replace की जा सकती हैं, लेकिन managers तब तक SWE को hire नहीं करना चाहते थे जब तक verified value साबित न हो
AI आने के बाद managers बहुत सारा ऐसा code बनवा देंगे जिसे वे समझते नहीं, और 3 साल बाद जब वह सब टूटेगा तो SWE को फिर बुलाकर ठीक करवाएँगे
उल्टा, ऐसे high-difficulty/high-value jobs ज़्यादा हो सकती हैं जहाँ "AI से हल न होने वाली समस्याएँ" सुधारनी पड़ें
LLM बिना किसी formal model या diagram के सीधे code बना देता है
मैं तो चाहता हूँ कि AI ऐसे formal designs या diagrams बनाए
क्योंकि ऐसे tools code समझने और design स्पष्ट करने में मदद करते हैं
काश AI इस हिस्से में भी सहायता करे
software development की bottleneck typing speed या generation नहीं, बल्कि verification और understanding है
भले ही LLM बिना hallucination के perfectly काम करे, एक conscientious developer को code line-by-line review करना ही पड़ेगा
इंसान 10 गुना तेज़ी से code समझ नहीं सकता, इसलिए generated code को दोबारा पढ़ने और उसकी छिपी मंशा समझने में और ज़्यादा समय लग सकता है
"10x productivity" सिर्फ तब लागू होती है जब output बिना verification आगे बढ़ा दिया जाए, या जब code बहुत simple हो और errors का महत्व न हो
production software, जहाँ गलती का मतलब disaster हो सकता है, वहाँ आज भी human cognition ही bottleneck है; LLM ने बोझ writing से review पर शिफ्ट किया है, इसलिए overall productivity पर इसका असर उल्टा negative भी हो सकता है
यह चर्चा कुछ हद तक average developers की self-exposure जैसी लगती है
अगर आप project की तकनीक को समझते हैं और काम को सही तरह विभाजित कर सकते हैं, तो आप code complexity का पहले से अनुमान लगाकर AI को ठीक स्तर के units में काम दे सकते हैं
AI कोई जादू नहीं है; इसकी भी एक upper bound complexity है जिसे वह लिख सकता है
अगर आप उस सीमा और अपने project की technology को अच्छी तरह समझते हैं, तो components को उस सीमा से नीचे तोड़कर AI को निर्देश दे सकते हैं
यह तरीका काफ़ी अच्छा काम करता है
यह लगभग tautology है
अगर आप AI के लिए instructions इतने simple बना दें कि वह अच्छे से काम कर सके, तो स्वाभाविक है कि वह अच्छा काम करेगा
लेकिन व्यवहार में AI को बहुत ज़्यादा spoon-feeding करनी पड़ती है, और तब भी output को ध्यान से दोबारा जाँचना पड़ता है क्योंकि भरोसा नहीं किया जा सकता
उल्टा, काम को छोटे-छोटे हिस्सों में बाँटकर AI को समझाना, कई बार code खुद लिखने से भी ज़्यादा झंझट वाला हो सकता है
अगर AI किस्मत से पहली बार में सही जवाब दे दे तो efficiency है, लेकिन असल दुनिया में बार-बार सुधार करना पड़ता है या फिर अंत में दोबारा खुद बनाना पड़ता है, जिससे समय और मेहनत बर्बाद होती है
AI का structured और साफ़ दिखने वाला code भी अक्सर असल में ग़लत होता है, इसलिए वह ख़तरनाक है
सच में मुश्किल और समय लेने वाला हिस्सा complex भागों की design है
मामूली हिस्से तो input देने भर से बन जाते हैं, लेकिन complex हिस्सों को हल करना ही असली time sink है
इस comment के पीछे मुझे एक तरह का भाव महसूस होता है: "क्या मैं खुद को average से ऊपर का developer मानता हूँ?"
शायद इसका उल्टा भी सच हो सकता है
कमज़ोर developers meaningless auto PR submit करते रहते हैं और AI के output पर मोहित हो जाते हैं, जबकि ऊँचे standards वाले developers उस output से प्रभावित नहीं होते
सच तो यह है कि जब तक किसी के साथ काम न किया जाए, यह तय करना मुश्किल है कि कौन भरोसेमंद है, इसलिए मैं neutral रहता हूँ
AI की भी सीमाएँ हैं, इंसानों की भी
अंत में ज़रूरत उबाऊ project management की ही पड़ती है
सही requirements, design, और पर्याप्त जानकारी के साथ काम को छोटे units में बाँट दिया जाए, तो आप AI से कह सकते हैं "GitHub issue #42 implement करो" और TV देखते हुए उसे काम करते देख सकते हैं
लेकिन अगर कहेंगे "facebook बना दो", तो जाहिर है सब बिगड़ जाएगा
AI ने एक और बड़े क्षेत्र में मदद की है: bug ढूँढने में
मैं ज़्यादातर numerical simulation पर काम करता हूँ, और कई दिनों से अटका हुआ एक issue — कुछ missing parentheses की वजह से equation scale ग़लत हो गया था — मैंने chatgpt को file और symptoms समझाए, और उसने जल्दी root cause पकड़ लिया
कभी-कभी AI वह चीज़ साफ़-साफ़ दिखा देता है जो मैं मिस कर गया था
यह आपको 10x developer नहीं बनाता, लेकिन सही इस्तेमाल हो तो बड़ा positive effect ज़रूर महसूस होता है
मेरा अनुभव भी ऐसा ही है
AI से code generation ठीक-ठाक है, लेकिन debugging में यह सचमुच बहुत बड़ा productivity leap है
एक तरह का बहुत बुद्धिमान "rubber duck" है
(hobby developer के नज़रिए से) LLM की वजह से देर रात, जब दिमाग़ ठीक से नहीं चलता, development बहुत आसान हो जाता है
मैंने भी AI की वजह से अनगिनत घंटे बचाए हैं
मेरे लिए यह 10x और infinity के बीच कहीं जैसा महसूस होता है
मैं खुद को 10x engineer नहीं मानता
company में सहकर्मियों से ज़्यादा productive होने की वजह यह है कि मैं system design और business requirements को अस्पष्ट tickets की तरह जस-का-तस follow नहीं करता
AI मेरे सहकर्मियों को simplify नहीं कर पा रहा, क्योंकि वे शुरू से चीज़ों को unnecessarily complex बनाने की आदत नहीं बदलते
AI इस समस्या का समाधान नहीं करता
company में मेरी salary और सहकर्मियों की salary में 2 गुना का अंतर नहीं है, इसलिए मैं ऐसा मानता हूँ
AI tools अपनाने से यह हक़ीक़त नहीं बदलेगी
यह लेख पहले "10x" जैसा बहुत ऊँचा benchmark सेट करता है, फिर लेखक के उस benchmark को पार करने की निजी कोशिशों का रिकॉर्ड बन जाता है
इसलिए मुझे लगता है कि लेखक ने AI समर्थकों को तीन श्रेणियों में बाँटा: भ्रमित लोग, बेचने वाले लोग, और insecurity का फायदा उठाने वाले बुरे managers
व्यक्तिगत रूप से, "hallucination" पर शिकायत मुझे कुछ हद तक एक "signal" लगती है
मुझे लगता है hallucination की चर्चा बिल्कुल ज़रूरी है
LLM को लेकर चर्चा बहुत extreme हो गई है — या तो यह पूरी तरह बेकार है, या developers की जगह ले लेगा
उदाहरण के लिए, Claude 4 Sonnet ने clang compilation के बारे में ग़लत जवाब दिया था और कहा था कि Godbolt ग़लत है
फिर भी पूरे session में उसने काफ़ी मदद की, इसलिए बस इतना याद रखना चाहिए कि outputs के प्रति critical रहना ज़रूरी है
hallucination सचमुच मौजूद है, और नतीजों को लेकर हमेशा सावधान रहना चाहिए
comment छोड़ने के लिए धन्यवाद, और AI पर तुम्हारी लिखी बातों ने मेरा impostor syndrome कम करने में मदद की
लेख में वर्गीकरण सिर्फ उन लोगों के लिए था जो "10x लगातार सफलता" का दावा करते हैं; सभी AI समर्थकों को एक साथ नहीं रखा गया था
मैं जानना चाहता हूँ कि क्या तुम्हें hallucination को पूरी तरह खत्म करने का कोई तरीका मिला है
खासकर Terraform जैसी चीज़ों में LLM अक्सर ऐसी properties बना देता है जो अस्तित्व में ही नहीं हैं, और JS जैसी जगहों पर भी uncommon libraries इस्तेमाल करने में अभी भी काफ़ी भ्रम पैदा करता है
अगर "hallucination" पर शिकायत करना एक signal है, तो ऐसा सोचना भी अपने आप में एक signal है…
(संक्षिप्त प्रतिवाद)
यह 10x benchmark industry-wide exaggerated marketing का हिस्सा है
उदाहरण: Sam Altman का 10x दावा
Cursor AI productivity प्रचार
AI-augmented 10x developers
मान लें कि कोई व्यक्ति जिसे web app बनाना नहीं आता, वह 6 हफ़्तों तक रोज़ 4 घंटे (120 घंटे) सीखते हुए किसी तरह एक app बनाता है
दूसरी तरफ़, अगर वही Claude code जैसे AI tools का इस्तेमाल करके दो weekend days (12 घंटे) में वही web app बना ले, तो productivity 10 गुना बढ़ी
मेरे साथ कुछ ऐसा ही वास्तव में हुआ है
पहले motivation या energy की कमी से जो काम नहीं हो पाते थे, AI की वजह से अब weekend में पूरे कर पाता हूँ
लेकिन पहले तरीके में सीखने की प्रक्रिया शामिल है, जो अगली बार कुछ बदलने में मदद कर सकती है
सच कहें तो Claude Code जैसे AI से React के अलावा web app scaffolding करवाएँ, तो हाल बेहाल हो जाता है
app development experience न रखने वाला व्यक्ति weekend में आसानी से polished app नहीं बना लेगा
पहले user login पर ही सब टूट सकता है
लंबी अवधि में देखें तो यह arithmetic समझ में नहीं आती
LLM से शुरू में app जल्दी बन सकता है, लेकिन धीरे-धीरे maintenance की क्षमता घटती है, और एक बिंदु पर system इतना complex हो जाता है कि उसे "context window" के भीतर रखकर manage करना संभव नहीं रहता
नतीजतन productivity उल्टा 0 के करीब भी जा सकती है
आपने अपने दिमाग़ और learning experience को लगभग outsource कर दिया, इसलिए app तो बन गया लेकिन growth और learning बहुत कम हुई
क्या आप उसे सीधे deploy करने वाले हैं?
व्यवहारिक रूप से दोनों चीज़ें एक जैसी नहीं हैं
1x developer का output नापना ही मुश्किल है, उस पर कोई गुणा लगाना तो और भी अर्थहीन है
मुझे लगता है AI ने "side quest productivity" बहुत बढ़ा दी है
जिन कामों को मैं झंझट समझकर टालता रहता था — mockups बनाना, tests लिखना, libraries निकालना, documentation करना वगैरह — उनमें AI बेहतरीन है
हो सकता है यह feature delivery का समय कम न करे, लेकिन इन सहायक कामों को शामिल करें तो अंतिम परिणाम थोड़ा ज़्यादा complete हो जाता है
उम्मीद है कि इन अतिरिक्त कामों की वजह से भविष्य में bugs ढूँढने में कम समय लगेगा
(व्यक्तिगत अनुभव)
यह सिर्फ मेरे case की बात है, लेकिन हमारी company में LLM से लिखे गए test code का implementation code से बहुत ज़्यादा जुड़ जाना आम बात है
test spies जैसे patterns का overuse बहुत होता है
नतीजतन, user के नज़रिए से behavior जाँचने के बजाय, tests सिर्फ internal implementation details की ही जाँच करते रह जाते हैं
tests implementation बदलते ही बहुत बार टूट जाते हैं, इसलिए वे productivity का साधन नहीं बल्कि बोझ बन जाते हैं
यह सिर्फ LLM की समस्या नहीं है; पहले से tests ठीक से न लिख पाने वाले developers के लिए LLM ने समस्या और बढ़ा दी है
जिन developers के पास TDD और अच्छी तरह designed test code का अनुभव कम है, उनके लिए LLM ऐसे anti-patterns को amplify करता है
"side quest productivity" अभिव्यक्ति बहुत अच्छी है
AI "death by a thousand cuts" नहीं, बल्कि "a thousand band-aids से बनी नई ज़िंदगी" जैसा लगता है
मैं भी "side quest" विचार से सहमत हूँ
असली बदलाव यह है कि AI की वजह से मैं ऐसे tools या features बना पा रहा हूँ जिन्हें AI के बिना बनाता ही नहीं
यह सिर्फ 2 हफ़्ते बचाने की बात नहीं, बल्कि एक नया output पैदा होने की बात है
LLM को लेकर expectations अक्सर reality से ज़्यादा हैं, लेकिन व्यवहार में यह कई स्थितियों में बहुत उपयोगी है
"zoom level" के हिसाब से देखें तो "vibe coding" जैसे बहुत मोटे स्तर से लेकर "यह function बना दो" जैसे छोटे स्तर तक, जितना granular तरीके से काम बाँटते हैं, उतने बेहतर results मिलते हैं
code generation के अलावा नई technology सीखने जैसे कई अन्य उपयोगों में भी यह प्रभावी है
अगर मेरी role में meetings ज़्यादा हों या managerial काम ज़्यादा हो, तो LLM की usefulness कम हो जाती है
आगे चलकर PR workflows, commit cleanup, और sequence reordering जैसे कामों में भी LLM के इस्तेमाल की संभावना दिखती है
अक्सर बिना सोचे-समझे 'नहीं हो सकता', 'यह संभव नहीं है' कहने वाले इंजीनियरों का जवाब देने के लिए ही इसका इस्तेमाल किया जाए, तो भी सच कहूँ तो X10 असर दिख सकता है।
मैंने अक्सर ऐसे दृश्य देखे हैं जहाँ non-developers को बिल्कुल अनजान समझकर हर बात पर कहा जाता था कि यह नहीं हो सकता।