نویسنده یک پلتفرم بیمه ۲۰ ساله، ۱۰۸ تیکت پشتیبانی را از طریق یک خط لوله (pipeline) اختصاصی عامل هوش مصنوعی (AI-agent) عبور داد و نتیجه، گردش کاری است که یک وظیفه چند ساعته برای توسعه‌دهنده ارشد را به چند دقیقه کاهش می‌دهد؛ تغییری که می‌تواند نحوه حفظ کدهای قدیمی (legacy) در سازمان‌ها را بازتعریف کند.

چرا سیستم‌های قدیمی (legacy) مهم‌تر از کدهای جدید هستند

اپلیکیشن بیمه مورد نظر، یک مونو‌لیت (monolith) با ۲.۳ میلیون خط کد و تقریباً ۱۰۰۰ بسته PL/SQL است. بزرگی این سیستم به تنهایی باعث می‌شود که هیچ فرد واحدی نتواند مالکیت کل کد را بر عهده بگیرد. اگر این موضوع را با هزارتویی از پارامترهای پیکربندی خاصِ مشتری، مستندات پراکنده و آرشیو تیکت‌هایی که به سال ۲۰۱۷ بازمی‌گردد ترکیب کنید، گلوگاه اصلی به جای نوشتن کد، «یافتن زمینه (context)» خواهد بود.

هیاهوی معمول هوش مصنوعی مدرن بر تولید کدهای تازه برای پروژه‌های جدید (greenfield) تمرکز دارد. در این مورد، بخش دشوار، نحو (syntax) زبان PL/SQL نیست، بلکه یافتن قطعه دقیق منطق، پیکربندی مربوطه و تیکت تاریخی است که برای اولین بار مشکل را توصیف کرده است. یک توسعه‌دهنده با تجربه می‌تواند ساعت‌ها وقت صرف کنار هم قرار دادن سرنخ‌های به‌دست‌آمده از GitLab، SVN، ویکی‌ها و تیکت‌های پشتیبانی قدیمی کند. عامل هوش مصنوعی همین کار را در چند دقیقه انجام می‌دهد.

گردش کار در عمل

وقتی یک تیکت جدید ثبت می‌شود، نویسنده تنها یک دستور را اجرا می‌کند. سپس عامل هوش مصنوعی:

  • متن تیکت و هرگونه فایل پیوست را از طریق API سیستم تیکتینگ استخراج می‌کند.
  • یک جستجوی کلمات کلیدی و برداری (vector search) در کل آرشیو تیکت‌ها انجام می‌دهد تا موارد مشابه گذشته را پیدا کند.
  • از یک کتابخانه شخصی از اسکریپت‌های SQL قابل استفاده مجدد پرس‌وجو می‌کند.
  • تاریخچه کد را در سیستم‌های کنترل نسخه (GitLab یا SVN) بررسی می‌کند.

تمام یافته‌ها در یک فایل تجمیع می‌شوند که گام بعدی را نیز پیشنهاد می‌دهد؛ که معمولاً شامل اصلاح کد، پیش‌نویس پاسخ به مشتری یا درخواست برای تشخیص‌های تکمیلی است.

قابلیت‌های داخلی

نویسنده ۲۴ «مهارت» برای این عامل تعریف کرده است که در چهار دسته گروه‌بندی شده‌اند:

  • دسترسی به زمینه (Context access) – خواندن APIها، دفترچه‌های راهنما و پایگاه‌های داده برای استخراج حقایق مرتبط.
  • دانش دامنه (Domain knowledge) – تفسیر قوانین حسابداری بیمه و معماری سیستم.
  • نوشتن (Writing) – تولید قطعه‌کدهای (snippets) PL/SQL و بسته‌بندی آن‌ها برای استقرار.
  • متا (Meta) – تشخیص الگوها و ایجاد خودکار مهارت‌های جدید در صورت نیاز.

این مهارت‌ها به عامل اجازه می‌دهد مانند یک مهندس جونیور (junior engineer) عمل کند که هرگز نمی‌خوابد و دقیقاً همان خط کد یا پیکربندی را که یک تیکت به آن اشاره دارد، پیدا می‌کند.

حفاظ‌های ایمنی تعبیه شده در چرخه

خودکارسازی در محیط عملیاتی (production) نیازمند تدابیر ایمنی است. نویسنده از دو قانون ساده پیروی می‌کند:

