- LLM ने कोड लिखने की गति बढ़ाई है, लेकिन software engineering की मूलभूत जटिलता को कम नहीं किया
- कोड generation आसान होने के साथ यह भ्रम फैल रहा है कि expertise की अब ज़रूरत नहीं रही, और कुछ संगठन इसी आधार पर engineers की छंटनी कर रहे हैं
- असली कठिनाई कोड लिखने में नहीं, बल्कि system design, specification, verification, और consistency बनाए रखने में है, और AI इस क्षेत्र का बोझ उल्टा और तेज़ कर देता है
- specification, test, और implementation के बीच mismatch (spec drift) तेज़ी से बढ़ सकता है, जिससे system reliability टूटने का जोखिम बढ़ता है
- 40 साल से अधिक के अनुभव में बार-बार दिखा एक पैटर्न है; 1990 के दशक के Visual Basic दौर में भी यही "expertise की ज़रूरत नहीं" वाला दावा उठा था, लेकिन अंत में engineering discipline की ज़रूरत फिर साबित हुई
- LLM design exploration और शुरुआती implementation को तेज़ करने का बेहतरीन tool है, लेकिन इसका उपयोग engineering discipline को replace करने के लिए नहीं, बल्कि उसे मजबूत करने के लिए होना चाहिए
उद्योग का खतरनाक भ्रम
- जैसे ही LLM कोड generate करने लगे, software industry में ऐसा माहौल बन गया कि software engineering की अब ज़रूरत ही नहीं रही
- architecture, specification, और careful verification जैसी disciplines को मानो बीते ज़माने की चीज़ समझा जा रहा है
- कुछ संगठनों में यह सोच पहले ही policy में बदल चुकी है, और AI की प्रगति का हवाला देकर engineers की बड़े पैमाने पर layoffs हो रहे हैं
- AI दरअसल गलत business decisions या market pressure से बचने का सबसे नया बहाना भर है
- AI को prompt देना धीरे-धीरे उस discipline के विकल्प के रूप में पेश किया जा रहा है जो software engineering को परिभाषित करती थी
इतिहास का दोहराया जाने वाला पैटर्न
- 40 साल से अधिक के करियर में एक ही पैटर्न बार-बार दिखा: नया tool आता है → घोषणा होती है कि मुश्किल समस्याएँ हल हो गईं → productivity उछलती है और प्रभावशाली demo दिखते हैं → headcount में कटौती → system complexity बढ़ती है → और आखिर में नतीजे उम्मीद से अलग निकलते हैं
- tools और दावे बदलते रहते हैं, लेकिन पैटर्न लगभग वही रहता है
विमान रखरखाव की उपमा
- aircraft maintenance में tools, computer diagnostics, digital manuals, और AI telemetry interpretation जैसी बड़ी प्रगति हुई है, फिर भी skilled technicians की ज़रूरत बनी हुई है
- commercial aircraft सैकड़ों लाख parts और हजारों interconnected subsystems वाले बेहद जटिल systems हैं
- समस्या का diagnosis केवल सही tool या checklist का पालन करना नहीं है, बल्कि वास्तविक operating conditions में system कैसे behave करता है, इस पर अनुभव और judgment चाहिए
- कोई भी airline सिर्फ tools बेहतर हो जाने के कारण trained mechanics को हटाकर gate agents से repair कराने का प्रस्ताव नहीं देगी
- लेकिन software industry लगभग यही बात अपने बारे में कह रही है
DIY बनाम पेशेवर systems
- hobby projects, छोटे personal apps, और नए ideas पर experiment करना बिल्कुल समस्या नहीं है; computing के इतिहास के कई सबसे रोचक ideas ऐसे ही प्रयोगों से आए हैं
- लेकिन professional software development एक पूरी तरह अलग श्रेणी है: payment processing, sensitive data storage, infrastructure management, और वे systems जिन पर लोग हर दिन निर्भर रहते हैं
- customers स्वाभाविक रूप से उम्मीद करते हैं कि system सही चले, evolve होने पर भी सही बना रहे, और जो लोग इसे बना रहे हैं वे system के काम करने के तरीके को समझते हों
- ये अपेक्षाएँ professional engineering की बुनियादी शर्तें हैं, और यहीं discipline व expertise अपरिहार्य हो जाते हैं
कोड कभी मुश्किल हिस्सा था ही नहीं
- software development में कोड लिखना ही सबसे कठिन हिस्सा है, यह बहुत पुरानी गलतफहमी है
- syntax टाइप करना हमेशा system building का सबसे कम रोचक हिस्सा रहा है; असली कठिन काम है system behavior तय करना, components के interaction का design करना, और complexity बढ़ने पर understandability बनाए रखना
- यह coding problem नहीं, बल्कि engineering problem है
- कोड उत्पादन में लगने वाला प्रयास कम होने से ये समस्याएँ खत्म नहीं होतीं; बस अब बड़े और अधिक जटिल systems को तेज़ी से बनाना संभव हो जाता है
- इसे productivity gain मानना भ्रम है: बोझ बस दूसरी जगह चला गया है
- code review और generated code को संभालने में लगने वाला cognitive load अक्सर कोड लिखने से भी बड़ा productivity drag बन जाता है
- अगर underlying behavior को पर्याप्त रूप से समझे बिना केवल गति बढ़ा दी जाए, तो यह सिर्फ उस बिंदु को तेज़ करता है जहाँ complexity असंभालनीय हो जाती है, और नतीजा फिर भी गलत होता है
यह पैटर्न पहले भी देखा गया: Visual Basic युग
- 1990 के दशक में Visual Basic को लेकर भी ऐसे ही वादे थे: programming का लोकतंत्रीकरण हो गया है और specialist knowledge की अब ज़रूरत नहीं रही
- वास्तव में, Visual Basic ने कई ऐसे applications बनाना संभव किया जो अन्यथा शायद कभी नहीं बनते
- लेकिन जैसे-जैसे systems बड़े और interconnected हुए, यह फिर स्पष्ट हुआ कि software artifacts बनाना और reliable systems engineer करना एक ही बात नहीं है
- आज हम उसी पैटर्न का और अधिक तीव्र संस्करण देख रहे हैं: अब बाधा सिर्फ application building की नहीं, बल्कि code production की भी कम हो गई है
- यहीं से यह आकर्षक विश्वास पैदा होता है कि expertise अब ज़रूरी नहीं रही
Alignment की समस्या
- reliable software उस alignment पर निर्भर करता है जिसकी engineering के बाहर बहुत कम चर्चा होती है
- system की शुरुआत behavior के एक idea से होती है → उसे specification में document किया जाता है → engineers specification को tests और production code में बदलते हैं
- किसी system की long-term reliability के लिए specification, tests, और implementation — इन तीनों का हर समय aligned रहना ज़रूरी है
- जैसे ही ये तीनों अलग होने लगते हैं, system धीरे-धीरे अपनी integrity खोने लगता है
- specification ऐसे behavior का वर्णन करने लगती है जो अब implement ही नहीं है
- tests behavior के केवल कुछ हिस्सों को verify करते हैं और बाकी छूट जाता है
- बाद में जुड़ने वाले engineers code पढ़कर system behavior का अनुमान लगाते हैं, जबकि वह code मूल design को दर्शाता भी हो सकता है और नहीं भी
- समय के साथ ये अनुमान जमा होते जाते हैं, और अंत में system ऐसा बन जाता है जिसे वास्तव में कोई भी पूरी तरह नहीं समझता
- इस घटना को "spec drift" कहा गया है: system का विवरण और system स्वयं धीरे-धीरे एक-दूसरे से अलग हो जाते हैं
- code बदल गया, लेकिन specification वैसी ही रही
- specification evolve हुई, लेकिन tests स्थिर रहे
- behavior धीरे-धीरे बदलता गया, और किसी को भी भरोसे से नहीं पता कि मूल intent क्या था
- alignment टूटने पर reliability लंबे समय तक टिक नहीं सकती
AI drift को तेज़ करता है
- LLM code production को नाटकीय रूप से तेज़ कर देते हैं, और यही उनकी सबसे बड़ी ताकत होने के साथ जोखिम का बिंदु भी है
- जब कोड उसके आसपास की engineering discipline से तेज़ी से बनने लगता है, तो spec drift पैदा करने वाली ताकत भी तेज़ हो जाती है
- जो बदलाव कभी careful thinking और manual implementation मांगते थे, वे अब कुछ ही सेकंड में हो सकते हैं
- system के पूरे section को rewrite किया जा सकता है इससे पहले कि कोई यह जाँच सके कि behavior अभी भी specification के अनुरूप है या नहीं
- code अक्सर ठीक-ठाक, compilable, readable दिखता है, और शायद existing tests भी पास कर लेता है, लेकिन system को नियंत्रित करने वाला alignment पहले ही गायब हो चुका हो सकता है
- जो चीज़ productivity जैसी दिखती है, वह वास्तव में पहले से कहीं तेज़ misalignment की दिशा में बढ़ने की क्षमता हो सकती है
जहाँ AI वास्तव में मददगार है
- LLM कोई गलती नहीं हैं; सोच-समझकर इस्तेमाल किए जाएँ तो वे engineers के system explore करने और design करने के तरीके को नाटकीय रूप से बेहतर बना सकते हैं
- जिन क्षेत्रों में वे खास तौर पर मजबूत हैं: समस्या पर reasoning, design alternatives का exploration, complex systems का सार निकालना, और implementation के शुरुआती चरणों को तेज़ करने वाले drafts तैयार करना
- जिन क्षेत्रों में वे कमजोर हैं: वे काम जिनमें समय के साथ कठोर discipline और consistency चाहिए
- specification, tests, और implementation के बीच alignment बनाए रखना अब भी engineering responsibility है; कोई tool इस जिम्मेदारी की जगह नहीं ले सकता, सिर्फ मदद कर सकता है
- असली अवसर LLM का उपयोग engineering process को चुपचाप replace करने में नहीं, बल्कि उसे मजबूत करने में है
Conversational software engineering
- LLM ने जो दिलचस्प संभावना खोली है, उनमें से एक यह है कि software engineering का कुछ हिस्सा अधिक conversational हो सकता है
- दशकों तक system design tools काफ़ी rigid रहे हैं: specifications documents में, architecture diagrams में, और वहाँ तक पहुँचने वाली reasoning meetings और hallway conversations में खो जाती थी
- LLM के साथ engineers ideas को interactive तरीके से explore कर सकते हैं, assumptions को test कर सकते हैं, और design work को स्वाभाविक बातचीत के अधिक करीब तरीके से कर सकते हैं
- लेकिन conversation engineering नहीं है: conversation ideas explore करने का तरीका है, जबकि engineering तब शुरू होती है जब ideas को verified, tested, और maintainable रूप में capture किया जाता है
- अगली पीढ़ी के engineering tools के सामने चुनौती यह है कि इन दोनों दुनियाओं को कैसे जोड़ा जाए, बिना उस discipline को खोए जिसकी complex systems को ज़रूरत होती है
Expertise अब भी मायने रखती है
- professional software को आज भी ऐसे engineers की ज़रूरत है जो वे systems वास्तव में कैसे काम करते हैं, यह समझते हों
- tools development को तेज़ कर सकते हैं, लेकिन complex systems को design, reason, और maintain करने के लिए ज़रूरी expertise को खत्म नहीं कर सकते
- industry इस बात को भूल जाने के खतरनाक रूप से करीब पहुँच गई है
- LLM अनुभवी engineers को बहुत अधिक productive बना सकते हैं, लेकिन reliable systems बनाने के लिए आवश्यक engineering discipline की जगह नहीं लेते
- इन tools का उपयोग पूजा की तरह नहीं, बल्कि प्रभावी ढंग से किया जाना चाहिए
अभी कोई टिप्पणी नहीं है.