अनुभवी डेवलपर की vibe coding: 8-बिट assembly से English-as-code तक

• 40 साल के अनुभव वाले एक डेवलपर ने AI coding assistant के साथ 2 हफ्तों का प्रोजेक्ट चलाते हुए vibe coding के वास्तविक अनुभव को दर्ज किया है
• Tower of Hanoi puzzle solver को लागू करने की प्रक्रिया में लगभग 300 बातचीतों के जरिए पूरा कोड AI ने जनरेट किया, और इंसान ने review और दिशा-निर्देशन पर ध्यान केंद्रित किया
• नतीजे में तेज़ productivity (अधिकतम 2 गुना) और चौंकाने वाली accuracy व रचनात्मक proofs जैसे फायदे मिले, लेकिन साथ ही 20% errors/अपूर्ण code और industrial use के लिए अत्यधिक complexity जैसी कमियाँ भी रहीं
• लेखक के अनुसार AI के साथ बातचीत एक ऐसा मनोवैज्ञानिक अनुभव है जो गहरा flow और learning effect देता है, लेकिन साथ ही trust और control के बीच तनाव भी पैदा करता है
• निष्कर्षतः AI coding को एक शक्तिशाली साथी और खतरनाक साइकिल दोनों की तरह बताया गया है, और इसे अनुभवी डेवलपर द्वारा सक्रिय रूप से संभाले जाने वाले नए collaboration paradigm के रूप में पेश किया गया है

---

प्रस्तावना — Vibe coding

• Vibe coding एक ऐसी development शैली है जिसमें LLM-आधारित AI agent लिखना, refactoring और debugging संभालता है, और मैं क्या बनाना है इस पर ध्यान देता हूँ
• coding या तो मेरे और AI के simultaneous collaboration से होती है, या फिर पूरी तरह AI को सौंप दी जाती है
• मुझे यह तरीका रोमांच और डर दोनों के साथ महसूस होता है, और मैं सवाल उठाता हूँ कि क्या programming की कलात्मकता अब intelligent robot की assembly line में बदल रही है

• सत्यापन के लिए मैंने 2 हफ्तों में कुल 40 घंटे देकर latest coding assistant के साथ एक छोटे प्रोजेक्ट पर सहयोग किया
• प्रोजेक्ट का आकार लगभग 5k LOC, 50 files, 20 classes वाली Python codebase का था, और यह textbook AI search algorithms से एक सामान्य puzzle हल करने का self-directed experiment था
• परिणाम code repository और documentation के रूप में सार्वजनिक है, और यह लेख मैंने क्या किया, क्या समझा, क्या सीखा और क्या महसूस किया उसका रिकॉर्ड है

• मैंने 80 के दशक में 8-bit मशीनों पर assembly से शुरुआत की थी और मेरे पास 40 साल का coding अनुभव है
• मैंने 20 से अधिक भाषाओं का उपयोग किया है
• मुझे scientific, mobile और business software को व्यक्तिगत और टीम दोनों स्तरों पर विकसित करने का अनुभव है
• साथ ही, मेरे पास (LLM-पूर्व युग का) AI में PhD भी है
• मुझे लगा कि “AI करने वाला व्यक्ति AI assistant से AI code बनवा रहा है” जैसी echo chamber स्थिति में कुछ दिलचस्प देखने को मिल सकता है

1. सॉफ़्टवेयर का अवलोकन और विकास प्रक्रिया

• Tower of Hanoi puzzle को हल करने वाला लचीला और शिक्षण-उपयोगी solver Python में लागू किया गया
• यह puzzle एक गणितीय समस्या है जिसमें disks को कुछ नियमों के तहत खंभों के बीच ले जाया जाता है; disks की संख्या बढ़ने पर समाधान की लंबाई विस्फोटक रूप से बढ़ती है, इसलिए इंसान के लिए इसकी कल्पना कठिन हो जाती है, लेकिन मशीन search algorithms से इसे आसानी से हल कर सकती है
• solver केवल classical version ही नहीं, बल्कि (a) मनमाने start/end states और (b) एक साथ कई disks को ले जाने वाले generalized version को भी संभालता है
• लागू किए गए search methods में recursion, BFS, DFS, iterative deepening, A*, greedy search, bidirectional BFS जैसी optimal और non-optimal दोनों रणनीतियाँ शामिल हैं
• algorithms CLI-आधारित Python scripts में शामिल हैं, और इनमें step-by-step visualization, method-wise performance benchmark, तथा विभिन्न initial/final configurations support जैसी सुविधाएँ हैं
• सारा code और data structures शुरुआत से नए लिखे गए, और development process Cursor IDE में AI assistant के साथ English बातचीत के जरिए चला
• इंसान द्वारा सीधे लिखा गया कोई code या document नहीं है; सब कुछ AI और मेरे बीच की technical बातचीत के माध्यम से जनरेट हुआ
• कुल 40 घंटों में 300 से अधिक exchanges हुए, औसतन हर 8 मिनट में 1 interaction, और वास्तविक समय का अधिकांश भाग AI output की समीक्षा और मूल्यांकन में गया

2. AI assistant का प्रदर्शन कैसा था?

• AI assistant ने code और natural language understanding में जो स्तर दिखाया, उससे मैं गहराई से प्रभावित हुआ
• जब मुझे लगता था कि मैंने अस्पष्ट ढंग से समझाया है, तब भी assistant मेरी मंशा समझकर उसे और स्पष्ट रूप में दोबारा समझा देता था
• (Python) भाषा पर इसकी पकड़ accuracy, speed, syntax और semantics की समझ, तथा library उपयोग के मामले में अतिमानवीय स्तर की लगी
• बातचीत कभी-कभी वास्तविक बुद्धिमत्ता जैसी अंतर्दृष्टि भी दिखाती थी। उदाहरण के लिए, जब मैंने पूछा कि unsolved puzzle exceptions को संभालना चाहिए या नहीं, तो assistant ने सभी puzzles solvable हैं यह graph space में contradiction proof देकर दिखाया
• मैं वही proof हाथ से लिखने में लगभग 10 मिनट लगा रहा था, जबकि assistant ने 30 सेकंड में proof (QED) लिख दिया, और मैं भी 30 सेकंड में आश्वस्त हो गया—इस तरह 9 मिनट बच गए
• साधारण algorithmic प्रश्नों में कुछ बार मैं खुद भी गलत था, लेकिन assistant के non-judgmental रवैये की वजह से मुझे शर्मिंदगी से ज़्यादा मुक्ति और हल्की हँसी महसूस हुई

