AI काम करने वाले उत्पाद नहीं बनाता, वह अभी भी आपका काम है
AI टूल्स विचार से पहले काम करने वाले prototype तक पहुँचने की गति को बहुत बढ़ा रहे हैं, लेकिन कई इंजीनियरों का तर्क है कि वे reliable, maintainable, “production-grade” software तक पहुँचने की कठिन यात्रा को बहुत कम नहीं करते। टिप्पणीकार AI-जनित कोड को छोटे ऐप्स और प्रयोग के लिए उपयोगी कच्चे माल या एक “supercharged IDE” की तरह देखते हैं, लेकिन अक्सर इसे गंदा, असंगत, और बड़े पैमाने पर विकसित करना कठिन मानते हैं—जब तक कि मज़बूत human architecture, testing, और domain expertise न हो। इसके पीछे एक व्यापक चिंता है: software development का industrialization, skill requirements में बदलाव, और यह अनिश्चितता कि AI ज़्यादातर developers को augment करेगा, उन्हें deskill करेगा, या अंततः पूरे roles को विस्थापित कर देगा।
AI की मदद का दायरा: प्रोटोटाइप बनाम प्रोडक्शन
- व्यापक सहमति है कि AI शून्य से पहले काम करने वाले संस्करण तक पहुँचने की प्रक्रिया को बहुत तेज़ कर देता है।
- कई लोगों का तर्क है कि यह “प्रोडक्शन‑ग्रेड” तक पहुँचने की राह को उसी तरह छोटा नहीं करता: यानी ऐसा सिस्टम जो परखा हुआ हो, बनाए रखने योग्य हो, टीम द्वारा अच्छी तरह समझा गया हो, और किनारे के मामलों में भी मज़बूत हो।
- कुछ लोग इसका विरोध करते हैं: अगर कोडिंग का समय 10× तेज़ हो जाता है, तो बाद के चरणों को भी लाभ मिलना चाहिए। जवाब में कहा जाता है: असली बाधाएँ कोड टाइप करना नहीं, बल्कि यूज़र फ़ीडबैक, आवश्यकताओं की खोज, और समझौता-निर्णय हैं।
“प्रोडक्शन‑ग्रेड” का मतलब क्या है
- इसे इस तरह बताया गया है:
- वास्तविक यूज़र्स की शिकायतों, किनारे के मामलों, और बदलती ज़रूरतों के बीच टिके रहना।
- टीम के भीतर सिस्टम की एक साझा मानसिक मॉडल को प्रतिबिंबित करना।
- लगातार आश्चर्यों या रिग्रेशन के बिना बनाए रखने योग्य होना।
- AI-जनित कोड स्थानीय रूप से ठीक दिख सकता है, लेकिन महीनों में यह वैश्विक रूप से असंगत आर्किटेक्चर बना देता है: सूक्ष्म डिज़ाइन ड्रिफ्ट, अत्यधिक जटिलता, और समझने में कठिन सिस्टम।
कोड गुणवत्ता, स्लॉप, और मेंटेनेंस
- कई लोगों की रिपोर्ट है:
- AI happy-path CRUD ऐप्स, आंतरिक टूल्स, और “फेंक देने योग्य” प्रयोगों के लिए बहुत अच्छा है।
- लंबे समय तक चलने वाले या जटिल सिस्टम तब बिगड़ जाते हैं जब उन्हें बड़े पैमाने पर agents चलाते हैं; AI कोड जोड़ने में अच्छा है, उसे हटाने/साफ़ करने में नहीं।
- बार-बार “समस्याएँ खोजो और ठीक करो” वाले लूप अंतहीन churn पैदा कर सकते हैं: एक हिस्से को ठीक करना और दूसरे को फिर से तोड़ देना।
- कुछ अन्य कहते हैं कि उद्योग भर में औसत micro-level code quality बेहतर हुई है, बेहतर patterns, linters, और AI-assisted bug fixing की वजह से, लेकिन macro-level coherence अभी भी चुनौती है।
लोग AI का प्रभावी उपयोग कैसे करते हैं
- सफल पैटर्न:
- AI को बहुत तेज़ सहायक या “code monkey” की तरह इस्तेमाल करना: architecture, domain modeling, और test design इंसान करते हैं; AI ज़्यादातर implementation लिखता है।
- पहले स्पष्ट योजना अनिवार्य करना, फिर चरणबद्ध implementation और सख़्त testing (unit, integration, property checks)।
- पूरी तरह agentic “चलने दो” workflows के बजाय छोटे/कमज़ोर models का उपयोग करना ताकि घनिष्ठ, इंटरैक्टिव सहायता मिले।
- विफलता वाले पैटर्न:
- गहरे review के बिना एक prompt प्रति PR “vibe coding।”
- गैर-इंजीनियरों द्वारा ऐसे AI-जनित सिस्टम शिप करना जिन्हें वे समझते नहीं, और फिर दूसरों से उन्हें “productionize” करने की अपेक्षा करना।
नौकरियाँ, भूमिकाएँ, और कार्यप्रणाली
- डर व्यक्तिगत कौशल से कम और इन बातों से ज़्यादा जुड़ा है:
- समान output के लिए कम भूमिकाओं की ज़रूरत।
- सॉफ़्टवेयर इंजीनियरों की पारंपरिक “craft + methodology” पहचान का क्षरण।
- कई लोग तर्क देते हैं कि AI-scale codebases के लिए नई कार्यप्रणालियों की ज़रूरत है (जैसे अधिक formal methods, algebraic data types, मज़बूत verification), न कि केवल पुरानी practices में “AI” जोड़ देना।
उत्पादों और अर्थव्यवस्था पर प्रभाव
- दिखाई देने वाले प्रभाव पर असहमति है:
- कुछ लोगों को नए (खासकर niche) टूल्स की बाढ़ दिखती है, विशेष रूप से healthcare और internal SaaS जैसे क्षेत्रों में।
- अन्य लोग कम-मेहनत वाले apps की बाढ़, खराब UX, और end-user के लिए कुछ ही स्पष्ट रूप से transformative उत्पाद नोट करते हैं।
- कुल मिलाकर: AI स्पष्ट रूप से code output और prototyping को बढ़ाता है; लेकिन क्या यह अभी उसके अनुरूप बेहतर products और टिकाऊ systems दे रहा है, यह विवादित है और अधिकांशतः अनसुलझा माना जाता है।