AI कोड जनरेशन की सीमाएँ और मानवीय संवेदना के क्षरण पर एक व्यक्तिगत केस स्टडी

• RP2350 RISC-V core को डिबग करने के लिए SWD protocol implementation library के रूप में, Raspberry Pi Pico2 का उपयोग करके दूसरे Pico को probe की तरह इस्तेमाल करने वाली संरचना
• कोड का लगभग 80% AI(Claude) द्वारा जनरेट किया गया, और लेखक ने oscilloscope और दस्तावेज़ों के आधार पर मूल prototype बनाया, फिर AI से कोड का विस्तार करवाया
• प्रोजेक्ट के दौरान AI कोड की निरर्थक token संरचना, context का खो जाना, कोड पर स्वामित्व की भावना का खोना आदि के कारण गहरी घृणा और संशय का अनुभव हुआ
• दूसरी ओर, AI को दस्तावेज़ विश्लेषण, डेटा decoding, struct जनरेशन जैसे सहायक टूल के रूप में उपयोग करने पर सकारात्मक अनुभव मिला
• यह मामला AI कोड जनरेशन की गुणवत्ता·संवेदना·स्वामित्व की समस्याओं को उजागर करता है और प्रोग्रामिंग के सार तथा मानव की भूमिका पर मूलभूत प्रश्न उठाता है

---

0. VIBE CODE WARNING

• पूरे कोड का लगभग 80% AI-generated (vibe coded) है, और README का अधिकांश भाग भी auto-generated है
• लेखक ने oscilloscope और दस्तावेज़ों के आधार पर SBA, register read/write, abstract commands, PROGBUF आदि स्वयं इम्प्लीमेंट किए, फिर AI को लाइब्रेरीकरण सौंपा
• कोड 1,000 लाइन से बढ़कर 4,000 लाइन होने पर कोड की संरचना और अर्थ पूरी तरह खो गए, और यह अपने लिखे हुए कोड जैसा महसूस नहीं हुआ
• AI ने dap_read_mem32 को गलत समझा, जिससे protocol errors और illogical code बड़ी मात्रा में उत्पन्न हुए
• परिणामस्वरूप लगभग 10,000 लाइनों का कोड 10 घंटे में पूरा हो गया, लेकिन न उपलब्धि का एहसास हुआ, न विकास का

AI कोड और मानव कोड का अंतर

• मनुष्य द्वारा लिखा गया कोड इरादे और उद्देश्य वाले tokens से बना होता है, इसलिए उसे समझा जा सकता है; जबकि AI कोड के tokens अर्थहीन संयोजनों जैसे लगते हैं और पढ़ना कठिन होता है
• AI कोड के कुछ हिस्से इंसानों से बेहतर गुणवत्ता दिखाते हैं, लेकिन ठीक अगली पंक्ति सिर्फ ऊपर से भरोसेमंद दिखने वाला त्रुटिपूर्ण कोड हो सकती है
• यह असमानता और संवेदी भरोसे का खोना प्रोग्रामर की निर्णय क्षमता को सुन्न कर देता है
• कोड जितना बड़ा होता है, “यह अच्छा कोड है या बुरा” महसूस करने वाली taste की भावना गायब होने लगती है, और mental model तथा ownership बिखर जाते हैं

मानवीय भावनाएँ और संशय

• लेखक “क्या यही प्रोग्रामिंग है?” पूछते हुए घृणा और शर्म व्यक्त करता है
• उस युग में जहाँ AI कोड लिख रहा है, मनुष्य क्या बनाए और किस हद तक हस्तक्षेप करे—इस पर अस्तित्वगत उलझन प्रकट की गई है
• सिर्फ “कोड न लिखना” क्या प्रगति है, या “समस्या को मॉडल न करना” क्या दक्षता है—इस पर भी उसे भरोसा नहीं रहा
• वह अब भी कुछ अपने हाथ से बनाना चाहता है, लेकिन AI-केंद्रित development environment में उसका अर्थ धुंधला हो गया है

AI के सकारात्मक उपयोग का अनुभव

