२० वर्षांपूर्वीच्या एका विमा प्लॅटफॉर्मच्या लेखकाने १०८ सपोर्ट तिकीट एका कस्टम AI-agent पाइपलाइनद्वारे चालवले आणि त्याचा निकाल असा एक वर्कफ्लो आहे जो अनेक तास लागणारे सिनियर-डेव्हलपरचे काम काही मिनिटांत पूर्ण करतो. हा बदल एंटरप्राइजेसना त्यांचा लेगसी कोड (legacy code) जिवंत ठेवण्याच्या पद्धतीत आमूलाग्र बदल घडवून आणू शकतो.

नवीन कोडपेक्षा लेगसी सिस्टम्स (legacy systems) का महत्त्वाच्या आहेत

संबंधित विमा ॲप्लिकेशन हे २३ लाख ओळींचा कोड आणि अंदाजे १,००० PL/SQL पॅकेजेस असलेला एक मोनोलिथ (monolith) आहे. केवळ त्याच्या आकारामुळेच कोणताही एक व्यक्ती संपूर्ण कोडबेस हाताळू शकत नाही. त्यात ग्राहकांसाठी विशिष्ट कॉन्फिगरेशन पॅरामीटर्सचा गुंता, विखुरलेली डॉक्युमेंटेशन आणि २०१७ पासूनचे तिकीट आर्काइव्ह यांचा विचार केला, तर खरा अडथळा कोड लिहिण्यात नसून "संदर्भ शोधण्यात" (finding context) आहे.

आजकालच्या आधुनिक AI च्या चर्चेमध्ये प्रामुख्याने 'ग्रीनफील्ड प्रोजेक्ट्स'साठी (greenfield projects) नवीन कोड तयार करण्यावर लक्ष केंद्रित केले जाते. या प्रकरणात, कठीण भाग PL/SQL ची सिंटॅक्स (syntax) नसून लॉजिकचा नेमका भाग, संबंधित कॉन्फिगरेशन आणि समस्या पहिल्यांदा वर्णन करणारे ऐतिहासिक तिकीट शोधणे हा आहे. एक अनुभवी डेव्हलपर GitLab, SVN, विकी आणि जुन्या सपोर्ट तिकीट्समधून पुरावे गोळा करण्यासाठी तासनतास घालवू शकतो. AI एजंट हेच काम काही मिनिटांत करतो.

प्रत्यक्ष वर्कफ्लो (workflow)

जेव्हा एखादे नवीन तिकीट येते, तेव्हा लेखक एक कमांड चालवतो. त्यानंतर एजंट खालील गोष्टी करतो:

  • तिकीट-सिस्टम API द्वारे तिकीट मजकूर आणि जोडलेल्या कोणत्याही फाईल्स मिळवतो.
  • जुन्या सारख्या प्रकरणांचा शोध घेण्यासाठी संपूर्ण तिकीट आर्काइव्हमध्ये कीवर्ड आणि वेक्टर सर्च (vector search) करतो.
  • पुन्हा वापरता येण्याजोग्या SQL स्क्रिप्ट्सच्या वैयक्तिक लायब्ररीमधून माहिती शोधतो.
  • व्हर्जन-कंट्रोल सिस्टम्समध्ये (GitLab किंवा SVN) कोडचा इतिहास तपासतो.

सर्व निष्कर्ष एका फाईलमध्ये संकलित केले जातात, ज्यामध्ये पुढील पाऊल—सहसा कोड फिक्स, ग्राहकाला देण्यासाठी उत्तराचा मसुदा किंवा अतिरिक्त निदानासाठी (diagnostics) विनंती—सुचवले जाते.

अंगभूत क्षमता (Built-in capabilities)

लेखकाने एजंटसाठी २४ "कौशल्ये" (skills) परिभाषित केली आहेत, जी चार श्रेणींमध्ये विभागली आहेत:

  • Context access – संबंधित तथ्ये मिळवण्यासाठी APIs, मॅन्युअल्स आणि डेटाबेस वाचणे.
  • Domain knowledge – विमा लेखांकन नियम (insurance accounting rules) आणि सिस्टमची आर्किटेक्चर समजून घेणे.
  • Writing – PL/SQL स्निपेट्स तयार करणे आणि ते डिप्लॉयमेंटसाठी पॅकेज करणे.
  • Meta – पॅटर्न ओळखणे आणि आवश्यकतेनुसार आपोआप नवीन कौशल्ये तयार करणे.

या कौशल्यांमुळे एजंट एका ज्युनियर इंजिनिअरप्रमाणे काम करू शकतो जो कधीही झोपत नाही, आणि तिकीट ज्या कोड लाइन किंवा कॉन्फिगरेशनचा संदर्भ देते, ती नेमकी ओळ शोधून देतो.

लूपमध्ये समाविष्ट केलेले सुरक्षा कवच (Safety nets)

