LLMs मेरे सॉफ्टवेयर इंजीनियरिंग करियर को धीरे-धीरे खत्म कर रहे हैं और मुझे नहीं पता क्या करूँ
सॉफ्टवेयर करियर के कथित क्षरण
- कई वरिष्ठ इंजीनियर महसूस करते हैं कि उनकी मूल बढ़तें—डीबगिंग कौशल, डोमेन विशेषज्ञता, कोड गुणवत्ता—कमोडिटी बन रही हैं, क्योंकि LLMs अब बग्स को एक ही बार में हल कर सकते हैं, डिज़ाइन डॉक लिख सकते हैं, और काम करने वाले प्रोटोटाइप जनरेट कर सकते हैं।
- कुछ लोग प्रबंधन के इस दबाव की रिपोर्ट करते हैं कि “AI का ज्यादा उपयोग करो” और उत्पादकता को टोकन, कोड की पंक्तियों, या टिकटों की संख्या से मापा जाए, जिससे वे खुद को “स्लॉप फ़ार्म्स” के ओवरसीयर जैसा महसूस करते हैं, न कि निर्माताओं जैसा।
- अन्य लोग नोट करते हैं कि यह निराशावाद पहले की लहरों—ऑफशोरिंग, वेब, क्लाउड—के समय भी परिचित था, और तर्क देते हैं कि अच्छे इंजीनियरों की मांग बनी हुई है, बस अपेक्षाएँ बदल गई हैं।
डोमेन विशेषज्ञता बनाम जनरलिस्ट कौशल
- एक पक्ष: वित्त, कर, सिमुलेशन, सिग्नल प्रोसेसिंग, स्वास्थ्य सेवा, विनियमन जैसे क्षेत्रों में गहरी डोमेन जानकारी अब भी एक मजबूत मोआट है; LLMs अक्सर सूक्ष्म नियमों, किनारी मामलों, और संस्था-विशिष्ट प्रथाओं को चूक जाते हैं।
- विरोधी दृष्टिकोण: “डोमेन ज्ञान को प्रॉम्प्ट किया जा सकता है”; व्यापक इंजीनियरिंग सिद्धांत और एजेंट्स को ऑर्केस्ट्रेट करने की क्षमता, उस विशिष्ट विशेषज्ञता से अधिक महत्वपूर्ण होगी जिसे LLMs डॉक्स से पढ़ सकते हैं।
- कई लोग बताते हैं कि डोमेन विशेषज्ञों की अभी भी जरूरत होगी ताकि वे विनियमन की व्याख्या कर सकें, नियामकों के साथ बातचीत कर सकें, और कानूनी जोखिम का दायित्व ले सकें—ऐसे कार्य जो आसानी से मॉडलों को नहीं सौंपे जा सकते।
LLMs की क्षमताएँ और सीमाएँ
- भारी उपयोगकर्ता वास्तविक लाभ रिपोर्ट करते हैं: तेज़ रिफैक्टरिंग, जटिल बग खोज, टेस्ट जेनरेशन, YAML/config संपादन, डेटा इंजीनियरिंग PoCs, और यहाँ तक कि विज़ुअल सत्यापन के साथ गैर-तुच्छ गणित/भौतिकी कोड।
- उसी समय, फ्रंटियर मॉडल अभी भी:
- APIs, नियमों, तारीख़ों, या अनुपालन आवश्यकताओं के बारे में hallucinate करते हैं।
- अत्यधिक कोड बनाते हैं, लॉजिक की नकल करते हैं, और आर्किटेक्चरल पैटर्न को तब तक अनदेखा करते हैं जब तक उन्हें बहुत सख्ती से सीमित न किया जाए।
- अच्छी तरह जानी-पहचानी डोमेनों से बाहर धकेले जाने पर या specs अस्पष्ट होने पर बुरी तरह विफल हो जाते हैं।
- कई लोग “driver skill” पर ज़ोर देते हैं: अनुभवी devs को बड़े लाभ मिलते हैं; juniors और non-devs अक्सर नाज़ुक, असंगत सिस्टम बनाते हैं।
कोड गुणवत्ता, आर्किटेक्चर, और “AI स्लॉप”
- व्यापक चिंता है कि प्रबंधन C-ग्रेड “AI slop” को स्वीकार कर लेगा क्योंकि वह तेज़ और सस्ता है, भले ही technical debt और failure rates चुपचाप बढ़ जाएँ।
- अन्य लोग कहते हैं कि अब आर्किटेक्चर और स्पष्टता और भी महत्वपूर्ण हैं, क्योंकि एजेंट और इंसान दोनों सुव्यवस्थित सिस्टम पर बेहतर काम करते हैं, और LLMs को सावधानी से गाइड किया जाए तो वे पैटर्न लागू करने में मदद कर सकते हैं।
- कई लोग एक नया anti-pattern बताते हैं: एजेंट्स द्वारा एक ही बार में बनाए गए विशाल PRs, जिनके बाद लंबे, कष्टदायक human review cycles आते हैं जो अधिकांश speed gains को मिटा देते हैं।
सुरक्षा, विनियमन, और जवाबदेही
- विनियमित क्षेत्रों (fintech, healthcare, aviation, PCI, GDPR, AML) में, टिप्पणीकार बताते हैं कि LLMs:
- कानूनी आवश्यकताओं को गलत पढ़ते हैं या गढ़ लेते हैं।
- गैर-अनुपालक डिज़ाइन सुझाते हैं जो audits में विफल हो जाएंगे या गंभीर liability पैदा करेंगे।
- यहाँ सहमति: पूरी तरह autonomous agentic development लापरवाही है; इंसान को code और compliance की जिम्मेदारी में बने रहना चाहिए, और regulators/auditors अभी AI-ready नहीं हैं।
- कुछ लोग गंभीर घटनाओं के बाद भविष्य में “AI slop trials” की कल्पना करते हैं, जो deterministic tools + human review की ओर practice को सख्त कर सकते हैं।
आर्थिक और सामाजिक प्रभाव
- व्यापक डर है कि LLMs white-collar headcount को छोटा करेंगे: कम इंजीनियर अधिक product areas को सपोर्ट करेंगे, tech salaries नीचे सामान्य होंगी, और juniors बाहर रह जाएंगे।
- अन्य लोग तर्क देते हैं कि नई sectors और tools सामने आएँगे (जैसे पिछली tech shifts में हुआ), और software तथा automation की कुल मांग individual productivity से तेज़ी से बढ़ सकती है।
- कुछ लोग इसे “post-labor” परिदृश्यों तक बढ़ाते हैं, और सवाल उठाते हैं कि यदि अधिकांश knowledge work automate हो सकता है तो अरबों लोगों का आर्थिक सिस्टम कैसे चलेगा; सुझाव UBI से लेकर wealth taxes तक और “capital या land का मालिक बनो” तक हैं।
निपटने की रणनीतियाँ, मूल्य, और विकल्प
- सामान्य सलाह:
- AI को replacement नहीं, “power tool” की तरह अपनाएँ: harnesses सीखें, agents के लिए deterministic tools बनाएँ, architecture, testing, और system design पर ध्यान दें।
- अपनी पहचान “coder” से “engineer” या “problem solver” में बदलें: keystrokes के बजाय requirements, intent, और constraints पर काम करें।
- डोमेन विशेषज्ञता और soft skills (communication, risk judgment, legal/compliance के साथ काम, customer understanding) बनाए रखें या और गहरी करें।
- एक मुखर अल्पसंख्या नए work style (“vibe coding,” robots की निगरानी) से घृणा करती है और trades, woodworking, farming, या अन्य hands-on crafts में जाने पर विचार करती है—जबकि अन्य लोग चेतावनी देते हैं कि वे रास्ते भी कठिन, भीड़भाड़ वाले, और जोखिमपूर्ण हैं।
- कई लोग आनंद की हानि नोट करते हैं: coding अब craft कम और machine output को edit व supervise करने की प्रक्रिया ज़्यादा बन जाती है, जिससे burnout और mass disillusionment की चिंताएँ बढ़ती हैं, इससे पहले कि अन्य sectors AI के प्रभाव को पूरी तरह महसूस करें।