कृत्रिम बुद्धिमत्ता के युग में एक वाइबकोडर की उदासी

उपशीर्षक: कंप्यूटर साइंस के छात्र के रूप में वाइब कोडिंग की उदासी

आज मैंने क्लॉड कोड से पूछा: क्या मेरा तरीका सही है?

हमेशा की तरह, उसने विस्तृत तर्क देते हुए कहा, "आप अच्छा कर रहे हैं।" मैंने फिर संदेह भरी निगाहों से देखा और जवाब दिया, "मुझे पता है कि तुम्हें तारीफ करने के लिए प्रशिक्षित किया गया है, इसलिए यह ज्यादा सांत्वना नहीं देता।" लेकिन फिर भी, कोई सांत्वना न होने से यह बेहतर था, और मैंने उसकी विशिष्टता में गहराई से जाना। स्नातक के दिनों के विपरीत, अब कोई प्रोफेसर या वरिष्ठ नहीं हैं जो मुझे सही उत्तर बता सकें।

आजकल मैं कोड नहीं लिखता। मैं आवश्यकताओं को बताता हूँ और प्रगति का निरीक्षण करता हूँ।

खासकर आजकल मेरी चिंता डेवलपमेंट प्रक्रिया और गुणवत्ता को लेकर है। जैसे-जैसे सॉफ्टवेयर का पैमाना बढ़ता है, एआई द्वारा पढ़े जा सकने वाले संदर्भ की मात्रा आसानी से पार हो जाती है। संदर्भ के भीतर भी भ्रम होता है, और इतने बड़े कोड को एक छोटे एआई की मानसिक शक्ति के साथ लगातार नियंत्रित करना आसान काम नहीं है। 'संदर्भ इंजीनियरिंग' शब्द के बाद, हाल ही में 'हार्नेस इंजीनियरिंग' शब्द भी सामने आया है।

इसलिए, जब मुझे सोशल मीडिया पर कोई अच्छा संदर्भ मिलता है, तो मैं उसे पहले एआई को देता हूँ ताकि वह विश्लेषण कर सके कि Naia प्रोजेक्ट में क्या लागू किया जा सकता है, और फिर मैं उसे लागू करता हूँ। इस प्रक्रिया में, मैं अज्ञात शब्दों के बारे में पूछता हूँ और बहुत कुछ सीखता हूँ।

लेकिन मुझे हमेशा संदेह रहता है कि क्या मैं अच्छा कर रहा हूँ और क्या यह वास्तव में सबसे अच्छा तरीका है। इस संदेह का एक आधार था। एक दिन एआई ने कहा कि उसने समीक्षा की है, लेकिन वास्तव में फाइल पढ़ने का कोई निशान नहीं था। उसने कोड छोड़ दिया, गलत दायरा पकड़ा, और बिना देखे ही देखा हुआ बताया। जब मैंने उसे 2 बार साफ होने तक बार-बार समीक्षा करने को कहा, तो लगभग तीसरी बार में वह जवाब के पीछे यह जोड़कर पास कर देता है कि उसने समीक्षा की है और कुछ नहीं मिला। सोचकर देखें तो, LLM संरचना के कारण, यह एक विश्वसनीय उत्तर है, इसलिए उसने इसे जोड़ा होगा। 'क्या यह आमतौर पर यहीं खत्म हो जाता है?' वह खुद जवाब देता है और खुद ही इसे सच मान लेता है।

आज मैंने गूस्कीम का प्रेजेंटेशन सुना, जिन्होंने moai sdk विकसित किया है। मैंने उस प्रोजेक्ट को लिया और फिर से उसका विश्लेषण करवाया, और प्रोजेक्ट में सुधार के बिंदु पाए। #87इश्यू इस बार मैंने पाया कि वे EARS का उपयोग कर रहे थे। यह रोल्स-रॉयस द्वारा विकसित एक एयरोस्पेस आवश्यकता मानक है (IEEE RE'09), जिसे अमेज़न ने 2025 में एआई-नेटिव डेवलपमेंट के लिए अपनाया है। कहा जाता है कि यह एक संरचित व्याकरण के साथ उस समस्या को रोकता है जहाँ एआई 'पूर्ण' के मानदंड को प्रत्येक मुद्दे के लिए अलग-अलग व्याख्या करता है।

इन कार्यों को दोहराते हुए, मैं प्रोजेक्ट की एआई-आधारित डेवलपमेंट प्रक्रिया में लगातार सुधार करने की कोशिश कर रहा हूँ। मैंने jikime-adk, arXiv पेपर्स, Google Cloud के Dueling LLMs, और Thoughtworks के Spec-Driven Development का विश्लेषण और सुधार करवाया है। बेशक, यह सब इसलिए नहीं कि मैं यह सब जानता हूँ, बल्कि यह भी क्लॉड द्वारा विश्लेषण की गई सामग्री है।