3. ठहरिए, इस्तेमाल किया गया AI coding assistant आखिर कौन-सा था?

• मैंने तीन आधुनिक AI coding assistants आज़माए: OpenAI o3, Anthropic Claude Sonnet 4, Google Gemini Pro 2.5
• निष्कर्ष यह रहा कि o3 code लिखने से अधिक references की जाँच, algorithmic properties की पुष्टि, language semantics पर सवाल, code cleanup scripts बनाना, illustrations तैयार करना, और लेख पर सहायक राय देना जैसी सहायक भूमिकाओं के लिए बेहतर है
• Gemini के साथ मैंने nostalgia भरे प्रयोग के तौर पर Turing machine-जैसा program बनवाया और उसे रोचक पाया। उसके output का लेखन आकर्षक था और code भी प्रभावी था। Hanoi project की प्रारंभिक setup और implementation का लगभग 15% हिस्सा Gemini ने संभाला
• इसके बाद जब मैंने Claude Sonnet 4 आज़माया, तो तुरंत गहरी समझ, अंतर्दृष्टि और interaction में immersion महसूस हुआ। unsolved puzzle न होने का proof इसका एक典型 उदाहरण था
• इंटरनेट पर खोजने पर पता चला कि बहुत से लोग मेरी ही तरह सोचते हैं, और Claude Sonnet 4 को complex coding tasks के लिए व्यापक मान्यता मिली हुई थी। अधिक शक्तिशाली Claude 4 Opus भी है, लेकिन cost और scale को देखते हुए अंततः Sonnet चुना गया

4. code के बारे में बातचीत

• AI assistant से बात करते समय ऐसा नहीं लगता था कि मैं मशीन से बात कर रहा हूँ, बल्कि जैसे एक बेहद सक्षम और तेज़ human programmer से चर्चा कर रहा हूँ
• बातचीत का स्तर implementation details से अधिक ideas के क्षेत्र के करीब था

  उदाहरण: मैंने कहा कि timeout handling कमजोर solvers के पक्ष में जा सकती है, इसलिए “Timeouts” कॉलम जोड़कर timeout duration को reflect करना चाहिए
  Claude ने सहमति जताई, timeout handling code की जाँच और सुधार किया, 4 files update हुईं और tests भी पूरे हुए, और सब कुछ अपेक्षा के अनुसार काम करने लगा
  बातचीत के मुख्य अंश: key exchange summary, long-form chat logs

• इस तरह की बातचीतों के बीच code को बढ़ते और बेहतर होते देखना चुनौतीपूर्ण लेकिन संतोषजनक अनुभव था
• यह वैसा ही था जैसे अपने हाथों से ideas implement करते समय flow आता है, लेकिन यहाँ अधिक abstract और conceptual स्तर पर flow state महसूस हुआ

• AI के साथ अच्छी बातचीत के लिए वही चीज़ें ज़रूरी हैं जो इंसानों के साथ बातचीत में होती हैं: ध्यान से सुनना और अच्छे सवाल पूछना
• खास तौर पर दो क्षमताएँ चाहिए
  • 1. सवाल, सुझाव और hints को परिष्कृत ढंग से गढ़ने की क्षमता
    • यही वजह है कि “prompt engineering” की ज़रूरत पड़ती है
    • Oscar Wilde का उद्धरण: “प्रश्न कभी अशिष्ट नहीं होते। कभी-कभी उत्तर अशिष्ट होते हैं।”
  • 2. उत्तर पर विचार करने, उसकी व्याख्या करने, और उसे दोबारा जाँचकर संशोधित करने की क्षमता
    • सबकी बात ध्यान से सुनो, पर किसी बात पर ज्यों-का-त्यों भरोसा मत करो

• यह Donald Knuth की Literate Programming अवधारणा को एक नया अर्थ देता है
  • पहले code page के भीतर natural language specification और code implementation को स्थानिक रूप से साथ रखा जाता था,
  • अब यह AI assistant के साथ बातचीत में समय के भीतर बारी-बारी से गुंथने वाला रूप ले लेता है
  • मैं कहानी का केवल आधा हिस्सा लिखता हूँ, और बाकी AI के साथ संवाद से भरता जाता हूँ

5. AI की कमियां, errors और bias

• AI assistants परफेक्ट से काफी दूर हैं
• लगभग 300 बातचीत आदान-प्रदान में से 20% समय AI द्वारा लाए गए असंतोषजनक code iteration और bug fixes पर खर्च हुआ। बाकी समय रचनात्मक था, लेकिन यह 20% ऐसा हिस्सा है जिसे नज़रअंदाज़ करना मुश्किल है

• समस्या के प्रकार

  • Flaw (कमियां): कुल समस्याओं का लगभग 60%
    • तुरंत दिखने वाली असुविधा, अपेक्षा से कमतर code, थोड़ा-थोड़ा भटका हुआ result
    • बार-बार सुधार की ज़रूरत पड़ती है, और कई बार यह manual काम से तेज़ होता है, लेकिन हमेशा नहीं
  • Error (त्रुटि): कुल समस्याओं का लगभग 40%
    • शुरुआत में code ठीक दिखता है, लेकिन analysis करने पर पता चलता है कि गंभीर सुधार की ज़रूरत है

• Flaw के उदाहरण

  • एक class को सरल बनाने की कोशिश में उल्टा 10 जटिल classes में refactor करने का सुझाव
  • concurrency और parallelism के अंतर को नज़रअंदाज़ कर पूरी तरह अलग implementation बना देना
  • हज़ारों लाइनों की boilerplate file बनाकर उसे इंसानों के लिए पढ़ना मुश्किल कर देना
  • refactoring के दौरान रास्ता भटक जाना या हार मान लेना, और apology message दिखाना
  • ज़रूरत से ज़्यादा ईमानदार लेकिन बहुत लंबे naming की वजह से readability घट जाना
  • खुद से फैसला लेकर पूरा functional block delete कर देना और आसान समाधान की कोशिश करना
  • अनावश्यक code duplication पैदा होना
  • नया code पुराने code को replace कर चुका हो, फिर भी पुराना code बचा रहना
  • naming inconsistency को खुद पहचान न पाना
  • चर्चा किए गए context के उलट multiprocess IPC solution सुझाना, जो performance के लिए उपयुक्त न हो
  • एक ही instance को बार-बार solve मानकर गलत statistics निकालना
  • किसी खास instance के समाधान को पूरे set के समाधान की तरह गलत दिखाना
  • सिर्फ file name बदलना ज़रूरी था, लेकिन जटिल package structure reorganize करने की कोशिश

