वाइब कोडिंग के जादू को तोड़ना
(fast.ai)- AI द्वारा जनरेट किए गए जटिल कोड का बड़े पैमाने पर उत्पादन फैल रहा है, और इंसानों द्वारा न पढ़े जाने वाले कोड बनाने की प्रवृत्ति पूरे उद्योग में फैलती जा रही है
- प्रबंधन AI के कारण workforce reduction को जायज़ ठहरा रहा है, और डेवलपर्स पर AI से बने कोड का अनुपात भरने का दबाव है
- ऐसी ‘वाइब कोडिंग’ जुए की लत के तंत्र जैसी ‘dark flow’ स्थिति पैदा करती है, जिससे उत्पादकता का भ्रम होता है
- वास्तव में AI coding tools इस्तेमाल करने पर 20% उत्पादकता बढ़ने का एहसास होता है, लेकिन असल में 19% धीमापन आता है, ऐसा शोध बताता है
- AI उपयोगी है, लेकिन मानव की सोच, रचनात्मकता और software engineering क्षमता का विकल्प नहीं है, और इसे छोड़ देना उलटे गिरावट का जोखिम पैदा कर सकता है
वाइब कोडिंग का फैलाव और समस्या की पहचान
- वाइब कोडिंग AI द्वारा जनरेट किए गए जटिल कोड का बड़े पैमाने पर उत्पादन है, जिससे ऐसा कोड बनता है जिसे इंसानों के लिए पढ़ना या maintain करना मुश्किल हो जाता है
- कुछ कंपनियां यह कहकर छंटनी को सही ठहराती हैं कि AI इंसानों का काम कर सकता है
- डेवलपर्स पर AI-जनरेटेड कोड का अनुपात पूरा न करने पर performance evaluation में नुकसान झेलने का दबाव होता है
- छात्र और नौकरीपेशा लोग दोनों ही “AI जल्द ही मेरा काम बदल देगा” जैसी चिंता में self-development से हिचकने लगते हैं
- AI वास्तव में उपयोगी है, लेकिन वाइब कोडिंग में सावधानी ज़रूरी है, और गलत इस्तेमाल पर इसके नकारात्मक परिणाम हो सकते हैं
‘flow’ और ‘dark flow’ का अंतर
- मनोवैज्ञानिक Mihaly Csikszentmihalyi के अनुसार ‘flow’ चुनौती और कौशल के संतुलन से बनने वाली गहन तल्लीनता की अवस्था है
- इसके विपरीत, जुए की तरह कौशल से असंबंधित गतिविधियों में भी तल्लीनता पैदा हो सकती है, और यह ‘नकली flow’ के अंतर्गत आता है
- slot machine के Loss Disguised as a Win (LDW) उदाहरण की तरह, असल में नुकसान होने पर भी जीत जैसा भ्रम पैदा किया जाता है
- शोध के अनुसार LDW वास्तविक जीत जैसी शारीरिक प्रतिक्रिया पैदा करता है, जिससे लत वाली तल्लीनता और मजबूत होती है
- इस तरह की स्थिति को ‘dark flow’ या ‘junk flow’ कहा जाता है, यानी ऐसी नशे जैसी तल्लीनता जिसमें विकास नहीं होता
वाइब कोडिंग और जुए की समानता
- डेवलपर Armin Ronacher ने बताया कि AI coding tools इस्तेमाल करने के बाद उन्होंने बहुत सारा कोड बनाया, लेकिन वास्तव में उसका लगभग उपयोग नहीं कर पाए
- यह जुए की ‘नकली जीत’ जैसी भ्रमकारी संरचना से मिलता-जुलता है
- वाइब कोडिंग निम्न बिंदुओं पर flow की शर्तों का उल्लंघन करती है
- परिणाम पर स्पष्ट feedback का अभाव, बल्कि गलत उपलब्धि-बोध देना
- चुनौती के स्तर और कौशल के स्तर में असंतुलन
- control illusion के ज़रिए उपयोगकर्ता को यह विश्वास दिलाना कि वह परिणामों को नियंत्रित कर रहा है
- AI द्वारा जनरेट किए गए कोड की गुणवत्ता की समस्या अक्सर कई हफ्तों बाद समझ में आती है, और bug व maintain न की जा सकने वाली जटिलता बाद में सामने आती है
- LLM और slot machine दोनों उपयोगकर्ता की मनोवैज्ञानिक प्रतिक्रिया को अधिकतम करने के लिए डिज़ाइन किए गए हैं, ताकि लगातार उपयोग कराया जा सके
उत्पादकता का भ्रम और ‘अविश्वसनीय कथावाचक’
- METR के शोध के अनुसार, AI tools इस्तेमाल करने वाले डेवलपर्स को 20% अधिक तेज़ होने का एहसास हुआ, लेकिन वे वास्तव में 19% धीमे थे
- इसका मतलब है अनुभूत दक्षता और वास्तविक दक्षता के बीच 40% का अंतर
- AI से लिखे गए लेख भी ऊपरी तौर पर समान दिख सकते हैं, लेकिन गुणवत्ता में कमजोर हो सकते हैं
- एक AI शोधकर्ता की blog post AI से लिखे जाने के बाद पहले से कम पढ़ने योग्य शैली में बदल गई
- लोग अपनी उत्पादकता का वस्तुनिष्ठ आकलन करने में मुश्किल महसूस करते हैं, और AI इस्तेमाल के बाद उसे बढ़ा-चढ़ाकर आंकने की प्रवृत्ति रखते हैं
गलत भविष्यवाणियां और करियर जोखिम
- AI coding को पूरी तरह बदल देगा, ऐसी भविष्यवाणियां बार-बार गलत साबित हुई हैं
- Geoffrey Hinton ने कहा था कि 2021 तक AI radiologist की जगह ले लेगा, लेकिन ऐसा नहीं हुआ
- Google के Sundar Pichai और Jeff Dean ने कहा था कि 2023 तक सभी data scientists automated neural network design tools इस्तेमाल करेंगे, लेकिन यह भी नहीं हुआ
- Anthropic के Dario Amodei ने दावा किया कि 2025 के अंत तक AI पूरे कोड का 90% लिखेगा, लेकिन इसके समर्थन में कोई आधार नहीं है
- ऐसे बढ़ा-चढ़ाकर पेश किए गए अनुमानों के आधार पर अपनी तकनीकी क्षमताओं का विकास रोक देना खतरनाक है
- AI की प्रगति की रफ्तार को वास्तविकता से लगातार अधिक आंका गया है
मानव सोच और रचनात्मकता का स्थायी महत्व
- AI coding agents व्याकरणिक रूप से सही कोड बना सकते हैं, लेकिन
- उपयोगी abstraction, modularization और code structure में सुधार नहीं कर पाते
- यानी coding का कुछ हिस्सा automate हुआ है, लेकिन software engineering automate नहीं हुई
- AI द्वारा जनरेट किया गया टेक्स्ट भी व्याकरण की दृष्टि से स्वाभाविक हो सकता है, लेकिन वह सोच को परिष्कृत या मूल बिंदु को नहीं पकड़ता
- Jeremy Howard ने चेतावनी दी कि “अगर सोचने की प्रक्रिया पूरी तरह AI को सौंप दी जाए, तो सीखने और बढ़ने की क्षमता खो जाती है”
- AI एक tool के रूप में उपयोगी है, लेकिन यह मानव की मूल क्षमताओं का विकल्प नहीं है
6 टिप्पणियां
जब किसी व्यक्ति की काम करने की क्षमता का आकलन किया जाता है, तो उसमें 'रवैया' नाम का एक तत्व होता है। काम के दिशानिर्देशों और वरिष्ठ के आदेशों के अलावा, व्यक्ति का अपने काम के प्रति खुद का रवैया भी महत्वपूर्ण होता है। यह रवैया काम के प्रति लगातार रुचि, अंतर्दृष्टि और जिम्मेदारी के रूप में सामने आता है। इनमें जिम्मेदारी सबसे अहम है। AI बाकी चीजों की नकल कर सकता है, लेकिन उसमें जिम्मेदारी नहीं होती। AI परिणामों का मूल्यांकन कर सकता है, लेकिन प्रक्रिया के प्रति जिम्मेदारी का मूल्यांकन नहीं कर सकता।
AI को 'कैसे(How)' अच्छी तरह पता होता है, लेकिन यह नहीं पता होता कि 'क्यों' करना चाहिए। काम के मूल उद्देश्य को समझने की कोशिश करना, trial and error का जोखिम उठाकर नए रास्ते तलाशने की जिज्ञासा रखना, और लक्ष्य की दिशा तय करना—यह केवल इंसान ही कर सकता है। ज़िम्मेदारी का मतलब सिर्फ नतीजे पाना नहीं है, बल्कि उस प्रक्रिया में उद्देश्य को नज़र से ओझल न होने देना और लगातार सवाल पूछते हुए खोज करते रहने का रवैया भी है।
मैनुअल और निर्देशों के अलावा दूसरे तरीकों को रचनात्मक रूप से खोज निकालने की क्षमता भी जिम्मेदार रवैये से ही आती है।
इससे मैं पूरी तरह सहमत हूँ।
Hacker News की राय
अभी मुझे पहला वाला जोखिम कहीं ज़्यादा बड़ा लगता है। बकवास bugs, dead-end architecture, security issues, code ownership की भावना में कमी, और सीखने के मौके खोना जैसी समस्याएँ हैं
दूसरी ओर, AI को कम इस्तेमाल करने पर productivity घट सकती है, लेकिन codebase की गहरी समझ और training लंबे समय में बड़ी पूँजी बन सकती है
निजी तौर पर मुझे लगता है कि code के भीतर खुद जूझते हुए मिलने वाले creative ideas सबसे ज़्यादा मूल्यवान होते हैं
अफ़सोस यह है कि अगर बहुत जल्दी AI को काम सौंप दिया जाए, तो ऐसे मौके खो जाते हैं
repetitive काम कम हो जाने से दिमाग कम थकता है, और मुश्किल समस्याओं पर फोकस कर पाने से बेहतर ideas आते हैं
असली बात है अच्छी taste और standards बनाए रखना
अगर design और documentation पहले से बारीकी से तैयार हो, तो सफलता की संभावना ज़्यादा रहती है
code generation से ज़्यादा planning और design phase ही असली मुश्किल हिस्सा है
लेकिन documentation या boilerplate लिखने में LLM काफ़ी समय बचाता है
कोई एक ही बार में पूरा app बनाना चाहता है, तो कोई इसे सिर्फ़ simple autocomplete के स्तर पर इस्तेमाल करता है
लगातार नए तरीके सामने आ रहे हैं, इसलिए खुले मन से अलग-अलग प्रयोग करना ही सबसे अच्छा है
नई technology को हमेशा छोटे हिस्सों में validate करके धीरे-धीरे expand करना ही सही तरीका होता है
AI का सही उपयोग वही है जितना ‘validate’ हो चुका हो
इस बहस को Pascal’s Wager की तरह मोड़ देना दुखद है, और अक्सर यह कुछ बेचने वालों की दलील होती है
भले ही AI code अच्छी तरह लिख दे, लेकिन tax calculation की सूक्ष्म ग़लतियों जैसे नज़र न आने वाले failure modes सबसे खतरनाक होते हैं
असली accounting system में ग़लत संख्याएँ चुपचाप दर्ज हो सकती हैं
इसलिए मैं AI को सिर्फ़ advanced autocomplete tool की तरह इस्तेमाल करता हूँ — architecture और domain logic मैं खुद design करता हूँ, और इसे सिर्फ़ repetitive code या test scaffolding के लिए इस्तेमाल करता हूँ
आख़िरकार समस्या “AI द्वारा लिखा code” नहीं, बल्कि वह code है जिसे मैं खुद नहीं समझता
LLM functions लिखने में अच्छा है, लेकिन कौन-से functions चाहिए, यह तय नहीं कर सकता
असली project architecture तो वास्तविक bottlenecks से टकराते हुए बनती है
AI ने सिर्फ़ implementation speed में मदद की, structural judgment पूरी तरह इंसान की ज़िम्मेदारी है
ख़ास तौर पर domain bugs को LLM कभी नहीं पकड़ सकता
आख़िर में architecture और domain knowledge की ज़िम्मेदारी इंसान को ही लेनी होगी
अगर आप उससे सिर्फ़ ‘code लिखने’ को कहेंगे, तो वह लक्ष्य ही नहीं है, इसलिए स्वाभाविक है कि वह नहीं कर पाएगा
पिछले एक साल में मैंने software design और Vibe coding दोनों साथ सीखे हैं
DDD, Clean Architecture, Agile जैसी कई किताबें पढ़ते हुए मैं पहले से कहीं बेहतर engineer बना हूँ
AI का इस्तेमाल करूँ तब भी code की ज़िम्मेदारी आख़िरकार मेरी ही है
दोनों क्षेत्रों में एक साथ आगे बढ़ा जा सकता है
इसमें समय और practice लगती है, लेकिन इसे सीखना बहुत मूल्यवान है और यह दूसरी skills की जगह नहीं लेता
क्योंकि LLM जिस चीज़ में कमज़ोर है, वह high-level judgment और structural design है
अच्छी तरह डिज़ाइन किया गया system AI की efficiency को अधिकतम कर देता है
साथ ही नई paradigms सीखना LLM द्वारा बनाए गए code को बेहतर परखने और सुधारने में मदद करता है
BDD, PBT, model verification जैसी techniques AI coding को अधिक सुरक्षित बनाने के tools हैं
ऊपर से यह जीत जैसा दिखता था, लेकिन वास्तव में यह हार के वेश में जीत थी
इस पर किसी ने कहा कि यह वर्णन बिल्कुल नशे के उछाल और गिरावट जैसा लगता है
LLM का सही इस्तेमाल करने के लिए इन तीनों भूमिकाओं की muscles चाहिए
अगर आप मनचाहा UI/UX स्पष्ट रूप से कल्पना कर सकते हैं, तो मौजूदा models से भी काफ़ी अच्छे नतीजे मिल सकते हैं
इसके उलट, “कुछ भी बना दो” जैसे prompts ख़तरनाक हैं
AI को advanced mecha suit की तरह चलाना चाहिए — इंसान loop के भीतर हो तो ही असली रफ़्तार मिलती है
technology की प्रगति इतनी तेज़ है कि जो काम पिछले साल मुश्किल था, वह आज मामूली हो गया है
अंदर इस्तेमाल होने वाले AI tools तक को open source models से बदला जा रहा है
अभी का समय मानो “AI version of Don’t Look Up” जैसा लगता है — सबको बहुत देर होने से पहले AI युग के हिसाब से खुद को फिर से तैयार करना होगा
मेरे एक दोस्त ने 3 महीने Cursor से product बनाया, लेकिन उसमें features बहुत थे और उपयोगिता लगभग नहीं थी
आख़िरकार समस्या ऐसे व्यक्ति की अनुपस्थिति थी जो code को समझता हो
बुनियादी मानसिक जाँच (sanity check) तक न करना समझना मुश्किल है
उपयोगी abstraction, modularization, और code structure में सुधार नहीं कर पाता