Nguồn: Bài viết này được re-publish và format lại từ Accelerating Optimizely CMS and Commerce upgrades with agentic AI (Part 1 of 2) của tác giả Hung Le Hoang, đăng trên Optimizely World ngày 11 tháng 5 năm 2026. Toàn bộ nội dung gốc thuộc về tác giả.
- Phần 1 (bài này): CMS 11 + Commerce 13 → CMS 12 + Commerce 14 — kiến trúc Upgrade Machine và cách một run hoạt động
- Phần 2: CMS 12 + Commerce 14 → CMS 13 + Commerce 15 — platform uplift vs capability adoption
TL;DR
Niteco xây dựng một Upgrade Machine: hệ thống agentic AI gồm main orchestrator, các specialized subagent, và skills library ngày càng lớn. Nó tạo ra codebase PR-ready build thành công ở Release mode và CMS backend khởi động sạch trên target platform — trong một run được ghi lại, từ pipeline start đến clean build, trong 4 giờ 38 phút. Từ đó, delivery team tiếp quản để stabilize và ship lên production — thường hai đến sáu tuần tùy footprint.
1. Tại sao Optimizely upgrade hay bị đình trệ
Một Optimizely upgrade hiếm khi chỉ là cập nhật package. Nó chạm vào runtime assumption, custom code, integration, routing, DI wiring, configuration, content model, và cutover readiness. Bước CMS 11 + Commerce 13 → CMS 12 + Commerce 14 nằm trên một platform modernization rộng hơn — pattern ổn định nhiều năm có thể đột ngột đòi structural refactoring.
Có một thực tế về lifecycle: Optimizely đã thông báo end-of-support cho CMS 11 và Commerce 13 trong 2026, với nhiều team tham chiếu cửa sổ tháng 4/2026 gia hạn đến tháng 10. Trì hoãn làm tăng platform risk khi vendor support thu hẹp lại.
Trong thực tế, kẻ giết deadline thực sự là discovery gap: integration không có document, legacy helper, configuration wiring không ai muốn đụng vào. Những gap này đẩy team vào vòng lặp compile-fix chậm và runtime surprise xuất hiện muộn. Mục tiêu của Upgrade Machine: xóa repetitive refactor grind khỏi critical path và trao cho engineer một clean buildable baseline.
2. Giới hạn của automation truyền thống
Rule-based tooling xử lý tốt những gì được thiết kế cho nó: retarget framework, align package ref, áp dụng API substitution xác định. Hầu hết upgrade nên bắt đầu từ đó — và Upgrade Machine cũng vậy.
Khoảng cách xuất hiện khi bạn gặp context-heavy work. Hãy tưởng tượng một cross-file refactor có ba fix đều compile — nhưng chỉ một đúng với platform pattern. Rule engine không phân biệt được. Nó hoặc apply transformation mà nó tự tin, hoặc escalate. Những escalation đó tích lũy thành backlog nhiều tuần. Đó là lãnh địa nơi agentic AI thay đổi kinh tế học: hệ thống lý luận về intent, đề xuất lựa chọn kèm đánh đổi, và chờ developer quyết định thay vì đoán hay âm thầm apply fix sai.
Lợi thế cấu trúc khác là kiến thức tích lũy. Rule-based tooling bắt đầu từ đầu mỗi engagement. Skills library lớn dần với mỗi run — pattern khám phá trên một codebase, validate qua nhiều codebase khác, rồi promote lên automation-safe cho run tiếp theo.
3. Kiến trúc Upgrade Machine
Hai lựa chọn thiết kế định nghĩa hệ thống. Thứ nhất, tự chủ với guardrail: agent chạy độc lập, nhưng chỉ trong workflow thực thi checkpoint, reviewer gate, và escalation threshold. Khi độ không chắc chắn vượt ngưỡng, hệ thống dừng lại và hỏi — không đoán. Thứ hai, kiến thức tích lũy: mỗi engagement feed pattern mới ngược vào skills library, nên run tiếp theo bắt đầu thông minh hơn run trước.
Bên dưới các agent là một agent harness — không phải model, mà là execution layer giúp agentic work an toàn trong môi trường engineering thực tế. Nó cung cấp run isolation (mỗi run có branch riêng, baseline không bị chạm), state management (context tối thiểu per subagent, không có drift), tool governance (tool nào, thứ tự nào, constraint nào), và full observability (structured log, diff, artifact ở mỗi phase).
4. Skills library
Skills library là asset quan trọng nhất trong hệ thống. Mỗi skill encode ba thứ: cách phát hiện pattern (trigger), cách transform an toàn, và cách verify tính đúng đắn ngoài "nó compile." Trường cuối là thứ phân biệt library với rule engine — validation rule có thể kiểm tra DI registration, circular dependency risk, semantic correctness.
Một ví dụ đại diện về skill trong thực tế:
// Trigger: CS0246 ServiceLocator not found, hoặc ServiceLocator.Current usage
// Transformation:
- var svc = ServiceLocator.Current.GetInstance<IMyService>();
+ // Inject qua constructor: private readonly IMyService _svc;
// Validation: verify IMyService đã được register trong DI container,
// kiểm tra không có circular dependency, xác nhận không còn static call site nào
Skill không tự sinh ra autonomous. Pattern được quan sát trong engagement thực, validate qua nhiều codebase độc lập, rồi mới promote lên automation-safe. Các category hiện có trong library: project và dependency modernization, DI và configuration alignment, routing và runtime initialization, integration client modernization (resilience, async correctness), Commerce-specific divergence pattern, và safe cleanup pattern đòi human sign-off trước khi chạy.
5. Cách một run hoạt động
Một run đi qua năm phase. Mỗi phase có exit condition rõ ràng — machine không advance cho đến khi condition được đáp ứng.
Phase 1 — Pre-flight và isolation. Orchestrator map cấu trúc solution, dependency graph, và likely breaking zone. Công việc bắt đầu trên isolated branch. Baseline không bao giờ bị chạm. Output: dependency map và breaking-zone inventory.
Phase 2 — Guided migration. Legacy pattern được transform sang modern equivalent và dependency được align cho target platform. Ưu tiên là tính đúng đắn của platform shape, không phải compilation thành công bề mặt. Fix compile nhưng vi phạm migration pattern không được chấp nhận.
Phase 3 — Build-Fix Loop. Đây là nơi agentic AI thể hiện giá trị. Orchestrator build, classify error theo migration debt index, dispatch Code-Fix theo batch có kiểm soát, chạy Reviewer gate, commit checkpoint, và lặp lại. Mỗi iteration không phải retry — mà là classify, dispatch, review, checkpoint. Reviewer gate chặn bất kỳ fix nào compile được nhưng vi phạm migration intent. Khi debt index trống, loop thoát.
Nếu orchestrator gặp case mơ hồ — nhiều fix hợp lệ mà chỉ một đúng — nó dừng lại, trình bày lựa chọn kèm đánh đổi, và chờ developer quyết định. Không đoán. Đây là escalation model.
Phase 4 — Release build và CMS boot validation. Debug build không đủ. Release-mode compilation phát lộ optimization break theo cách Debug không thể. CMS startup validation phát lộ wiring issue chỉ xuất hiện ở runtime. Phase này lặp lại cho đến khi cả hai pass sạch.
Phase 5 — Output artifacts. Machine compile tất cả run output thành structured handover package: PR-ready branch với checkpoint commit, change log theo pattern families, build log, remaining decisions list (item intentionally escalated), stabilization checklist cho solution footprint, và skill enrichment notes cho run tiếp theo.
6. Ranh giới handover
Machine dừng khi CMS backend khởi động sạch và PR-ready branch tồn tại. Tất cả sau đó — integration stabilization, functional và exploratory testing, performance hardening, cutover rehearsal, và production deployment — thuộc về delivery team, thường hai đến sáu tuần tùy solution footprint.
Ranh giới này không phải giới hạn kỹ thuật. Đây là lựa chọn thiết kế có chủ ý. Gộp "automated refactoring complete" với "ready to deploy" là cách hệ thống agentic AI mất trust kỹ thuật. Machine không deploy. Không merge. Nó tạo PR và chờ human review và approve.
Với engineering leader, risk profile quen thuộc: branch-based workflow với full diff visibility, checkpoint commit ở mỗi phase, action log, và mandatory human review trước khi bất cứ thứ gì đến main. Điểm khác biệt duy nhất là refactoring xảy ra trong vài giờ thay vì nhiều tuần.
Kết luận
Bước CMS 11 + Commerce 13 → CMS 12 + Commerce 14 là lift lớn nhất trong hành trình hai bước. Repetitive refactor work vốn chiếm tuần đầu tiên nay là bài toán của machine, không phải của team. Engineer kế thừa clean buildable baseline và dành thời gian cho công việc thực sự đòi human judgement.
Một khi platform đã lên CMS 12 + Commerce 14, bước tiếp theo hẹp hơn và nhanh hơn. Phần 2 đề cập upgrade đó — và câu hỏi quan trọng hơn về cách tách platform uplift khỏi capability adoption.
Bài viết gốc được đăng bởi Hung Le Hoang trên Optimizely World, ngày 11 tháng 5 năm 2026. Niteco Engineering.