Tác giả của một nền tảng bảo hiểm 20 năm tuổi đã chạy 108 ticket hỗ trợ qua một pipeline AI-agent tùy chỉnh, và kết quả là một quy trình làm việc giúp biến một tác vụ kéo dài nhiều giờ của lập trình viên cao cấp thành chỉ vài phút — một sự thay đổi có thể tái định hình cách các doanh nghiệp duy trì các mã nguồn cũ (legacy code).

Tại sao các hệ thống cũ lại quan trọng hơn mã nguồn mới

Ứng dụng bảo hiểm đang được nhắc đến là một khối monolith với 2,3 triệu dòng mã và khoảng 1.000 gói PL/SQL. Chỉ riêng kích thước của nó đã khiến không một cá nhân nào có thể nắm vững toàn bộ mã nguồn. Thêm vào đó là một mê cung các tham số cấu hình riêng biệt cho từng khách hàng, tài liệu rải rác và kho lưu trữ ticket kéo dài từ năm 2017, khiến nút thắt cổ chai thực sự trở thành việc "tìm kiếm ngữ cảnh" chứ không phải là viết mã.

Những lời đồn thổi về AI hiện đại thường tập trung vào việc tạo ra mã nguồn mới cho các dự án greenfield. Trong trường hợp này, phần khó khăn không nằm ở cú pháp PL/SQL mà là việc xác định chính xác đoạn logic, cấu hình liên quan và ticket lịch sử mô tả vấn đề lần đầu tiên. Một lập trình viên dày dạn kinh nghiệm có thể mất hàng giờ để xâu chuỗi các manh mối từ GitLab, SVN, wiki và các ticket hỗ trợ cũ. AI agent thực hiện cùng một công việc đó chỉ trong vài phút.

Quy trình làm việc trong thực tế

Khi một ticket mới được gửi đến, tác giả chỉ cần chạy một câu lệnh duy nhất. Sau đó, agent sẽ:

  • Lấy nội dung ticket và bất kỳ tệp đính kèm nào thông qua ticket-system API.
  • Thực hiện tìm kiếm theo từ khóa và vector trên toàn bộ kho lưu trữ ticket để tìm ra các trường hợp tương tự trong quá khứ.
  • Truy vấn thư viện cá nhân gồm các script SQL có thể tái sử dụng.
  • Kiểm tra lịch sử mã nguồn trong các hệ thống quản lý phiên bản (GitLab hoặc SVN).

Tất cả các kết quả tìm thấy được tổng hợp vào một tệp duy nhất, tệp này cũng gợi ý bước tiếp theo — thường là một bản sửa lỗi mã nguồn, một bản thảo phản hồi khách hàng, hoặc một yêu cầu chẩn đoán bổ sung.

Các khả năng tích hợp sẵn

Tác giả đã định nghĩa 24 “kỹ năng” cho agent, được nhóm thành bốn danh mục:

  • Truy cập ngữ cảnh – đọc các API, tài liệu hướng dẫn và cơ sở dữ liệu để lấy các thông tin liên quan.
  • Kiến thức chuyên môn – giải thích các quy tắc kế toán bảo hiểm và kiến trúc của hệ thống.
  • Viết mã – tạo các đoạn mã PL/SQL và đóng gói chúng để triển khai.
  • Meta – nhận diện các khuôn mẫu và tự động tạo ra các kỹ năng mới khi cần thiết.

Những kỹ năng này cho phép agent hoạt động như một kỹ sư cấp dưới (junior engineer) không bao giờ ngủ, giúp tìm ra chính xác dòng mã hoặc cấu hình mà một ticket đang đề cập đến.

Các lưới an toàn được tích hợp vào quy trình