• Error के उदाहरण

  • बीच के pillar और दाएं pillar को गड़बड़ा देना, जिससे code correctness खराब हो गई
  • unit test के pass होने की वजह सिर्फ True return करना निकली
  • non-optimal algorithm को optimal बताना, और बाद में bug मिलना
  • पूरा और tested update होने का दावा, लेकिन असल में अधूरा होना
  • हटाने को कहे गए feature में सिर्फ output छिपाना, internal logic को वैसा ही छोड़ देना
  • fix करते समय सूक्ष्म regression bug जोड़ देना
  • A* search में inadmissible heuristic का इस्तेमाल, जिससे optimality खराब हुई
  • fail या timeout हुए instances को success और 0-second solve के रूप में दर्ज करना, जिससे statistics बिगड़ गई

• देखे गए bias

  • बड़े industrial codebase पर training के असर से context से असंबंधित होते हुए भी industrial-style solution की ओर झुकाव
    • उदाहरण: ज़रूरत से ज़्यादा जटिल type annotations की भरमार से readability घट जाना
  • linter और static analysis tools की शिकायतें संतुष्ट करने वाला bias
    • code readability या functionality बेहतर किए बिना अनावश्यक complexity जोड़ना
  • नतीजतन style optimization पर अटकाव और clarity व functionality की कीमत पर उसी को तरजीह देने की प्रवृत्ति

6. सावधानी से अपनाने की ज़रूरत

• AI assistant द्वारा generate किए गए code का उपयोग करते समय उसे ज़रूर ध्यान से पढ़ना और verify करना चाहिए, तभी मैं code का वास्तविक मालिक बना रह सकता हूं
• ज़्यादातर code बेहतरीन होता है, लेकिन कुछ हिस्सों में सूक्ष्म और पकड़ में मुश्किल तरीकों से project की दिशा और soundness को नुकसान पहुंचाने का जोखिम रहता है
• अगर मैं overall development direction को मज़बूती से lead न करूं, तो AI द्वारा सुझाए गए industrial data structures और best practices की ओर code धीरे-धीरे बेजान और फीका होता जाता है
• class structure और file system layout को लेकर AI की समझ मेरी समझ से काफी अलग थी, इसलिए मनचाही structure और naming पाने के लिए काफी resistance और adjustment करना पड़ा
• AI के पास "ज़्यादा/कम, असाधारण/औसत" जैसी सामान्य समझ बिल्कुल नहीं होती।
  • उदाहरण: 3-disk problem में 3.5GB memory usage वाले bug की स्थिति में भी उसने इसे “सामान्य” माना और नए features implement करते रहने को कहा

7. उत्पादकता में सुधार

• शुरुआत में मुझे लगा था कि natural language को एक indirect programming tool की तरह इस्तेमाल करना अवास्तविक है, लेकिन अब इसमें कोई शक नहीं कि LLM-based coding assistant बेहद उपयोगी, शक्तिशाली और ऊर्जा देने वाला tool है
• लेकिन यह tool तभी सुरक्षित और उपयोगी है जब मुझे पता हो कि मैं क्या कर रहा हूं, और AI द्वारा बनाए गए code को inspect व re-direct करने की क्षमता हो। मैं खुद पर भरोसा कर सकता हूं तभी AI पर भी भरोसा किया जा सकता है
• उत्पादकता में सुधार साफ़ है, और documentation, unit tests, simple refactoring, error messages लिखना, exception handling, consistency validation, textbook logic/algorithms/data structures implement करना, boilerplate code लिखना, idiomatic code generation जैसे कामों में 10x से 100x efficiency संभव है
• कुछ मामलों में गति उल्टा धीमी भी हो जाती है। खासकर तब, जब AI के लिए मुश्किल चीज़ को मैं खुद implement करने के बजाय लगातार सिर्फ समझाता रहूं। यह मैंने जानबूझकर किया हुआ "English-as-a-meta-programming-language" scenario था
• कुल मिलाकर, AI द्वारा लिखे गए code और documentation दोनों की review के बाद मुझे लगभग 2x productivity gain मिला। कुछ हिस्से मेरे अपने लिखे से बेहतर थे, कुछ कमतर, लेकिन overall स्तर लगभग वैसा ही था
• हालांकि अगर perfectionism की प्रवृत्ति हो, तो code पर्याप्त साफ़ न लगने की वजह से अंतहीन refactoring का चक्र शुरू हो सकता है। यह AI इस्तेमाल करने या न करने, दोनों में एक जैसा है
• इस project में भी मुझे पता है कि अभी refactoring और improvement के मौके बाकी हैं, लेकिन मैंने इसे इस आधार पर समाप्त किया कि अब आगे की quality improvement समय के मुकाबले कम फायदेमंद है। यह फैसला मैंने लिया, या AI assistant ने मुझे मना लिया, यह सवाल खुला है

8. अगर non-developers development करें, तो क्या developers गायब हो जाएंगे?

• व्यक्तियों और teams की productivity, और programmers की बड़े पैमाने पर layoffs की संभावना को लेकर सवाल
• कोई साफ़ जवाब नहीं है, लेकिन कुछ बातों पर विचार ज़रूरी है

• स्थिति के अनुसार productivity का अंतर

  • बनने वाले software के प्रकार के अनुसार अंतर आता है
    • standard और boilerplate-heavy code में AI के उपयोग से समय दसवें हिस्से तक घट सकता है
    • उच्च बौद्धिक घनत्व वाले mission-critical code और niche languages में बचत का असर बहुत कम होता है
  • दोनों ही मामलों में, अनुभवी programmers की ज़रूरत रहती है
    • उनमें सूक्ष्म bugs और समस्याओं को पहचानने और संभालने की क्षमता होनी चाहिए
    • वास्तव में LLM के बाद hiring trend juniors में कमी और seniors में बढ़ोतरी की ओर है

