AI के पास बुद्धि नहीं है और आपके पास भी नहीं होगी
इंजीनियर इस पर बहस कर रहे हैं कि क्या AI‑जनित कोड अनिवार्य रूप से एक असंभालने योग्य गड़बड़ बन जाएगा, या यह बस खराब आर्किटेक्चर और tech debt जैसी पुरानी मानवीय समस्याओं को ही दर्शाता है। कई लोगों का तर्क है कि large language models मजबूत specs, tests, और “agent scaffolding” के साथ औसत डेवलपर्स की बराबरी कर सकते हैं या उनसे आगे निकल सकते हैं, लेकिन चिंता यह है कि उन पर अत्यधिक निर्भरता से संस्थागत ज्ञान, जूनियर डेवलपर्स के कौशल, और वर्षों में समझदारी भरे architectural tradeoffs लेने की क्षमता कमजोर हो जाएगी। दूसरे लोग जवाब देते हैं कि coding स्वयं एक सस्ता, disposable commodity बनती जा रही है, और असली अंतर यह होगा कि टीमें systems कैसे design करती हैं, constraints कैसे परिभाषित करती हैं, और AI-saturated workflow में short-term velocity और long-term code health के बीच संतुलन कैसे बनाती हैं।
AI‑जनित कोड की गुणवत्ता और “वाइब कोडिंग”
- कई लोगों का मानना है कि LLM/एजेंट द्वारा लिखा गया कोड अत्यधिक जटिल, असंगत, और छिपे हुए बग्स के प्रति संवेदनशील होता है, खासकर जब “do X” जैसे अस्पष्ट प्रॉम्प्ट्स के साथ इस्तेमाल किया जाए।
- अन्य लोग तर्क देते हैं कि यह मूलतः औसत दर्जे के मानवीय कोड से अलग नहीं है; AI बस फीचर डिलीवरी और कोड रॉट, दोनों को तेज़ कर देता है।
- कई लोग नोट करते हैं कि AI की गुणवत्ता बाधाओं, उदाहरणों, और समीक्षा से बहुत प्रभावित होती है; बिना मार्गदर्शन वाले एजेंट पूर्वानुमेय रूप से घटिया आउटपुट देते हैं।
मेंटेनेबिलिटी, मेट्रिक्स, और आर्किटेक्चर
- थ्रेड इस बात पर सहमत है कि दीर्घकालिक मेंटेनेबिलिटी को मापना कठिन है; सामान्य मेट्रिक्स (cyclomatic/cognitive complexity, SonarQube) शोरयुक्त होते हैं और आसानी से गेम किए जा सकते हैं।
- कुछ लोग सुझाते हैं कि incremental edits के लिए RL environments और benchmarks मॉडलों को मेंटेनेबिलिटी की ओर प्रशिक्षित कर सकते हैं, लेकिन यह अभी शुरुआती चरण में है।
- उच्च-स्तरीय आर्किटेक्चर और boundary design वे क्षेत्र हैं जहाँ एजेंट अभी सबसे अधिक विफल होते हैं; टूल्स low-level नियम लागू कर सकते हैं, लेकिन अच्छा सिस्टम डिज़ाइन नहीं।
सीखना, बुद्धि, और संस्थागत ज्ञान
- एक बार-बार उभरती चिंता यह है कि ऐसे डेवलपर्स जिन्होंने “2025 के बाद से कोड नहीं लिखा” हो, वे शायद कभी गहरी intuition नहीं बना पाएँगे और AI पर निर्भर हो जाएँगे।
- तुलना manufacturing के outsourcing से की जाती है, जिससे औद्योगिक know-how खो गया; AI भी इसी तरह software craftsmanship और domain understanding को कमज़ोर कर सकता है।
- दूसरे लोग जवाब देते हैं कि मनुष्य पहले से ही शायद ही कभी mastery तक पहुँचते हैं, और कोड के बारे में “wisdom” अक्सर tacit होती है तथा इंसानों को सिखाने के लिए भी formalize करना कठिन होता है।
लोग वास्तव में AI का उपयोग कैसे कर रहे हैं
- कुछ लोग बड़ी productivity gains की रिपोर्ट करते हैं: agents को अधिकांश implementation के लिए इस्तेमाल करना, फिर specs, architecture, और tests पर ध्यान देना; कुछ घंटों में बड़े refactors करना; अधिक exhaustive testing और validation generate करना।
- अन्य लोगों को लगता है कि वे models को बहुत ज़्यादा “nag” करने और अजीब डिज़ाइनों को ठीक करने में समय बिताते हैं, इसलिए critical paths को हाथ से कोड करना पसंद करते हैं।
- उल्लेखित तकनीकों में शामिल हैं: AGENTS.md conventions, rich code comments को “infrastructure‑free memory” के रूप में, multi-agent cross-review, और संचित slop को कम करने के लिए explicit refactoring passes।
प्रोत्साहन, श्रम, और संस्कृति
- कई लोग manager-level focus on velocity और time-to-market को AI slop सहने और उन engineers को दंडित करने के लिए दोषी ठहराते हैं जो quality सुधारने के लिए गति धीमी करते हैं।
- जब applicants AI का उपयोग करके अपनी कमजोर बुनियाद को छिपा सकते हैं, तब hiring और evaluation अधिक कठिन हो जाते हैं।
- कुछ लोगों का तर्क है कि code quality की परवाह करना मुख्यतः culture और incentives की समस्या है, न कि tooling की।
भविष्य के बारे में भविष्यवाणियाँ
- एक धड़ा सर्वव्यापी AI की उम्मीद करता है, संभवतः पूरी तरह agentic pipelines के साथ; “NO-AI” नीतियाँ उन्हें niche या अस्थिर लगती हैं।
- दूसरा धड़ा “NO-AI” (या AI-minimal) shops को premium या safety-driven niche के रूप में देखता है, खासकर high-stakes domains में।
- दिशा को लेकर सर्वसम्मति स्पष्ट नहीं है: कुछ लोग AI coding quality के तेज़ी से सुधरने की उम्मीद करते हैं; अन्य लोग maintainability और context limits जैसी मूल समस्याओं में ठहराव देखते हैं।