हमें हर चीज़ को “वाइब कोडिंग” कहना बंद करना चाहिए

लंबे ब्रेक के बाद मैं फिर से कोडिंग पर लौट आया, और Lovable वह जगह थी जहाँ मैंने इसे फिर से शुरू किया। ऐप्स शानदार दिखे, पहली नज़र में काम किए, और कुछ ही घंटों में तैयार हो गए। शुरू में यह उल्लेखनीय लगा। लेकिन जैसे ही मैं यह जानना चाहता था कि कोड क्या कर रहा है – और क्यों – यह पर्याप्त नहीं रहा। तभी मेरा दृष्टिकोण बदलने लगा।

अंतर उपकरण के बारे में नहीं है, या AI द्वारा आपके लिए लिखे गए कोड की मात्रा के बारे में नहीं है. यह आपके आउटपुट के साथ आप जो अनुबंध स्वीकार करते हैं, उसके बारे में है: क्या आप समझा सकते हैं कि आपने अभी दुनिया में क्या जारी किया, या नहीं।

वाइब कोडिंग, अपने मूल अर्थ में, AI‑जनित सॉफ़्टवेयर को बिना ठीक से जाँच या समझे स्वीकार करने को कहते हैं। AI‑सहायता प्राप्त विकास अलग है। मॉडल अभी भी अधिकांश कोड लिख सकता है, लेकिन सिस्टम बनाने वाले व्यक्ति को इसके व्यवहार को समझने, इसकी धारणाओं का परीक्षण करने और यह तय करने की जिम्मेदारी रहती है कि क्या यह रिलीज़ करने के लिए तैयार है।

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

वाइब कोडिंग ने अपना अर्थ कैसे खो दिया

‘वाइब कोडिंग’ शब्द को फ़रवरी 2025 में Andrej Karpathy, जो OpenAI के सह‑संस्थापक हैं, ने बनाया था। उनका उदाहरण जानबूझकर अनौपचारिक था: एक “फेंकने योग्य सप्ताहांत प्रोजेक्ट” जिसे स्वचालित रूप से “Accept All” पर क्लिक करके बनाया गया, अंतर को नजरअंदाज़ किया गया और कोड को उनकी समझ से परे बढ़ने दिया गया।

कुछ हफ़्ते बाद, डेवलपर और टूल‑निर्माता Simon Willison ने देखा कि इस शब्द का उपयोग बहुत अलग तरीके से किया जा रहा था: इसे किसी भी AI‑सहायता प्राप्त प्रोग्रामिंग के लिए एक समानार्थक शब्द के रूप में बना दिया गया था, जिसके बारे में उन्होंने तर्क दिया कि यह शब्द को पतला कर देता है और जिम्मेदार AI‑सहायता विकास क्या हासिल कर सकता है, इसका गलत प्रभाव देता है।

रोचक बात यह है कि Karpathy अंततः सहमत हुए। एक साल बाद, उन्होंने एक अलग शब्द पेश किया कोडिंग एजेंट्स के साथ अधिक अनुशासित कार्य के लिए। उन्होंने “एजेंटिक इंजीनियरिंग” को एक कार्यप्रवाह के रूप में वर्णित किया जिसमें डेवलपर्स एजेंट्स को निर्देश देते हैं और उनकी निगरानी करते हैं, न कि केवल उनके द्वारा उत्पन्न परिणाम को स्वीकार करते हैं। यह अंतर महत्वपूर्ण है: पेशेवर AI‑सहायता विकास को योजना, जाँच और जवाबदेही की आवश्यकता होती है, जो अनौपचारिक वाइब कोडिंग में नहीं होती।

रेखा है जिम्मेदारी

Willison का नियम सरल है, और यह किसी भी व्यक्ति के लिए एक परीक्षण के रूप में काम करता है: ऐसा कोड कमिट न करें जिसे आप किसी और को समझा न सकें। इसका मतलब यह नहीं है कि हर एक पंक्ति पढ़ें: एजेंट्स एक साथ सैकड़ों पंक्तियाँ उत्पन्न कर रहे हैं, यहाँ तक कि अनुभवी डेवलपर्स भी अब ऐसा नहीं करते। इसका अर्थ है मूल तर्क को समझना और यह साबित कर पाना कि कोड ठीक वही क्यों करता है जो वह करता है। यदि आप कर सकते हैं, तो यह मायने नहीं रखता कि मॉडल ने इसे लिखा या आपने लिखा: यह वाइब कोडिंग नहीं है, यह एक टूल का उपयोग करके सॉफ़्टवेयर बनाना है।

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

