Kỹ sư Anthropic chia sẻ quy trình 6 bước để hiện đại hóa mã nguồn bằng AI

Trong loạt bài Notes from the Field, các kỹ sư triển khai tiền phương của Anthropic chia sẻ những phương pháp tốt nhất được đúc kết từ các dự án thực tế của khách hàng. Trong bài viết này, chúng tôi chia sẻ kinh nghiệm quản lý các dự án hiện đại hóa mã nguồn quy mô lớn.

Hiện đại hóa mã nguồn trước đây từng được coi là nỗ lực kéo dài nhiều năm với sự tham gia của toàn bộ nhân sự, nay có thể hoàn thành trong vài tháng (hoặc vài tuần), nhưng khối lượng công việc tổ chức ở cả hai phía thường vẫn giữ nguyên.

Ví dụ, mọi thay đổi đối với một hệ thống ngân hàng quan trọng đều phải trải qua quy trình quản lý thay đổi, đánh giá và phê duyệt. Đây là một quy trình chặt chẽ vì các cơ quan quản lý, kiểm toán viên và doanh nghiệp đều yêu cầu điều đó.

Những quy trình đó chính là yếu tố tạo nên sự tin cậy cho các hệ thống quan trọng, và chúng được xây dựng dựa trên giả định rằng con người là người viết ra mỗi thay đổi và con người sẽ đánh giá từng bản diff. Khi các tác nhân (agent) tăng tốc việc viết mã, nút thắt cổ chai sẽ chuyển từ khâu tạo thay đổi sang khâu huy động tổ chức để xử lý các thay đổi đó.

Bài viết này đề cập đến những công việc mà doanh nghiệp phải thực hiện trước khi quá trình hiện đại hóa diễn ra: xác định thế nào là hoàn thành, bằng chứng nào cần đi kèm với một thay đổi, cách thức đưa các thay đổi đã được chứng nhận vào môi trường production, và những gì cần chuẩn bị để hệ thống có thể vận hành.

Chúng tôi chia quy trình này thành sáu bước:

1. Xác định mục tiêu: tech stack và hành vi mà mã nguồn sau khi hiện đại hóa phải đạt được.
2. Tạo chứng nhận: các điều kiện mà những thay đổi phải đáp ứng để được coi là chính xác so với trạng thái mục tiêu.
3. Thiết lập chính sách thúc đẩy: lộ trình để các thay đổi đã được chứng nhận đi vào môi trường production theo tốc độ mà chúng được tạo ra.
4. Chuẩn bị các điều kiện tiên quyết: môi trường, CI/CD, năng lực đánh giá và các phê duyệt.
5. Xây dựng và tinh chỉnh quy trình làm việc của agent: quy trình làm việc động tùy chỉnh của Claude Code giúp phân phối quá trình hiện đại hóa thành nhiều luồng công việc nhỏ hơn, chạy song song bởi các subagent để tạo ra các thay đổi. Quy trình này được xây dựng dựa trên mục tiêu, chứng nhận và chính sách thúc đẩy.
6. Chạy hiện đại hóa: kiểm chứng quy trình từ đầu đến cuối trên một phần nhỏ của codebase, sau đó mở rộng quy mô.

Bước 1: Xác định mục tiêu

Mục tiêu là trạng thái cuối cùng của quá trình hiện đại hóa. Trạng thái cuối cùng mong muốn sẽ xác định loại hình hiện đại hóa trong ba loại mà bạn đang thực hiện, được trình bày chi tiết trong bảng dưới đây.

Xác định loại hình hiện đại hóa

Việc xác định loại hình hiện đại hóa thường là chủ đề tranh luận trong nội bộ tổ chức. Theo kinh nghiệm của chúng tôi, những người gần gũi nhất với môi trường production thường muốn thay đổi stack nhưng giữ nguyên hành vi để kiểm soát rủi ro (hiện đại hóa dạng transform). Ở phía ngược lại thường là các kỹ sư đã gắn bó lâu năm với codebase, họ muốn tận dụng quá trình hiện đại hóa để giải quyết nợ kỹ thuật, cùng với các bên liên quan khác muốn nhân cơ hội này để đưa ra các yêu cầu mới (hiện đại hóa dạng reimagine).

