২০ বছরের পুরনো একটি ইন্স্যুরেন্স প্ল্যাটফর্মের লেখক ১০৮টি সাপোর্ট টিকিট একটি কাস্টম AI-এজেন্ট পাইপলাইনের মাধ্যমে চালিয়েছেন এবং এর ফলাফল হলো এমন একটি ওয়ার্কফ্লো যা একজন সিনিয়র ডেভেলপারের বহু ঘণ্টার কাজকে মাত্র কয়েক মিনিটে রূপান্তরিত করে—এমন একটি পরিবর্তন যা এন্টারপ্রাইজগুলো কীভাবে তাদের লিগ্যাসি কোড (legacy code) টিকিয়ে রাখে তার ধরন বদলে দিতে পারে।
কেন নতুন কোডের চেয়ে লিগ্যাসি সিস্টেম বেশি গুরুত্বপূর্ণ
আলোচ্য ইন্স্যুরেন্স অ্যাপ্লিকেশনটি ২.৩ মিলিয়ন লাইনের কোড এবং প্রায় ১,০০০টি PL/SQL প্যাকেজের একটি মনোলিথ (monolith)। এর বিশাল আকারের কারণে কোনো একক ব্যক্তির পক্ষে পুরো কোডবেসটি বোঝা অসম্ভব। এর সাথে যুক্ত হয়েছে গ্রাহক-নির্দিষ্ট কনফিগারেশন প্যারামিটারের গোলকধাঁধা, বিক্ষিপ্ত ডকুমেন্টেশন এবং ২০১৭ সাল পর্যন্ত বিস্তৃত একটি টিকিটের আর্কাইভ; ফলে আসল বাধাটি কোড লেখা নয়, বরং "প্রসঙ্গ খুঁজে বের করা" (finding context)।
আধুনিক AI-এর সাধারণ হাইপ বা প্রচার মূলত গ্রিনফিল্ড প্রজেক্টের (greenfield projects) জন্য নতুন কোড তৈরির ওপর গুরুত্ব দেয়। কিন্তু এই ক্ষেত্রে কঠিন অংশটি PL/SQL-এর সিনট্যাক্স নয়, বরং লজিকের সঠিক অংশটি খুঁজে বের করা, প্রাসঙ্গিক কনফিগারেশন এবং সেই ঐতিহাসিক টিকিটটি শনাক্ত করা যা প্রথম সমস্যাটি বর্ণনা করেছিল। একজন অভিজ্ঞ ডেভেলপার GitLab, SVN, উইকি এবং পুরনো সাপোর্ট টিকিট থেকে সূত্রগুলো একত্রিত করতে ঘণ্টার পর ঘণ্টা সময় ব্যয় করতে পারেন। AI এজেন্ট সেই একই কাজ কয়েক মিনিটে করে ফেলে।
ব্যবহারিক ক্ষেত্রে ওয়ার্কফ্লো
যখন একটি নতুন টিকিট আসে, লেখক একটি মাত্র কমান্ড চালান। এরপর এজেন্টটি যা করে:
- টিকিট-সিস্টেম API-এর মাধ্যমে টিকিটের টেক্সট এবং যেকোনো সংযুক্ত ফাইল সংগ্রহ করে।
- অতীতের অনুরূপ ঘটনাগুলো খুঁজে পেতে পুরো টিকিট আর্কাইভ জুড়ে কিওয়ার্ড এবং ভেক্টর সার্চ চালায়।
- পুনরায় ব্যবহারযোগ্য SQL স্ক্রিপ্টের একটি ব্যক্তিগত লাইব্রেরি থেকে তথ্য অনুসন্ধান করে।
- ভার্সন-কন্ট্রোল সিস্টেমে (GitLab বা SVN) কোডের ইতিহাস পরীক্ষা করে।
সমস্ত প্রাপ্ত তথ্য একটি ফাইলে সংকলিত করা হয় যা পরবর্তী পদক্ষেপটিও সাজেস্ট করে—সাধারণত একটি কোড ফিক্স, গ্রাহকের জন্য একটি খসড়া উত্তর, অথবা অতিরিক্ত ডায়াগনস্টিকসের অনুরোধ।
বিল্ট-ইন সক্ষমতা
লেখক এজেন্টের জন্য ২৪টি “স্কিল” বা দক্ষতা সংজ্ঞায়িত করেছেন, যা চারটি বিভাগে বিভক্ত:
- Context access – প্রাসঙ্গিক তথ্য সংগ্রহের জন্য API, ম্যানুয়াল এবং ডাটাবেস পড়া।
- Domain knowledge – ইন্স্যুরেন্স অ্যাকাউন্টিং নিয়ম এবং সিস্টেমের আর্কিটেকচার ব্যাখ্যা করা।
- Writing – PL/SQL স্নিপেট তৈরি করা এবং সেগুলো ডেপ্লয়মেন্টের জন্য প্যাকেজ করা।
- Meta – প্যাটার্ন শনাক্ত করা এবং প্রয়োজনে স্বয়ংক্রিয়ভাবে নতুন স্কিল তৈরি করা।
এই দক্ষতাগুলো এজেন্টকে এমন একজন জুনিয়র ইঞ্জিনিয়ারের মতো কাজ করতে সাহায্য করে যে কখনো ঘুমায় না, এবং টিকিটে উল্লিখিত কোডের সঠিক লাইন বা কনফিগারেশনটি সামনে নিয়ে আসে।
লুপের মধ্যে অন্তর্ভুক্ত নিরাপত্তা ব্যবস্থা
প্রোডাকশন এনভায়রনমেন্টে অটোমেশনের জন্য সুরক্ষা ব্যবস্থার প্রয়োজন হয়। লেখক দুটি সহজ নিয়ম অনুসরণ করেন:
১. Static validation – প্রতিটি তৈরি করা স্ক্রিপ্ট লাইভ স্কিমার বিপরীতে একটি EXPLAIN PLAN-এর মাধ্যমে চালানো হয়। এটি কোডটি আসলে এক্সিকিউট না করেই সিনট্যাক্স বা লজিক্যাল ত্রুটি পরীক্ষা করে।
২. Dual-model confirmation – একটি দ্বিতীয়, স্বাধীন AI এজেন্ট যেকোনো ঝুঁকিপূর্ণ পরিবর্তন পর্যালোচনা করে। যদি উভয় মডেল একই সিদ্ধান্তে পৌঁছায়, তবে লেখক কাজ চালিয়ে যান; অন্যথায়, টিকিটটি ম্যানুয়াল পর্যালোচনার জন্য পাঠানো হয়।
এই পরীক্ষাগুলো প্রক্রিয়াটিকে একটি 'ব্ল্যাক বক্স'-এ পরিণত হতে বাধা দেয়, যা অনিচ্ছাকৃতভাবে কোনো গুরুত্বপূর্ণ ইন্স্যুরেন্স লেনদেন নষ্ট করে দিতে পারত।
ক্রমবর্ধমান সুবিধা
প্রতিটি টিকিটের আউটপুট পুনরায় টিকিটের রেকর্ডের সাথে যুক্ত করা হয়, যা একটি জীবন্ত নলেজ বেস (knowledge base) তৈরি করে। যখন মাস বা বছর পরে একই ধরনের সমস্যা আবার দেখা দেয়, তখন এজেন্টটি কেবল পূর্ববর্তী সমাধানই নয়, বরং সেই সমাধানের পেছনের যুক্তিটিও পড়তে পারে। কার্যত, প্রতিটি সমাধান করা টিকিট ভবিষ্যতের টিকিটের জন্য ট্রেনিং ডেটা হিসেবে কাজ করে, যা এই চক্রকে আরও ত্বরান্বিত করে।
বাস্তবসম্মত সীমাবদ্ধতা
- Manual testing remains – প্রমোশনের আগে লেখক এখনও একটি টেস্ট এনভায়রনমেন্টে পরিবর্তনগুলো যাচাই করেন।
- No hard-stop metrics – যদিও সময় সাশ্রয় উল্লেখযোগ্য মনে হচ্ছে, লেখক ঠিক কত ঘণ্টা সময় কমছে তা পরিমাপ করেননি।
- Personal setup – বর্তমান ইমপ্লিমেন্টেশনটি একটি মাত্র ওয়ার্কস্টেশনে চলছে; এটিকে একটি টিমের মধ্যে স্কেল করতে অতিরিক্ত ইঞ্জিনিয়ারিং প্রয়োজন হবে।
এই সীমাবদ্ধতাগুলোর কারণে এই পদ্ধতিটি এখনও একটি 'টার্নকি প্রোডাক্ট' (turnkey product) হিসেবে তৈরি হয়নি, তবে এগুলো মূল ধারণাটিকে খাটো করে দেয় না: AI প্রেক্ষাপট বা কনটেক্সট সংগ্রহের সময়কে ঘণ্টার বদলে মিনিটে নামিয়ে আনতে পারে।
পরবর্তী লক্ষ্য
লেখকের এই পরীক্ষাটি কোনো বাণিজ্যিক অফারের চেয়ে একটি 'প্রুফ-অফ-কনসেপ্ট' (proof-of-concept) হিসেবে বেশি গণ্য। পরবর্তী যৌক্তিক পদক্ষেপগুলোর মধ্যে রয়েছে:
- মেট্রিক্সগুলোকে আনুষ্ঠানিক রূপ দেওয়া (Formalizing metrics) – একটি বিজনেস কেস তৈরি করার জন্য AI পাইপলাইনের আগে এবং পরে টিকিটের সমাধানের সময় ট্র্যাক করা।
- টিম ডিপ্লয়মেন্ট (Team deployment) – এজেন্টটিকে একটি শেয়ার্ড সার্ভিস হিসেবে প্যাকেজ করা যাতে একাধিক ইঞ্জিনিয়ার একই নলেজ বেস থেকে উপকৃত হতে পারেন।
- CI/CD-এর সাথে ইন্টিগ্রেশন (Integration with CI/CD) – যাচাইকৃত স্ক্রিপ্টগুলোকে সরাসরি একটি continuous-integration পাইপলাইনে ইনপুট দেওয়া ম্যানুয়াল হ্যান্ড-অফ ছাড়াই টিকিট থেকে প্রোডাকশন পর্যন্ত প্রক্রিয়াটি সম্পন্ন করতে পারে।
যদি এই সম্প্রসারণগুলো সফল হয়, তবে এই মডেলটি বিশাল এবং জটিল কোডবেসের (codebases) সাথে লড়াই করা অন্যান্য এন্টারপ্রাইজের জন্য একটি টেমপ্লেট হয়ে উঠতে পারে।
মূল শিক্ষা (Takeaway)
লিগ্যাসি এনভায়রনমেন্টে AI-এর আসল মূল্য নতুন কোড স্বয়ংক্রিয়ভাবে লেখায় নয়, বরং তাৎক্ষণিকভাবে সঠিক কনটেক্সট সামনে আনার মধ্যে নিহিত। একজন সিনিয়র ডেভেলপারের ঘণ্টার পর ঘণ্টা ডিটেকটিভ কাজকে মাত্র কয়েক মিনিটে রূপান্তর করার মাধ্যমে, একটি AI-agent ওয়ার্কফ্লো পুরনো সিস্টেমগুলোকে কার্যকর রাখতে পারে, সাপোর্ট খরচ কমাতে পারে এবং ধীরে ধীরে একটি স্বয়ংসম্পূর্ণ নলেজ রিপোজিটরি তৈরি করতে পারে। পরীক্ষাটি দেখায় যে, লিগ্যাসি সফটওয়্যারের ক্ষেত্রে প্রোডাক্টিভিটি বৃদ্ধির সবচেয়ে বড় উৎস হলো উত্তরের অনুসন্ধান প্রক্রিয়াকে সংক্ষিপ্ত করা, নতুন কোড তৈরি করা নয়।