सॉफ्टवेयर इंजीनियरिंग खत्म हो गई है। टेक ट्विटर (tech Twitter) पर सबसे ऊंची आवाजें यही चाहती हैं कि आप इस पर विश्वास करें। वे एआई (AI) टूल्स के स्क्रीन रिकॉर्डिंग साझा करते हैं जो एक सिंगल पैराग्राफ प्रॉम्प्ट से पूरे एप्लिकेशन तैयार कर देते हैं और पूछते हैं कि कोई अभी भी कोड लिखने के लिए इंसान को पैसे क्यों देगा। यह घबराहट समझ में आती है, लेकिन यह पूरी तरह से मुख्य बिंदु को ही नजरअंदाज कर देती है।
एआई इंजीनियरों के लिए नहीं आ रहा है। यह उन लोगों के लिए आ रहा है जो टाइपिंग की गति को तकनीकी निर्णय लेने की क्षमता (technical judgment) समझने की गलती करते हैं। कोडिंग और इंजीनियरिंग के बीच एक बहुत बड़ा अंतर है, और वही अंतर इस पूरे पेशे का आधार है।
एक एआई असिस्टेंट आपकी कॉफी खत्म करने से पहले ही आपको किसी फीचर को लागू करने के पांच अलग-अलग तरीके बता सकता है। बाधा (bottleneck) अब बदल गई है। अब हम यह सोचकर खाली फाइल को नहीं घूरते कि शुरुआत कैसे करें। अब हम पांच संभावित समाधानों को यह सोचकर घूरते हैं कि इनमें से कौन सा वास्तविक ट्रैफिक आने पर तुरंत क्रैश नहीं होगा। वह निर्णय लेना ही इंजीनियरिंग है। बाकी सब कुछ सिर्फ सिंटैक्स (syntax) है।
डेमो ही प्रोडक्ट नहीं है
किसी भी एआई कोडिंग डेमो को देखें और आप देखेंगे कि मिनटों में एक सुंदर इंटरफेस तैयार हो जाता है। लेकिन आप यह नहीं देखेंगे कि लोड बढ़ने पर डेटाबेस कनेक्शन पूल कैसे खत्म हो रहा है। आप किसी एपीआई (API) एंडपॉइंट पर मिसिंग रेट लिमिट्स (rate limits), ऑडिट लॉग्स की अनुपस्थिति, या हर यूजर इंटरैक्शन को ऑब्जेक्ट बकेट में लॉग करने की स्टोरेज लागत नहीं देखेंगे, क्योंकि एआई को लगा कि स्टेट (state) को डंप करने के लिए यह एक सुविधाजनक जगह है।
प्रोडक्शन सिस्टम्स के लिए स्केलेबिलिटी (scalability), सुरक्षा, परफॉरमेंस और लागत नियंत्रण की आवश्यकता होती है। ये गुण स्प्रिंट रिव्यू (sprint review) में दिखाई नहीं देते। वे केवल तभी सामने आते हैं जब वास्तविक उपयोगकर्ता अपने अप्रत्याशित व्यवहार, अपने एज केसेस (edge cases), और आपके द्वारा अपेक्षित क्रम में बटन क्लिक करने से इनकार करने के साथ आते हैं। मैंने ऐसे बहुत से एआई-असिस्टेड प्रोजेक्ट्स देखे हैं जो क्यूए (QA) में तो बिल्कुल सही लग रहे थे, लेकिन लॉन्च के एक हफ्ते बाद महंगे सबक बन गए।
काम करने वाला कोड अब सस्ता हो गया है। अच्छी इंजीनियरिंग नहीं।
अब क्या मायने रखता है
इस बदलाव में जो इंजीनियर फल-फूल रहे हैं, वे वे नहीं हैं जो सबसे तेज़ टाइप करते हैं। वे वे हैं जो एक भी लाइन जेनरेट होने से पहले जानते हैं कि कौन से सवाल पूछने हैं।
वे समस्याओं को स्पष्ट रूप से परिभाषित करते हैं। यदि आप अनुमति दें, तो एक एआई मॉडल खुशी-खुशी गलत समस्या का समाधान कर देगा। यह एक ऐसे रीड-हैवी (read-heavy) डैशबोर्ड के लिए एक जटिल कैशिंग लेयर (caching layer) बना देगा जिसका उपयोग केवल छह आंतरिक विश्लेषक करते हैं। यह यह पूछने के लिए नहीं रुकेगा कि क्या वास्तविक समस्या एक मिसिंग डेटाबेस इंडेक्स है या मौलिक रूप से टूटा हुआ डेटा मॉडल है। एक कुशल इंजीनियर समस्या को तब तक फिर से परिभाषित (reframe) करता है जब तक कि समाधान स्पष्ट न हो जाए, चाहे उस समाधान में कोड शामिल हो या नहीं।
वे बड़े सिस्टम को छोटे टुकड़ों में तोड़ते हैं। एआई लोकल कॉन्टेक्स्ट (local context) में उत्कृष्ट है। यह एक सिंगल फंक्शन, एक सिंगल कंपोनेंट, एक सिंगल टेस्ट लिख सकता है। इसे पूरे डिस्ट्रिब्यूटेड आर्किटेक्चर (distributed architecture) को अपने दिमाग में रखने में कठिनाई होती है। जो इंजीनियर एक मोनोलिथ (monolith) को विघटित कर सकते हैं, सेवाओं के चारों ओर सीमाएं निर्धारित कर सकते हैं, और टीमों के बीच कॉन्ट्रैक्ट्स (contracts) परिभाषित कर सकते हैं, वही जेनरेट किए गए स्निपेट्स को टिकाऊ सिस्टम में बदलते हैं।
वे एआई के सुझावों को चुनौती देते हैं। मॉडल का आत्मविश्वास एक मृगतृष्णा (mirage) है। यह ऐसे आर्किटेक्चर का प्रस्ताव दे सकता है जो नेटवर्क लेटेंसी (network latency) को नजरअंदाज करते हैं, ऐसी लाइब्रेरी की सिफारिश कर सकता है जो वर्षों से डिप्रिकेटेड (deprecated) हो चुकी हैं, या ऐसे फीचर्स को हल कर सकता है जो वास्तव में आवश्यकताओं (requirements) में मौजूद ही नहीं हैं।