Cả hai quan điểm đều hợp lý, nhưng nếu vấn đề không được giải quyết, nó sẽ trỗi dậy sau đó như một cuộc tranh cãi về việc liệu một thay đổi nhất định có "chính xác" hay không. Việc đạt được sự đồng thuận về lộ trình cần thực hiện sẽ tạo ra ma sát ban đầu, nhưng giúp tinh giản toàn bộ dự án.

Lập bản đồ codebase và tạo đặc tả hành vi

Hiểu rõ hệ thống hiện tại thường là bước đầu tiên tốt nhất để xác định mục tiêu. Việc trích xuất những gì mã nguồn cũ thực sự làm và tạo danh mục các hành vi hiện tại giúp dễ dàng quyết định xem các phần nào nên được thay đổi hoặc loại bỏ, từ đó xác định xem đó là hiện đại hóa dạng transform hay reimagine. Điều này cũng thường tiết lộ các logic kinh doanh và các trường hợp biên (edge cases) chưa được biết đến.

Claude có thể thực hiện phần lớn công việc khám phá đó bằng cách lập bản đồ các phụ thuộc và ghi lại các quy trình làm việc mà không ai còn nhớ cách xây dựng. Các lệnh assess, map và extract-rules của plugin hiện đại hóa mã nguồn giúp khai thác các quy tắc kinh doanh kèm theo trích dẫn nguồn để các kỹ sư có thể xem xét lại.

Tuy nhiên, việc khám phá của Claude có thể không nắm bắt được toàn bộ cách thức vận hành của một hệ thống legacy. Các cuộc phỏng vấn với người dùng doanh nghiệp, nhà phát triển và tài liệu nội bộ có thể lấp đầy những khoảng trống đó. Việc thu thập ngữ cảnh có thể mất thời gian ban đầu, nhưng chất lượng của ngữ cảnh đó sẽ định hình mọi quyết định mà quy trình làm việc đưa ra sau này.

Đối với dạng reimagine, việc xác định mục tiêu đòi hỏi thêm công việc: một bản đặc tả hành vi chi tiết cần được viết ra và thống nhất với các nhóm người dùng.

Thiết lập lý do và mục tiêu của dự án

Song song với việc xác định mục tiêu, tổ chức nên cân nhắc lý do tại sao quá trình hiện đại hóa lại đáng để thực hiện. Hiện đại hóa các hệ thống legacy có thể giảm chi phí bảo trì và vận hành, tuy nhiên, theo kinh nghiệm của chúng tôi, giảm chi phí không phải là mục tiêu thúc đẩy chính của hầu hết các dự án hiện đại hóa.

Giảm thiểu rủi ro thường là lợi ích quan trọng nhất của hiện đại hóa. Hãy cân nhắc rủi ro nếu không thực hiện hiện đại hóa khi tranh luận về việc có nên triển khai dự án hay không.

Ví dụ, một hệ thống chứa các lỗ hổng chưa được vá có thể dẫn đến vi phạm an ninh mạng hoặc sự cố nghiêm trọng đủ để gây rủi ro cho chính doanh nghiệp. Một runtime không còn được hỗ trợ hoặc đội ngũ kỹ sư hiểu về hệ thống ngày càng ít đi sẽ làm trầm trọng thêm rủi ro đó.

Các công cụ lập trình dựa trên agent như Claude Code đã rút ngắn thời gian hiện đại hóa, nhưng ngân sách vẫn khó ước tính, dẫn đến sự trì trệ. Chúng tôi đã công bố chi phí của một số dự án hiện đại hóa quy mô lớn của mình, cũng như những đơn vị khác đã làm. Những thông tin này có thể đóng vai trò là cơ sở tham chiếu sơ bộ, và chúng tôi có thêm hướng dẫn về dự báo ngân sách ở cuối tài liệu này.

Thách thức chính trong việc khởi động các dự án này thường là xây dựng sự đồng thuận và cam kết nội bộ từ các nhóm sở hữu hệ thống và các nhóm phụ thuộc vào nó. Việc xây dựng bài toán kinh doanh và thiết lập mục tiêu dự án, thường là ở cấp lãnh đạo, sẽ giúp phần này của quy trình trở nên dễ dàng hơn. Điều này cũng giúp củng cố các đánh đổi trong chứng nhận và chính sách thúc đẩy theo sau. Khi các bên liên quan không đồng ý về mức độ rủi ro mà một thay đổi có thể mang lại, rủi ro của việc không hiện đại hóa chính là đối trọng.