प्रोडक्शन एन्व्हायरमेंटमधील ऑटोमेशनसाठी संरक्षणाची गरज असते. लेखक दोन साधे नियम पाळतो:

  1. Static validation – प्रत्येक तयार केलेली स्क्रिप्ट लाईव्ह स्कीमावर EXPLAIN PLAN द्वारे चालवली जाते. यामुळे कोड प्रत्यक्षात कार्यान्वित न करता सिंटॅक्स किंवा लॉजिकल त्रुटी तपासल्या जातात.
  2. Dual-model confirmation – दुसरे, स्वतंत्र AI एजंट कोणत्याही जोखमीच्या बदलाची पुनरावलोकन करते. जर दोन्ही मॉडेल्स एकाच निष्कर्षावर पोहोचले, तर लेखक पुढे जातो; अन्यथा, तिकीट मॅन्युअल रिव्ह्यूसाठी पाठवले जाते.

या तपासण्यांमुळे ही प्रक्रिया 'ब्लॅक बॉक्स' बनण्यापासून वाचते, ज्यामुळे चुकून एखादा महत्त्वाचा विमा व्यवहार (insurance transaction) बिघडू शकला असता.

वाढते फायदे (Compounding benefits)

प्रत्येक तिकीटाचा आउटपुट पुन्हा तिकीट रेकॉर्डला जोडला जातो, ज्यामुळे एक जिवंत नॉलेज बेस (knowledge base) तयार होतो. जेव्हा काही महिन्यांनी किंवा वर्षांनी अशीच समस्या पुन्हा उद्भवते, तेव्हा एजंट केवळ मागील उपायच नाही तर त्या निर्णयामागील कारण देखील वाचू शकतो. परिणामी, प्रत्येक सोडवलेले तिकीट भविष्यातील तिकीटसाठी ट्रेनिंग डेटा बनतो, ज्यामुळे ही प्रक्रिया अधिक वेगवान होते.

प्रामाणिक मर्यादा (Honest limitations)

  • Manual testing remains – लेखक अजूनही प्रमोशन करण्यापूर्वी टेस्ट एन्व्हायरमेंटमध्ये बदल तपासतो.
  • No hard-stop metrics – वाचलेला वेळ लक्षणीय वाटत असला तरी, लेखकाने तासांमधील नेमकी घट मोजलेली नाही.
  • Personal setup – सध्याची अंमलबजावणी एका सिंगल वर्कस्टेशनवर आहे; ती टीममध्ये स्केल करण्यासाठी अतिरिक्त इंजिनिअरिंगची आवश्यकता असेल.

या मर्यादांमुळे हा दृष्टिकोन 'टर्नकी उत्पादन' (turnkey product) बनत नाही, परंतु ते मूळ महत्त्वाचे सत्य कमी करत नाही: AI संदर्भ गोळा करण्याचा वेळ तासांवरून मिनिटांवर आणू शकते.

पुढे काय पाहायचे

लेखकाचा हा प्रयोग व्यावसायिक ऑफर नसून एक 'प्रूफ-ऑफ-कॉन्सेप्ट' (proof-of-concept) आहे. पुढील तार्किक पावले खालीलप्रमाणे असू शकतात:

  • मेट्रिक्सचे प्रमाणीकरण – बिझनेस केस तयार करण्यासाठी AI पाइपलाइनच्या आधी आणि नंतर तिकीट निवारण वेळ (ticket resolution time) ट्रॅक करणे.
  • टीम डिप्लॉयमेंट – एजंटला शेअर सेवा (shared service) म्हणून पॅकेज करणे, जेणेकरून अनेक इंजिनिअर्स एकाच नॉलेज बेसचा फायदा घेऊ शकतील.
  • CI/CD सोबत एकत्रीकरण – प्रमाणित स्क्रिप्ट्स थेट कंटीन्युअस-इंटिग्रेशन पाइपलाइनमध्ये फीड केल्यामुळे, मॅन्युअल हँड-ऑफशिवाय तिकीट ते प्रोडक्शनपर्यंतची प्रक्रिया अखंडपणे पूर्ण होऊ शकते.

जर हे विस्तार यशस्वी झाले, तर हे मॉडेल मोठ्या आणि जुन्या कोडबेसशी (codebases) संघर्ष करणाऱ्या इतर उद्योगांसाठी एक टेम्पलेट बनू शकते.

मुख्य निष्कर्ष

लेगसी एन्व्हायरनमेंटमध्ये (legacy environments) AI चे खरे मूल्य नवीन कोड आपोआप लिहिण्यात नसून, योग्य संदर्भ (context) त्वरित समोर आणण्यात आहे. वरिष्ठ डेव्हलपरच्या तासांच्या शोधकार्याला काही मिनिटांत रूपांतरित करून, एक AI-एजंट वर्कफ्लो जुन्या सिस्टिम्स कार्यान्वित ठेवू शकतो, सपोर्ट खर्च कमी करू शकतो आणि हळूहळू एक स्वयंचलित ज्ञान भांडार (knowledge repository) तयार करू शकतो. हा प्रयोग दर्शवतो की, लेगसी सॉफ्टवेअरसाठी, उत्पादकता वाढवण्याचा सर्वात मोठा मार्ग उत्तरांचा शोध घेण्याची प्रक्रिया संक्षिप्त करणे हा आहे, नवीन कोड तयार करणे नाही.