सुर्खियां हमें बताती रहती हैं कि AI सॉफ्टवेयर डेवलपर्स को अप्रचलित बना देगा। मुझे इस पर विश्वास नहीं है। असली जोखिम यह नहीं है कि मशीनें

सुर्खियाँ हमें बताती रहती हैं कि AI सॉफ्टवेयर डेवलपर्स को बेकार कर देगा। मुझे इस पर विश्वास नहीं है। असली जोखिम यह नहीं है कि मशीनें इंजीनियरिंग का नियंत्रण ले लेंगी। जोखिम यह है कि इंजीनियर सोचने का कठिन काम करना बंद कर देंगे।

सॉफ्टवेयर कभी भी केवल सिंटैक्स टाइप करने के बारे में नहीं था। यह हमेशा जटिलता को अपने दिमाग में रखने, विफलता के तरीकों (failure modes) को समझने और तब समझौते (trade-offs) करने के बारे में था जब कोई भी विकल्प पूर्ण न हो। AI ने उस गति को बदल दिया है जिस गति से हम कोड लिखते हैं, लेकिन इसने यह नहीं बदला है कि हमें 'ह्यूमन इन द लूप' (humans in the loop) की आवश्यकता क्यों है। बल्कि, इसने स्पष्ट सोच को और अधिक मूल्यवान और दुर्लभ बना दिया है।

पहला ड्राफ्ट इंजीनियरिंग नहीं है

मैं बड़ी संख्या में जूनियर डेवलपर्स को ChatGPT या Claude को उस सीनियर इंजीनियर की तरह व्यवहार करते हुए देख रहा हूँ जो बगल वाली कुर्सी पर बैठा हो। वे टिकट का विवरण पेस्ट करते हैं, उत्तर कॉपी करते हैं, टेस्ट चलाते हैं और कमिट कर देते हैं। यदि यह कंपाइल हो जाता है, तो कार्य पूरा मान लिया जाता है। यह लूप तेज़, बाधा रहित और खतरनाक है।

AI का उपयोग करना समस्या नहीं है। मैं इसका उपयोग करता हूँ। मेरे जानने वाले अधिकांश उत्पादक इंजीनियर इसका उपयोग करते हैं। समस्या तब शुरू होती है जब AI कमरे में एकमात्र इंजीनियर बन जाता है। केवल इसलिए किसी समाधान को स्वीकार कर लेना क्योंकि वह काम कर रहा है, इंजीनियरिंग नहीं है। यह अपने निर्णय (judgment) को एक ऐसे मॉडल को सौंपना है जो आपके उपयोगकर्ताओं, आपके व्यावसायिक बाधाओं (business constraints), या पिछली बार जब आपका स्टैक रात के 2 बजे क्रैश हुआ था, उसे नहीं समझता।

लार्ज लैंग्वेज मॉडल्स (LLMs) अनिश्चित रूप से आत्मविश्वास के साथ उत्तर देते हैं, भले ही वे पूरी तरह से गलत हों। एक इंजीनियर ने AI से एक स्केलेबल आर्किटेक्चर डिजाइन करने के लिए कहा। मॉडल ने एक विस्तृत, आधिकारिक प्रस्ताव दिया जो पूरी तरह से एक ऐसे फीचर के इर्द-गिर्द बना था जो वास्तविक उत्पाद में मौजूद ही नहीं था। यह सही लग रहा था। यह आंतरिक रूप से सुसंगत था। लेकिन यह बेकार था। खतरा केवल यह नहीं है कि AI मतिभ्रम (hallucinations) पैदा करता है। खतरा यह है कि अब बहुत से लोग उन मतिभ्रमों पर भरोसा करते हैं क्योंकि उनके पास झूठ पकड़ने के लिए आवश्यक संदर्भ (context) नहीं रह गया है।

आप घर्षण (Friction) से सीखते हैं

जब मैं इस बारे में सोचता हूँ कि मैं एक जूनियर डेवलपर से एक ऐसा व्यक्ति कैसे बना जो किसी सिस्टम की जिम्मेदारी ले सके, तो मुझे वह सिंटैक्स याद नहीं आता जिसे मैंने रटा था। मुझे आउटेज (outages) याद आते हैं। मुझे वे धीमी क्वेरीज़ याद आती हैं जिन्हें मुझे हाथ से ट्रेस करना पड़ा था, वे रेस कंडीशंस (race conditions) जो केवल प्रोडक्शन लोड के तहत दिखाई देती थीं, और वे डिप्लॉयमेंट जो इसलिए टूट गए क्योंकि मेरा लोकल एनवायरनमेंट वास्तविक दुनिया जैसा बिल्कुल नहीं था।

डिबगिंग (Debugging) ही वह जगह है जहाँ सीखना होता है। जब आप कोड को मैन्युअल रूप से स्टेप-बाय-स्टेप देखते हैं, तो आप देखते हैं कि सिस्टम वास्तव में क्यों विफल होते हैं। आप खोजते हैं कि बाधाएं (bottlenecks) कहाँ आती हैं। आप सीखते हैं कि जब आप दस उपयोगकर्ताओं वाले डेमो से दस हजार समवर्ती अनुरोधों (concurrent requests) को संभालने वाले प्रोडक्शन सिस्टम पर जाते हैं, तो आर्किटेक्चर कैसा व्यवहार करता है। आप अपनी रगों में यह बात उतार लेते हैं कि प्रोडक्शन एक अच्छी तरह से स्क्रिप्ट किए गए डेमो से कैसे अलग होता है।

