‘वाइब कोडिंग’ काम को खत्म नहीं करता: इसे विश्वास, जोखिम और गति की ओर स्थानांतरित करता है

‘वाइब कोडिंग’ काम को खत्म नहीं करता: इसे विश्वास, जोखिम और गति की ओर स्थानांतरित करता है

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

कार्यक्षेत्र में वादा स्पष्ट है: कम घर्षण, अधिक गति। एक ऐसी जानकारी जो अक्सर उद्योग के विश्लेषण में उद्धृत की जाती है, मैकिन्से को श्रेय देते हुए, सुझाव देती है कि एआई सहायक तकनीकों के साथ डेवलपर्स पारंपरिक तरीकों की तुलना में 56% तेजी से कार्य पूरा करते हैं। इसके साथ, बाजार "विचार" और "उत्पाद" के बीच का अंतर भरता है जिसमें ऐसे संपादक और वातावरण शामिल होते हैं जो इस तर्क को आगे बढ़ाते हैं: कर्सर कंपोजर स्वचालित उत्पादन के लिए, रीप्लिट प्राकृतिक भाषा में ऐप बनाने के लिए, और Google फ्लो जो विचारण के साथ तैनाती को जोड़ते हैं, जिसमें फ़ायरबेस स्टूडियो और "वाइब डेप्लॉयिंग" की ओर बढ़ने का प्रयास शामिल है।

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

जब कोड 'सस्ता' होता है, तो अपनाना मानसिक घर्षण की एक समस्या बन जाता है

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

एक संवादात्मक प्रवाह में, उपयोगकर्ता जो चाहता है उसका वर्णन करता है, एआई कुछ कार्यात्मक लौटाता है और टीम संकेतों के साथ पुनरावृत्ति करती है। यह गतिशीलता तत्काल इनाम पैदा करती है जो प्रयास की भावना को कम करती है। आंतरिक खरीदार के दृष्टिकोण से - उत्पाद, विपणन, संचालन - इसका आकर्षण स्पष्ट है: तेजी से प्रोटोटाइप, तकनीकी घुटन से कम निर्भरता, और “अंततः हम निर्माण कर सकते हैं” की एक कथा। संज्ञानात्मक घर्षण कम होता है क्योंकि विकास की विशिष्ट भाषा समाप्त होती है: अब किसी समुद्र में फ्रेमवर्क, निर्भरता और कॉन्फ़िगरेशन को नेविगेट करना आवश्यक नहीं है ताकि कुछ चालू हो सके।

लेकिन इसी घर्षण की कमी प्रयास को एक कम दृश्य स्थान की ओर स्थानांतरित करती है: जोखिम का आकलन। जब आउटपुट तेजी से प्रकट होता है, तो मस्तिष्क मानता है कि रास्ता भी सरल है। और वहीं असमानता का जन्म होता है: महसूस किया गया मूल्य तुरंत हो जाता है, जबकि वास्तविक लागत - तकनीकी ऋण, सुरक्षा, रखरखाव - स्थगित और, उससे भी बदतर, जिम्मेदारी की श्रृंखला में धुंधली हो जाती हैं।

यह वह पैटर्न है जिसे मैं बार-बार देखता हूँ: नेता "डेमो को चमकाने" में निवेश करते हैं, क्योंकि यही वही है जो समिति समझती है और प्रशंसा करती है। और वे ऑपरेशनल डर को खत्म करने में निवेश करने से कम हैं, क्योंकि ये डर तब तक दिखाई नहीं देते जब तक वे घटना, देरी या अधिक लागत के रूप में प्रकट नहीं होते।

56% तेजी से उत्पादकता वास्तविक है, लेकिन आर्थिक इकाई बदलती है

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

कर्सर कंपोजर, रीप्लिट या Google फ्लो जैसे उपकरण ऐप बनाने और तैनात करने के लिए "कोशिश" करने की सीमांत लागत को कम करते हैं। यह नवाचार के पोर्टफोलियो को बदल सकता है: अधिक प्रयोग, अधिक एमवीपी, वास्तविक उपयोगकर्ताओं के साथ अधिक परीक्षण। रणनीतिक रूप से, यह शक्तिशाली है क्योंकि यह महीनों की तैयारी को घंटों या दिनों में बदलता है।

हालांकि, CFO और COO को विकास की वित्तीय संरचना में परिवर्तन पर अवश्य ध्यान देना चाहिए: इंजीनियरिंग की लागत का एक हिस्सा "निर्माण" से "सत्यापन" की ओर स्थानांतरित होता है। यदि पहले गुणवत्ता नियंत्रण लिखने और कोड की समीक्षा करने के कार्य में निहित था, तो अब नियंत्रण एक स्पष्ट गतिविधि बन जाता है: नीतियाँ, परीक्षण, समीक्षाएँ, तैनाती की सीमाएँ, और स्वीकार्यता मानदंड।

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

