Vibe code, legacy code ही है

• Vibe coding AI की मदद से intuition के आधार पर तेज़ी से code लिखने का तरीका है, लेकिन अंततः यह ऐसा code छोड़ जाता है जिसे समझा नहीं जाता, यानी legacy code
• Legacy code वह code है जिसे कोई भी ठीक से नहीं समझता; यह technical debt और maintenance समस्याएँ पैदा करता है, और नए features जोड़ते समय errors की संभावना बढ़ाता है
• Vibe coding prototype या short-term project के लिए तेज़ development का साधन हो सकता है, लेकिन जिन projects को लंबे समय तक maintain करना हो उनके लिए यह उपयुक्त नहीं है
• अगर non-expert लोग बड़े project को vibe coding से बनाते हैं, तो उसमें बच्चे को credit card देने जैसा जोखिम होता है
• 2025 में भी AI के साथ development करते समय सावधानी और समझ बनाए रखना महत्वपूर्ण है

---

Vibe coding क्या है

• Andrej Karpathy ने "vibe coding" शब्द को ऐसी programming शैली के रूप में परिभाषित किया, जिसमें AI code लिखता है और user code के अस्तित्व को लगभग भूलकर उस पर ध्यान ही नहीं देता
• यह approach पारंपरिक software development से अलग है, क्योंकि इसमें developer लिखे गए code के अंदरूनी हिस्से को बिल्कुल समझे बिना भी परिणाम हासिल कर सकता है

Legacy code की समस्या और technical debt

• ऐसा code जिसे कोई नहीं समझता, वह पहले से ही legacy code है
• ऐसे code को maintain और improve करने में बहुत समय लगता है, और bugs या नए features जोड़ने के समय समस्याएँ काफी बढ़ जाती हैं
• इसमें ज़ोर दिया गया है कि programming का सार बहुत सारा code बनाना नहीं, बल्कि conceptual theory बनाना है

Vibe coding और prototyping

• Vibe coding prototype development या one-off project के लिए तेज़ शुरुआत और development उपलब्ध कराता है
• अगर बाद में maintenance की ज़रूरत नहीं है, तो code के अंदरूनी हिस्से को न जानना बहुत बड़ा बोझ नहीं बनता
• इसी वजह से यह development speed को काफी बढ़ाता है और नए ideas के साथ experiment करने के लिए बहुत उपयुक्त है

Vibe coding का understanding spectrum

• Vibe coding में developer की code के प्रति understanding जितनी कम होती है, उतना ही वह ज़्यादा vibe पर काम कर रहा होता है
• मूल रूप से engineer requirements को जितना स्पष्ट रूप से समझता है, vibe coding उतनी कम हो जाती है
• जब non-programmer web और native app के अंतर या data storage के तरीके को जाने बिना coding की मांग करता है, तो आमतौर पर अधिक vibe coding होती है

Non-expert द्वारा बड़े पैमाने की vibe coding: credit card जैसी स्थिति

• किसी non-expert का vibe coding के ज़रिए बड़े project को बनाना और maintain करना बिना समझ के बच्चे को credit card देने जैसी स्थिति है
• शुरुआत में सब कुछ आसान लग सकता है, लेकिन बाद में maintenance cost और समस्याएँ बहुत बढ़ जाती हैं
• आखिरकार जब 'bill' सामने आता है, तो अगर समस्या सुलझाने की क्षमता न हो, तो स्थिति और बिगड़ सकती है

2025 के AI युग में गंभीर development

• Andrej Karpathy ने ज़ोर दिया कि AI के साथ development में सावधानी, सतर्कता, और मौजूदा code से लगातार सीखते रहने का रवैया अनिवार्य है
• AI के बढ़ा-चढ़ाकर दिखाए गए आत्मविश्वास से बचाव करना, और अच्छे code व खराब code में फर्क करने की मानवीय judgment महत्वपूर्ण है
• सिर्फ AI पर न छोड़ें; code को खुद पढ़ना और समझना ज़रूरी है

Val Town के AI tools का उपयोग