• AI को दस्तावेज़ विश्लेषण, oscilloscope डेटा decoding, C struct auto-generation आदि में इस्तेमाल करना कुशल और संतोषजनक लगा
• विशेष रूप से, पहला register पढ़ने और SBA के जरिए memory पढ़ने में सफल होने पर वास्तविक उपलब्धि का एहसास हुआ
• यानी, AI को कोड लेखक नहीं बल्कि सहायक की तरह इस्तेमाल करने पर सकारात्मक अनुभव संभव है

निष्कर्षात्मक चिंतन

• AI कोड जनरेशन तेज़ है, लेकिन यह अर्थ, संवेदना और स्वामित्व के क्षरण को जन्म देता है
• जब मनुष्य की “अच्छे कोड का स्वाद (taste)” महसूस करने की क्षमता मिटने लगती है, तब प्रोग्रामिंग का सार भी डगमगाने लगता है
• लेखक आशा करता है कि यह एक अस्थायी संक्रमणकाल हो, और अंत में स्वीकार करता है कि “बेहतर प्रोग्रामिंग” क्या है, यह वह स्वयं भी नहीं जानता

---

मूल लेख के बाद का तकनीकी सेक्शन (1~20) RP2350 RISC-V debug protocol के विस्तृत implementation दस्तावेज़ हैं, जिनमें SWD लेयर संरचना, DAP/DAPC registers, PROGBUF execution, SBA access, hart control, tracing, reset, dual-hart structure आदि सहित पूरे debug stack की पूर्ण तकनीकी विनिर्देश शामिल हैं।
लेकिन मुख्य विषय AI द्वारा जनरेट किए गए कोड और मानवीय संवेदना के विच्छेद पर एक व्यक्तिगत केस स्टडी (Vibe Code Warning) है।

[GN⁺]

Hacker News राय

• जो लोग कहते हैं कि “AI ने programming का मज़ा छीन लिया”, उनकी भावना से मैं सहानुभूति रखता हूँ, लेकिन मेरा मानना है कि ‘करने’ से ज़्यादा ‘पूरा करने’ की अहमियत है
  पहले गैस लैम्प जलाने वाले लोग बिजली के बल्ब आने से अपनी नौकरी खो बैठे, लेकिन आखिरकार महत्वपूर्ण बात शहर को रोशनी देना थी
  मेरे लिए AI ideas को साकार करने और नतीजे बनाने का एक tool है। मैं अब भी ‘असली programmers’ जितना ही समय और मेहनत लगाता हूँ, लेकिन मेरा फोकस problem definition, modularization, testing, bug fixing, और iterative improvement पर होता है

  • “करना vs पूरा करना” जैसा यह द्वैत खतरनाक सोच है
    ऐसा संसार बनाना ज़रूरी है जहाँ इंसान अर्थ, गरिमा, और आनंद महसूस कर सके।
    अगर मैं स्वादिष्ट खाना खा रहा हूँ लेकिन उसे बनाने वाले लोग पीड़ा में थे, या वह किसी दुष्ट ताकत ने robots से बनवाया हो, तो मुझे वह नहीं चाहिए।
    समाज इंसानों के लिए है, सिर्फ़ efficiency की checklist के लिए नहीं
  • “पूरा करना” आखिर है क्या? AI द्वारा लाई गई रफ़्तार और जटिलता की वजह से परिणामों की जाँच करना लगातार कठिन होता जा रहा है
    निजी projects में यह ठीक हो सकता है, लेकिन जहाँ ग्राहक, users, या shareholders हों, वहाँ साबित किए जा सकने वाले परिणाम चाहिए
    गैस लैम्प वाली उपमा ठीक नहीं है। AI बिजली जैसी physical system नहीं, बल्कि software है।
    आखिरकार महत्वपूर्ण बात problem solving है। अगर समाधान नहीं हुआ, तो वह सिर्फ़ labor है
  • गैस लैम्प वाली उपमा अनुपयुक्त है। गैस लैम्प जलाना रचनात्मक अभिव्यक्ति नहीं था, लेकिन code लिखना एक रचनात्मक क्रिया है
    बहुत से लोग सिर्फ़ उपयोगी software बनाने के लिए नहीं, बल्कि सृजन के आनंद के लिए code लिखते हैं
    “असली programmers” भी उतना ही समय सोचने, define करने, test करने, और fix करने में लगाते हैं
  • AI और technology जो कुछ बना रहे हैं, उसका काफ़ी हिस्सा वास्तव में अनावश्यक काम है
    ‘smart floss dispenser’, automatic toilet paper purchaser, या Clippy जैसे bots समय और ऊर्जा की बर्बादी हैं
  • craftsmanship और ज्ञान के साथ संबंध महत्वपूर्ण है
    सिर्फ़ परिणाम हासिल करने से ज़्यादा, सीखने और समझने की प्रक्रिया से मिलने वाला संतोष बड़ा होता है
    survival memoir Adrift, 76 Days at Sea पढ़ते समय मुझे महसूस हुआ कि गहरा ज्ञान जीवन और मृत्यु का फ़र्क तय कर सकता है
    यह उस सवाल से भी मिलता-जुलता है कि data को खुद host किया जाए या centralized service को सौंप दिया जाए