Bước 2: Xác định chứng nhận

Chứng nhận là tập hợp các điều kiện hoặc bài kiểm tra mà mọi thay đổi trong quá trình hiện đại hóa phải đáp ứng. Hãy chọn các điều kiện mang lại bằng chứng tích lũy mạnh mẽ nhất cho thấy thay đổi đó là chính xác so với mục tiêu.

Mỗi điều kiện cần có khả năng kiểm tra tự động mà không cần con người can thiệp, để quy trình làm việc của agent có thể lặp lại trên một thay đổi cho đến khi nó đáp ứng chứng nhận hoặc gắn cờ để con người xem xét nếu không thể đạt được.

Những gì có trong chứng nhận phụ thuộc vào mục tiêu, nhưng thường sẽ được rút ra từ danh sách này:

• Bộ kiểm thử gốc vượt qua (pass)
• Các bài kiểm thử do Claude viết trong quá trình hiện đại hóa đều vượt qua (pass)
• Độ bao phủ kiểm thử (test coverage) đạt ngưỡng đã thỏa thuận
• Các tiêu chuẩn hiệu năng (performance benchmarks) nằm trong giới hạn đã thỏa thuận
• Các đánh giá đối kháng độc lập bởi Claude, mỗi đánh giá trong một cửa sổ ngữ cảnh (context window) mới, không tìm thấy vấn đề chặn nào
• Đối với giao diện người dùng, tính năng sử dụng máy tính (computer use) do Claude điều khiển không phát hiện lỗi hồi quy (regressions)
• Phiên bản hiện tại và phiên bản mục tiêu tạo ra cùng một đầu ra từ cùng một đầu vào, có thể là dữ liệu trực tiếp, dữ liệu đã ghi lại hoặc dữ liệu do Claude tạo ra
• Trạng thái bền vững (persisted state) và định dạng truyền tin (wire formats) đảm bảo tính toàn vẹn khi chuyển đổi qua lại giữa phiên bản hiện tại và phiên bản mục tiêu
• Các thay đổi được chạy trong môi trường staging trong một khoảng thời gian đã thỏa thuận mà không có lỗi hồi quy về tỷ lệ lỗi, độ trễ hoặc cảnh báo
• Phân tích tĩnh (static analysis) và quét bảo mật không cho thấy phát hiện mới nào
• Đối với các mục tiêu đã biên dịch, bản dựng (build) sạch và vượt qua các kiểm tra kiểu (type checks)

Hãy soạn thảo chứng chỉ (certificate) cùng với những người sẽ đánh giá và thúc đẩy các thay đổi vào môi trường production. Hãy mời các nhà phát triển, nhóm người dùng và lãnh đạo doanh nghiệp đang phụ thuộc vào cơ sở mã (codebase) tham gia ngay từ khi chứng chỉ và quy trình làm việc của tác nhân (agentic workflow) vẫn đang trong giai đoạn thiết kế.

Chuyên môn của họ giúp định hình các tiêu chí đo lường của chứng chỉ, và sự tham gia sớm của họ chính là yếu tố tạo nên sự đồng thuận khi các thay đổi đến giai đoạn đánh giá. Một cách kiểm tra hiệu quả cho chứng chỉ hoàn thiện là liệu họ có cảm thấy thoải mái khi hợp nhất (merge) chỉ dựa trên bằng chứng từ chứng chỉ đó hay không. Nếu họ thấy tiêu chuẩn của mình trong đó, chính sách thúc đẩy ở Bước 3 có thể được nới lỏng hơn.

Những gì chứng chỉ kiểm tra và cách thức kiểm tra phụ thuộc vào loại hình hiện đại hóa (modernization type).