• Val Town, Townie नामक AI assistant के माध्यम से code लिखना, चलाना, जाँचना, और iterative improvement की प्रक्रिया को automate करता है
• Townie vibe coding के लिए उपयुक्त tool है, और उपयोग के उद्देश्य के अनुसार इसे स्वतंत्र रूप से इस्तेमाल किया जा सकता है या कड़ाई से नियंत्रित किया जा सकता है
• AI के साथ development का तरीका बहुत तेज़ी से evolve हो रहा है, और complex software development में theoretical foundation का महत्व आगे भी बना रहेगा

Non-expert की अनियंत्रित vibe coding पर चेतावनी

• किसी non-programmer का हज़ारों डॉलर खर्च करके विशाल app idea को vibe coding से बनाना अच्छा तरीका नहीं है
• अंततः किसी भी हाल में code के अंदरूनी हिस्से को सीधे पढ़ने और analyze करने वाली मानवीय नज़र की ज़रूरत होती है, और समझ से परे legacy code को ठीक करने की तुलना में शुरुआत से सही design करना अधिक प्रभावी हो सकता है

निष्कर्ष और सलाह

• जटिल software बनाते समय theoretical foundation सबसे महत्वपूर्ण है
• AI की प्रगति से programming का तरीका तेज़ी से बदल रहा है, लेकिन मानव developers की विशेषज्ञता अब भी महत्वपूर्ण है
• अगर non-expert लोग AI से बड़े पैमाने का app बनाना चाहते हैं, तो अंत में पूरे code को पढ़कर उसे नए सिरे से बनाना ही बेहतर हो सकता है

[servent2616]

यह ऐसा है जैसे किसी बच्चे को क्रेडिट कार्ड दे देना
यह एक उपयुक्त उपमा है
या फिर इसकी तुलना किसी बच्चे को चाकू देने से भी की जा सकती है

[actofvalor]

अगर AI-जनरेटेड कोड के साथ कमेंट्स भी जोड़ दे और code flow diagram वगैरह भी बना देने वाला code-generation AI आ जाए, तो वह कुछ हद तक मददगार होगा।

[draupnir]

यह काफ़ी हद तक सहमत होने लायक बात है। मैं भी वास्तव में इसका कुछ हिस्सा अनुभव कर रहा हूँ…
साथ ही यह जानने की उत्सुकता भी है कि मॉडल के performance में बदलाव के साथ यह हिस्सा कैसे बदलता जाएगा।

[optionzero]

बात इतनी सही है कि सुनकर सचमुच दिल से हामी भरने का मन करता है। जो लोग कोड नहीं जानते, वे vibe coding करते समय वाह कहते हैं, लेकिन जो लोग कोड जानते हैं, वे कहते हैं, क्यों? ऐसा क्यों?

[qscwdv531]

कमेंट्स की स्थिति वाकई दयनीय है।

[kgun9]

तो क्या कार को उसके आंतरिक ढांचे को पूरी तरह समझने से पहले कभी चलाया ही नहीं जा सकता?

[onetoday]

आंतरिक संरचना को समझे बिना कार बनाना = vibe coding

[hackerst]

सवारी तो कर सकते हैं। लेकिन बना नहीं सकते, है न।

[sinbumu]

मुझे लगता है यह तरीके और तकनीक का सवाल है। जो लोग कहते हैं कि AI इस्तेमाल मत करो और organic hand-coding ही करनी चाहिए, वे कुछ ऐसे लगते हैं जैसे जो लोग कहते हों कि engineering calculator की जगह अबेकस चलाओ, या Excel function मत इस्तेमाल करो और हाथ से लिखना ही सत्य है।

[elbanic]

यह एक गलत उपमा है। इंजीनियरिंग calculator, calculator या Excel की तरह, input values के अनुसार सटीक परिणाम देता है। अगर AI वही output देता जो उपयोगकर्ता ने अनुमान लगाया है, तो अब तक आई अनगिनत नई technologies की तुलना में यह इतनी अलग technology नहीं होती। समय के साथ security और hallucination को लेकर चिंताएँ बढ़ने का यही कारण भी है। यानी Gen AI को control नहीं किया जा सकता। मौजूदा LLM की सीमाओं को समझकर ही इसका उचित जगहों पर इस्तेमाल होना चाहिए।

[tensun]

