"Vibe Coding Cleanup Service" का उदय
(donado.co)- हाल में IT उद्योग में "Vibe Coding Cleanup" नाम की एक नई service category उभरी है:
Vibe Coding Cleanup as a Service - जैसे-जैसे यह हकीकत सामने आई कि AI-generated code का अधिकांश हिस्सा production के लिए उपयुक्त नहीं है, उसे व्यवस्थित और ठीक करने के लिए एक नया service market उभर आया है
- 2025 की शुरुआत में Andrej Karpathy द्वारा "Vibe Coding" को परिभाषित किए जाने के बाद, 92% developers AI tools का उपयोग कर रहे हैं, लेकिन code quality में गिरावट और security vulnerabilities की समस्या गंभीर रूप से सामने आई है
- वास्तव में developers अब AI द्वारा बनाए गए inconsistencies, duplication, और irrational logic को ठीक करने में विशेषज्ञ रूप से काम कर रहे हैं, और dedicated marketplaces तथा consulting services फैल रही हैं
- AI छोटे कामों में बेहतरीन है, लेकिन system context को ध्यान में नहीं रख पाती, जिससे structural debt और security issues बड़े पैमाने पर पैदा होते हैं, और यही आगे चलकर "cleanup economy" नाम का नया industrial opportunity बनाता है
- अगर companies को AI coding का सफल उपयोग करना है, तो prototype AI से बनवाना चाहिए, लेकिन architecture, security, और test cleanup processes में skilled professionals पर निवेश करना होगा
Vibe Coding का उदय और विस्तार
- 2025 की शुरुआत में Andrej Karpathy ने "Vibe Coding" शब्द का उपयोग किया, जिसके बाद यह अवधारणा स्थापित हुई
- natural language बातचीत के ज़रिए पूरे functions generate करने का तरीका
- productivity को 10x तक बढ़ाने की उम्मीद के साथ यह तेज़ी से फैल गया
- GitHub के अनुसार 92% developers AI coding tools का उपयोग कर रहे हैं
- Copilot हर महीने अरबों lines of code generate करता है
- लेकिन GitClear के analysis के अनुसार AI code उपयोग करने पर 41% अधिक code churn देखा गया
- 2 हफ्तों के भीतर revert या rewrite होने वाला code काफ़ी बढ़ गया
- Stanford की research में पाया गया कि AI assistance इस्तेमाल करने वाले developers ज़्यादा insecure code लिखते हैं, फिर भी उसे अधिक secure मानने की प्रवृत्ति दिखाते हैं
- input validation की कमी, outdated dependencies का उपयोग, और ambiguous design decisions जैसी वजहों से AI tools कई anti-patterns को amplify करने की समस्या पैदा करते हैं
Cleanup economy की हकीकत
- हाल में IT industry में Vibe Coding Cleanup नाम का एक नया service area चुपचाप उभरा है
- शुरुआत में यह "AI द्वारा बनाए गए गड़बड़ code को ठीक करना" जैसी मज़ाकिया बात लगती थी, लेकिन अब यह एक वास्तविक business opportunity बनती दिख रही है
- 404 Media की जांच के अनुसार, कुछ developers सिर्फ AI code cleanup करके career बना रहे हैं
- यह काम "AI spaghetti" कहलाने वाले inconsistencies, duplication, और अजीब logic को सुलझाने का है
- Ulam Labs Vibe Coding Cleanup को अपनी core service के रूप में प्रचारित कर रही है
- VibeCodeFixers.com नाम का एक dedicated marketplace भी सामने आया है
- कुछ ही हफ्तों में 300 से अधिक experts जुड़ गए और दर्जनों projects match हुए
- typical customer: "वह startup जिसने OpenAI credits पर हज़ारों डॉलर खर्च कर दिए हों और जिसके पास आधा-अधूरा काम करने वाला prototype हो"
AI code असफल क्यों होता है
- समस्या यह नहीं कि AI खुद खराब code लिखती है, बल्कि यह है कि वह system context को समझे बिना locally optimized code लिखती है
- नतीजतन inconsistent patterns, duplicate logic, और security gaps जमा होते जाते हैं और technical debt पैदा होता है
- Georgetown University की research के अनुसार AI-generated code का कम-से-कम 48% security vulnerabilities शामिल करता है
- जैसे secret information exposure, पुराने libraries का उपयोग, और load conditions में पैदा होने वाले race conditions
- इससे भी गंभीर बात यह है कि developers खुद AI द्वारा generated code को पर्याप्त रूप से नहीं समझ पाते, इसलिए समस्याओं की सही पहचान नहीं कर पाते
- Thoughtworks इसे "capability debt" कहता है
- यानी टीम code maintain करने की क्षमता खो देती है और AI dependency में फँस जाती है
Market opportunity
- cleanup market तेज़ी से बढ़ रहा है, लेकिन उसके सटीक आँकड़े समझना मुश्किल है
- Gartner का अनुमान है कि 2028 तक enterprise developers में से 75% AI code assistants का उपयोग करेंगे
- ज़्यादातर projects में cleanup की ज़रूरत पैदा होने की उम्मीद है
- अगर इनमें से केवल कुछ हिस्से को भी cleanup की आवश्यकता हुई, तो scale के हिसाब से यह बहुत बड़ा नया market बन सकता है
- आर्थिक दृष्टि से भी यह आकर्षक है
- startups AI से तेज़ी से MVP बनाते हैं, लेकिन बाद में cleanup पर उतना ही समय और पैसा लगाते हैं
- फिर भी यह पारंपरिक development की तुलना में तेज़ रहता है
- cleanup experts प्रति घंटा 200~400 डॉलर तक charge करते हैं
- fixed-price packages, AI code audits, और "Vibe-to-Production" pipelines जैसी productized services भी फैल रही हैं
- Thoughtworks के अनुसार, AI-आधारित projects में refactoring ratio घटा है और code churn बढ़ा है, तथा production में डालने से पहले बड़े पैमाने पर cleanup process अनिवार्य हो गई है
- कई consulting firms ने AI code cleanup या remediation roles के लिए dedicated talent hire करना शुरू कर दिया है
- निष्कर्ष यह है कि cleanup market वास्तविक है, तेज़ी से बढ़ रहा है, और अभी भी इसमें बहुत से untapped areas मौजूद हैं
Engineering पर प्रभाव
- software development methodology में मूलभूत बदलाव चल रहा है
- development process अब AI implementation करती है → इंसान architecture, testing, और cleanup संभालते हैं जैसी division of labor structure में बदल रहा है
- Gergely Orosz ने AI tools को "बहुत ज़्यादा उत्साही junior developer" से तुलना की है, जो तेज़ी से code लिखता है लेकिन हमेशा supervision की ज़रूरत होती है
- लेकिन AI हमेशा junior developer के स्तर पर ही रहती है और senior की तरह विकसित नहीं होती, इसलिए cleanup experts की भूमिका हमेशा बनी रहती है
- नए career paths भी खुल रहे हैं
- अगर junior developers cleanup skills सीख लें, तो 2 साल में senior-level salary तक पहुँच सकते हैं
- जो seniors AI की strengths और limitations दोनों समझते हैं, वे बहुत अधिक value create कर सकते हैं
- सफल companies वे नहीं होंगी जो AI का सबसे अधिक उपयोग करें, बल्कि वे होंगी जो cleanup process को व्यवस्थित रूप से build करें
- जिन organizations के पास मजबूत cleanup process होगा, उन्हें market में competitive advantage मिल सकता है
Donado Labs का दृष्टिकोण
- Donado Labs अपने अनेक Vibe code cleanup अनुभवों के आधार पर ज़ोर देता है कि AI acceleration के लिए उपयोगी है, लेकिन expert cleanup process अनिवार्य है
- prototyping और repetitive tasks के लिए AI, जबकि core architecture, security, और testing इंसान संभालें
- अपनी "Vibe to Production" service के ज़रिए वह AI prototypes को enterprise स्तर तक व्यवस्थित करता है
- इसमें testing, security hardening, और documentation भी शामिल हैं
- AI coding का सफल उपयोग करने वाली companies वे नहीं हैं जो AI का सबसे अधिक उपयोग करती हैं, बल्कि वे हैं जो AI का स्मार्ट तरीके से उपयोग करती हैं और cleanup में निवेश करती हैं
- technical debt जमा होने से पहले cleanup को साथ-साथ चलाना ही मुख्य बात है
- AI programmers को replace कर देगी, इस दावे के जवाब में सवाल है: "उस code की cleanup कौन करेगा?" — यही असल business opportunity है
4 टिप्पणियां
GPT के शुरुआती दिनों में coding outsourcing करने वालों के पास ऐसे लोग आते थे जो कहते थे कि उन्होंने AI से prototype बना लिया है, बस थोड़ा सा पूरा करना बाकी है, और इसी बहाने कीमत बहुत कम करवाने की कोशिश करते थे।
लेकिन सच कहूँ, क्या यह काम करने वाला कोई होगा?
Vibe coding आने से पहले भी मैं सोचता था कि काश कोई ऐसी सेवा हो जो पूरी तरह बिखरे हुए कोड को साफ़-सुथरा कर दे, और अब सचमुच किसी ने इसे बना भी दिया है। लेकिन, हमारी कंपनी में इसे अपनाने की नौबत शायद कभी नहीं आएगी, हाय।
AI चित्रों की उंगलियां ठीक करने वाली आउटसोर्सिंग एक समय काफ़ी चलन में थी.. लेकिन अब वह भी नहीं रही
लगता है AI cleanup भी उसी राह पर चलेगा
Hacker News टिप्पणियाँ
मैं काफ़ी लंबे समय से बिज़नेस के ज़रिए “restructure” प्रोजेक्ट संभालता आया हूँ
पहले ज़्यादातर ऐसा कोड आउटसोर्स एजेंसियों से मिलता था जो लगभग चलता ही नहीं था, लेकिन आजकल लगता है कि उसका स्रोत LLM की ओर खिसक गया है
आख़िरकार वही समस्याएँ बार-बार दोहराई जाती दिखती हैं
बस लागत घटाने का तरीका बदल गया है
शॉर्टकट चुनने की वजहें साफ़ हैं, लेकिन जब लोग यह गहराई से नहीं समझते कि इसकी कीमत भी चुकानी पड़ सकती है, तभी असली समस्या पैदा होती है
मैनेजर, कर्मचारी, आउटसोर्स स्टाफ—स्रोत कोई भी हो, नतीजा काफ़ी मिलता-जुलता रहता है
मैंने अभी तक vibe coding प्लेटफ़ॉर्म restructure service को अलग से कभी advertise नहीं किया, लेकिन शायद अब इसे आज़माने का समय आ गया है
ऑस्ट्रेलिया का software market छोटा है, इसलिए ऐसे प्रयोगों के नतीजे ज़्यादा सुनाई नहीं देते
मुझे लगता है vibe coding और outsourced development के बीच फ़र्क कोड की मात्रा में है
मैंने एक बार vibe coding से एक साधारण helper script बनवाई थी; अगर मैं खुद लिखता, तो वह अभी के कोड का शायद एक-तिहाई ही होती, और ज़्यादातर edge cases को छूता भी नहीं (कुछ बेकार exception handling थी, कुछ सच में काम की भी थी)
मैंने बस इतना किया कि कोड स्कैन करते समय एक line हटा दी, क्योंकि उससे गलती से home directory delete हो सकती थी
लेकिन बाद में जब मैंने ज़्यादा गहरा data work किया, तो पता चला कि कुछ temp files ग़ायब हैं, और delete code दो जगह और भी था
असल में इंसान के लिए पढ़ने लायक कोड इतना ज़्यादा था कि सब कुछ जाँचना अव्यावहारिक था
फिर भी speed के मामले में यह वाक़ई बहुत ज़्यादा efficient था
आगे से मैं कोड को बारीकी से पढ़ने की बजाय sandbox में AI से tests चलाने का प्लान बना रहा हूँ
खासकर Claude Code जैसे “plan mode” वाले tools में बड़ा फ़र्क है
मैं इन दिनों कंपनी में Claude Code बहुत इस्तेमाल कर रहा हूँ, और हमेशा plan mode में बातचीत के रूप में पहले पूछता हूँ कि “इसे कैसे implement किया जाए”, फिर कुछ rounds की बातचीत से अच्छे design की detailed plan को refine करता हूँ
उसके बाद AI बिल्कुल साफ़ बताता है कि वह कौन-सा कोड generate करेगा (code diff के साथ), and मेरी final approval के बाद ही असली कोड बनाता है
इसके उलट, जब मैंने पहले आउटसोर्स टीम का लिखा कोड review किया था, तो वह ऐसा बेतरतीब spaghetti code था जिसका मतलब समझना ही मुश्किल था
मुझे लगता है SEO के लिए भी site पर vibe-coding से जुड़े terms लिख देना अच्छा idea है
मेरे दिमाग़ में भी ऐसा ही ख़याल आया था
लेकिन जब कोई project vibe-coded होकर bug से भरा codebase बन जाए, तो क्या मैं जाकर bugs ठीक कर दूँ और structure साफ़ कर दूँ, बस उतना ही काफ़ी है?
जिस कंपनी के पास शुरुआत में सही setup करने की domain expertise ही नहीं थी, वह बाद में maintenance कैसे जारी रखेगी, यह सोचता हूँ
मेरी नज़र में outsourcing और LLM-based development, दोनों में आख़िरकार लगभग वही capabilities चाहिए
यानी requirements को साफ़ करना, communication, stakeholder management, spec definition, testing, documentation जैसी engineering की मज़बूत बुनियाद अब भी ज़रूरी है
Karpathy का "vibe coding" जैसा concept इस तरह popular हो जाना थोड़ा अजीब लगता है
शायद यह असल development experience कम रखने वाले लोगों के बीच ज़्यादा फैला होगा
मुझे याद है vibe coding का मतलब कुछ ऐसा था: बस AI से बात करते हुए code generation के output को ठीक से देखे बिना flow पर भरोसा करके आगे बढ़ जाना
अगर आप कोई गंभीर software बना रहे हैं और उसकी quality ज़रा भी मायने रखती है, तो यह बहुत ही भयानक तरीका है
Twitter meme, self-indulgent experiment, या घर में इस्तेमाल होने वाली छोटी scripts तक तो ठीक है, लेकिन proper product development के लिए यह बेतुका है
यह इतना चर्चा में इसलिए आया क्योंकि Karpathy जैसा मशहूर व्यक्ति इसे एक catchy नाम दे गया; कोई और कहता तो शायद यह दब ही जाता
AI से पहले भी junior या कम अनुभवी developers इसी तरह coding करते रहे हैं
कहीं से copy-paste करके बस इतना देखना कि चल रहा है या नहीं, और फिर कोई अजीब bug या core dump आए तो source code का क्रम बदलकर किसी तरह उसे गायब कर देना
ऐसी style पर कंपनी में कम से कम warning मिल सकती है, performance improvement plan पर डाला जा सकता है, और बुरा हुआ तो बाहर भी किया जा सकता है
गैर-विशेषज्ञ लोग software engineers के साथ बातचीत में अक्सर सही नतीजे नहीं निकाल पाए
vibe coding का उभरना मुझे इस बात पर आत्मचिंतन जैसा लगता है कि हम अब तक कैसा software deliver करते आए हैं
असल में जिन vibe coded startups को मैं जानता हूँ, उनका software quality के मामले में बेहद ख़राब है, लेकिन अगर वह उनकी मनचाही चीज़ कर देता है, तो इस चरण में quality उनके लिए महत्वपूर्ण नहीं है
जब तक software quality business को सचमुच नुकसान नहीं पहुँचाती, तब तक वे developers को hire करके अपनी idea के बिगड़ने का risk नहीं लेना चाहेंगे
आख़िर में, घटिया सही, लेकिन जो वे अभी इस्तेमाल कर सकते हैं, वह उनके लिए उस perfect software से बेहतर विकल्प है जो वे चाहते ही नहीं थे
पसंद हो या न हो, vibe coding आगे से गायब नहीं होने वाला
मैं भी निजी तौर पर इस concept से ज़्यादा सहमत नहीं हूँ, लेकिन organization के भीतर साथियों से कभी-कभी कह देता हूँ, ‘यह मैंने vibe coded करके बनाया है’
हमारे यहाँ इसका मतलब होता है कि ‘ज़्यादातर कोड AI से auto-generate कराया गया’
लेकिन ऐसा बना कोड बिना review सीधे production में डालने का इरादा मेरा कभी नहीं होता
यह बस ‘मैंने vibe coding से जल्दी से एक cool app बना लिया’ जैसी हल्की-फुल्की experimental चीज़ है
लगता है Karpathy का मतलब यह था कि vibe coding एक “possible experiment” है जिसे आज़माकर देखना मज़ेदार हो सकता है कि यह कहाँ तक जाता है
कंपनी में सचमुच सिर्फ vibe coding से product बनाने की recommendation वह नहीं कर रहे थे
लोगों ने इस expression के context को अपनी सुविधा से बहुत ज़्यादा खींच लिया
दरअसल Karpathy ने ख़ुद YouTube वीडियो में अपने मतलब को समझाया भी है
संबंधित लेख
Karpathy YouTube: Software Is Changing (Again)
मुझे लगता है लोग यह मानना चाहते थे कि अब मुश्किल काम आसान हो जाएगा, इसलिए ग़लतफ़हमी और बढ़ी
मैं अब भी मानता हूँ कि original tweet भी एक joke था, या ‘YOLO coding’ वाली आज़ादी को व्यक्त करने का तरीका, न कि किसी real work process की recommendation
बस उस वक़्त की मुक्त-भावना को मज़ेदार अंदाज़ में लिखा गया था
अब vibe coding लगभग हर AI coding assistance को नीचा दिखाने या चुटकी लेने वाले शब्द की तरह इस्तेमाल हो रहा है
कोई भी tool अच्छा या बुरा इस्तेमाल हो सकता है, लेकिन इन दिनों “vibe coding कितना बेवकूफ़ाना है” वाला meme online बहुत तेज़ी से approval बटोरता है
अब यह थकाने लगा है
लेख का मुख्य दावा यह है कि "अगर startup vibe coding की मदद से कई हफ़्ते बचाकर MVP बना ले, और बाद में लगभग उतनी ही लागत और समय लगाकर cleanup भी करे, तब भी वह traditional development से तेज़ रहता है"
मुझे जानना है कि क्या वाक़ई ऐसा है
मेरे अनुभव में, अगर developer खुद बना रहा हो और AI assistance का इस्तेमाल कर रहा हो, तो speed gap इतना बड़ा नहीं भी हो सकता
खासकर जब पता हो कि MVP या prototype बाद में सीधे production में जाने वाला है, तो शुरुआत में architecture ठीक से बनाना लंबे समय में बेहतर लगता है
लेकिन product side और management अक्सर इस समय को waste मानते हैं
vibe coding का असली फ़ायदा यह है कि product team को developer को समझाने की ज़रूरत नहीं पड़ती; वह अपनी चाही चीज़ सीधे खुद बना सकती है
शायद code खुद generate करने की बजाय specs और prototypes को साफ़ करने वाले vibe coding आधारित product tools का market हो सकता है
ऐसे tools developers को बेहतर specs देंगे, और business side को ज़्यादा योगदान और ownership भी देंगे
startups में time-to-market इतना महत्वपूर्ण होता है कि कुल मिलाकर ज़्यादा समय और लागत लगे, तब भी सिर्फ़ जल्दी launch होने के कारण technical debt लेना पूरी तरह तर्कसंगत फ़ैसला हो सकता है
इसीलिए लोग technical debt जमा करते हैं
Twitter भी शुरू में Ruby on Rails पर बनी web app थी, और जब भी Justin Bieber tweet करता था, server गिर जाते थे और fail-whale दिखता था
लेकिन growth के साथ उन्होंने experts hire किए और फिर सब कुछ ज़्यादा robust और scalable structure में दोबारा बनाया
MVP से ज़्यादा यह prototype तक के लिए ठीक हो सकता है,
लेकिन अगर organization और व्यक्ति, दोनों स्तर पर यह अनुशासन न हो कि prototype को prod में नहीं डालना है, तो vibe coding से बचना ही सही है
कंपनी management को यह समझाना कितना मुश्किल है कि “जो शानदार code अभी चल रहा है, वह अंदर से बुरी तरह टूटा हुआ है और उसे पूरी तरह बदलना पड़ेगा”, यह सब जानते हैं
ऐसे मामलों में no-code tools कहीं ज़्यादा सुरक्षित हैं
ज़्यादातर MVP या prototypes आख़िरकार बहुत जल्द production में पहुँच ही जाते हैं
मुझे याद है किसी ने कहा था, "अगर MVP code इतना गंदा नहीं है कि उसे देखकर शारीरिक तकलीफ़ हो, तो शायद आप code quality पर बहुत ज़्यादा समय खर्च कर रहे हैं"
आख़िर में ये अस्थायी जुगाड़ वाले code ही कंपनी की backbone बन जाते हैं
सिर्फ़ ऐसे codebase की सफ़ाई करने वाली service को "C-Suite cleanup as a Service" कहा जा सकता है, लेकिन अगर ऐसे advertise किया जाए तो शायद कोई hire ही न करे
लेख पढ़ते ही मुझे em-dash के बिना भी साफ़ लगा कि यह Claude ने लिखा है
पक्का OP ने अपने विचार और material prompt में दिया होगा, लेकिन कुछ खास phrases और sentence tone ठीक वैसे ही थे जैसे LLM में अक्सर निकलते हैं, इसलिए पढ़ना थोड़ा बनावटी लगा
मुझे लगता है आगे चलकर इस तरह की writing “LLM style” के रूप में outdated महसूस हो सकती है
अब शायद vibe-writing cleanup as a service ही trend बनेगा
मैं तो बहुत पहले से em-dash का खूब इस्तेमाल करता आया हूँ, लेकिन अब लगता है कि ज़बरदस्ती ही सही, इसे कम करने का समय आ गया है
Microsoft Word अपने-आप hyphen को em-dash में बदल देता है
मुझे vibe coding, DIY plumbing जैसी लगती है
आप खुद करके देखते हैं, और अगर bathroom में पानी फूट पड़े, तो आख़िरकार महँगा emergency plumber बुलाना पड़ता है
उस प्रक्रिया में अगली बार के लिए थोड़ा सीख भी मिल जाता है
तुलना कुछ हद तक सही है, लेकिन professional plumbers भी DIY को support करने वाले tools अच्छे से इस्तेमाल करते हैं
फ़र्क यह है कि experts को पता होता है कि उन्हें क्या, कब, और कहाँ तक इस्तेमाल करना है
मुझे तो यह उससे भी ज़्यादा गंभीर लगता है
plumbing में कम-से-कम आप आँखों से देख रहे होते हैं कि क्या हो रहा है, लेकिन vibe code में किसी दिन अचानक कुछ काम करना बंद कर देता है और वजह भी समझ नहीं आती
YouTube पर ऐसे DIY plumbers भी बहुत हैं जो कई बार professionals से भी ज़्यादा बारीकी से काम करते दिखते हैं
शायद यह इस बात पर निर्भर करेगा कि vibe coder ऐसे अनुभवों से सचमुच सीखता है या नहीं
समय के साथ पता चलेगा
मुझे यह analogy सच में काफ़ी सटीक लगती है
जैसे दबाव में आया real-estate agent घर बेचने के लिए जल्दी-जल्दी plumbing का काम कर दे, वैसे ही startup founder जल्दी demo बनाकर investors और customers की दिलचस्पी खींचने की कोशिश करता है, और बाद में असली experts बुलाकर cleanup करवाता है
क़िस्मत अच्छी हो, तो उससे पहले कोई बड़ा हादसा टल भी सकता है
मुझे हैरानी हुई कि Janitor Engineer (सफ़ाईकर्मी engineer) जैसा शब्द शायद पहले से industry में था
इसके अलावा, "Why AI code fails at scale" के बाद लेख में दिए गए links सब टूटे हुए थे, जो थोड़ा अजीब लगा क्योंकि लेख बहुत पुराना भी नहीं है
उम्मीद है कोई इसे बुरा नहीं मानेगा
vibe coding के popular होने के बाद से मैं भी आधा-मज़ाक में यह retirement plan सोचता रहा हूँ कि “all-organic-code” consultant बन जाऊँ और AI के बनाए code के ढेर खोल-खोलकर सुलझाता रहूँ
वास्तव में rare चीज़ तो greenfield project है
vibe coding documentation और architecture clarity को तेज़ी से कमज़ोर कर रहा है
कंपनियाँ सिर्फ़ code token generation और prototype speed को महत्वपूर्ण metrics मान रही हैं, और छिपी हुई maintenance व cleanup cost को नज़रअंदाज़ कर रही हैं
अब असली skill generation नहीं, cleanup है
असली काबिलियत तो शुरू से सही guide करके ठीक software निकलवाने में है
कुछ लोग Claude code जैसी चीज़ों को “यही latest tech है” मानते हैं, लेकिन सही तरीके से करने के लिए कहीं ज़्यादा involvement चाहिए
असल में यह पारंपरिक engineering से इतना अलग भी नहीं है
लागत कम रखना और requirements पूरी करना ही मूल बात है
अगर maintainability को explicitly नहीं माँगा जाएगा, तो वही नतीजा मिलेगा जो शुरू से इरादा था
यह documentation की मौत क्यों है, समझना चाहूँगा
एक तरीका यह भी है कि शुरुआत में सिर्फ़ docs लिखे जाएँ, और बाद में code उनके साथ match करता है या नहीं, यह verify करते हुए development हो
या फिर code से docs generate कराए जाएँ, और फिर इंसान खुद जाँच ले कि वे उचित हैं या नहीं
हमारी कंपनी दशकों से ग्राहकों की emergency systems recovery करती आ रही है (जैसे outage वगैरह से गंभीर financial loss हो रहा हो और वे खुद recover न कर पा रहे हों)
पिछले कुछ सालों में ऐसे cases काफ़ी तेज़ी से बढ़े हैं
vibe code कई मायनों में legacy code जैसा है
आपको code पर भरोसा नहीं होता, इसलिए बदलाव से बचते हैं, और internal व external quality दोनों कम होती हैं
लेकिन कुछ फ़र्क भी हैं
अपनी उम्र के हिसाब से code की मात्रा कम है, schedule pressure ज़्यादा है, और expectations बढ़ा-चढ़ाकर रखी जाती हैं
सबसे cost-effective बात यह है कि errors को जितना हो सके runtime पर पहुँचने से पहले, design या compile time से पहले ही पकड़ लिया जाए
समस्या यह है कि AI की वजह से अब सब लोग runtime तक बहुत तेज़ी से भाग रहे हैं
वैसे “Vibe code is legacy code (val.town)” पढ़ने लायक लेख है
संबंधित HN पोस्ट
legacy code हमेशा बुरा हो, ऐसा नहीं है
अक्सर वह जटिल होता है, या documentation कम होती है, और लंबे समय में उस पर छोटे-बड़े operational patches जमा होते जाते हैं
कई operational issues (जैसे नई requirements) उसमें शामिल हो चुके होते हैं, इसलिए वह असली production service में अच्छी तरह चलता भी है
समस्या तब आती है जब codebase को जानने वाले लोग ग़ायब हो जाते हैं, और यहाँ तक कि उस समय की language या tools जानने वाले लोग भी नहीं बचते
सोच रहा हूँ कि क्या vibe coding strongly typed languages में भी लागू हो सकती है
मैं इससे सहमत हूँ कि vibe से बने code को legacy code की तरह treat किया जा सकता है
लेकिन क्या लोग vibe code के मामले में भी सचमुच बदलाव करने से कतराते हैं, यह जानने की जिज्ञासा है
लगता है LLM code generation भविष्य में ग़ायब भी हो सकता है
लेख यह मानकर चलता है कि LLM code हमेशा बनेगा और हमेशा cleanup की ज़रूरत होगी, लेकिन अगर LLM cost + cleanup cost हमेशा developer salary से ज़्यादा पड़े, तो क्या आख़िरकार हमें फिर से इंसानों द्वारा सीधे लिखे गए code की ओर लौटना नहीं पड़ेगा?
LLM से code generate करके उसे जाँचकर इस्तेमाल करना vibe coding से अलग है
vibe coding में अक्सर तैयार code को बिना जाँच सीधे इस्तेमाल किया जाता है
दोनों तरीक़े शायद फिर भी ग़ायब नहीं होंगे
आज का AI-based vibe coding धीरे-धीरे hype खो रहा है
क्योंकि जल्द ही उससे भी बेहतर AI आ जाएगा
अगर कोई पूरा दिन सिर्फ़ vibe coding ही करता रहे, तो आख़िर में इसकी लागत उठाना मुश्किल मॉडल बन सकता है
बहुत ज़्यादा support/assistance मिलने के कारण सबका उत्साहित हो जाना शायद एक भ्रम भी हो सकता है, और बाद में लोग हक़ीक़त समझकर दर्दनाक समायोजन से गुजरें
लेकिन coding examples को समेटकर predictive completion और auto-generation support tools बनने की दिशा कभी ग़ायब नहीं होगी
जैसे पहले लोग syntax highlighting के बिना भी code लिखते थे, लेकिन अब कोई जान-बूझकर वैसा नहीं करता
DFS जैसी चीज़ 80वीं बार फिर से टाइप करने से programmer के रूप में मेरा self-esteem नहीं बढ़ता