AI को अधिक इंजीनियरिंग अनुशासन की मांग करनी चाहिए। कम नहीं
AI-सहायता प्राप्त कोडिंग कोड बनाने की लागत को नाटकीय रूप से घटा रही है, जिससे चिंता बढ़ रही है कि जैसे-जैसे कोड की मात्रा बढ़ेगी, इंजीनियरिंग कठोरता और maintainability प्रभावित हो सकती है। टिप्पणीकारों का तर्क है कि LLMs इम्प्लीमेंटेशन को तेज़ कर सकते हैं और अधिक महत्वाकांक्षी प्रोजेक्ट्स संभव बना सकते हैं, लेकिन इसके लिए अपारदर्शी तकनीकी ऋण के अभूतपूर्व संचय को रोकने हेतु अधिक मजबूत upfront design, documentation, testing, और evaluation practices चाहिए। इस बात पर व्यापक संदेह है कि AI जल्द ही अनुभवी इंजीनियरों की जगह ले लेगा; इसके बजाय, कई लोग अपेक्षा करते हैं कि भूमिकाएँ architecture, verification, और AI-जनित परिवर्तनों की गुणवत्ता तथा intent को प्रबंधित करने की दिशा में बदलेंगी.
लेख पर समग्र प्रतिक्रिया
- कई लोगों को यह लेख शब्दाडंबरपूर्ण, इधर-उधर भटकता हुआ, और ठोस निष्कर्षों से हल्का लगा; कुछ को “AI slop” जैसी लेखन-शैली का संदेह हुआ।
- एक अल्पसंख्यक को केंद्रीय विचार पसंद आया (AI ⇒ अधिक अनुशासन, कम नहीं), लेकिन उन्हें तर्क उलझा हुआ या ढुलमुल लगा।
- पाठकों ने “AI अस्तित्वगत रूप से महत्वपूर्ण है” वाली बयानबाज़ी और समझौतों के प्रति हाथ-हिलाऊ रवैये के बीच तनाव नोट किया।
कोड बनाम स्पेक्स, डॉक्स, और प्रॉम्प्ट्स
- एक मुख्य बहस: क्या कोड “प्राथमिक आर्टिफैक्ट” बना रहना चाहिए, या क्या स्पेक्स, टेस्ट, और प्रॉम्प्ट्स समीक्षा की मुख्य वस्तुएँ बनें, जबकि कोड को डिस्पोज़ेबल माना जाए?
- कई लोगों का तर्क है कि कोड ही एकमात्र अस्पष्टता-रहित, निष्पादनयोग्य स्पेसिफिकेशन है, इसलिए उसे केंद्र में रहना चाहिए।
- अन्य लोग ज्ञान को डिज़ाइन डॉक्स, ADRs, टेस्ट्स, और प्रॉम्प्ट हिस्ट्रीज़ में स्थानांतरित करने का समर्थन करते हैं, ताकि AI कोड को केवल एक इम्प्लीमेंटेशन डिटेल के रूप में पुनः उत्पन्न कर सके।
- संशयवादी चेतावनी देते हैं कि मोटे स्तर की एब्स्ट्रैक्शन्स और LLM “स्पेक्स” अभी इतनी भरोसेमंद नहीं हैं कि विस्तृत कोड समीक्षा छोड़ी जा सके।
AI कोड गुणवत्ता, “slop,” और सत्यापन
- प्रबल भावना है कि AI काम करने वाला, लेकिन अजनबी-सा, अत्यधिक जटिल, या नाज़ुक कोड बनाता है जिसे पढ़ना और मेंटेन करना दर्दनाक होता है।
- समर्थक जवाब देते हैं कि अच्छी डिज़ाइन, सीमाओं, और टेस्ट्स के साथ AI उच्च-गुणवत्ता वाला, रक्षात्मक कोड बना सकता है और गैर-नवीन काम को तेज़ कर सकता है।
- व्यापक सहमति है कि अब बाधा कोड जनरेशन नहीं, बल्कि मूल्यांकन और सत्यापन है।
- कुछ लोग ऐसे सिस्टम की कल्पना करते हैं जो अधिकांश कोड को इंसानों के पढ़ने के बजाय प्रॉपर्टीज़ और टेस्ट्स से सत्यापित करें; अन्य को संदेह है कि स्थिर, मानव-समझने योग्य कोड के बिना यह वास्तविक रूप से संभव होगा।
कोड की पंक्तियाँ, उत्पादकता, और तकनीकी ऋण
- HN का लंबे समय से चला आ रहा मानक: कोड हटाना वरिष्ठता का संकेत है। कई लोग AI युग में इस विचार का और मजबूती से बचाव करते हैं।
- AI बड़े PRs और “ऊपरी तौर पर विश्वसनीय” कोड व डॉक्यूमेंटेशन की बाढ़ लाता है, जिससे यह पहचानना कठिन हो जाता है कि वास्तव में सिस्टम को कौन समझता है।
- LoC या PR count को उत्पादकता मेट्रिक के रूप में इस्तेमाल करना अब विशेष रूप से टूट चुका माना जाता है।
- कई टिप्पणियाँ AI-जनित कोड और दस्तावेज़ों से तकनीकी ऋण के एक विशाल नए रूप की भविष्यवाणी करती हैं, जिसकी तुलना asbestos या “technical bankruptcy” से की गई है।
अनुशासन, भूमिकाएँ, और प्रोत्साहन
- कई लोग सहमत हैं कि AI अधिक अनुशासन की माँग कर सकता है: बेहतर स्पेक्स, टेस्ट्स, observability, और provenance (जैसे, प्रॉम्प्ट्स और डिज़ाइन-इरादे को कैप्चर करना)।
- साथ ही, AI के कारण बिना समझे उत्पादक दिखना आसान हो जाता है, खासकर “AI everywhere” इस्तेमाल करने के कार्यकारी दबाव के तहत।
- कुछ को उम्मीद है कि SWE भूमिकाएँ विलुप्त होने के बजाय architecture, documentation, और test design की ओर शिफ्ट होंगी; अन्य का तर्क है कि unskilled + AI एक नया सिस्टमिक जोखिम है, खासकर juniors के लिए।