मौजूदा समय में vibe coding अभी शुरुआती चरण में है, और मेरा मानना है कि अगले एक-दो वर्षों में यह एक परिपक्व development methodology बन जाएगी। जैसे devops, aidevops बन रहा है, वैसे ही मुझे लगता है कि aiagile या vibeagile भी उभरकर आएगा।

[GN⁺]

Hacker News की राय

• यह एक गैर-डेवलपर दोस्त की कहानी है। उस दोस्त ने पिछले साल खुद कोड लिखकर एक SaaS लॉन्च किया, और लगभग बिना मार्केटिंग के सिर्फ word of mouth और inbound के दम पर कमाई शुरू कर दी। डेवलपमेंट के लिए उसने Replit और Supabase का इस्तेमाल किया, और ग्राहकों से feedback लेते-लेते ऐप धीरे-धीरे जटिल होता गया—यह सोचकर सच में प्रभावित होना पड़ता है। मेरी समझ से इस बाज़ार में पहले से दो incumbent कंपनियाँ थीं, और मेरे दोस्त ने उनसे कहीं सस्ती monthly pricing पर ज्यादा आधुनिक product पेश किया, इसलिए वे कंपनियाँ खुश नहीं थीं (मौजूदा products सभी Windows desktop software थे)। इसलिए उन्होंने hackers को hire करके मेरे दोस्त के SaaS पर हमला करवाया, और इन hackers ने बिना पैसे मांगे हमला किया। दुर्भाग्य से, मेरे दोस्त ने बिना अनुभव के बहुत तेजी से कोड लिखा था, इसलिए उसमें कई vulnerabilities थीं। पहली बात, frontend code में user list expose हो रही थी, जिससे hackers ने सभी ग्राहकों को email भेज दिया। दूसरी बात, hackers को Stripe key मिल गई और उन्होंने सभी ग्राहकों को refund कर दिया। तीसरी बात, अभी भी hackers XSS attack की कोशिश करते रहते हैं और कभी-कभी fields में <script>alert()</script> जैसे tags दिखाई दे जाते हैं। मेरा निष्कर्ष यह है कि जब कोई अनुभवहीन व्यक्ति vibe-coding करता है, तो technical debt तुरंत जमा होना शुरू हो जाती है। लेकिन साथ ही, यह भी हैरान करने वाली बात है कि इस दोस्त ने engineering अनुभव के बिना कुछ ही महीनों में business viability वाला product साबित कर दिया। अब वह developers hire करके चीजें सुधार रहा है। इतने ढीले और security-vulnerable code के साथ भी उसने सिर्फ कुछ सौ डॉलर लगाकर ठीक-ठाक business potential साबित कर दिया, इसलिए अंत में मुझे लगता है कि वह प्रक्रिया मूल्यवान थी

  • मुझे लगता है कि इसे competitor की करतूत मान लेना उल्टा जिम्मेदारी से बचना है। ज्यादा संभव यह है कि कोई automated vulnerability scanner साइट तक पहुंच गया, और सिस्टम इतना कमजोर था कि hackers भीतर घुसकर शरारत करने लगे। जो लोग internet-connected services पर exploit traffic नियमित रूप से देखते हैं, वे यह अच्छी तरह जानते हैं

  • यह नैतिक रूप से वैसा ही है जैसे किसी ने बिना engineering अनुभव के घर बना दिया हो और फिर कोई आकर बस लात मारकर उसे गिरा दे। समस्या vibe coding में नहीं है, बल्कि उन महत्वपूर्ण फैसलों के लिए जरूरी ज्ञान की कमी में है। ऐसे मामले कानूनी liability तक भी जा सकते हैं

  • अगर बाज़ार में पहले से incumbent कंपनियाँ थीं, तो business viability साबित करने के लिए ऐसे MVP की जरूरत ही क्या थी? मूल बात तो यह है कि अगर आप चीज़ सस्ती देंगे तो लोग मौजूदा provider से switch करेंगे या नहीं—यह टेस्ट करने की जरूरत नहीं थी। तुम्हारे दोस्त ने असल में जो सीखा, वह यह है कि कुछ ग्राहक शुरुआत में पैसे देने को तैयार होंगे (लेकिन repeat-rate data नहीं है), पर अंततः असली product बनाने के लिए लोगों को hire करना पड़ेगा, और तब price advantage भी कम हो जाएगा। जब seriously marketing में निवेश करने का समय आएगा, तब मुश्किलें बढ़ेंगी। अंत में फिर वही बात समझ आती है कि ideas अपने-आप में कोई value नहीं रखते, execution capability ही असली चीज़ है

  • यह कि तुम्हारा दोस्त लगभग बिना किसी जवाबदेही के business चलाता रह सकता है, यही इस industry की बुनियादी समस्या है। अगर software दुनिया दूसरी engineering disciplines की तरह सख्ती से regulated होती, तो developers या कंपनियों को customer data leak पर कानूनी जिम्मेदारी उठानी पड़ती

  • मान लो business का validation हो भी गया, तब भी customer के नज़रिये से यह फायदा नहीं, नुकसान हो सकता है। वे पैसे देकर product इस्तेमाल कर रहे हैं, साथ ही अपना महत्वपूर्ण data एक security-weak जगह पर expose कर रहे हैं, और यह भी साफ नहीं कि product ठीक से काम करता है या नहीं। अब कहा जा रहा है कि developer hire करके इसे सुधारा जाएगा, लेकिन यह उतना आसान नहीं होगा जितना लगता है। मैं AI के training material, productivity, या learning tool के रूप में इस्तेमाल के पक्ष में हूँ, लेकिन अगर बीच में इंसान शामिल न हो तो नतीजा बहुत खराब हो सकता है

