कोडिंग का समाधान नहीं हुआ है
यह दावा कि बड़े भाषा मॉडल्स ने “कोडिंग का समाधान” कर दिया है, इंजीनियरों से तीखी प्रतिक्रिया पाता है, जो बताते हैं कि छोटे स्निपेट लिखना या कोड पोर्ट करना, जटिल प्रणालियों को डिज़ाइन, सत्यापित, और बनाए रखने से बहुत अलग है। टिप्पणीकार AI को boilerplate, refactoring, और bug-finding के लिए बेहद शक्तिशाली accelerator मानते हैं, लेकिन कहते हैं कि agentic coding अक्सर नाज़ुक, फूला हुआ, या अपारदर्शी codebases बनाता है, जिनके लिए architecture, testing strategy, और accountability में अनुभवी इंसानों की आवश्यकता बनी रहती है। उभरती सहमति यह है कि AI ने code बनने का तरीका, खासकर routine tasks के लिए, नाटकीय रूप से बदल दिया है, लेकिन software engineering के कठिन हिस्सों या human judgment की जरूरत को समाप्त नहीं किया है.
क्या “कोडिंग” का समाधान हो गया है? अलग-अलग रुख
- एक पक्ष का दावा है कि “आज कोडिंग का समाधान हो चुका है”: अग्रणी LLMs अधिकांश भाषाओं में, खासकर CRUD, एल्गोरिदम, और रिफैक्टर के लिए, सामान्य मानव स्तर पर या उससे ऊपर कोड लिख, पढ़, पोर्ट, और अनुकूलित कर सकते हैं।
- दूसरे लोग कहते हैं कि यह बात बढ़ा-चढ़ाकर कही गई है: LLM का कोड अभी भी अच्छे मानव कोड से खराब है, खासकर आर्किटेक्चर, दीर्घकालिक रखरखाव, और गैर-कार्यात्मक आवश्यकताओं (NFRs) पर।
- कई लोग “छोटी कोडिंग” (फंक्शंस, एंडपॉइंट्स, पोर्ट्स) को काफी हद तक हल हुई मानते हैं, जबकि “सॉफ्टवेयर इंजीनियरिंग” (आवश्यकताएँ, डिज़ाइन, ट्रेड-ऑफ, जीवनचक्र) को अभी बहुत दूर।
वर्तमान मॉडलों की क्षमताएँ बनाम सीमाएँ
- सफलता की कहानियाँ: बड़े पोर्ट्स (जैसे, सैकड़ों हजार LOC TypeScript→Rust), भारी Agentic वर्कफ़्लोज़, बोर्ड-गेम इम्प्लीमेंटेशन, बड़े उत्पादकता लाभ (10×+ का दावा)।
- आलोचक बताते हैं कि ये अक्सर सीमित समस्याएँ होती हैं जिनमें मजबूत ऑरेकल होते हैं (मौजूदा व्यवहार, टेस्ट सूट), और यह साबित नहीं करतीं कि एंड-टू-एंड ग्रीनफील्ड सिस्टम डिज़ाइन हल हो गया है।
- दीर्घकालिक योजना, वैश्विक आर्किटेक्चर, और भविष्य-सुरक्षित API/type डिज़ाइन को बार-बार कमजोर बिंदु बताया जाता है।
गुणवत्ता, स्लॉप, और बड़े पैमाने पर कोड समीक्षा
- कई लोग बताते हैं कि AI कमजोर डेवलपर्स को बहुत अधिक मात्रा में खराब समझ वाला कोड बनाने में सक्षम बनाता है, जिससे मानव समीक्षा पर बोझ बढ़ जाता है (प्रति सप्ताह दशकों से सैकड़ों हजार LOC तक)।
- AI कोड समीक्षक अक्सर शैलीगत छोटी बातों पर नुक्ताचीनी करते हैं, लेकिन गहरे डिज़ाइन दोष चूक जाते हैं; मज़बूत मानव निगरानी के बिना “AI द्वारा AI की समीक्षा” खतरनाक मानी जाती है।
- कुछ संगठन पहले से ही AI-जनित PRs को लगभग बिना समीक्षा के मानते हैं, जिससे रिग्रेशन, ऑब्ज़र्वेबिलिटी का नुकसान, और सूक्ष्म शुद्धता/प्रदर्शन समस्याएँ पैदा होती हैं।
टेस्टिंग, निर्धारिता, और “समझ”
- AI समर्थक पक्ष: यदि आपके पास मजबूत स्पेक्स और विशाल स्वचालित टेस्ट हैं, तो इससे कम फर्क पड़ता है कि कोड किसने/क्या ने लिखा; टेस्ट और फ़ज़र्स भी AI-जनित हो सकते हैं।
- संदेहवादी पक्ष: फिर भी आपको यह परिभाषित करने के लिए इंसानों की ज़रूरत होती है कि क्या टेस्ट करना है, आवश्यकताओं की व्याख्या करने के लिए, और उन व्यवहारों को नोटिस करने के लिए जो निर्दिष्ट नहीं थे; वरना एजेंट केवल वही ऑप्टिमाइज़ करते हैं जो टेस्ट में है और बाकी सब बहकने देते हैं।
- “गैर-निर्धारिता” पर बहस: कुछ लोग कहते हैं कि LLM की स्टोकेस्टिसिटी मानव त्रुटि से बदतर नहीं है; अन्य लोग ज़ोर देते हैं कि अपारदर्शी, गैर-दोहराने योग्य जनरेशन का कोई समानांतर नहीं है जैसे कंपाइलरों या सिद्ध लाइब्रेरियों में।
जवाबदेही, जोखिम, और डोमेन
- व्यापक सहमति है कि जवाबदेही अभी भी मानव/संगठनात्मक ही रहती है; AI को दंडित नहीं किया जा सकता और न ही उसे उत्तरदायी ठहराया जा सकता है।
- कुछ का तर्क है कि अधिकांश एंटरप्राइज़ सॉफ्टवेयर कम-जोखिम है और AI स्लॉप “काफी अच्छा” है; दूसरे लोग नोट करते हैं कि भुगतान, लॉजिस्टिक्स, हेल्थकेयर प्रशासन जैसी साधारण प्रणालियाँ भी विफल होने पर वास्तविक दुनिया में नुकसान पहुँचा सकती हैं।
भूमिकाओं और कौशल पर प्रभाव
- नया “कौशल”: एजेंट्स का समन्वय करना, AGENTS.md और आर्किटेक्चर दस्तावेज़ लिखना, स्पेक्स और टेस्ट डिज़ाइन करना, और हाथ से कोड लिखने के बजाय मर्ज को गेट करना।
- “AI ओवरडोज़” और कौशल-क्षय की चिंताएँ: जूनियर लोग शायद कभी गहरी समस्या-समाधान क्षमता विकसित न कर पाएँ; सीनियर लोग महसूस करते हैं कि दशकों की कोडिंग विशेषज्ञता का मूल्य घट रहा है।
- कई लोग “कोड मंकी” भूमिकाओं में कमी देखते हैं, लेकिन फिर भी ऐसे लोगों की माँग बनी रहने की उम्मीद करते हैं जो सिस्टम, आवश्यकताओं, और ट्रेड-ऑफ्स पर तर्क कर सकें।