- हाल ही में टीम के कोड में यह तुरंत पहचान में आ जाता है कि कोई हिस्सा LLM-generated code है।
- ऐसा कोड project conventions को फॉलो नहीं करता, फिर भी साफ़ और अच्छे से टेस्टेड होता है।
- कई बार कई existing patterns और libraries को नज़रअंदाज़ करके सीधे नया implementation लिखा जाता है।
- सॉफ्टवेयर विकास में केवल गति पर ही केंद्रित रहने की प्रवृत्ति के बारे में चिंता बढ़ रही है।
- आखिर में महत्वपूर्ण चीज़ quality और consistency तथा maintainability ही होती है।
वाइब कोडिंग के संकेत
- टीम के हालिया कोड में से कुछ ऐसा दिखता है जो बहुत साफ़ और फीचरली परफेक्ट लगता है, लेकिन project-specific conventions न मानने से तुरंत पता चलता है कि यह LLM-generated है।
- उदाहरण के लिए, जब परियोजना में पहले से मौजूद data-fetching library होने के बावजूद सभी exception cases हैंडल करने वाली HTTP request implementation सीधे खुद लिखी जाती है।
- मौजूदा मॉड्यूल के utility functions दोबारा-तिबारा नए सिरे से बनते हैं, या module-level config override mechanism मौजूद होने पर भी global config बदल दिया जाता है।
- फंक्शनल तरीके से कोडिंग की संस्कृति बन जाने के बावजूद नया class-based code लिखा जाता है।
- ऐसा कोड वही शैली है जिसे किसी इंसान ने कई साल पहले शायद ही कभी लिखा होता।
मेंटेनेंस और सॉफ्टवेयर सिद्धांतों का महत्व
- सॉफ्टवेयर डेवलपमेंट में हमने लंबे समय तक लंबे समय तक maintainable patterns और standards बनाने में प्रयास किया है।
- कोई भी ऐसा कोड बना सकता है जो सिर्फ काम करे, लेकिन समय के साथ आसानी से maintain और बदलने में आसान कोड बनाना ही वास्तविक चुनौती है।
- मुद्दा सिर्फ फीचर implement करना नहीं, बल्कि समय के बाद भी संचालित रखा जा सकने वाला codebase होना है।
- “Vibe Coding” इन established philosophy और standards को कमजोर कर सकता है।
क्या गति ही सर्वोच्च प्राथमिकता होनी चाहिए?
- कॉफी शॉप में नया barista जल्दी में काम करते हुए कॉफी गिरा देता है—इस उदाहरण से यह दिखता है कि speed obsession सही परिणाम नहीं देता।
- आजकल development teams भी बहुत जल्दी नए software बनाने के चक्कर में quality गिरावट का सामना कर रही हैं।
- लोग असल में चाहते हैं कि थोड़ा देर से सही, लेकिन सही आउटपुट मिले।
- पहले यह लगता था कि सिर्फ speed पर फोकस करना शायद non-development roles की समस्या है, लेकिन साथ काम करने वाले developers में भी principles छोड़कर सिर्फ speed के पीछे भागने का चलन देखकर निराशा होती है।
सच में क्या चाहिए
- कोड को IDE में कैसे डाला गया यह मायने नहीं रखता।
- महत्त्वपूर्ण यह है कि डेवलपर का quality के प्रति संवेदनशील दृष्टिकोण हो।
- LLM को बड़ा technical innovation मानते हुए भी, असली software बनाना की जिम्मेदारी अभी भी developer पर ही रहती है।
- “बेहतर prompt लिखना”, “सही libraries चुनना”, “examples provide करना”, “छोटे फाइल यूनिट में काम करना” जैसे concrete existing principles को समझकर apply करने की सलाह दी गई।
- code quality और maintainability को केवल मॉडल के ‘weights’ पर छोड़ देने का जोखिम न लें।
अभी कोई टिप्पणी नहीं है.