• Đối với hiện đại hóa nâng cấp (uplift modernization), tính tương đương được đối chiếu với cơ sở mã gốc và bộ kiểm thử gốc có thể là cốt lõi của chứng chỉ.
• Đối với hiện đại hóa chuyển đổi (transform modernization), tính tương đương cũng được đối chiếu với cơ sở mã gốc, nhưng bộ kiểm thử gốc hiếm khi chạy được trên ngăn xếp (stack) mới. Thay vào đó, việc phát lại lưu lượng truy cập production (replay of production traffic), kiểm thử khác biệt (differential testing) giữa cũ và mới, cùng triển khai song song với production (prod-parallel deployment) sẽ đảm nhận phần lớn công việc.
• Đối với hiện đại hóa tái hình dung (reimagine modernization), chứng chỉ được neo vào đặc tả hành vi (behavioral spec). Đây là trường hợp khó nhất. Một đặc tả ít khách quan hơn so với hệ thống hiện có để thực hiện so sánh khác biệt (diff), vì vậy cần mức độ đánh giá của mô hình cao hơn, điều này có thể dẫn đến kết quả biến thiên nhiều hơn. Ở đây, chứng chỉ dựa vào các bài kiểm tra được viết từ đặc tả, các đánh giá đối kháng độc lập bởi Claude để kiểm tra từng thay đổi so với đặc tả, và các kiểm tra khác biệt nơi hệ thống mới duy trì hành vi của hệ thống cũ. Hãy dự kiến sửa đổi chứng chỉ khi đặc tả được làm rõ: các lỗ hổng trong đặc tả sẽ xuất hiện ở đây đầu tiên.

Các hệ thống cũ thường có độ bao phủ kiểm thử mỏng, các bài kiểm tra không ổn định (flaky tests) và ít dữ liệu đo lường (telemetry). Một phần của việc xác định chứng chỉ là xác định các lỗ hổng này. Nếu khó hỗ trợ một chứng chỉ mạnh, một trong những việc hữu ích nhất ở bước này là sử dụng Claude để xây dựng các bằng chứng còn thiếu, cho dù đó là thiết lập môi trường song song với production, xây dựng công cụ phát lại (replay harness) hay viết thêm các bài kiểm tra.

Bước 3: Thiết lập chính sách thúc đẩy (promotion policy)

Các tác nhân (agents) sẽ tạo ra các thay đổi nhanh hơn nhiều so với bất kỳ đội ngũ con người nào có thể đánh giá từng thay đổi một (diff-by-diff). Chính sách thúc đẩy là một lộ trình đánh giá theo tầng–được ghi lại và thống nhất trước–nhằm thiết lập độ sâu của việc đánh giá thủ công cho một thay đổi, để quá trình hiện đại hóa có thể hoàn thành đúng tiến độ chấp nhận được.

Giống như chứng chỉ, hãy thực hiện bước này với các bên đánh giá và tích hợp nó vào quy trình quản lý thay đổi hiện có của tổ chức bạn bất cứ khi nào có thể. Chi tiết sẽ khác nhau tùy theo tổ chức và các đánh đổi rủi ro mà tổ chức đó đối mặt, nhưng có một vài quy tắc áp dụng ở mọi nơi:

• Phân tầng các thay đổi theo phạm vi ảnh hưởng (blast radius) và độ tin cậy của tác nhân. Hãy sử dụng phân loại thay đổi hoặc rủi ro của chính tổ chức bạn nếu có. Duy trì đánh giá thủ công đầy đủ cho các đường dẫn quan trọng (critical paths).
• Khắc phục các cờ (flags) lặp lại tại nguồn. Nhóm và phân tích các thay đổi được gắn cờ theo thời gian. Khi cùng một loại cờ liên tục xuất hiện, hãy sửa nguyên nhân trong quy trình làm việc của tác nhân hoặc trong chứng chỉ thay vì đánh giá từng trường hợp một.
• Thiết kế định dạng đầu ra cùng với các bên đánh giá. Thống nhất thông tin và định dạng nào giúp việc đánh giá nhanh nhất, và tín hiệu nào mang lại độ tin cậy cao hơn các tín hiệu khác. Hãy để họ đánh giá các kết quả đầu ra mẫu sớm ở Bước 5.
• Phân bổ thời gian của chuyên gia (SME) một cách hiệu quả. Các SME sẽ không đọc mọi diff cuối cùng, nhưng sự phán đoán của họ vẫn là nguồn lực khan hiếm. Hãy giúp họ dễ dàng đi thẳng đến các thay đổi trong các tầng rủi ro cao nhất và các quyết định của tác nhân đã được gắn cờ trong mỗi tầng đó, mà không cần phải lội qua các diff lớn. Một lượng nhỏ giờ làm việc của chuyên gia khi đó sẽ bao quát được các thay đổi mang nhiều rủi ro nhất.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