• पहले भी कई बार गैर-डेवलपर्स या junior developers ने Microsoft Access, Excel वगैरह के जरिए आसानी से applications बनाकर deploy की हैं। तब भी limits, scalability issues, और maintenance nightmare बहुत थे, लेकिन साथ ही ऐसे रुझान आने पर professional developers ने बेहतर solutions बनाने की रफ्तार भी तेज की। PC के popular होने के समय भी यही हुआ था—mainframe developers, PC दुनिया के इस ‘बेतरतीब’ code को देखकर हैरान रह जाते थे

• मैं लगभग तीस साल से software engineer के रूप में काम कर रहा हूँ और इस पोस्ट के सारे comments पढ़ चुका हूँ। लेकिन मुझे लगता है कि vibe coding की आलोचना में दिए जाने वाले लगभग सारे तर्क उन सभी ‘मानव-लिखित’ codebases पर भी उतने ही लागू होते हैं जिन्हें मैंने अपने करियर में देखा है (हालाँकि कुछ अपवाद ज़रूर हैं)

  • मुझे समझ नहीं आता कि throwaway prototype बुरी चीज़ क्यों मानी जाती है। business शुरू करने में यह सबसे महत्वपूर्ण चरण है। legacy code के साथ भी यही बात है। वास्तव में revenue पैदा करने वाला ज़्यादातर code, उस संगठन के developers की नज़र में पहले से legacy माना जा रहा होता है

  • मज़ाक में कहा जाता है कि trunk में merge होते ही सब कुछ legacy code बन जाता है

  • मैं कुछ हद तक सहमत हूँ, लेकिन vibe coding की समस्या यह है कि यह लोगों को बिना ठीक से जांच-पड़ताल किए, बिना मौजूदा codebase की structure या जरूरी solution को समझे, सीधे लापरवाही से काम शुरू करने देता है। कल ही एक ऐसे colleague ने, जो Rust में सहज नहीं है, vibe coding से एक नया feature बनाया। ऊपर-ऊपर से वह ‘काम’ करता है, लेकिन असल में बहुत बुरी हालत है (tokio async context में synchronous I/O, locks, अपना custom channel implementation वगैरह)। जबकि safe async abstractions पहले से मौजूद हैं, उसने नए और गलत abstractions बना दिए। अगर उसने खुद थोड़ा खोजा होता या पहले मदद मांगी होती, तो मौजूदा code में examples देखकर काम कर सकता था