• इंटरनेट पर जब मुझे कोई ऐसा लेख दिखता है जो मेरे विचारों को पूरी तरह व्यक्त करता है, तो सचमुच सांत्वना मिलने जैसा लगता है
  “prompt को ऐसे tweak करो” जैसी noise की जगह मानवीय अनुभव की बात करने के लिए धन्यवाद

  • मेरा भी यही हाल है। AI को लंबे समय तक इस्तेमाल करने पर वैसी ही खोखली और निरुद्देश्य भावना आती है जैसे YouTube को बिना सोचे scroll करते रहना
    इस हालत से निकलने के लिए एक रात की अच्छी नींद चाहिए
  • कुछ लोग सोचते हैं कि AI को Excel की तरह इस्तेमाल किया जा सकता है, लेकिन मुझे यह slot machine के ज़्यादा क़रीब लगता है
    यह लगभग सही जवाब देता है, लेकिन मनोवैज्ञानिक रूप से इसकी लत जुए की मशीन जैसी लगती है

• किसी ने कहा कि “AI से 10 घंटे में 10,000 lines का code लिखा, लेकिन वह भयानक था”, मगर वह अनुभव approach के हिसाब से पूरी तरह बदल सकता है
  prompt structuring, planning, review, testing, speed control — ये सब हर व्यक्ति के लिए अलग होते हैं
  बहुत से novice developers ‘vibe coding’ कहे जाने वाले तात्कालिक approach को आज़माकर असफल हो जाते हैं

  • मैंने भी agent systems को tune करते हुए लगातार नए तरह की विफलताएँ खोजी हैं
    थकान काफ़ी बढ़ गई है, इसलिए अभी थोड़ा विराम लिया है, और कभी न कभी अपना agent खुद बनाने की योजना है
    OpenAI, Microsoft, Anthropic जैसी big tech कंपनियों पर यह छोड़ना ख़तरनाक लगता है
  • मैंने अभी तक vibe coding से बना कोई बड़े पैमाने का open source project नहीं देखा है
    अंततः यह सिर्फ़ बातें बनाने वाला buzzword लगता है
  • इतनी मेहनत के बाद भी, क्या यह सच में खुद coding करने से तेज़ है? यही सवाल है
    ऐसा लगता है जैसे नई library सीखने से बचने के लिए project management में शरण ली जा रही हो
  • तुम्हारी बात सही है, लेकिन “सही approach” क्या है, यह ठोस रूप से बताने वाला कोई नहीं है
    पहले चर्चा में रहा “Just Talk to It” लेख भी details में कमज़ोर था
  • vibe coding आख़िरकार planning ability का proxy metric जैसा लगता है
    जितना ज़्यादा तात्कालिकपन होगा, उतनी ही ज़्यादा ठोस planning चाहिए। क्या तुम्हारी बात का सार यही है?