वित्तीय परिणाम सीधा है: "पहले 80%" की लागत कम हो जाती है और "अंतिम 20%" की लागत बढ़ जाती है, वह खंड जहाँ ताकत, सुरक्षा और रखरखाव मौजूद होते हैं। एक परिपक्व टीम इसे पहले ही अनुमानित करती है। एक डेमो से बहकाया गया टीम इसे देर से खोजती है।

कंपनियों के अंदर वाइब कोडिंग को आगे बढ़ाने वाली चार शक्तियाँ

मैं वाइब कोडिंग की प्रगति को चार शक्तियों के बीच एक समझौते के रूप में देखता हूं जो प्रत्येक अपनाने के निर्णय में प्रतिस्पर्धा करती हैं।

प्रेरणा वास्तविक निराशाओं से आती है: अंतहीन बैकलॉग, महंगा प्रतिभा, और कुछ इंजीनियरों की निर्भरता जो "जानते हैं कि सब कुछ कहां है"। कई संगठनों में, समस्या विचारों की कमी नहीं है, बल्कि उन्हें समय पर उपयोगी सॉफ़्टवेयर में परिवर्तित करने की असमर्थता है। वहां, कोई भी तंत्र जो प्रतीक्षा और समन्वय को कम करता है, उसे बढ़त मिलती है।

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

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

अंत में, आदत है: इंजीनियरिंग की स्थिति में ऐसे अनुष्ठान हैं जो "शांति ख़रीदने" के लिए हैं —कोड की समीक्षा, मानक, स्वामित्व, दस्तावेज़— भले ही वे धीमे हों। वाइब कोडिंग उन अनुष्ठानों को चुनौती देता है और उन्हें उत्तरदायी लेकिन हल्के अन्य के साथ बदलने की मांग करता है।

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

उत्पाद के नेता और CTO की नई प्रतियोगिता: प्रॉम्प्ट और तैनात का संचालन

यदि कोड का उत्पादन करना सस्ता हो जाता है, तो अंतर दो क्षमताओं में स्थानांतरित होता है: सही तरीके से निर्दिष्ट करना और सही तरीके से प्रशासन करना। वाइब कोडिंग में, प्रॉम्प्ट एक विवरण नहीं है; यह डिजाइन का एक नया रूप है। वे कंपनियाँ जो यह मानकीकरण नहीं करती हैं कि कैसे पूछा जाए, कैसे मान्य किया जाए और कैसे तैनात किया जाए, एक उत्पादकता का रंगमंच समाप्त करती हैं: कई डेमो, थोड़ी विश्वसनीयता।

यहाँ बुद्धिमान आंदोलन हाइब्रिड है, जैसा कि इस घटना की कई पठन सुझाव करते हैं: वाइब कोडिंग का उपयोग विचार और प्रोटोटाइप को तेज करने के लिए करें, लेकिन उत्पादन की अनुशासन बनाए रखें। इसका मतलब है स्पष्ट नियम: कौन से प्रकार के सिस्टम गहन सहायता से उत्पन्न किए जा सकते हैं, किसे गहरी समीक्षा की आवश्यकता है, और तैनाती से पहले न्यूनतम नियंत्रण कहां होता है।

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

आधिकारिक तौर पर, इस प्रवृत्ति से उस नेता को अधिक मूल्यवान बनाता है जो डर को नियंत्रित करना जानता है: जो सरल प्रक्रियाओं के साथ अनिश्चितता को कम करता है, जो समीक्षा को हल्का और सामान्य बनाता है, और जो बिना नौकरशाही के जिम्मेदारी को परिभाषित करता है। वाइब कोडिंग काम को खत्म नहीं करता; यह दृश्य काम को खत्म करता है और अव्यक्त काम को व्यवसायिक बनाने के लिए मजबूर करता है।

सही कार्यकारी निर्णय: चमक में कम निवेश और संचालन नियंत्रण में अधिक निवेश

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

C-Level के लिए, महत्वपूर्ण बिंदु उपकरण का चयन नहीं है, बल्कि विश्वास के एक प्रणाली का डिज़ाइन है: गुणवत्ता मानदंड, तैनाती के सीमाएँ, और नियंत्रण जो गति को न तोड़ें। जो कंपनी इसे "एक नया IDE" के रूप में मानती है वह आंतरिक घर्षण और संचयी जोखिम का सामना करेगी। जो कंपनी इसे निर्णय लेने, समीक्षा करने और जिम्मेदारी निभाने के तरीके के पुनः डिज़ाइन के रूप में मानती है वह upside को पकड़ लेगी बिना झ Exposure को बढ़ाया।

दृश्य रणनीतिक त्रुटि तब होती है जब नेतृत्व अपनी पूंजी को अत्यधिक त्वरित डेमो के साथ उत्पाद को चमकाने में निवेश करता है, और डर और घर्षण के उस कम बजट को छोड़ देता है जो यह निर्धारित करता है कि ग्राहक, आंतरिक या बाहरी, वास्तव में इसे खरीदता है या नहीं।