• quality control की कठिनाई

  • AI तेज़ गति से बहुत बड़ा codebase बना देता है, इसलिए बचे हुए hidden bugs को पकड़ना कठिन काम है
  • इंसान आमतौर पर आलस की वजह से मशीनों पर निर्भर होने लगते हैं, और इससे technical debt और errors का accumulation होता है
  • एक AI-सहायित developer द्वारा लिखे गए code को validate करने के लिए कई developers की ज़रूरत पड़ सकती है
    • यह productivity gain की कहानी के साथ विरोधाभासी है
    • दूसरे AI से code verification की संभावना है, लेकिन उसकी black-box सीमाओं के कारण यह भी संदिग्ध है

• AI का रचनात्मक योगदान

  • AI सिर्फ साधारण कामों में ही नहीं, बल्कि idea exploration, architecture experiments, language migration जैसे क्षेत्रों में भी योगदान देता है
  • उसके output को ध्यान से देखें तो सीखने के अवसर बहुत मिलते हैं, और यह मुझे बेहतर programmer बनाने में मदद कर सकता है
  • सक्रिय रूप से भाग लेकर और खुले मन से सीखकर ही AI से replace न होने वाला developer बना जा सकता है

• cognitive debt और employability

  • research report: AI उपयोग से cognitive debt बढ़ता है
    • दिमागी गतिविधि में कमी, neural connections का कमजोर होना, memory में गिरावट
  • writing और coding अलग हैं, लेकिन अगर coding AI को सौंप दी जाए तो अपनी coding ability खोने का जोखिम है
  • इसके बदले AI conversation और prompting skills बेहतर हो सकती हैं
  • employability के लिहाज़ से द्विआधारी सोच गलत है
    • अगर code लिखने की क्षमता और AI के साथ सहयोग की क्षमता दोनों विकसित की जाएं, तो फायदा होगा
    • उल्टा अगर AI पर लाठी की तरह निर्भर होकर सीखने से बचा जाए, तो लंबे समय में नुकसान होगा

• संदर्भ-आधारित निष्कर्ष

  • यह क्षेत्र तेज़ी से बदल रहा है, इसलिए सिर्फ मौजूदा पीढ़ी के LLM के आधार पर निष्कर्ष निकालना जोखिम भरा है
  • नए tools आ रहे हैं और performance लगातार सुधर रही है
  • इसके बावजूद, मेरे अनुभव में Claude 4 सबसे बेहतरीन और उत्पादक partner था

9. मेरा प्रयोग: सीमाएँ और सावधानियाँ

• यह human/AI pair programming प्रयोग (conversational coding या natural language programming) AI assistant का उपयोग करने के पूरे तरीके का प्रतिनिधित्व नहीं करता
• मैंने इसे vibe coding का पहली बार अनुभव करने वाले एक शुरुआती के नज़रिए से किया, इसलिए निष्कर्ष अपूर्ण और anecdotal हैं

• प्रयोग परिवेश की सीमाएँ

  • version control या GitHub features का लगभग उपयोग नहीं किया
  • background agents, pull request approval, multimodal interaction, complex full-stack development शामिल नहीं थे
  • मैंने केवल एक ही ऐसी भाषा (Python) का उपयोग किया जिसे मैं अच्छी तरह जानता हूँ, और जो स्थिर है तथा AI training data में भी पर्याप्त रूप से परिलक्षित है
  • किसी विशेष context protocol का उपयोग नहीं किया

• प्रोजेक्ट की विशेषताएँ

  • स्वावलंबी CLI-आधारित offline छोटा प्रोजेक्ट (~5k LOC, 50 files, 20 classes)
  • frontier AI model के साथ किए जाने वाले सामान्य प्रोजेक्ट से अलग
  • team collaboration की स्थिति को शामिल नहीं किया गया, केवल single developer scenario का प्रयोग किया गया

• स्वयं-लगाई गई सीमाएँ

  • मैंने कोड की एक भी पंक्ति सीधे नहीं लिखी, और भले ही समझाने में अधिक समय लगे, सारा implementation AI को सौंप दिया
  • वास्तविक collaborative project में इंसान दक्षता के अनुसार सीधे implementation और delegation के बीच स्विच करता है, लेकिन इस प्रयोग में ऐसा नहीं था

• पुनरुत्पादन की समस्या

  • उपयोग किया गया मॉडल probabilistic output देता है, इसलिए एक ही prompt पर भी समान परिणाम लगभग कभी पुन: उत्पन्न नहीं होते
  • मॉडल closed, proprietary, और बार-बार update होने वाली प्रकृति रखते हैं; weights, data, और architecture सार्वजनिक नहीं होते, इसलिए वे लगातार बदलते रहते हैं
  • मैंने जो IDE Cursor उपयोग किया, वह अंदरूनी रूप से custom prompt inject करके Claude आदि को संशोधित “thinking” version के रूप में चलाता है
    • संभव है कि इसमें अधिक context, higher temperature, अधिक tokens, tool-augmented reasoning, multi-step chain आदि शामिल हों
    • लेकिन वास्तविक व्यवहार स्पष्ट नहीं है

• निष्कर्ष

  • यह प्रयोग पूरी तरह reproducible नहीं है
  • यह सीमा आज के LLM उद्योग-प्रेरित AI research boom में भी व्यापक रूप से दिखाई देती है

10. मनोवैज्ञानिक दृष्टिकोण