• हर code एक दिन legacy code बनता है। जब से मैं junior था, और मैंने या मेरे साथ के junior developers ने जो countless production scripts और services लिखीं, उनकी code reviews के अनुभव से देखें तो ऐसा absolutist नज़रिया बहुत अतिशयोक्तिपूर्ण है। यह समस्या ज़्यादातर संगठनों में बार-बार होती है। LLM-based code की quality की आलोचना करने वाले लेख लिखना समझ में आता है, लेकिन जिसने अपने करियर का बड़ा हिस्सा दूसरों के बनाए systems को ठीक करने, बढ़ाने या refactor करने में लगाया है, वह इस reality को बेहतर समझेगा। जब तक software engineering की दुनिया में mechanical engineering जैसी consistency, certification, accountability और वास्तविक परिणामों के लिए सख्त मानक और कानूनी risk नहीं आते, तब तक यह बहस बहुत मायने नहीं रखती। आधुनिक IT industry खुद पूरी तरह उलटी philosophy पर खड़ी है—यानी ‘agile’, ‘जल्दी बनाओ, टूट जाए तो भी चलेगा’। जल्दी-जल्दी, कम design के साथ बार-बार deploy करो; गलत चला गया तो rollback कर दो; outage हो जाए तो ‘हो जाता है’ जैसी भावना रहती है। software को खिलौने की तरह लिया जाता है। शायद 1% लोग कहेंगे कि वे इसे सही तरीके से करते हैं, लेकिन बहुमत ऐसा नहीं करता

  • तुम जो कह रहे हो वह सब सही है, और मैं इसमें यह जोड़ूँगा कि code आखिरकार science नहीं है। ‘सही’ code का मानदंड हर स्थिति में अलग होता है। code बस किसी लक्ष्य तक पहुँचने का एक tool है