वह सारा ज्ञान किसी जनरेट किए गए उत्तर को स्वीकार करने से नहीं आता। वह समस्या से जूझने से आता है। यदि AI हर संघर्ष को खत्म कर देता है, यदि यह कोड लिखता है, बग्स ठीक करता है और विफलताओं को समझाकर टाल देता है, तो डेवलपर्स की अगली पीढ़ी अपनी वरिष्ठता (seniority) कैसे हासिल करेगी? अनुभव कोई ऐसा सर्टिफिकेट नहीं है जिसे आप डाउनलोड कर सकें। यह वह 'स्कार टिश्यू' (scar tissue) है जो आप प्रोडक्शन की घटनाओं और टूटे हुए डिप्लॉयमेंट से बनाते हैं। यदि आप घर्षण को हटा देते हैं, तो आप विकास (growth) को भी हटा देते हैं।

निर्णय (Judgment) जनरेशन से बेहतर है

कुछ समय के लिए, उद्योग ने प्रॉम्प्ट इंजीनियरिंग (prompt engineering) को रिज्यूमे में लिखने के लिए एक नए कौशल के रूप में देखा। इसने पूरी तरह से मुख्य बिंदु को ही मिस कर दिया। AI से भरे वातावरण में सबसे मूल्यवान क्षमता विकल्प उत्पन्न करना नहीं है। बल्कि यह जानना है कि किन सुझावों को अस्वीकार करना है।

मैं जिन बेहतरीन इंजीनियरों के साथ काम करता हूँ, वे सबसे अधिक प्रॉम्प्ट नहीं लिखते। वे सबसे कठिन प्रश्न पूछते हैं। वे जानते हैं कि कब एक रिफैक्टर (refactor) एक छिपी हुई निर्भरता (dependency) पैदा करता है। वे पहचान लेते हैं कि कब एक जनरेट किया गया टेस्ट केवल 'हैप्पी पाथ' को कवर करता है लेकिन उस एज केस (edge case) को नजरअंदाज कर देता है जो ग्राहक के डेटा को दूषित कर सकता है। वे पूरी तरह से वैध कोड को देखकर कह सकते हैं, "यह कोड सही है, लेकिन आर्किटेक्चर गलत है।"

यह आखिरी वाक्य दो बहुत अलग संस्कृतियों के बीच की विभाजक रेखा है। AI-असिस्टेड इंजीनियरिंग का अर्थ है कि आप मशीन का उपयोग स्कैफोल्डिंग (scaffolding) तैयार करने, पैटर्न तलाशने या बॉयलरप्लेट (boilerplate) को ऑटोमेट करने के लिए करते हैं, जबकि आपका दिमाग निर्णय लेता है। AI-डिपेंडेंट इंजीनियरिंग का अर्थ है कि आप मशीन को चलाने के लिए भरोसा करते हैं। कई संगठन चुपचाप निर्भरता की ओर बढ़ रहे हैं क्योंकि अल्पकाल में यह तेज़ महसूस होता है। तेज़ होना सही होने के बराबर नहीं है।

वह काम जो अभी भी मनुष्यों के पास है

AI डेवलपमेंट लाइफसाइकिल के लगभग हर हिस्से को तेज़ कर सकता है, फिर भी कुछ मुख्य अभ्यास ऐसे हैं जिन्हें पूरी तरह से मानवीय ही रहना चाहिए। सिस्टम डिज़ाइन के लिए प्रतिस्पर्धी बाधाओं के बीच संतुलन बनाए रखना आवश्यक है: लागत, लेटेंसी, विश्वसनीयता और भविष्य की मेंटेनेबिलिटी। आर्किटेक्चर रिव्यू संस्थागत स्मृति और सेकंड-ऑर्डर इफेक्ट्स का अनुमान लगाने की क्षमता पर निर्भर करते हैं। मेंटरशिप के लिए ऐसे व्यक्ति की आवश्यकता होती है जिसने वास्तव में उन फेलियर मोड का सामना किया हो जिनके बारे में वह आपको चेतावनी दे रहा है। उत्पाद की गहरी समझ उपयोगकर्ताओं से बात करने और वास्तविक परिस्थितियों में उनके व्यवहार को देखने से आती है, न कि ट्रेनिंग डेटा पढ़ने से।

इंजीनियरिंग जजमेंट उन अनुभवों का योग है। यह वह शांत आवाज़ है जो आपको बताती है कि एक माइग्रेशन शुक्रवार की दोपहर को शिप करना बहुत जोखिम भरा है, भले ही कोड रिव्यू पास हो गया हो। यह वह अंतर्ज्ञान है जो बताता है कि अभी किया गया परफॉरमेंस ऑप्टिमाइज़ेशन बाद में एक सिक्योरिटी होल पैदा कर सकता है। एक LLM में कोई अंतर्ज्ञान नहीं होता। इसमें केवल पैटर्न्स होते हैं। पैटर्न्स उपयोगी होते हैं, लेकिन वे जजमेंट नहीं हैं।

अभी भर्ती कर रही कंपनियों को केवल उन लोगों के लिए ऑप्टिमाइज़ करना बंद कर देना चाहिए जो केवल AI टूल्स का उपयोग करने में अच्छे हैं। ऐसे लोगों को काम पर रखें जो AI को चुनौती दे सकें। ऐसे उम्मीदवारों की तलाश करें जो रुकें, जनरेट किए गए आउटपुट को ध्यान से पढ़ें, और समझाएं कि वे उससे असहमत क्यों हैं। वे ही वे इंजीनियर होंगे जो आपके सिस्टम को तब भी स्वस्थ रखेंगे जब जनरेट किया गया कोड प्रोडक्शन की जटिल वास्तविकता का सामना करेगा।

बिना दिशा-सूचक के त्वरण

AI को एक एक्सीलरेटर पेडल की तरह समझें। एक ऐसी कार में जिसमें...