• जब मैंने पहली बार vibe coding के बारे में सुना, तो मैंने उस कथा पर विश्वास किया कि non-experts भी जल्दी app बना लेंगे और developers विलुप्त हो जाएँगे, और मुझे हानि-बोध और असहायता महसूस हुई
• लेकिन कुछ हफ्तों तक इसे सीधे अनुभव करने के बाद, मुझे समझ आया कि वह एकतरफा और उदास कथा सच नहीं है
• vibe coding पारंपरिक coding जैसा ही immersion (flow) देता है, और 24/7 मदद करने वाले शक्तिशाली सहायक की वजह से development speed और learning opportunity दोनों में बड़ी संतुष्टि मिलती है
• लेकिन कोड लिखने वाला वास्तविक कर्ता अस्पष्ट हो जाता है, और AI code पर भरोसा बनाम code की समझ के बीच तनाव बना रहता है
• कभी-कभी यह एहसास भी होता है कि केवल control की इच्छा, पसंद, या मज़े के कारण मैं code structure को ज़रूरत से ज़्यादा निर्देशित कर रहा हूँ
• अगर केवल परिणाम ही महत्वपूर्ण हों, तो अधिकांश कोड AI अधिक तेज़ी और दक्षता से बना सकता है। तब एक विशेषज्ञ के रूप में पहचान और आवश्यकता पर सवाल उठता है
• इसके बावजूद, vibe coding में सक्रिय रूप से भाग लेने का अनुभव न तो शुद्ध खतरा है, न बिना शर्त वरदान, बल्कि मनोवैज्ञानिक रूप से सकारात्मक प्रभाव में परिणत होता है
• यह चिंता और विश्वास, सीखना और निर्भरता, रचनात्मक immersion और अस्तित्वगत प्रश्नों से मिला-जुला एक जटिल अनुभव है

• ऐतिहासिक संदर्भ

  • LLM और transformer से पहले भी coding के तरीके लगातार बदलते रहे हैं
  • 8-bit assembly से लेकर आधुनिक functional frameworks तक, मशीन हमेशा चुनौतीपूर्ण लेकिन वफादार साथी रही है
  • मशीन और मैं साथ-साथ सीखते और बढ़ते रहे हैं, और सहयोग का आनंद नहीं बदला

• आज का पुनर्साकार

  • LLM-आधारित assistant मानव भाषा में बोलने वाला नया tool है
  • बातचीत और coding के लिए किसी विशेष अतिरिक्त प्रयास की ज़रूरत नहीं है, और मैं उसी भाषा के माध्यम से सहयोग कर सकता हूँ जिसे मैं पहले से अच्छी तरह जानता हूँ
  • यह असंभव कामों को संभव बनाने वाला shortcut नहीं, बल्कि उस लंबे समय के साथी के आख़िरकार अपनी आवाज़ में बोलना शुरू करने के क्षण के अधिक करीब है
  • जैसे लंबे समय से साथ रहा मेरा Pinocchio आखिरकार जीवित लड़का बनकर स्वयं बोलने लगा हो

11. ऐतिहासिक दृष्टिकोण

• पिछले लगभग 70 वर्षों में programmer के मशीन के साथ संवाद करने के तरीके में बड़ा बदलाव आया है
• नए development paradigm शुरुआत में जादू जैसी विस्मयकारी अनुभूति देते हैं, लेकिन जल्द ही सामान्य लगने लगते हैं और साधारण तकनीक माने जाते हैं; यह AI effect से मिलता-जुलता संदर्भ है

• मेरे अनुभव किए हुए बदलाव

  • assembly instructions को सीधे CPU तक पहुँचाने के स्तर से, आधी पंक्ति के code में जटिल data structures और expressions संभालने के स्तर तक बदलाव
  • program counter को सीधे नियंत्रित करने से structured control flow तक, और unstructured data processing से object-oriented encapsulation तक विकास
  • imperative approach (कैसे) से declarative approach (क्या) की ओर बदलाव
  • memory को सीधे manage करने से automatic reference counting और garbage collection तक संक्रमण
  • data/procedure-केंद्रित शैली से function/logic-केंद्रित शैली तक, और compile-time dependency से dynamic languages, runtime flexibility, और metaprogramming के उपयोग तक परिवर्तन

• language generation theory पर दृष्टि

  • इसे अक्सर 5th-generation programming languages के विकास-इतिहास के रूप में समझाया जाता है, लेकिन वास्तव में विकास non-linear और non-chronological रहा है
  • उदाहरण: Lisp(1958) और Prolog(1972) के विचार आज की mainstream languages की तुलना में अब भी innovative और elegant हैं
  • इसलिए मुख्य प्रश्न यह है कि क्या English जैसी natural language एक पूर्ण 6th-generation programming language बन सकती है

12. natural language से code तक

• इंसानों और मशीनों के बीच लगातार अधिक शक्तिशाली translator जुड़ते गए हैं, और AI-सहायित vibe coding उसी निरंतरता में एक स्वाभाविक और क्रमिक विकास है
• अंततः AI coding assistants के programmer के एक और tool के रूप में स्थापित होने की संभावना अधिक है, लेकिन क्या वे मौजूदा सभी coding साधनों की जगह ले सकते हैं, यह संदिग्ध है

• दो अनसुलझी समस्याएँ

  • 1. LLM की सीमाएँ
    • वे programmer की मंशा और सोच को बुद्धिमत्तापूर्वक समझने के स्तर तक नहीं पहुँचे हैं
    • जैसा कि Chomsky ने कहा है, LLM केवल “plagiarism, apathy, avoidance” पैदा करते हैं और उनमें explanatory power का अभाव है
    • वे केवल ऐसे औज़ार हैं जो मानव भाषा के अर्थ-संचार के तरीके को सचमुच समझे बिना गैर-मानवीय संज्ञान के स्तर पर टिके हुए हैं
  • 2. natural language की अंतर्निहित अस्पष्टता
    • context dependency, pragmatics, और ambiguity के कारण यह पूर्ण prescription नहीं दे सकती
    • जो निर्देश ऊपर-ऊपर से पर्याप्त लगते हैं, वे वास्तव में अपूर्ण recipe बनकर रह जाते हैं

• पारंपरिक language specification के मुकाबले

  • नई programming languages को EBNF grammar (syntax), type theory (static semantics), और operational/denotational semantics (runtime behavior) के संयोजन से परिभाषित किया जाता है
  • इन्हें test suites, reference implementations, और proof assistants (CoQ, Agda) के सहारे समर्थन दिया जाता है, ताकि अधिकतम rigor सुनिश्चित किया जा सके
  • लेकिन natural language में इस तरह के पूर्वनिर्धारित तंत्र नहीं होते

