2 साल की ‘vibecoding’ के बाद मैंने फिर से हाथ से कोड लिखना शुरू किया
(atmoio.substack.com)- AI coding tools का उपयोग करते हुए लेखक ने धीरे-धीरे बड़े काम AI को सौंपे और शुरुआत में काफ़ी प्रभावित हुआ, लेकिन बाद में यह स्पष्ट हुआ कि नतीजों में consistency और structural completeness की कमी है
- विस्तृत specification लिखने पर भी AI agent लंबी अवधि का context बनाए नहीं रख पाया और design को विकसित नहीं कर सका, जिसके चलते पूरा codebase अंततः असमान टुकड़ों का संग्रह बन गया
- कोड के टुकड़े अलग-अलग देखने पर पूरे लगते हैं, लेकिन समग्र रूप से structural disorder (sloppy) और context collapse पैदा होता है
- इन अनुभवों के बाद लेखक ने निष्कर्ष निकाला कि AI-जनित code से user trust या data protection की गारंटी नहीं दी जा सकती, और वह फिर से सीधे खुद कोड लिखने लगा
- AI coding अब भी उपयोगी है, लेकिन technical debt और developer control के क्षरण का कारण बन सकती है, इसलिए इसका सावधानी से उपयोग ज़रूरी है
AI coding का शुरुआती उत्साह और उसकी सीमाओं की पहचान
- ज़्यादातर उपयोगकर्ता AI coding की शुरुआत छोटे कामों से करते हैं और धीरे-धीरे जटिल tasks सौंपते हुए उसकी क्षमता से प्रभावित होते हैं
- लेकिन एक बिंदु के बाद AI की गलतियाँ और असंगति सामने आने लगती हैं, जिससे उम्मीद और वास्तविकता के बीच अंतर दिखने लगता है
- जब परिणाम संतोषजनक नहीं होते, तो उपयोगकर्ता अक्सर इसे अपने prompt की समस्या मानकर और अधिक विस्तृत specification लिखने की कोशिश करते हैं
- Obsidian जैसे tools का उपयोग कर बारीक spec documents तैयार किए जाते हैं, लेकिन AI उन्हें लंबे समय में आगे विकसित नहीं कर पाती
specification-आधारित approach की विफलता
- वास्तविक development में design documents खोज और implementation की प्रक्रिया में लगातार बदलने वाले ‘living documents’ होते हैं
- लेकिन AI agents शुरुआती specification पर अटक जाते हैं और लचीला संशोधन या पुनर्व्याख्या नहीं कर पाते
- जटिल संरचनाओं को संभालते समय agent अक्सर पूरे problem context को खो देता है, या ज़बरदस्ती आगे बढ़ने लगता है
- नतीजतन, कोड ऊपर से पूरा दिखने पर भी internal consistency और structural integrity से वंचित रहता है
code quality का पतन और ‘vibecoding’ की सीमा
- AI द्वारा लिखा गया code आंशिक रूप से शानदार दिख सकता है, लेकिन समग्र रूप से वह अर्थहीन संयोजन बन जाता है
- पूरे codebase की समीक्षा के बाद लेखक ने उसमें ‘शुद्ध अव्यवस्था(slop)’ की मौजूदगी पाई
- AI prompt और self-consistency के प्रति तो वफादार रहती है, लेकिन पूरे system की harmony या आस-पास के patterns की consistency पर ध्यान नहीं देती
- यह कुछ वैसा ही है जैसे किसी उपन्यास के कुछ पैराग्राफ़ बेहतरीन हों, लेकिन पूरा chapter बिखरा हुआ हो — ‘vibewriting’
मानव-केंद्रित development की ओर वापसी
- लेखक ने तय किया कि AI-जनित code को product के रूप में deploy करना या user data की सुरक्षा में इस्तेमाल करना संभव नहीं है
- “मैं इस code के साथ users से झूठ नहीं बोलूँगा” इस संकल्प के साथ वह खुद कोड लिखने की ओर लौट आया
- खुद लिखने पर उसने महसूस किया कि speed, accuracy, creativity, productivity उल्टे बेहतर हो गए
- सिर्फ़ कोड जनरेशन की रफ़्तार नहीं, बल्कि कुल development efficiency के आधार पर देखने पर इंसानी बढ़त साफ़ नज़र आई
AI coding का लगातार उपयोग, लेकिन सावधानी के साथ
- लेखक अब भी कुछ कामों में LLM का सीमित उपयोग (लगभग 40%) करता है
- दोहराए जाने वाले कामों या साधारण code generation में यह उपयोगी है, लेकिन technical debt और code understanding में गिरावट जमा होती जाती है
- लंबे समय में developer के codebase का mental model खो देने और AI के बिना समस्या हल न कर पाने का ख़तरा है
- यात्रा के दौरान (ट्रेन, विमान आदि) AI पर निर्भरता के कारण productivity 0% हो जाने जैसी स्थिति भी सामने आई
- दूसरे developers का कहना है कि ‘बस specification अच्छी तरह लिख दो’ वाली सोच waterfall model की वापसी है, जबकि वास्तविक development में तुरंत खोज, प्रयोग और interaction अनिवार्य होते हैं
निष्कर्ष
- AI coding अब भी एक शक्तिशाली tool है, लेकिन पूरे system के context और structural consistency को बनाए रखने की इसकी क्षमता सीमित है
- इंसानी developer की intuition-आधारित judgment और तत्काल समायोजन की क्षमता अब भी केंद्रीय महत्व रखती है,
AI का उपयोग सहायक साधन के रूप में, सावधानीपूर्वक नियंत्रण के साथ किया जाना चाहिए
9 टिप्पणियां
Vibe coding का कॉन्सेप्ट बने अभी पूरा 1 साल भी नहीं हुआ, ये कैसी SNS वाली फेंक है यार lol
स्पेसिफिकेशन को तराशने में मेहनत लगाना ज़रूरी है.. अगर स्पेसिफिकेशन को सच में software engineering में सीखे हुए FM तरीके से बनाया और निखारा जाए, फिर traceability management करते हुए उसे update करके काम किया जाए, तो अच्छा रहता है.
प्रोजेक्ट करते समय मैं हमेशा स्पेसिफिकेशन टेम्पलेट और prompt version को लगातार बढ़ाता रहता हूँ, लेकिन अब धीरे-धीरे लगने लगा है कि शायद मुझे सच में software engineering को थोड़ा और गहराई से पढ़ना चाहिए.
लेखक अब भी कुछ कामों में LLM का सीमित रूप से इस्तेमाल करते हैं (लगभग 40%)
ऊपर जैसा लिखा गया है, उसे देखकर लगता है कि लेखक की राय भी AI को पूरी तरह छोड़ देने की नहीं है।
लगता है कि हमें इसे अच्छी तरह इस्तेमाल करने के तरीकों के बारे में लगातार सोचना चाहिए। मेरा मानना है कि AI को छोड़कर डेवलपमेंट करना धीरे-धीरे पीछे छूटने जैसा है.
मेरा मानना है कि इस लेख के लेखक ने पहले ही इसे अच्छी तरह इस्तेमाल करने के तरीके अपनाए हैं, लेकिन इसके बावजूद हमें इस बात पर सोचना चाहिए कि AI का और बेहतर उपयोग किस दिशा में किया जाए।
(अभी बस काफ़ी trial and error चल रहा है...)
स्पेक को अपडेट करें
हाँ,
hookलगाकर implementation पूरा होने परspecको update किया जा सकता है, और अगर वह न भी हो तोspecको manually update करने वाला command या skill भी जोड़ा जा सकता है, hahaआह, बूढ़ा नहीं होना चाहता।
Hacker News की राय
मुझे लगता है कि AI का बुनियादी चीज़ों में बहुत अच्छा होना ही उल्टा खतरनाक है
छात्र “AI कर देगा” कहकर खुद कोड लिखना छोड़ देते हैं, और नतीजतन वे बीच के चरणों या कठिन कॉन्सेप्ट्स को हाथ से सीख ही नहीं पाते
CS शिक्षक के रूप में मैं छात्रों से ज़ोर देकर कहता हूँ, “मशीन नहीं, तुम्हें खुद कोड लिखना चाहिए”
forklift से वज़न उठाना आसान है, लेकिन उससे मांसपेशियाँ नहीं बनतीं
सीखने की प्रक्रिया में जो दर्द होता है, वही विकास का असली केंद्र है
बेशक नौकरी में परिणाम ज़्यादा महत्वपूर्ण होता है, लेकिन फिर भी उच्च-स्तरीय सोच करने वाले लोगों की ज़रूरत रहती है
उम्मीदवार का theoretical knowledge बिल्कुल सही था, लेकिन वह अपने लिखे कोड का काम करने का तरीका बिल्कुल समझा नहीं पाया
आखिर में उसने कबूल किया कि “ज़्यादातर GenAI ने लिखा था”, और ‘सीखी हुई चीज़’ और ‘खुद करके देखी हुई चीज़’ के बीच का फ़ासला बहुत बड़ा था
कोड कैसे लिखा जाता है से ज़्यादा महत्वपूर्ण है यह सिखाना कि कोड काम कैसे करता है
पहले वह दौर था जब लोग assembly language में सीधे लिखते थे, लेकिन अब उससे ज़्यादा मूल्यवान है compiler के सिद्धांत को समझना
वास्तव में ज़्यादातर लोग compiler या OS खुद नहीं बनाएँगे, लेकिन उसके सिद्धांत जानना programming language की सीमाओं को समझने में मदद करता है
जब compiler पहली बार आए थे तब भी यही बहस थी, और आख़िरकार हम abstraction के और ऊँचे स्तर पर पहुँच गए
सिर्फ़ implementation करने से सोच गहरी नहीं होती
अगर implementation AI को सौंप दें, तो आख़िरकार वह ‘आँखों पर पट्टी बाँधकर लोग रास्ता खोज रहे हों’ जैसी स्थिति बन जाती है
खुद कोड के साथ काम करते हुए सोचना ज़रूरी है
मैं इस बात से सहमत नहीं हूँ कि “AI छोटे काम तो अच्छा करता है, बड़े काम और भी अच्छा करता है”
व्यवहार में मुझे हमेशा निराशाजनक नतीजे ही मिले हैं
या तो कोड ठीक से चलता नहीं था, या बार-बार सुधार के निर्देश देने पड़ते थे
अगर feedback loop कठिन हो, तो आख़िर में आप ही एकमात्र feedback source बन जाते हैं, और तभी AI की सीमाएँ साफ़ महसूस होती हैं
उदाहरण के लिए TaskManager structure या memory ownership rules जैसी चीज़ें साफ़ समझा दूँ, तो वह tests pass करने वाला कोड अच्छी तरह बना देता है
Ryan Dahl जैसे लोग कहते हैं कि “अब मैं खुद कोड नहीं लिखता”, लेकिन ऐसा इसलिए है क्योंकि उन्होंने दोहराव वाले feedback के ज़रिए उसे सहयोगी की तरह निखारा है
AI को बच्चे को सिखाने की तरह संभालना पड़ता है
input, output और expected errors को साफ़ लिखकर, बार-बार प्रयोग करते हुए उनमें सुधार किया जा सकता है
Claude सवाल पूछता है, research करता है, और code review भी करता है
यह मानो किसी सक्षम junior developer को mentor करने जैसा लगता है
मैंने “vibe coding” को शुरू में खुले मन से आज़माया था, लेकिन धीरे-धीरे संदेह बढ़ता गया
दोहराव वाले और स्पष्ट कोड के लिए यह अच्छा है, लेकिन business-critical logic के लिए उपयुक्त नहीं
Claude अक्सर specification को नज़रअंदाज़ कर देता है, एक ही logic कई बार दोहरा देता है, या कहता है कि ठीक कर दिया लेकिन वैसा का वैसा छोड़ देता है
यह भी लगता है कि मॉडल धीरे-धीरे सुस्त होता जा रहा है
अब मैं इसे सिर्फ़ design discussion या debugging के लिए इस्तेमाल करता हूँ
अगर AI भरने के लिए बहुत सारे ‘उबाऊ हिस्से’ हैं, तो शायद शुरुआत से ही code structure ठीक नहीं है
इस हिस्से में LLM अब भी मददगार है
कई developer वैसे भी पहले से तय design लेकर सिर्फ़ implementation करते हैं, इसलिए AI उनकी रफ़्तार बढ़ा सकता है
मैं इस दावे से सहमत नहीं हूँ कि “AI design changes को reflect नहीं कर पाता”
बल्कि “यही तो इंसान की भूमिका है”
उदाहरण के लिए अगर API structure बदलने को कहें, तो AI संबंधित सभी हिस्से ढूँढकर बदल सकता है और tests भी चला सकता है
वे implementation details पर अटक जाते हैं, या conceptual verification छूट जाती है
फिर भी इंसान के लिखे tests भी कई बार ऐसे ही होते हैं, इसलिए बात समझ में आती है
अगर आप खुद कोड नहीं लिखते, तो abstraction के खुरदरे और असंतुलित हिस्से महसूस ही नहीं होते, और वही आगे चलकर संरचनात्मक गुणवत्ता में गिरावट लाते हैं
यही फ़र्क कोड की परिपक्वता तय करता है
लेकिन असली बात यह है कि किन कामों में सचमुच manual intervention चाहिए, यह पहचानने की क्षमता होनी चाहिए
लेकिन efficiency तभी निकलती है जब आप high-tier subscription (जैसे Claude Max 200 डॉलर) लेते हैं
और यह भी कि AI tool proficiency को वस्तुनिष्ठ रूप से आँकने का कोई तरीका होना चाहिए
मुझे “मैं 2 साल पहले से vibe coding कर रहा था” वाली बात पर संदेह है
Karpathy ने यह term तो सिर्फ़ लगभग 1 साल पहले गढ़ी थी (स्रोत)
यह दिलचस्प था कि GPT ने खुद अपने इस्तेमाल के लिए API design किया और उसी के अनुसार implementation भी करवाया
लेकिन बाद में कहा गया कि नए models ने self-modification और replication से जुड़ी बातचीत को block करना शुरू कर दिया
पूरी तरह agentic tool न भी हो, तो ChatGPT या Claude से भी यह आसानी से हो सकता है
और अब वह research stage से ही AI के साथ सहयोग करके बेहतर नतीजे पाता है
मैं छात्रों से कहता हूँ, “TV पर sports देखने से exercise नहीं हो जाती”
vibe coding में भी यही बात लागू होती है, क्योंकि खुद हाथ से कोड लिखने पर जो उपलब्धि का एहसास मिलता है, वह अलग है
AI द्वारा बनाया गया ‘आधा-अधूरा तैयार कोड’ मुझे फिर से प्रेरित कर देता है
मुझे संदेह है कि असली engineer सचमुच ‘vibe coding’ को अंधाधुंध करते हैं
मैं तो उल्टा बातचीत के ज़रिए तराशने वाली शैली अपनाता हूँ
requirements रखता हूँ, AI के साथ design proposals की समीक्षा करता हूँ, और structure को धीरे-धीरे पूरा करता हूँ
यह प्रक्रिया धीमी है, लेकिन इससे collaboration और सोच की गहराई बनी रहती है
AI, भारी मात्रा में code learning के आधार पर नए ideas देता है, और मैं अपने अनुभव से उन्हें संतुलित करता हूँ
आख़िरकार AI मुझे अपने विस्तारित रूप (me++) जैसा महसूस होता है
मैं अभी सब कुछ किसी पूर्ण agent को सौंपने के लिए तैयार नहीं हूँ, लेकिन यह तरीका सबसे उत्पादक लगता है
मुझे AI का लिखा कोड ऐसे उपन्यास जैसा लगता है जो टुकड़ों में शानदार हो लेकिन पूरे में बिखरा हुआ
chapter स्तर पर वह परफेक्ट लगता है, लेकिन पूरे संदर्भ में भ्रमित कर देता है
अगर नहीं, तो 10,000-line के vibe-coded codebase से सही तरह काम करने की उम्मीद करना भी मुश्किल है
अगर उसमें इंसानी सोच और भावना परिलक्षित न हो, तो user experience भी एकरूपता खो देता है और cognitive friction पैदा होती है
और उसका कहना है कि जब design स्पष्ट हो, तो LLM boilerplate काम को विस्फोटक गति से तेज़ कर देता है
लेकिन design अभी भी इंसान का काम है
उसका project GitHub सार्वजनिक संस्करण में देखा जा सकता है
मैं मानता हूँ कि LLM द्वारा बनाया गया कोड टुकड़ों में उत्कृष्ट हो सकता है, लेकिन उसकी overall structure कमज़ोर होती है
लेकिन अगर codebase को समझकर खुद review किया जाए, तो इसे काफ़ी हद तक सुधारा जा सकता है
vibe coding prototype बनाने के लिए बेहतरीन है
जल्दी से दिशा पकड़कर, बाद में refactor करते हुए विस्तार करना प्रभावी तरीका है
यानी केवल output देखकर फैसला करना ही असली vibe coding है