Tự động hóa trong môi trường production đòi hỏi các biện pháp bảo vệ. Tác giả tuân thủ hai quy tắc đơn giản:

  1. Kiểm tra tĩnh (Static validation) – mọi script được tạo ra đều được chạy qua lệnh EXPLAIN PLAN đối với schema thực tế. Việc này giúp kiểm tra lỗi cú pháp hoặc lỗi logic mà không thực sự thực thi mã.
  2. Xác nhận bằng mô hình kép (Dual-model confirmation) – một AI agent độc lập thứ hai sẽ xem xét bất kỳ thay đổi nào được coi là rủi ro. Nếu cả hai mô hình đều đưa ra cùng một kết luận, tác giả sẽ tiếp tục; nếu không, ticket sẽ được chuyển lên để xem xét thủ công.

Những bước kiểm tra này giúp quy trình không trở thành một "hộp đen" có thể vô tình làm hỏng một giao dịch bảo hiểm quan trọng.

Lợi ích cộng dồn

Kết quả đầu ra của mỗi ticket được đính kèm ngược lại vào hồ sơ ticket, tạo ra một cơ sở kiến thức sống. Khi một vấn đề tương tự tái diễn sau nhiều tháng hoặc nhiều năm, agent không chỉ có thể đọc được giải pháp trước đó mà còn cả lập luận dẫn đến giải pháp đó. Về cơ bản, mỗi ticket được giải quyết sẽ trở thành dữ liệu huấn luyện cho các ticket trong tương lai, giúp đẩy nhanh chu kỳ hơn nữa.

Những hạn chế thực tế

  • Vẫn cần kiểm thử thủ công – tác giả vẫn phải xác nhận các thay đổi trong môi trường test trước khi triển khai chính thức.
  • Chưa có các chỉ số đo lường cụ thể – mặc dù thời gian tiết kiệm được có vẻ đáng kể, nhưng tác giả vẫn chưa định lượng chính xác số giờ giảm được.
  • Thiết lập cá nhân – bản triển khai hiện tại chỉ chạy trên một máy trạm duy nhất; việc mở rộng cho cả một đội ngũ sẽ đòi hỏi thêm các kỹ thuật bổ sung.

Những hạn chế này khiến phương pháp này chưa thể trở thành một sản phẩm turnkey, nhưng chúng không làm giảm đi giá trị cốt lõi: AI có thể rút ngắn việc thu thập ngữ cảnh từ hàng giờ xuống còn vài phút.

Những điều cần theo dõi tiếp theo

Thí nghiệm của tác giả là một bản thử nghiệm khái niệm (proof-of-concept) hơn là một sản phẩm thương mại. Các bước logic tiếp theo bao gồm:

  • Chuẩn hóa các chỉ số – theo dõi thời gian giải quyết ticket trước và sau khi áp dụng AI pipeline để xây dựng business case.
  • Triển khai cho đội ngũ – đóng gói agent dưới dạng một dịch vụ dùng chung để nhiều kỹ sư có thể cùng khai thác từ một cơ sở tri thức duy nhất.
  • Tích hợp với CI/CD – việc đưa các script đã được xác thực trực tiếp vào một continuous-integration pipeline có thể khép kín vòng lặp từ ticket đến production mà không cần bàn giao thủ công.

Nếu những mở rộng này thành công, mô hình này có thể trở thành một khuôn mẫu cho các doanh nghiệp khác đang phải vật lộn với những codebase khổng lồ và lâu đời.

Bài học rút ra

Giá trị thực sự của AI trong các môi trường legacy không nằm ở việc tự động viết mã mới, mà là ở khả năng hiển thị ngay lập tức các ngữ cảnh phù hợp. Bằng cách biến hàng giờ làm việc điều tra của một lập trình viên cao cấp thành chỉ vài phút, quy trình làm việc với AI-agent có thể duy trì sự hoạt động của các hệ thống cũ, giảm chi phí hỗ trợ và dần dần xây dựng một kho lưu trữ tri thức tự củng cố. Thử nghiệm cho thấy rằng, đối với phần mềm legacy, sự gia tăng năng suất lớn nhất đến từ việc rút ngắn quá trình tìm kiếm câu trả lời, chứ không phải từ việc tạo ra mã mới.