मैंने LangChain के open-swe का विश्लेषण करवाया और ensure_no_empty_msg पैटर्न लागू किया, जो एआई को खाली प्रतिक्रियाओं के साथ समीक्षा करने से रोकता है। jikime-adk में, मैंने एक पैटर्न लागू किया जिसमें कमिट मैसेज में ## AI Context सेक्शन जोड़ा जाता है, ताकि एआई द्वारा लिए गए निर्णयों और पाए गए नुकसानों को रिकॉर्ड किया जा सके, जिससे सत्र टूटने पर भी git log एक पुनर्प्राप्ति स्रोत बन सके।

सामान्य तौर पर, हर कोई स्वतंत्र रूप से समान समस्याओं को हल कर रहा था।

लेकिन मुझे अभी भी संदेह है कि क्या यह तरीका सही है.. मुझे चिंता है कि कहीं यह फ्रेंकस्टीन न बन जाए, और एक विशेषज्ञ के रूप में यह अजीब लगता है। किसी भी तरह, कोई पाठ्यपुस्तक नहीं है और सबसे अच्छा होने का कोई पर्याप्त प्रमाण नहीं है।

सॉफ्टवेयर इंजीनियरिंग के वे सभी तरीके जिनका हम उपयोग करते थे, दशकों की विफलताओं के परिणामस्वरूप सामने आए हैं। एजाइल इसलिए आया क्योंकि वाटरफॉल लगातार विफल हो रहा था, और टीडीडी भी बिना परीक्षण के विकास करते समय लगातार समस्याओं के कारण सामने आया, इसलिए उनके पास आधार है।

लेकिन जो चीजें मैंने अब जोड़ी हैं, वे एक-दूसरे के लिए डिज़ाइन नहीं की गई हैं। एयरोस्पेस मानक, एक कोरियाई इंडी डेवलपर, और एक LangChain एजेंट एक ही सिस्टम में हैं।

इस चिंता के कारण, मैंने बाहरी शोधों को भी खंगालने को कहा। V-Bounce पेपर (arXiv 2408.03416) का तर्क है कि एआई युग में मानव की भूमिका कार्यान्वयनकर्ता से सत्यापनकर्ता में बदल जाती है। यह सच है, लेकिन केवल सिद्धांत है और कोई कार्यान्वयन नहीं मिला। Thoughtworks का Spec-Driven Development एक विशिष्ट उपकरण पर निर्भर करता है। एंथ्रोपिक के भीतर, वे कहते हैं कि क्लॉड कोड का 90% क्लॉड कोड द्वारा लिखा गया है, लेकिन उन्होंने कार्यप्रणाली का खुलासा नहीं किया है।

अंततः, जो लोग अब एआई के साथ गंभीरता से विकास कर रहे हैं, वे सभी अपने तरीके से काम कर रहे हैं। कोई मानक नहीं है।

इसलिए, आजकल मैं यह पता लगाने की कोशिश कर रहा हूँ कि इस फ्रेंकस्टीन के वास्तव में काम करने को कैसे मापा जाए। CI विफल होने पर भी मर्ज हो गया, और समीक्षा का टेक्स्ट था, लेकिन फाइल पढ़ने का कोई निशान नहीं था। कार्यप्रणाली डिज़ाइन की गई है, लेकिन इसे लागू नहीं किया जा सकता। ऐसा लगता है कि एक सिस्टम है, लेकिन मुझे नहीं पता कि यह काम करता है या नहीं। इसे सत्यापित करने का एकमात्र तरीका LLM द्वारा नहीं बल्कि कोड द्वारा बनाए गए ईमानदार आंकड़े उत्पन्न करना है, या यदि LLM का उपयोग किया जाता है, तो 'संख्याएँ' प्राप्त करनी होंगी जो सांख्यिकीय रूप से सुधार दिखाती हों। मुझे इस बात की चिंता है कि प्रोजेक्ट में बार-बार होने वाली विफलताओं का नियमित रूप से विश्लेषण करके एआई को सुधार का सुझाव देने दिया जाए, और संदर्भ और हार्नेस इंजीनियरिंग के प्रदर्शन मूल्यांकन के माध्यम से प्रगति को मापा जाए।

अभी तो मैं बस लगाम कसकर आगे बढ़ रहा हूँ। मुझे नहीं पता कि मैं कहाँ जा रहा हूँ, लेकिन उम्मीद है कि मैं अंधा नहीं हूँ। मैं लगाम बना रहा हूँ, लेकिन मैंने वास्तव में पहली बार घोड़े की सवारी की है। यह वाइब कोडिंग को पकड़े हुए हार्नेस जैसा लगता है।