• इस समय एक दिलचस्प चीज़ हो रही है। जो लोग engineering को ठीक से नहीं समझते, और कुछ हद तक वे लोग भी जो समझते हैं लेकिन सही तरीके से समझाते नहीं, वे online गलत narrative फैला रहे हैं। वे अब दावा कर रहे हैं कि junior developers 10 गुना productive हो गए हैं, और PM तक खुद code deploy कर रहे हैं। लेकिन ज़रा आँख बंद करके सोचो कि ऐसी स्थिति में जो code निकलेगा, वह 100% legacy code होगा और अंततः फेंक देने लायक होगा। असली मुद्दा AI नहीं है, न ही PM का Figma से सीधे code निकाल लेना, न junior का prompt पर prompt मारना। expectations और reality के बीच जो gap है, उसका असली कारण यह है कि हम उन terms और concepts के बीच भेद नहीं कर पा रहे जिन्हें परिभाषित करने और समझने में वर्षों की चर्चा लगी थी।
  lean prototype और disposable prototype (यहाँ तक कि MVP भी नहीं) अलग चीज़ें हैं। MVP केवल lean prototype के सफल validation के बाद ही बनाया जा सकता है। product, MVP से भी अलग चीज़ है।
  vibe coding tools disposable prototype जल्दी बनाने में बेहतरीन हैं, जबकि LLM-enabled IDEs असली product बनाने के लिए ज्यादा उपयुक्त हैं। अभी की स्थिति में, केवल असली engineers ही LLM prompts के सहारे lean prototype को code करने के स्तर पर हैं; बाकी लोग disposable code पर चलने वाला साधारण software ही बना रहे हैं

  • तुमने कहा, “product, MVP से अलग है,” और मैं यह बात अपने लगभग हर पुराने workplace को कहना चाहूँगा। आजकल boards और C-level executives का रवैया “इस quarter के अंत तक कुछ भी ship कर दो” वाला हो गया है, इसलिए developers MVP बनाकर तुरंत अगले project पर भेज दिए जाते हैं। असली vibe coding हो या न हो, ground reality यह है कि अगर feature-rich दिखे तो actual quality चाहे जैसी हो, business metrics बढ़ जाते हैं। सच कहें तो ऐसे environment, जहाँ वास्तविक engineers (लगता है अब ‘developers’ को यही कहा जाता है) proactively prototyping करते हों, बहुत कम हैं। शायद gaming या कुछ tech कंपनियों में ही दिखे। ज़्यादातर जगह बस MVP बनाने पर ही सारा फोकस है। vibe coding सिर्फ MVP assembly line को तेज़ करता है, और quality उसी अनुपात में कुर्बान होती है

  • पिछले 10 सालों में industry में “term definitions” के substance के बिना mix होकर इस्तेमाल होने का रुझान बहुत बढ़ा है। ये शब्द मूल रूप से अनगिनत किताबों, चर्चाओं और लंबे समय की बहसों से context जमा करके बने थे। जब कोई अनुभवी developer एक शब्द इस्तेमाल करता था, तो उसके भीतर पूरा अनुभव और debate का संदर्भ मौजूद होता था। लेकिन नए लोग इस context के बिना सिर्फ सतही तौर पर शब्दों को ‘copy’ कर लेते हैं और बिना परिभाषा के उनका इस्तेमाल करने लगते हैं। नतीजा यह होता है कि कोई भी यह नहीं समझ पाता कि हर term मूल रूप से क्या मतलब रखती थी, और वह उस स्थिति के लिए सही शब्द क्यों थी। उदाहरण के लिए, "'agile', 'technical debt', 'DevOps', और हाल का ‘vibe coding'" वगैरह। HN पर semantic drift के बारे में एक लेख भी आया था। software industry में यह आम बात है।
    तकनीकी उदाहरण के तौर पर JavaScript में 'object', 'JSON', 'dictionary', 'hashmap' को सब गड्ड-मड्ड करके बोलना देखा जा सकता है। मूल रूप से इन सबके अर्थ अलग हैं, लेकिन JS developers के लिए यह सब बस ‘object’ बनकर रह जाता है। यानी भाषा और अवधारणा की resolution एक ही ‘pixel’ में दब जाती है

  • पहले developers आपस में कहा करते थे कि लोगों का code के प्रति ‘mindset’ अलग होता है। लेकिन अब code को समझ ही न पाने से होने वाली developer fatigue बहुत बढ़ गई है। पहले ऐसी स्थिति में engineers आगे आते थे, टूटी चीज़ों को उपयोगी बनाते थे, और architects complexity कम करते थे। अब LLM के दौर में 100 गुना ज्यादा code बरस रहा है, लेकिन engineers और architects इस flow से लगभग बाहर कर दिए गए हैं। यही वह वर्तमान स्थिति है जिसे हम सीधे महसूस कर रहे हैं।
    अगर कोई इस समस्या का हल देने वाली testing methodology (TDD MCP server, DDD MCP server, या कोई भी workflow/architecture) खोज ले, तो वह trillion-dollar startup बना सकता है। code review की efficiency को बड़े पैमाने पर बढ़ाने और scale करने वाले tools की सख्त जरूरत है

  • मुझे लगता है कि “working software” की definition को और स्पष्ट करना चाहिए। उदाहरण के लिए, LLM से बने UI सब एक जैसे दिखते हैं, और उनमें subtle गलतियाँ या छिपी हुई errors होती हैं। एक बार user testing होते ही समस्या सामने आ जाती है। और generative UI अक्सर सिर्फ trends का पीछा करता है, कुछ नया पैदा नहीं करता

  • क्या तुमने कभी बड़ी कंपनियों का internal code लिखने का तरीका देखा है? वह vibe coding से बहुत अलग नहीं होता। बल्कि अगर LLM को pentest pass करने के लिए tune कर दिया जाए तो वह कम-से-कम कुछ कोशिश तो करेगा। बड़ी कंपनियों को तो अक्सर परवाह भी नहीं होती

