क्यों AI ने सॉफ़्टवेयर इंजीनियरों की जगह नहीं ली है, और नहीं लेगा

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” के एक छोटे समूह में केंद्रित कर देगा।