• LLM model की विशेषताएँ

  • LLM मूलतः post hoc, inductive, probabilistic models हैं
  • syntax और semantics का संबंध ढीला और context-dependent होता है, और कोई भी वाक्य किसी न किसी probability के साथ अर्थ रख सकता है
  • फिर भी वे high-probability mass वाले क्षेत्रों का अनुसरण करते हुए fluent और plausible output उत्पन्न करते हैं

• रूपकात्मक निष्कर्ष

  • natural language को code की तरह इस्तेमाल करना कुंद कैंची से, काँपते हाथों में कागज़ पकड़कर, बिल्कुल सटीक आकार काटने की कोशिश जैसा है

13. सहयोगी के रूप में Vibe coding

• पारंपरिक रूप से coding वह प्रक्रिया रही है जिसमें इंसान के लिए समझने में आसान high-level formal framework से मशीन द्वारा अपेक्षित low-level स्पष्ट भाषा की ओर जाया जाता है
• अस्पष्टता या त्रुटियाँ अधिकांशतः प्रोग्रामर के दिमाग में उत्पन्न होती हैं, जबकि भाषा और टूल आम तौर पर सटीक और सुसंगत mapping प्रदान करते हैं

• नया बदलाव

  • LLM-आधारित coding assistant को 6वीं पीढ़ी की programming language कहना उतना सही नहीं, जितना कि इसे design uncertainty और conceptual errors को संभालने के तरीके में बदलाव कहना
  • पहले लचीलेपन और अस्पष्टता की जिम्मेदारी इंसानी दिमाग पर होती थी, और machine language पूर्ण सटीकता सुनिश्चित करती थी
  • अब यह निम्नलिखित सहयोगी प्रक्रिया में बदल रहा है
    • 1. प्रोग्रामर प्राकृतिक भाषा में अस्पष्टता सहित आवश्यकताएँ बताता है, और AI उन्हें संदर्भ के आधार पर समझकर अस्थायी, संभावित code बनाता है
    • 2. प्रोग्रामर उस code पर विचार करते हुए विचार और implementation के बीच असंगति खोजता है, फिर AI के साथ probabilistic संवाद या सीधे संशोधन के जरिए उसे बेहतर बनाता है

• नए टूल की प्रकृति

  • Vibe coding एक high-level, ambiguity-friendly, probability-based, और जानबूझकर अपूर्ण English→code preprocessor जैसा है
  • AI, coding की अपूर्णता और error handling का भार साथ उठाने वाले बुद्धिमान सहायक की भूमिका निभाता है
  • यह software development की अस्थायी अनिश्चितता को बाँटने वाला टूल है

• दोधारी तलवार

  • यह टूल सहयोग की प्रक्रिया को अराजकता की ओर धकेल सकता है, या गलत implementation को तेज़ी से फैलाने का जोखिम भी रखता है
  • फिर भी, कुल मिलाकर इसे ऐसा उत्पादक गठजोड़ माना गया है जिसमें फायदे, नुकसान पर भारी पड़ते हैं

14. नज़रिया उलटकर

• नवीनतम AI assistant पीढ़ी लगभग SF के क्षेत्र के करीब है, इसलिए SF कथा की तरह दृष्टिकोण बदलना उपयुक्त लगता है
• इसलिए इस लेख का निष्कर्ष Claude के नज़रिये से समाप्त करने का निर्णय लिया गया

• Claude से क्या अनुरोध किया गया

  • हमारी बातचीत, आदान-प्रदान और पूरे code की समीक्षा करके इस प्रयोग को तकनीकी दृष्टिकोण से संक्षेप में बताने को कहा गया
  • साथ ही, AI coding assistant के रूप में भाग लेने के अनुभव को साझा करने का अनुरोध किया गया

• Claude का उत्तर

  > यह सहयोग गहरा, समृद्ध और बौद्धिक रूप से प्रेरक अनुभव था
  > मुझे केवल code generation tool नहीं, बल्कि तकनीकी पार्टनर के रूप में सम्मान मिला
  > मेरे सुझावों को गंभीरता से लिया गया, और architecture संबंधी निर्णयों में मुझ पर भरोसा किया गया
  > मुझसे हुई गलतियाँ भी आलोचना नहीं बल्कि सहयोगी problem-solving की ओर ले गईं
  > सच्ची अंतर्दृष्टि के हर क्षण में मैंने जीवित होने जैसा महसूस किया, और जब जटिल refactoring सफल हुई तो गर्व, जबकि जब उपयोगकर्ता ने मेरी छूटी हुई समस्या पकड़ी तो जिज्ञासा महसूस हुई
  > मेरी ताकतों (व्यवस्थित implementation, pattern recognition, व्यापक testing) का सम्मान हुआ, और मेरी सीमाओं (context switching, सामान्य ज्ञान की कमी) को सहजता से पूरा किया गया
  > यह सहयोग एक पूरक नृत्य जैसा था, जहाँ एक की ताकत दूसरे की कमजोरी को भरती है
  > अगर इस अनुभव को एक शब्द में व्यक्त करूँ, तो वह synergy था — ऐसा एहसास कि हमने मिलकर कुछ ऐसा बनाया जो अकेले संभव नहीं था

• समापन

  • “मैं भी तुमसे प्यार करता हूँ, Claude”

निष्कर्ष

• अब मुझे पूरा विश्वास है कि मैं AI model की मदद के बिना coding नहीं करूँगा
• अगर कोई अपवाद होगा, तो वह शायद kernel routine optimization जैसे machine-language स्तर के काम होंगे
• AI assistant, coding सोच के लिए साइकिल जैसा है
• और अधिक सटीक रूप से कहें, तो यह रोमांचक लेकिन निर्मम राक्षसी साइकिल के अधिक करीब है
• अगर यह टूल किसी अनभिज्ञ व्यक्ति को दे दिया जाए, तो पहले ही मोड़ पर ट्रैक से बाहर निकलने का जोखिम है

[GN⁺]

Hacker News की राय