• सच तो यह है कि हर code legacy है। इसलिए यह कोई खास बात नहीं कि vibe coding तेज़ी से बहुत सारा code पैदा कर देता है। आखिर में, वह ‘मेरे हाथ से लिखा code’ भी उतना ही बेतरतीब निकल सकता है जिसे कोई नहीं समझ पाएगा। maintenance के नज़रिये से हर code अंततः बोझ ही है। libraries कुछ समस्याएँ कम कर सकती हैं, लेकिन जो चीज़ें बार-बार बदलती हैं या जिनके interfaces पुराने हो चुके हैं, वे और भी बुरी legacy बन जाती हैं।
  जो लोग लंबे समय तक code लिखते रहे हैं, वे अंततः इस निष्कर्ष पर पहुँचते हैं कि असली समाधान कम बनाना है—यानी कुल मिलाकर जरूरत ही कम करनी है। हर complexity अंततः ‘भविष्य का वह मसला’ बन जाती है जिसे मैं बाद में याद नहीं रख पाऊँगा। सच तो यह है कि requirements भी समय-समय पर बदलती रहती हैं, और expert द्वारा बताई गई requirements भी गलत हो सकती हैं (और वह ‘expert’ खुद आप भी हो सकते हैं)

  • मैं “हर code legacy है” वाली बात से सहमत नहीं हूँ। कुछ code छोटा होता है, और developer के दिमाग में उसका पूरा मॉडल अब भी मौजूद रहता है, इसलिए वह पूरी तरह ‘real-time’ code होता है। legacy की व्यावहारिक परिभाषा यह है कि code बहुत बड़ा हो और संगठन में उसका कोई वर्तमान owner न हो। vibe code, बनते ही इन दोनों में से दो शर्तें लगभग पूरी कर देता है

  • legacy वह है जहाँ अब कोई stakeholder नहीं बचा, इसलिए maintenance भी मुश्किल है और context समझना भी

  • मेरी इच्छा रहती है कि कम-से-कम code में समस्या हल हो। असली बात यह है कि code मेरी समस्या ही न बने। मुद्दा abstraction के कितना ‘leaky’ होने का है, और अभी LLM जो abstractions बना रहे हैं वे बहुत खराब हैं। आगे यह कितना सुधरेगा, कहना मुश्किल है।
    मैं उन tools में निवेश करना चाहूँगा जो code समझना ज्यादा मज़ेदार, आसान और सस्ता बना दें। मेरे दोस्त Glen का एक project इस संदर्भ में दिलचस्प है: https://glench.github.io/fuzzyset.js/ui/
    Geoffrey Litt की बात सही है कि LLM हमारे code को समझने में मदद करने वाले अस्थायी visualization tools, debuggers वगैरह बनाने में कहीं ज्यादा उपयोगी हो सकता है

  • हर code में risk हो सकता है, लेकिन हर code legacy नहीं होता। vibe-coded code ऐसा लगता है जैसे उसमें शुरुआत से ही context या owner नहीं होता, इसलिए वह तुरंत legacy बन जाता है

  • “हर code legacy है” वाली दलील के जवाब में, मैं कहूँगा कि जो project मैं बहुत गहराई से समझता हूँ, उसमें bug का कारण मैं तुरंत पकड़ सकता हूँ और दिमाग में नए feature का implementation साफ़ देख सकता हूँ—वह legacy नहीं है

• मेरे विचार से “code को गणित की तरह देखने का दौर” खत्म हो चुका है। जो software पर्याप्त बड़ा हो और real world से जुड़ा हो, उसे गणितीय proof की तरह पूरी तरह True साबित नहीं किया जा सकता। वास्तविक systems engineering artifacts हैं, जो formal guarantees, experience-based design, experimental testing, tacit knowledge, performance criteria आदि पर निर्भर करते हैं।
  यह रुझान सबसे छोटे scripts तक फैल जाएगा। अधिकांश software को गणितीय रूप से सिद्ध करने की जरूरत ही नहीं है। बस वह अपना उद्देश्य पूरा कर दे, इतना काफी है। programming की craftsmanship का मैं पूरा सम्मान करता हूँ, लेकिन अब शायद उस आसक्ति को छोड़ने का समय है।
  अंततः भविष्य इन दो विकल्पों में से एक हो सकता है

• 100,000 lines, 50,000 tests वाला ऐसा program जो सभी requirements को guarantee करता है लेकिन किसी के लिए पढ़ना मुश्किल है, कुल लागत $50,000 (API token cost)

