AI-सहायता प्राप्त इंजीनियरिंग, वाइब कोडिंग नहीं: वह फ़र्क़ जो मायने रखता है

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

AI-सहायता प्राप्त इंजीनियरिंग रफ़्तार रखती है और अटकलबाज़ी छोड़ देती है। कोड अब भी AI ही लिखता है, पर हर बदलाव एक डिलीवरी अनुशासन के भीतर उतरता है: वह किसी ब्रांच पर वर्ज़न होता है, पॉलिसी के खिलाफ़ जांचा जाता है, स्वचालित टेस्ट से गुज़रता है, सिक्योरिटी समस्याओं के लिए स्कैन और प्रोब किया जाता है, और रोलबैक पथ वाली नियंत्रित पाइपलाइन से डिप्लॉय होता है। जिन बदलावों के नतीजे गंभीर हैं उन्हें एक इंसान स्वीकृत करता है, और ऑडिट ट्रेल दर्ज करता है कि उसने ऐसा किया। प्रॉम्प्ट वही है। प्रॉम्प्ट के बाद जो कुछ होता है, वह सब अलग है।

यह भेद किताबी नहीं है। यही तय करता है कि आपकी बनाई चीज़ ग्राहक डेटा संभाल सकती है या नहीं, सिक्योरिटी समीक्षा पास कर सकती है या नहीं, अपने रचयिता के जाने के बाद बच सकती है या नहीं, या किसी दूसरी टीम को सौंपी जा सकती है या नहीं। अगर इनमें से किसी का भी जवाब हां होना ज़रूरी है, तो फ़ैसला बनाने का तरीक़ा करता है, बनाने वाला मॉडल नहीं।

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

ज़्यादातर टीमें इस समस्या से हैंडओवर के पल टकराती हैं। मार्केटिंग, ऑपरेशंस या प्रोडक्ट का कोई व्यक्ति एक ऐसा टूल वाइब-कोड करता है जो इतना काम का निकलता है कि लोग उस पर निर्भर होने लगते हैं। फिर उसे SSO चाहिए। फिर वह कुछ निजी स्टोर करने लगता है। फिर कोई डायरेक्टर पूछता है कि बदलावों की समीक्षा कौन करता है, और ईमानदार जवाब होता है, कोई नहीं। उस मोड़ पर विकल्प बदसूरत होते हैं: उसे ढंग से दोबारा बनाओ, जस का तस अपनाकर अनजान जोखिम विरासत में लो, या एक ऐसा टूल बंद कर दो जिसे लोग पहले से इस्तेमाल कर रहे हैं।

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

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

अगर आप इंजीनियरिंग का नेतृत्व करते हैं, तो इस दर्द का सबसे नुकीला रूप है दोष की विषमता। बिज़नेस AI-निर्मित टूल्स की रफ़्तार का जश्न तब तक मनाता है जब तक उनमें से एक फ़ेल नहीं हो जाता, और नाकामी इंजीनियरिंग के सिर आती है, भले ही इंजीनियरिंग ने वह टूल कभी देखा तक न हो। यही गतिशीलता गवर्न्ड रास्ते को सिर्फ़ ज़िम्मेदार नहीं, अपने हित का क़दम भी बनाती है: बिना मंज़ूरी के बनाए जाने का इकलौता टिकाऊ जवाब है बनाने का एक ऐसा स्वीकृत तरीक़ा जो उतना ही तेज़ हो। पाबंदियां किसी ऐसे टूल से टकराकर नहीं बचतीं जो किसी की सोमवार-सुबह की समस्या हल करता हो; बेहतर डिफ़ॉल्ट बचते हैं।

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

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

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

Automo इसीलिए बनाया गया ताकि तेज़ रास्ता और अनुशासित रास्ता एक ही रास्ता हों। आप सरल भाषा में ऐप का वर्णन करते हैं और Automo असली React, TypeScript और Supabase एप्लिकेशन बनाता है जिनके मालिक आप हैं, पर हर बदलाव डिलीवरी लूप के भीतर उतरता है, उसके बगल में नहीं। Guardrails कोड को बिज़नेस क्षेत्रों में मैप करता है, जोखिम भरे बदलाव पकड़ता है, सरल भाषा में लिखी पॉलिसी लागू करता है, मानव समीक्षा दर्ज करता है और हर मर्ज के पीछे एक ऑडिट ट्रेल छोड़ता है। QA डिटरमिनिस्टिक ब्राउज़र रीप्ले, सेल्फ-हीलिंग टेस्ट, पब्लिश से पहले स्मोक गेट और पब्लिश के बाद प्रोडक्शन जांच चलाता है। Security स्टैटिक स्कैनिंग, डिपेंडेंसी जांच और एक्सेस-कंट्रोल प्रोब चलाता है, और फ़्लैग करने से पहले लाइव ऐप के खिलाफ़ कमज़ोरियों की पुष्टि करता है।

नतीजा यह कि Automo पर प्रोटोटाइप और प्रोडक्शन ऐप दो अलग-अलग चीज़ें नहीं हैं, वे एक ही चीज़ हैं, जांच के अलग-अलग स्तरों पर, और जांच प्लेटफ़ॉर्म लागू करता है, न कि वह व्यक्ति जिसे याद रह जाए। कोड मानक React, TypeScript और Tailwind है, कभी भी आपकी अपनी रिपॉज़िटरी में एक्सपोर्ट करने योग्य, इसलिए अनुशासन कभी पिंजरा नहीं बनता। गंभीर प्रोडक्शन प्रोग्राम चलाने वाली टीमों के लिए एक पंक्ति में यही पिच है: AI-सहायता प्राप्त इंजीनियरिंग, वाइब कोडिंग नहीं। गंभीर डेवलपमेंट प्रोग्राम USD 10,000 प्रति वर्ष से शुरू होते हैं; लूप को शुरू से अंत तक चलते देखने का सबसे तेज़ तरीक़ा एक डेमो है।

एक ईमानदार बात: कोई भी प्लेटफ़ॉर्म अनुशासन को मुफ़्त नहीं बनाता। पॉलिसी अब भी लिखनी पड़ती हैं, प्रोटेक्टेड ज़ोन घोषित करने पड़ते हैं, और फ़्लैग हुए बदलावों पर फ़ैसले की ज़िम्मेदारी अब भी किसी इंसान की होती है। प्लेटफ़ॉर्म जो बदलता है वह है डिफ़ॉल्ट. Automo पर अनुशासनहीन रास्ता ही वह है जिसमें अतिरिक्त मेहनत लगती है, जो ज़्यादातर टूलिंग के काम करने के तरीक़े का ठीक उल्टा है। व्यवहार में यही उलटफेर तय करता है कि किसी टीम के मानक डेडलाइन से टकराकर बचते हैं या नहीं।