लेगसी सॉफ़्टवेयर को AI SDLC में कैसे लाएं

AI-सहायता प्राप्त डेवलपमेंट की हर बातचीत आख़िरकार उसी दीवार से टकराती है: "नई ऐप्स के लिए तो ठीक है, पर हमारा बिज़नेस बारह साल पुराने Rails मोनोलिथ और एक ऐसे Java बिलिंग सिस्टम पर चलता है जिसे पूरी तरह कोई नहीं समझता।" दीवार असली है, ज़्यादातर AI डेवलपमेंट टूलिंग ग्रीनफ़ील्ड मानकर चलती है, पर टीमें उससे जो नतीजा निकालती हैं, कि AI की मदद से पहले लेगसी सिस्टमों को री-राइट का इंतज़ार करना होगा, वह बिल्कुल उल्टा है। लेगसी सिस्टम ही वह जगह हैं जहां AI-सहायता प्राप्त इंजीनियरिंग सबसे ज़्यादा फल देती है, क्योंकि मेंटेनेंस का बोझ, ज्ञान का जोखिम और बैकलॉग असल में वहीं रहते हैं।

किसी लेगसी सिस्टम को AI SDLC में लाने का मतलब किसी मॉडल से उसे दोबारा जनरेट करवाना नहीं है। मतलब है मौजूदा कोड को वही डिलीवरी लूप देना जो किसी नई AI-निर्मित ऐप को मिलता है: एक ऐसा एनवायरनमेंट जहां सिस्टम भरोसेमंद ढंग से चलता है ताकि एजेंट उस पर सुरक्षित काम कर सकें; एक नक्शा कि कौन सा कोड किस बिज़नेस फ़ंक्शन का है; ख़तरनाक इलाक़ों की हिफ़ाज़त करती पॉलिसी; उस व्यवहार के इर्द-गिर्द स्वचालित टेस्टों की बेसलाइन जिसे बदलना नहीं है; और बदलाव से डिप्लॉयमेंट तक एक नियंत्रित रास्ता। यह लूप बन जाए, तो AI एजेंट वह काम ढो सकते हैं जिससे इंसान कतराते हैं, डिपेंडेंसी अपग्रेड, बग बैकलॉग, छोटे फ़ीचर, दस्तावेज़ीकरण, गवर्नेंस के तहत, जबकि सिस्टम प्रोडक्शन में सेवा देता रहता है।

रणनीतिक पुनर्विचार यह है: आधुनिकीकरण कोई मंज़िल नहीं रहता (वह महान री-राइट, जो हमेशा अठारह महीने दूर है), वह इस बात का गुण बन जाता है कि सिस्टम अब से कैसे मेंटेन होता है। लूप के भीतर के सिस्टम हर गवर्न्ड बदलाव के साथ क़दम-दर-क़दम सेहतमंद होते जाते हैं। उसके बाहर के सिस्टम तयशुदा रफ़्तार से सड़ते हैं।

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

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

पारंपरिक बच निकलने का रास्ता, बिग-बैंग री-राइट, ऐसा नाकामी-रिकॉर्ड रखता है जिसे हर CIO जानता है: कई-कई साल की समय-सीमाएं, नए के नीचे-नीचे बदलता पुराना सिस्टम, और व्यवहार का आख़िरी 20%, बिना दस्तावेज़, बोझ उठाता, बजट का ज़्यादातर हिस्सा निगलता हुआ। री-राइट इसलिए फ़ेल होते हैं क्योंकि वे मांगते हैं कि संगठन पूरा सिस्टम एक साथ समझे, जो वही ज्ञान है जो खो गया था। इंक्रीमेंटल रास्ते इसलिए कामयाब होते हैं क्योंकि उन्हें एक बार में सिर्फ़ एक बदलाव समझना होता है, और एक बार में एक बदलाव ठीक वही दानेदारी है जिसे AI एजेंट और गवर्नेंस मिलकर अच्छे से संभालते हैं।

एक टैलेंट-सच्चाई भी है। लेगसी सिस्टम की मेंटेनेंस वाली कुर्सी कोई नहीं चाहता, और उसके लिए हायरिंग हर साल कठिन होती जाती है। सिस्टम को AI SDLC में लपेटना उस कुर्सी को फ़ुल-टाइम पुरातत्व से दिशा और समीक्षा में बदल देता है, एक ऐसी भूमिका जो वरिष्ठ लोग सचमुच लेंगे।

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

यह प्रवेश-मार्ग Ciao पर कोई जुगाड़ नहीं, फ़र्स्ट-क्लास रास्ता है। कस्टम सैंडबॉक्स इमेज AI-सहायता प्राप्त इंजीनियरिंग को Rails, Java, Go, Python, Node और मल्टी-प्रोसेस बैकएंड के इर्द-गिर्द लपेटती हैं, फ़्रेमवर्क का दूसरा चरण, एक प्लेटफ़ॉर्म क्षमता के रूप में। फिर मैपिंग और हिफ़ाज़त Guardrails करता है: वह कोड को बिज़नेस क्षेत्रों में मैप करता है, जोखिम भरे बदलाव पकड़ता है, सरल भाषा में लिखी पॉलिसी लागू करता है, मानव समीक्षा दर्ज करता है और हर मर्ज के पीछे ऑडिट ट्रेल छोड़ता है, ठीक वही गवर्नेंस-पहले वाला रुख जो लेगसी सिस्टम मांगते हैं। QA बेसलाइन बनाता और चलाता है, डिटरमिनिस्टिक ब्राउज़र रीप्ले, सेल्फ-हीलिंग टेस्ट, पब्लिश से पहले स्मोक गेट, बाद में प्रोडक्शन जांचें, और कुछ बिगड़े तो Doctor लाइव ऐप, DNS और CDN की जांच कर मूल कारण का निदान करता है।

अकेले सिस्टम की जगह पोर्टफ़ोलियो हो, तो Conductor सैकड़ों, कभी-कभी हज़ारों, प्रोजेक्ट्स के लिए लाइव हेल्थ और प्रोटेक्टेड-ज़ोन विज़िबिलिटी के साथ एक स्क्रीन देता है, एक चलते आधुनिकीकरण कार्यक्रम को छोटी टीम से मैनेज करने के लिए असल में यही चाहिए। डिप्लॉयमेंट वहीं रह सकता है जहां कंप्लायंस मांगे: आपका अपना AWS, Azure या GCP अकाउंट, प्राइवेट VPC, या अलग शर्तों के तहत ऑन-प्रेम। गंभीर डेवलपमेंट प्रोग्राम USD 10,000 प्रति वर्ष से शुरू होते हैं। सेल्स से करने लायक बातचीत ठोस है: एक पुराना पड़ता सिस्टम और उसका बैकलॉग लाइए, और उसके लिए पहले चरण का खाका बनवाइए।

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