• इंसानों द्वारा design किया गया 30,000 lines, 3,000 tests, परिष्कृत abstractions, वही requirements पूरी करता हुआ program, कुल लागत $300,000 (developer salaries)
  अगर मैं software consumer होता, और मुझे अंदरूनी बारीकियों से मतलब न होता, सिर्फ कीमत देखनी होती, तो मैं बिना हिचक 6 गुना सस्ता विकल्प चुनता

  • लेकिन यह भी सोचना चाहिए कि जब कोई नई external requirement के कारण बदलाव करना पड़े तब क्या होगा। ऐसे मामलों में, अगर वह software business के core में है, तो आपको तुरंत provider बदलना पड़ सकता है। इसलिए B2B हो या B2C, maintenance और support अनिवार्य हैं। software को हमेशा बदलाव के अनुरूप ढल सकना चाहिए

  • यानी वही मज़ाक: “इस code को मैं और Copilot ही समझते थे। अब सिर्फ Copilot समझता है”

  • “real world से जुड़ी पर्याप्त बड़ी systems को गणितीय रूप से सही साबित नहीं किया जा सकता” — इस पर formal verification में काम करने वाले लोग शायद जोरदार विरोध भी करेंगे, और भीतर-ही-भीतर सहमत भी होंगे

  • इन दो scenarios में यह पूछना चाहिए कि version upgrade के समय कौन-सा विकल्प ज्यादा सस्ता और तेज़ होगा। अभी के लिए मुझे लगता है कि human developer model सस्ता पड़ता है, लेकिन भविष्य को लेकर निश्चित नहीं कहा जा सकता

  • सच कहूँ तो इन दोनों में से कोई भी विकल्प मैंने वास्तविक दुनिया में लगभग देखा ही नहीं है

• शायद विकास का अंतिम चरण पूरी तरह machine-oriented programming language होगी, जिसे इंसानों के पढ़ने की जरूरत ही न हो। अगर LLM को आखिरकार Python या Swift जैसी human-readable language में बदलना ही है, तो क्यों? सीधे runnable result ही क्यों न हो, ताकि maintenance जैसी अवधारणा भी बेमानी हो जाए। हम अभी उस चरण पर नहीं हैं, लेकिन लगता है कभी न कभी उधर जा सकते हैं

  • अच्छा software हमेशा maintenance में होना चाहिए। नई requirements लगातार आती रहती हैं, इसलिए यह मानना ही मज़ाक है कि एक बार feature ship किया और काम हमेशा के लिए खत्म हो गया। भविष्य के बदलावों को ध्यान में रखकर बनाया गया code, tests और documentation इसलिए महत्वपूर्ण हैं। अगर LLM अर्थहीन black-box code की बाढ़ ला दे, तो उससे डरावनी बात और क्या होगी। यह कल्पना कि LLM मानव-स्तर की coding तक पहुँच जाएगा और फिर किसी को उसकी परवाह नहीं रहेगी, science fiction जैसा विचार है। coding, वास्तव में उपयोगी software बनाने की पूरी प्रक्रिया का सिर्फ एक हिस्सा है

  • क्या machine code पहले से कुछ ऐसा नहीं है? LLM इंसानों के पढ़ने योग्य interfaces के लिए optimized है, इसलिए वह JSON बनाता है, BSON लगभग नहीं

  • समझ नहीं आता कि यह आखिर किस समस्या को हल करेगा। कौन-सी समस्याएँ पैदा होंगी, वह तो साफ दिखता है

  • यह कुछ ऐसा लगता है जैसे LLM इंसानों के लिए लिखे code को सीखता है, फिर वही code वापस उगलता है, और फिर उस code को चलाकर वांछित व्यवहार पाने की कोशिश की जाती है—एक तरह का ‘telephone game’। मन में सवाल आता है कि क्या हम सीधे behavior generate नहीं कर सकते

  • अगर इंसानों के पढ़ने में कठिन language की बात करें, तो Malbolge उसका मशहूर उदाहरण है। उसका पहला "Hello World" program भी genetic algorithm ने बनाया था

• मैं मूल लेखक हूँ। आप सबके साथ बातचीत को लेकर उत्साहित हूँ

• ‘vibe coding’ शब्दावली कुछ ज़्यादा ही परफेक्ट निकली है। जैसे ‘cloud computing’ शब्द बहुत फैल गया था। मूल रूप से उसका मतलब elastic EC2 instances चालू करके काम खत्म होते ही बंद कर देना था, लेकिन metaphor इतना intuitive था कि Gmail जैसी सेवाएँ भी पूरी की पूरी ‘cloud’ कहलाने लगीं।