इसलिए, केवल अनुभव इसे समझा नहीं सकता। यह इस बात पर निर्भर करता है कि क्या आप AI द्वारा उत्पन्न चीज़ की जिम्मेदारी लेने को तैयार हैं। यह वह निर्णय है जिसे हर डेवलपर हर प्रोजेक्ट पर बार‑बार लेता है।

जब नियंत्रण गायब हो तो क्या होता है

सॉफ़्टवेयर को समझे या उसकी सुरक्षा की जाँच किए बिना जारी करने के परिणाम अमूर्त नहीं होते। Tea, एक ऐप जो डेटिंग के दौरान महिलाओं को सुरक्षित रखने में मदद करने के लिए बनाया गया था, दो सुरक्षा घटनाओं में दर्जनों हजार ID फ़ोटो और एक मिलियन से अधिक निजी संदेश उजागर किए। विफलताओं में एक असुरक्षित स्टोरेज बकेट और एक अलग डेटाबेस शामिल था जो बिना प्रमाणीकरण के पहुँचा जा सकता था।

इसी मूल समस्या – सॉफ़्टवेयर काम करता दिखता है जबकि उसकी प्राधिकरण तर्क खतरनाक रूप से गलत रहता है – Lovable प्लेटफ़ॉर्म पर निर्मित एक एप्लिकेशन में भी दिखाई दी: सुरक्षा शोध ने पाया कि प्राधिकरण तर्क उलटा था, जिससे लॉग‑इन उपयोगकर्ता बाहर हो गए जबकि बिना प्रमाणीकरण वाले हमलावर स्वतंत्र रूप से अंदर आ सके, यह 18,000 से अधिक उपयोगकर्ताओं को प्रभावित किया, जिसमें छात्र भी शामिल थे।

ये केवल “खराब” प्रोजेक्ट्स में ही नहीं होते। Google की 2025 DORA रिपोर्ट के अनुसार, अब 90% डेवलपर्स काम में AI का उपयोग करते हैं, जबकि लगभग एक‑तीहाई यह रिपोर्ट करते हैं कि वे जो उत्पन्न होता है उस पर बहुत कम या कोई भरोसा नहीं रखते।

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

नियंत्रण परत‑दर‑परत बनता है, एक बार में नहीं

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

जैसे-जैसे प्रोजेक्ट गंभीर होते गए, मेरा कार्यप्रवाह अधिक संरचित हो गया। केवल प्रॉम्प्ट्स पर निर्भर रहने के बजाय, मैंने कुछ भी उत्पन्न करने से पहले विनिर्देश तैयार करना शुरू किया। मैंने व्यापार आवश्यकताओं, तकनीकी स्टैक और एकीकरणों का दस्तावेज़ीकरण किया। फिर मुख्य उपयोगकर्ता यात्राओं के लिए यूनिट टेस्ट और Playwright टेस्ट आए।

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

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

Tea और Lovable मामलों की तुलना में, यह एक सामान्य समस्या थी। मैंने इसे जल्दी पाया, ठीक किया और आगे बढ़ा। यही आमतौर पर समीक्षा का वास्तविक रूप है। अधिकांश समय, यह छोटे समस्याओं को बड़े बनने से रोकता है।

मैं कोड को केवल इसलिए अविश्वास नहीं करता क्योंकि वह AI द्वारा बनाया गया है। मैं इसे केवल इसलिए भी भरोसेमंद नहीं मानता क्योंकि एप्लिकेशन चल रहा है। परीक्षण और समीक्षा ही वह तरीका है जिससे मैं यह तय करता हूँ कि यह इच्छित रूप से व्यवहार करता है या नहीं।

वाइब कोडिंग से एजेंटिक इंजीनियरिंग तक

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

खतरा यह नहीं है कि AI कोड जल्दी उत्पन्न करता है। खतरा यह है कि उत्पन्न करना समझ से तेज़ हो सकता है।. जब ऐसा होता है, दिखती हुई उत्पादकता उन जोखिमों को छुपा देती है जोकोई भी सही ढंग से जांच नहीं पाया है।

रखने योग्य एक नियम

“वाइब कोडिंग” को AI‑सहायता विकास के हर रूप के लिए लेबल के रूप में उपयोग करना बंद करें – यह शब्द को पतला कर देता है और नियंत्रण में एक महत्वपूर्ण अंतर को मिटा देता है। एक सरल नियम स्थापित करें: वह चीज़ रिलीज़ न करें जिसे आप समझा नहीं सकते। और जैसे-जैसे प्रोजेक्ट बढ़ता है, नियंत्रण को परत‑दर‑परत बनाएं, उभरते जोखिमों के साथ कदम‑दर‑कदम जांचें जोड़ते रहें।

AI अधिकांश कोड लिख सकता है। वह इसे रिलीज़ करने की जिम्मेदारी नहीं ले सकता। यह अभी भी हमारी ही जिम्मेदारी है।