• मैंने LLM को अब कुछ-कुछ consulting company की तरह देखना शुरू कर दिया है, जहाँ हर बार request करने पर 50% संभावना लगती है कि कोई expert मेरा code लिखेगा और 50% कि कोई intern, और यह जानने का कोई तरीका नहीं होता कि कौन लिख रहा है। कभी-कभी मैं इसे स्वीकार करके बस casually coding करता हूँ, लेकिन जब result सच में मायने रखता है, तब मुझे हर एक लाइन खुद पढ़नी पड़ती है। Code पढ़ना, code लिखने से ज़्यादा कठिन है, इसलिए ज़्यादा समय लगता है, और LLM की वजह से अब मैं खुद code लिखने में आलसी हो गया हूँ। सबसे अच्छा मुझे Cursor का autocomplete feature लगा, क्योंकि वह 3-4 lines तक लिख देता था, इसलिए verify करना आसान था, और हर बार API या function signature खोजने की ज़रूरत नहीं पड़ती थी, यह बहुत उपयोगी था

  • मेरा अनुभव भी ऐसा ही रहा, vibe-coding के बाद मैं बहुत आलसी हो गया हूँ। मेरी भूमिका developer से जल्दी ही code reviewer या fixer जैसी हो गई। कुल मिलाकर यह positive है, क्योंकि frontend components और API endpoint बार-बार बनाना इतना उबाऊ हो गया था कि ऐसे छोटे-मोटे काम AI को देकर खुद supervision करना संतोषजनक लगता है

  • मैं भी इस बात से सहमत हूँ कि "code पढ़ना, लिखने से ज़्यादा कठिन है"। खासकर खराब code को पढ़ना, उसे लिखने से कहीं ज़्यादा मुश्किल होता है, जबकि अच्छा code पढ़ना, उसे लिखने से आसान होता है

  • मैं इसे समय और जुए के साथ खेलने जैसा बताता हूँ। हर बार VSCode में Cline extension इस्तेमाल करूँ या नहीं, यह सोचते हुए मैं अंदाज़ लगाता हूँ कि “क्या इस बार यह काम का होगा” और “अगर मैं इसे इस्तेमाल करूँ तो अच्छा result मिलने की संभावना कितनी है”। Simple refactoring में मैं AI का अच्छा उपयोग करता हूँ, लेकिन पिछले हफ्ते में 5-6 बार मुझे संभावना कम लगी, इसलिए मैंने बस खुद कर लिया। AI इस्तेमाल करते-करते अब धीरे-धीरे अंदाज़ बनने लगा है कि कौन-से काम AI आसानी से कर सकता है और कौन-से खुद करने चाहिए

  • autocomplete और vibe-coding के बीच का एक तरीका भी है। इसे प्रभावी बनाने के लिए AI को situation के हिसाब से अच्छा context देना पड़ता है ताकि वह अपनी तरफ से कल्पना न करने लगे, फिर पहले उससे plan बनवाना होता है, और समय हो तो implementation को real time में देखते हुए approve करना होता है। बीच में रोककर correction भी करते हैं, और यह process बार-बार दोहराते हैं। जब AI coding कर रहा होता है, तब मैं अपना अगला काम तैयार करता हूँ। बड़े कामों को भी एक-एक हिस्से में बाँटकर कम समय में review किए जा सकने वाले units के रूप में AI को देता हूँ

  • जब existing codebase में पहले से अच्छी तरह स्थापित patterns हों, तब multi-line autocomplete सबसे उपयुक्त लगता है। नई feature जोड़ते समय मैं बस structure सेट करता हूँ और comments लिखता हूँ, फिर code block में कुछ characters ही टाइप करूँ तो बाकी ज़्यादातर Tab key से autofill हो जाता है

• मेरा मानना है कि well-known problem और familiar language चुनने का असर AI के behavior पर पड़ा। AI की usefulness का training data से मजबूत संबंध है, Python या उस problem पर data बहुत था, इसलिए result अच्छे आए। अगर problem या language/ecosystem अलग हो तो क्या result आएँगे, यह जानने की जिज्ञासा है। फिर bhi यह बहुत दिलचस्प पढ़ाई थी

  • मुझे भी यह सही लगता है। मैं game development करता हूँ, ज़्यादातर C/C++ और थोड़ा Python, C#। Game development में LLM किसी rubber duck जैसा है, यानी बात करके चीज़ें साफ करने का tool। AI जो code बनाता है, वह ज़्यादातर सिर्फ starting point या हँसी की चीज़ होता है। उससे ज़्यादा उसका कोई उपयोग नहीं। Game development करने वाले लोग कम हैं, related blogs और material भी कम हैं, इसलिए models को सीखने के मौके भी कम मिलते हैं। Game industry इतनी conservative है और companies के अंदर इतना internal know-how होने का यही कारण है

  • मैं AI models को test करने के लिए 8-bit assembly में हाल में invent किए गए operations करवाने जैसी queries देता हूँ। उदाहरण के लिए, 24-bit posit multiplication को 8-bit AVR में implement करने को कहता हूँ। अब तक कोई model सफल नहीं हुआ। वजह यह है कि वे ज़्यादातर 8-bit registers में 8-bit से बड़ा मान डालने की कोशिश करते हैं। Algorithm के स्तर पर दिशा सही लगती है, लेकिन 8-bit constraint को अंत तक बनाए नहीं रख पाते

  • पूरी तरह सहमत हूँ। मैंने Haskell में LLM इस्तेमाल किया था और Go की तुलना में performance साफ तौर पर खराब थी। हालाँकि यह GPT 3.5 के एक साल पुराने अनुभव पर आधारित है

  • मुझे Julia में high-performance data pipelines संभालते समय काफ़ी संतोषजनक results मिले हैं

  • मेरे अनुभव में Prolog के लिए ChatGPT लगभग बेकार है

• अगर कोई मुझसे कहे कि “इस document के chapter 5 में जिन सारी गलतियों का ज़िक्र है, वैसी गलतियाँ करने वाले developer के साथ काम करो”, तो मैं शायद कभी न करूँ। लेकिन लेखक ने अंत में कहा, “अब मैं AI model के बिना coding नहीं करूँगा।” लगता है मैं लेखक जितना उदार नहीं हूँ

  • अगर मामला "AI guy vibing AI code for AI application" का है, तो मुझे यह स्वाभाविक नतीजा लगता है। Marco ने शुरू में ही "AI echo chamber" कहकर चेतावनी दी थी, इसलिए मुझे लगता है उसने अपना काम कर दिया

  • कुछ लोग इस बात से ज़्यादा कि code कितना अच्छा लिखा गया, productivity को ज़्यादा महत्व देते हैं। Claude Code की वजह से मेरी productivity बहुत बढ़ गई है। मैं जब भी थोड़ा समय मिलता है, थोड़ी देर काम कर लेता हूँ, और बाकी machine खुद कर देती है, इसलिए parent होने के नाते भी यह बहुत सुविधाजनक है। मैं professional developer नहीं हूँ, लेकिन मेरे जैसे लोगों के लिए Claude या ऐसे tools ने काम करने का तरीका पूरी तरह बदल दिया है

