क्यों AI ने सॉफ़्टवेयर इंजीनियरों की जगह नहीं ली है, और नहीं लेगा
AI coding tools और agents सॉफ़्टवेयर निर्माण को तेज़ी से बढ़ा रहे हैं, जिससे गैर-इंजीनियर भी ऐप्स ship कर पा रहे हैं और छोटी टीमें या solo developers वह कर पा रहे हैं जिसके लिए पहले बड़े समूह चाहिए होते थे। टिप्पणीकारों का तर्क है कि यह मुख्यतः development की “execution” layer को automate करता है, जबकि क्या बनाना है तय करना, correctness सुनिश्चित करना, edge cases, security, maintenance, और accountability जैसे कठिन काम अभी भी मानव विशेषज्ञता मांगते हैं—हालाँकि संभवतः कम, लेकिन अधिक सक्षम engineers से। व्यापक सहमति है कि बहुत-सी low-skill या केवल “ticket-shuffling” भूमिकाएँ दबाव में आएँगी और software work और अधिक commoditized होगा, लेकिन इस बात पर तीखा मतभेद है कि job losses की भरपाई के लिए software demand कितनी दूर तक बढ़ सकती है।
LLM कोडिंग की क्षमताएँ और सीमाएँ
- LLM अब पूरे ऐप्स (वेब, मोबाइल, infra-as-code) की नींव रख सकते हैं और गैर-तुच्छ कार्यों को संभाल सकते हैं (फर्मवेयर रिवर्स इंजीनियरिंग, सुरक्षा स्क्रिप्ट्स, Terraform/Ansible, Frida, आदि)।
- वे boilerplate, wiring, और “text-shaped” backend समस्याओं में उत्कृष्ट हैं; लेकिन सूक्ष्म UX, दृश्य सौंदर्यबोध, और edge cases में कहीं कमजोर हैं।
- मॉडल अभी भी बुनियादी तार्किक गलतियाँ करते हैं (जैसे dates को string-sorting करना) और बिना समझे आत्मविश्वास से गलत रास्तों पर चलते रहते हैं।
- प्रभावी उपयोग के लिए मजबूत मानव मार्गदर्शन, परीक्षण, और समीक्षा की आवश्यकता होती है; बिना मार्गदर्शन वाला “vibecoding” बड़ी मात्रा में नाज़ुक, निम्न-गुणवत्ता कोड पैदा करता है।
Greenfield बनाम रखरखाव और जटिलता
- अकेले डेवलपर्स और छोटी टीमों के लिए, LLM पहले असंभव रहे 50–100k LOC प्रोजेक्ट्स को संभव बना रहे हैं; समय टाइप करने से हटकर योजना, पढ़ने, और QA की ओर शिफ्ट हो रहा है।
- बड़े सिस्टमों में (कई इंजीनियर, सैकड़ों फीचर्स), जटिलता, coupling, और अदृश्य constraints हावी हो जाते हैं। LLM अभी इसे अच्छी तरह नहीं संभालते।
- Greenfield prototypes काफी हद तक स्वचालित किए जा सकते हैं; दीर्घकालिक रखरखाव, legacy systems के साथ integration, और security कठिन और मानव-प्रधान बने रहते हैं।
प्रतिस्थापन बनाम संवर्धन
- कुछ लोग छोटे startups और pet projects के लिए “कई developers” के ठोस प्रतिस्थापन की रिपोर्ट करते हैं; अन्य कहते हैं कि ये net-new projects हैं जिन्होंने वैसे भी engineers को कभी hire नहीं किया होता।
- कई लोग AI को force multiplier मानते हैं: एक अच्छा engineer + agents, खासकर नए projects पर, बहुत बड़ी औसत टीम की जगह ले सकते हैं।
- आम सहमति: कमजोर/“ticket shuffler” developers सबसे अधिक जोखिम में हैं; मजबूत engineers जो agents के लिए specify, review, debug, और architecture बना सकते हैं, उन्हें अधिक leverage मिलता है।
निर्णय, domain knowledge, और जवाबदेही
- मूल मूल्य अब इस ओर शिफ्ट होता है:
- क्या बनाना है, यह तय करना (product thinking, domain knowledge)।
- जो ship हो रहा है, उसकी verification करना और उसकी जवाबदेही लेना (tests, security, compliance)।
- codebase और business context को इतनी गहराई से समझना कि trade-offs को navigate किया जा सके।
- गैर-तकनीकी कर्मचारी पहले से AI के साथ internal tools बना रहे हैं, लेकिन जल्दी ही complexity की दीवारों से टकराते हैं और व्यावहारिक रूप से undertrained developers बन जाते हैं।
- संगठनों को अभी भी एक human “fall guy” चाहिए, और वे legal/operational responsibility को अभी AI पर नहीं डाल सकते; vendors liability guarantees नहीं देते।
आर्थिक और श्रम-बाज़ार प्रभाव
- कुछ लोग “3D printer/CNC moment” की उम्मीद करते हैं: बहुत अधिक छोटे bespoke tools, पारंपरिक dev roles कम, औसत वेतन कम, और शीर्ष performers के लिए अधिक वेतन।
- अन्य लोग ऐतिहासिक पैटर्न की ओर इशारा करते हैं: automation कुल software demand को घटाने के बजाय बढ़ाने की प्रवृत्ति रखती है, हालांकि विशिष्ट roles और titles बदलते हैं।
- चिंता है कि AI coding को commoditize कर देगा, mid-skill roles को खोखला कर देगा, और rewards को उच्च-कौशल “AI shepherds” के एक छोटे समूह में केंद्रित कर देगा।