• अब public code वैसा मानव-निर्मित नहीं रहा जैसा पहले था
  अगर ऐसा code फिर से training data में जाता है, तो दुनिया और भी ज़्यादा बेमानी output से भर जाने का ख़तरा है
  language research में भी पहले से ऐसे उदाहरण हैं जहाँ machine-generated text इतना बढ़ गया कि data collection अर्थहीन हो गई

  • मुझे लगता है कि सब ठीक रहेगा। AI भले बहुत कूड़ा-जैसा code बनाता हो, लेकिन आखिरकार इंसान उसी में से हीरे चुन लेते हैं
    ज़्यादातर मामलों में दिशा अब भी इंसान ही तय कर रहा है
    हाँ, अगर कोई 12 साल का बच्चा “yolo 3d game now” टाइप कर रहा हो तो चिंता होती है, लेकिन साथ ही वह काफ़ी शानदार भी लगता है
  • दिलचस्प बात है। यह घटना शायद model poisoning जैसा असर पैदा कर सकती है

• vibe coded code पढ़ना कुछ-कुछ “English as She is Spoke” जैसा लगता है
  grammar सही होती है, लेकिन code इंसानी भाषा जैसा नहीं लगता

• मैं भी ऐसा ही सोचता हूँ
  आम तौर पर जब मैं कोई app develop करता हूँ, तो कई दिनों तक दिमाग में उसका mental model बनता रहता है, और shower लेते समय भी मैं उसकी संरचना को फिर से सोचता हूँ
  लेकिन vibe coding करने पर यह आंतरिक संदर्भ गायब हो जाता है, और code पढ़ना तकलीफ़देह लगता है
  दूसरी ओर, जो code मैंने खुद लिखा हो, उसे पढ़ना आनंद देता है

  • मैं वह भावना अब भी महसूस करता हूँ, लेकिन code level पर नहीं बल्कि system level पर
    systems के बीच connections और data flow समझ में आते हैं, लेकिन implementation details धुंधली रहती हैं

• मेरा अनुभव भी कुछ ऐसा ही है। LLM ने programming का मज़ा कम कर दिया है
  अब की routine “prompt लिखो → थोड़ा इंतज़ार करो → दोहराओ → code review” बन गई है
  code की संरचना समझ में आती है, लेकिन खुद हाथ से काम न करने की वजह से समझ की गहराई उथली हो जाती है
  सही training हो तो शायद यह संभव हो, लेकिन मैं अभी उस स्तर तक नहीं पहुँचा हूँ

  • मैं LLM से code नहीं लिखवाता, उसे सिर्फ़ idea brainstorming के लिए इस्तेमाल करता हूँ
    test code generation में यह उपयोगी है। एक अच्छा test मैं खुद लिखता हूँ, बाकी AI से बनवाकर समय बचाता हूँ
  • कम से कम LLM द्वारा बनाए गए code के लिए automated tests मैं खुद लिखता हूँ
    इससे उसकी सीमाएँ समझ में आती हैं, और फिर मैं बेहतर system design के साथ उसे दोबारा लिखता हूँ
    LLM का verbose code भी, पुराने developers द्वारा छोड़े गए अजीबोगरीब code से बेहतर लगता है

• लेख थोड़ा बढ़ा-चढ़ाकर लिखा गया है, लेकिन मैं भी सहमत हूँ
  LLM मौजूदा code को समझने और summarize करने, autocomplete, और non-developers द्वारा prototyping में उपयोगी है, लेकिन
  production code लिखने में इसका कभी इस्तेमाल नहीं करना चाहिए

• समाधान यह है कि model को grounding दिया जाए
  code में उसके लिए test-driven development (TDD) तरीका है
  पहले test लिखो, failure की पुष्टि करो, उसके कारण की जाँच करो, और फिर code लिखवाओ
  इससे code के लिए व्यवहार-आधारित specification बन जाती है, और बाद में इंसान या agent उसे reference document की तरह इस्तेमाल कर सकते हैं

• GitHub की README को अंत तक पढ़ने पर पता चला कि लेखक ने यह स्वीकार किया था कि code का 3/4 हिस्सा AI-generated है, फिर भी वह copyright claim कर रहा था
  जो content इंसान ने नहीं बनाया, उसे कानूनी रूप से copyright protection नहीं मिल सकती, इस बारे में पहले से judicial precedents मौजूद हैं