۱. اعتبارسنجی ایستا (Static validation) – هر اسکریپت تولید شده از طریق یک EXPLAIN PLAN در برابر شمای زنده (live schema) اجرا می‌شود. این کار خطاهای نحوی یا منطقی را بدون اجرای واقعی کد بررسی می‌کند.
۲. تایید دو-مدلی (Dual-model confirmation) – یک عامل هوش مصنوعی دوم و مستقل، هر تغییری را که پرخطر تشخیص داده شود، بازبینی می‌کند. اگر هر دو مدل به نتیجه یکسانی برسند، نویسنده اقدام می‌کند؛ در غیر این صورت، تیکت برای بررسی دستی ارجاع داده می‌شود.

این بررسی‌ها مانع از آن می‌شوند که فرآیند به یک «جعبه سیاه» تبدیل شود که ممکن است ناخواسته یک تراکنش حیاتی بیمه را مختل کند.

مزایای انباشته

خروجی هر تیکت دوباره به رکورد همان تیکت پیوست می‌شود و یک پایگاه دانش پویا ایجاد می‌کند. هنگامی که مشکل مشابهی ماه‌ها یا سال‌ها بعد دوباره ظاهر شود، عامل هوش مصنوعی می‌تواند نه تنها راه حل قبلی، بلکه استدلالی را که منجر به آن شده نیز مطالعه کند. در واقع، هر تیکتِ حل‌شده به داده‌های آموزشی برای تیکت‌های آینده تبدیل می‌شود و این چرخه را بیش از پیش تسریع می‌کند.

محدودیت‌های صادقانه

  • تست دستی همچنان باقی است – نویسنده همچنان تغییرات را قبل از اعمال نهایی، در یک محیط تست اعتبارسنجی می‌کند.
  • عدم وجود معیارهای قطعی – اگرچه صرفه‌جویی در زمان قابل توجه به نظر می‌رسد، اما نویسنده کاهش دقیق ساعت‌ها را کمی‌سازی نکرده است.
  • تنظیمات شخصی – پیاده‌سازی فعلی روی یک ایستگاه کاری (workstation) واحد اجرا می‌شود؛ مقیاس‌پذیری آن برای یک تیم، نیازمند مهندسی اضافی خواهد بود.

این محدودیت‌ها مانع از تبدیل شدن این رویکرد به یک محصول آماده‌ی استفاده (turnkey) می‌شود، اما از ارزش بینش اصلی نمی‌کاهد: هوش مصنوعی می‌تواند زمان جمع‌آوری زمینه (context gathering) را از ساعت‌ها به چند دقیقه کاهش دهد.

آنچه باید در آینده زیر نظر داشت

آزمایش نویسنده بیشتر یک اثبات مفهوم (proof-of-concept) است تا یک محصول تجاری. گام‌های منطقی بعدی عبارتند از:

  • رسمی‌سازی معیارها – ردیابی زمان حل تیکت‌ها قبل و بعد از خط لوله هوش مصنوعی برای ایجاد یک توجیه تجاری.
  • استقرار تیمی – بسته‌بندی عامل (agent) به عنوان یک سرویس مشترک، به‌گونه‌ای که چندین مهندس بتوانند از یک پایگاه دانش واحد بهره‌مند شوند.
  • یکپارچه‌سازی با CI/CD – تزریق مستقیم اسکریپت‌های تأییدشده به یک خط لوله یکپارچه‌سازی مداوم می‌تواند چرخه از تیکت تا مرحله تولید را بدون نیاز به تحویل دستی، تکمیل کند.

اگر این توسعه‌ها موفقیت‌آمیز باشند، این مدل می‌تواند به الگویی برای سایر شرکت‌هایی تبدیل شود که با پایگاه‌های کد عظیم و ریشه‌دار دست‌وپنجه نرم می‌کنند.

نتیجه‌گیری

ارزش واقعی هوش مصنوعی در محیط‌های قدیمی (legacy)، در نوشتن خودکار کدهای جدید نیست، بلکه در ارائه فوری بافتار (context) مناسب است. با تبدیل ساعت‌ها کار کارآگاهی یک توسعه‌دهنده ارشد به چند دقیقه، یک گردش کار مبتنی بر عامل هوش مصنوعی می‌تواند سیستم‌های قدیمی را عملیاتی نگه دارد، هزینه‌های پشتیبانی را کاهش دهد و به‌تدریج یک مخزن دانش خودتقویت‌کننده ایجاد کند. این آزمایش نشان می‌دهد که برای نرم‌افزارهای قدیمی، بزرگترین جهش بهره‌وری از کاهش زمان جست‌وجوی پاسخ‌ها حاصل می‌شود، نه از تولید کدهای جدید.