अगर vibe coding करनी है, तो C में क्यों न करें?
(stephenramsay.net)- vibe coding वास्तव में अच्छी तरह काम करती है, लेकिन इससे ऐसा कोड बनता है जिसे लेखक खुद पूरी तरह समझ नहीं पाता, और इस वजह से programming का मूल आनंद कम हो जाता है
- सभी programming languages मशीन के लिए नहीं बल्कि इंसानों की सुविधा के लिए बनाए गए tools हैं, और safety, abstraction, readability जैसे फायदे भी आखिरकार इंसानी सोच को व्यवस्थित करने की संरचनाएँ हैं
- तो फिर AI द्वारा लिखे जा रहे कोड के लिए क्या इंसान-मित्र भाषाएँ सच में ज़रूरी हैं?, इसी सवाल से मशीन-मित्र और AI-केंद्रित नई भाषा VOPL(Vibe-Oriented Programming Language) का प्रस्ताव रखा गया है
- इस भाषा में executable pseudocode, literate programming के विस्तार, या natural language आधारित किसी विशेष grammar जैसे कई संभावित रूप शामिल हो सकते हैं
- stored-program computer के शुरुआती दौर की तरह, नए computing paradigms के प्रति प्रतिरोध इतिहास में बार-बार दोहराया गया है, और vibe coding भी उसी प्रवाह का अगला चरण हो सकती है
प्रोग्रामिंग और vibe coding के बीच तनाव
- programming मेरे लिए काम नहीं, आनंद है, और 1990 के दशक के आखिरी वर्षों से यह एक लगातार बना हुआ जुनून रहा है
- मैं 25 वर्षों से programming सिखाता आया हूँ, और गैर-तकनीकी पृष्ठभूमि वाले लोगों को programmer बनाना अपनी सबसे गर्व की बात मानता हूँ
- programming करते समय मैं समस्या सुलझाने की उस खुशी को महत्व देता हूँ जिसमें मैं चीज़ों को खुद समझता हूँ
- इसके विपरीत vibe coding वह प्रक्रिया है जिसमें AI कोड लिखता है, और लेखक ऐसी स्थिति में पहुँच जाता है जहाँ वह परिणाम को पूरी तरह नहीं समझता
- यह कुछ हद तक “cheating” जैसा भी लग सकता है, लेकिन उससे भी बढ़कर यह एक ऐसे अजीब असहज एहसास को जन्म देता है जिसे ठीक-ठीक शब्दों में कहना मुश्किल है
- ऐसा लगता है कि यह coding के अपने मज़े का बड़ा हिस्सा छीन लेती है
- फिर भी vibe coding इतनी अच्छी तरह काम करती है कि उच्च गुणवत्ता वाले वास्तविक systems बना सकती है
- यह सिर्फ search के विकल्प भर से आगे है; यह उन समस्याओं को भी सही ढंग से हल कर देती है जिन्हें खुद सुलझाना झंझट लगता है
- AI इंसानों की तुलना में error tracking और memory management में अधिक कुशल है, और जब program ideas AI को दिए जाते हैं तो उसके बनाए नतीजे बार-बार चौंकाते हैं
भाषाएँ मूलतः इंसानों के लिए बने tools हैं
- Abelson & Sussman की Structure and Interpretation of Computer Programs में कहा गया है कि programming languages इंसानों के लिए अभिव्यक्ति के साधन हैं
- कोड “लोगों के पढ़ने के लिए” होता है, मशीनों को readability की ज़रूरत नहीं होती
- सभी programming languages इंसानी सोच और अभिव्यक्ति को सहारा देने वाले माध्यम के रूप में डिज़ाइन की गई हैं
- Rust की safety, C++ की abstraction, Go की concurrency जैसी चीज़ें मशीन नहीं बल्कि इंसानों की सुविधा के लिए बनी विशेषताएँ हैं
- memory management, concurrency, type safety जैसी चीज़ें सिर्फ ऐसी abstractions हैं जो इंसानी सोच की संरचना को सहारा देती हैं
- इसलिए AI के कोड लिखने वाले युग में इंसान-केंद्रित language design अनावश्यक हो सकता है
तो क्या AI को ऐसी भाषा चाहिए? : “C में vibe coding करो” प्रस्ताव का अर्थ
- vibe coding करते समय इंसान पहले से ही ऐसी स्थिति में program लिख रहा होता है जहाँ वह पूरे कोड को पूरी तरह नहीं समझता
- ऐसी स्थिति में इंसान-मित्र syntax बनाए रखने की वजह कमज़ोर पड़ जाती है
- इंसान-मित्र भाषा की बजाय, मशीन-मित्र भाषा(C या assembly) में सीधे लिखना अधिक तर्कसंगत हो सकता है
- AI, C के undefined behavior, memory deallocation, off-by-one जैसी चीज़ों को इंसानों से अधिक सूक्ष्मता से संभाल सकता है
- जिस तरह compiler optimization बेहतर कर लेता है, उसी तरह यह इंसानों से अधिक सटीक code execution management दिखाता है
- तो फिर सवाल है: क्या AI के उपयोग के लिए अधिक उपयुक्त भाषा की ज़रूरत नहीं है?
- आखिर Python, Rust, C++ जैसी “इंसान-केंद्रित” भाषाओं में ही vibe coding क्यों की जाए?
VOPL(Vibe-Oriented Programming Language) का प्रस्ताव
- अगर कोई भाषा vibe coding को आधार मानकर बनाई जाए, तो कुछ ऐसी संभावनाएँ कल्पना में आ सकती हैं
- executable pseudocode के करीब एक अत्यंत उच्च-स्तरीय भाषा
- literate programming के एक पूर्ण रूप की तरह, जहाँ इंसान सिर्फ विवरण दे और AI machine code तैयार करे
- natural language जैसी दिखने वाली लेकिन कुछ विशेष “idioms” वाली संरचना
- “goroutine” की जगह रोज़मर्रा की भाषा पर आधारित concurrency expressions(slang) जैसी अवधारणा
- दिशा यह होगी कि मशीन-केंद्रित expression system ऐसा बनाया जाए जिससे AI समस्या को ठीक से समझकर जल्दी executable code बना सके
- नई भाषा को AI को सिखाने की समस्या मौजूद है, लेकिन अभी भी कई developers AI को pseudocode देकर बातचीत की तरह कोड बनवा रहे हैं
संभव है कि VOPL का कोई रूप पहले से ही सीखा जा रहा हो
programming नाम की गतिविधि में बदलाव
- “हाथ से coding करना” भविष्य के vibe coder प्रशिक्षण में Montessori शैली की बुनियादी शिक्षा जैसा माना जा सकता है
- जैसे Photoshop से पहले हाथ से drawing का अभ्यास, या electronic calculator के युग में भी कागज़ पर समीकरण हल करने का अभ्यास शिक्षा का हिस्सा बना रहता है
- नए paradigm के आगमन के प्रति प्रतिरोध इतिहास में बार-बार दिखाई दिया है
- stored-program computer की शुरुआती शुरुआत पर हुआ विरोध (ENIAC → EDVAC)
- Grace Hopper को भी इस आलोचना का सामना करना पड़ा था कि मशीन, मशीन के लिए निर्देश नहीं लिख सकती
निष्कर्षात्मक संदेश
- vibe coding अब पहले ही वास्तविकता बन चुकी है, और भविष्य का development भाषा की स्वयं की पुनर्रचना की माँग कर सकता है
- इंसान-केंद्रित भाषाओं के युग से AI-केंद्रित भाषाओं की ओर बदलाव की संभावना पर अब गंभीर चर्चा का समय आ गया है
“Same vibe, as the kids say.” — आज की बोली में कहें तो, वही vibe है
4 टिप्पणियां
Language model से coding करते हुए यह मान लेना कि मशीन अपने-आप machine-level expressions को जादू की तरह बना देगी, बड़ी लुटेरी सोच है.
जितनी ज़्यादा constraints हों, उतना ही वह उन्हीं constraints के भीतर अच्छा काम करती है
भले ही AI कोड लिख दे, लेकिन सेवा की ज़िम्मेदारी तो डेवलपर को ही लेनी होगी। जिस कोड को आप खुद समझ नहीं सकते, उसकी ज़िम्मेदारी क्या आप सच में ले पाएंगे?
"vibe coding" कर रहे हों तब भी, अगर नतीजे की समीक्षा कर पाना है, तो यह काम ऐसी भाषा में करना चाहिए जिसे आप अच्छी तरह जानते हों"
कमेंट में एक बहुत महत्वपूर्ण वाक्य है।
Hacker News की राय
इससे फिर महसूस हुआ कि software development की भूमिकाएँ सच में बहुत विविध हैं
मैं backend, खासकर API development करता हूँ, और productivity की सबसे बड़ी रुकावट यह है कि ज़्यादातर लोग requirements को ठीक से define नहीं कर पाते
PM से पूछो तो वह टाल देता है, और frontend developer backend के API देने का इंतज़ार करता रहता है
आखिरकार सबसे मुश्किल चीज़ coding नहीं, बल्कि requirements को खोजना और समझना वाला सोचने का process है
असली programming वह है जिसमें आप अपने design किए हुए system को implement करके उसमें जान डालते हैं
अगर कंपनी में सिर्फ code लिखने के काम को ही ‘Programming’ समझ लिया जाए, तो गलतफ़हमी पैदा होती है
लेकिन लगता है कि उसके पास large-scale commercial software development का अनुभव ज़्यादा नहीं है
वह “programming के future” के बारे में जो भविष्यवाणी करता है, वह प्रभावशाली है, लेकिन industrial context में उसकी कुछ सीमाएँ हो सकती हैं
(संदर्भ: Stephen Ramsay परिचय)
आखिर में सबसे अहम चीज़ mindset और यह है कि आप technology के कितने exposure में हैं
LLM ने मेरी productivity बहुत बढ़ा दी है — खासकर मेरे जैसे व्यक्ति के लिए जिसके पास architectural thinking है
जो काम पहले महीनों लेते थे, अब उन्हें कुछ घंटों में बना लेता हूँ
आजकल मैं LLM से पुराने Shockwave Lingo code को modern language में translate करके legacy games को restore कर रहा हूँ
यानी अगर vibe coding भविष्य है, तो उसमें यह मान्यता शामिल है कि AI अभी complete नहीं है
जैसे ही हम कल्पना वाले AI की क्षमता और सीमाएँ मनमाने ढंग से तय करते हैं, पूरी चर्चा धुंधली हो जाती है
stakeholders के साथ चार-पाँच बार meeting करनी पड़ती है, तब जाकर बात साफ़ होती है
मैंने C में vibe coding करके देखा, फिर भी मुझे C पसंद नहीं आया
AI भी इंसानों की तरह memory free करना भूल जाता है और बाद में उसे ठीक करता है
Rust में करते समय यह कहीं ज़्यादा मज़ेदार था, और language के dependency ecosystem को समझना ही असली skill है
AI इस तरह की ‘किताबी जानकारी’ को जल्दी खोजने में मदद करता है
C में हर बार देखना पड़ता था कि memory free हुई या नहीं, लेकिन Rust में इसकी चिंता लगभग नहीं रहती
vibe coding करना भी हो, तो language के safety guardrails वाले Rust को मैं कहीं बेहतर मानता हूँ
Python की human-friendly सुविधाएँ AI के लिए भी मददगार हैं
अब AI की वजह से सीधे UI या utility को नया बनाना आसान हो गया है,
और सिर्फ performance-critical हिस्से C++ में implement करना भी सरल हो गया है
अगर मैं खुद GDB से debugging करता, तो बहुत ज़्यादा समय लगता
string handling और pointer management जैसी परेशान करने वाली चीज़ें उसने संभाल लीं, इसलिए अनुभव संतोषजनक रहा
compiler द्वारा generated code हमेशा ज़्यादा efficient होता है, लेकिन AI की गलतियों को मैं सीखने का अवसर मानता हूँ
local LLM से भी memory free जैसी validation को automate किया जा सकता है
हाल ही में “Why AI Needs Hard Rules, Not Vibe Checks” पर चर्चा हुई थी
(लिंक)
Rust vibe coding के लिए इसलिए उपयुक्त है क्योंकि इसमें type और lifetime guarantees जैसे मुफ़्त validation features मिलते हैं
इनके बिना LLM आसानी से unsafe code बना देता है
abstraction सिर्फ इंसानों के लिए नहीं, LLM के लिए भी ज़रूरी है
ऐसी language जिसमें हर function, variable, type और exception को सख्ती से specify करना पड़े
लिखने में असुविधाजनक हो सकती है, लेकिन पढ़ने और verify करने के लिए आसान structure देगी
यह code के execution path नहीं, बल्कि intent को preserve करने वाले translation की कठिनाई पर बात करता है
Shellcheck जैसे tools भी beginner को expert जैसा बना देते हैं
RL से सुधार करना है तो code की consistency को automatically judge कर पाना चाहिए
Prolog जैसी logic-based languages को फिर से महत्व देने की ज़रूरत है
अगर LLM bug-भरा code देता है, तो language बदलने से नतीजा बहुत अलग नहीं होगा
शुरुआत में vibe coding चौंकाने वाला था, लेकिन जल्दी ही लगातार correction loop ने दिमाग़ थका दिया
यह algorithmic feed scroll की तरह focus छीन लेता है
अब मैं खुद coding करता हूँ, और सिर्फ boring हिस्से ChatGPT को देता हूँ
ऊपर से कुछ सीखने को भी नहीं मिलता
इससे requirements साफ़ हो जाती हैं, और बाद में किसी दूसरे AI पर switch करना भी आसान होता है
मुझे शक है कि LLM memory leak रहित C code बना पाएगा
यह वह क्षेत्र है जहाँ human developer भी गलती करते हैं, और कमज़ोर training data वाला LLM तो और ख़तरनाक है
अगर segfault देने वाला program vibe coding से बना रहे हो, तो वह समय की बर्बादी है
चीज़ें शायद ही टूटती हैं और लगभग हमेशा compile हो जाती हैं
इंसान थकते हैं, LLM नहीं
अच्छे C code पर दोबारा train किया जाए, तो सुधार की गुंजाइश है
AI C में undefined behavior से बचेगा? यह मानना मुश्किल है
अगर model को इंसानों की तरह गलती करने वाले data पर train किया गया है, तो वही bug आने की संभावना रहेगी
वे सबसे संभावित token predict करते हैं, इसलिए आम गलतियाँ कुछ कम हो सकती हैं
crash की वजह भी उसने ठीक से ढूँढ ली
Zig या Rust जैसी modern languages कहीं बेहतर हैं
vibe coding मुझे असहज इसलिए करता है कि यह सिर्फ ‘cheating’ जैसा नहीं लगता
programming एक आत्मा से भरी कला है
हर व्यक्ति समस्या को अलग तरह से हल करता है, और वही रचनात्मकता है
vibe coding ऐसा लगता है जैसे उस रचनात्मकता को machine सोख ले रही हो
आखिर में सोच, निर्णय और गलतियाँ — सब मशीन ही कर रही होती है
“vibe-oriented programming language(VOP)” बनाने का प्रस्ताव भी आया था
लेकिन अगर language LLM के लिए है, तो उसे उल्टा सख्त और विस्तारपूर्ण होना चाहिए
जब तक हर condition और exception स्पष्ट न हो, तब तक compile ही नहीं होना चाहिए
इंसानों के लिए यह असुविधाजनक होगा, लेकिन LLM के लिए confusion कम करने का फ़ायदा देगा
ऐसी संरचना चाहिए जिसमें इंसान concept समझाए और AI उसे code में बदल दे
एक बार compile हो जाए, तो वह लगभग हमेशा सही चलती थी
vibe coding करनी भी हो, तो उसे ऐसी language में करना चाहिए जिसे आप अच्छी तरह जानते हों ताकि आप result की समीक्षा कर सकें
नहीं तो शायद सीधे brainfuck में experiment करना ही बेहतर हो
“तो फिर x86 assembly में करके देखें?” इस सवाल पर,
“मुझे उसे खुद review और extend भी कर पाना चाहिए” कहकर मना कर दिया गया
pure vibe coding सिर्फ एक thought experiment है, कोई realistic goal नहीं
कभी AI QA तक संभाल सकेगा, लेकिन अभी के लिए safe languages और human validation ज़रूरी हैं
अब मैं इतना पुराना developer हूँ कि इस तरह की बहसें भी थकाने लगी हैं