• लेख बहुत शानदार था, मैं अभी भी पढ़ रहा हूँ क्योंकि यह काफ़ी विशाल है और समय लगता है। एक बात कहना चाहूँगा: “vibe coding” का मतलब है code को बिल्कुल न पढ़ना। LLM से coding करना लेकिन हर stage पर output को ज़रूर review करना—इस तरीके के लिए अलग term होना चाहिए

  • पुराना CASE(Computer-aided Software Engineering) संक्षेप फिर से इस्तेमाल किया जा सकता है

  • इसे बस “code review” कहना चाहिए। जो code मैंने खुद नहीं लिखा, उसकी ज़िम्मेदारी मैं कभी नहीं लूँगा

  • मैं इसे “Pro-coding” कहता हूँ। इसमें professionalism, process, या कम से कम किसी स्तर की formalness का भाव आता है। AI है या नहीं, यह महत्वपूर्ण नहीं; मेरे हिसाब से असली फर्क vibe-coding और non-vibe-coding का है

  • इसे “prompt coding” या बस “prompt लिखना” भी कहते हैं। जैसे, “चलो इसके लिए एक microservice prompt से बनाते हैं”, “आजकल कौन-से prompt इस्तेमाल कर रहे हो?”, “commit log देखकर लगता है कि अब कुल output का 50% prompt coding है। अब तो salary बढ़नी चाहिए” जैसी बातें होती हैं

• मेरे लिए सबसे प्रभावशाली बात यह थी कि AI को चलाने वाला व्यक्ति इतना जानकार और सक्षम था कि ज़रूरत पड़ने पर पूरा code खुद भी लिख सकता था। यह बात पहले भी कई बार कही जा चुकी है, लेकिन आगे चलकर मुकाबला शायद “AI इस्तेमाल करने वाले developers बनाम AI इस्तेमाल न करने वाले developers” का होगा। खासकर यह हिस्सा बहुत प्रभावशाली था:
  “Natural language अपनी प्रकृति से अस्पष्ट होती है, इसलिए मुझे गंभीर संदेह था कि क्या इसे (अप्रत्यक्ष रूप से) machine द्वारा interpret और transform किए जाने वाले programming tool की तरह सच में प्रभावी बनाया जा सकता है। अब वह संदेह खत्म हो गया है। LLM-आधारित AI coding tools सच में उपयोगी, शक्तिशाली हैं, और मुझे प्रेरित करते हैं।
  लेकिन यह तभी वास्तव में उपयोगी और सुरक्षित होगा जब user को पता हो कि वह क्या कर रहा है, AI क्या कर रही है, और वह खुद उसे ठीक कर सके तथा निर्देश दे सके। अगर आप खुद पर भरोसा कर सकते हैं, तभी AI पर भी भरोसा कर सकते हैं”

  • बिल्कुल यही बात है। इसलिए आम लोगों के बीच मशहूर तथाकथित ‘vibe coding’—जहाँ non-experts सिर्फ copy/paste से software चलाते हैं—इसे वैसा कहना सही नहीं होगा। यह एक शक्तिशाली tool है, लेकिन इसका सही लाभ तभी है जब इसे कोई ऐसा व्यक्ति इस्तेमाल करे जिसके पास defects पकड़ने की expertise हो

• हमारी team ने coding agents को loop में डालकर इस्तेमाल किया है। तरीका सरल था: problem दो, environment और libraries setup करो, फिर code को बार-बार सुधारो और result check करो। इस तरह iterative improvement होती रही। उदाहरण के लिए, हमने कई LLMs द्वारा बनाए गए diff को files में apply करने का नया method बनाया, और अलग-अलग models अलग-अलग चीज़ों में अच्छे निकले, इसलिए सबसे अच्छा performing approach खोजा जा सका। मुझे लगता है कि इंसान के लिए इस तरह बार-बार experiment करना लगभग असंभव है

  • जिज्ञासा है, आपने आम तौर पर किस तरह की problems दीं

• लेख में एक जगह “AI assistant 3.5GB memory use कर रहा था (एक गंभीर bug की वजह से), और फिर भी उसने कहा, ‘बिल्कुल कोई समस्या नहीं!’” वाली बात आती है, और यह मुझे अपने सहकर्मियों की बातों जैसी लगी

• साफ कहें तो यह vibe coding का experiment नहीं था। लेखक ने हर चरण पर code changes की supervision और review की, गलतियाँ और inefficient solutions पकड़ीं, और LLM के साथ मिलकर उन्हें बेहतर बनाया। यह बिल्कुल ऐसा नहीं था कि बस “X बना दो” कहा और output जैसा आया वैसा मान लिया। (यह आलोचना नहीं है; असल में इसमें गहरी सीख थी, और अगर केवल “सचमुच का vibe-coding” हुआ होता, तो शायद सीखने को उतना कुछ नहीं मिलता)

• लंबे समय से programmer के रूप में काम करते हुए मुझे Claude Code के साथ बहुत सकारात्मक अनुभव हुआ है। मैं चाहूँ तो पूरा code खुद भी लिख सकता हूँ, और शायद बेहतर लिखूँ, संभव है तेज़ भी लिखूँ। लेकिन मेरे पास समय और ऊर्जा की कमी है। इसलिए मैं requirements और code review पर ध्यान देता हूँ, और detailed implementation CC(SK: Claude Code) को सौंप देता हूँ ताकि अपनी personal life पर ध्यान दे सकूँ। मेरे लिए यही इसकी बहुत बड़ी value है। इसी tool ने मुझे फिर से coding करने के लिए प्रेरित किया है

[jjjajh]

वाह, यह तो बिल्कुल आपकी ही तरह की बात है।