Cloudflare ra mắt ADLC: Khi AI Agent thay thế con người trong quy trình phát triển phần mềm

Các quản lý kỹ thuật đã dành vài thập kỷ qua để tìm cách giúp nhiều lập trình viên cùng làm việc trên một cơ sở mã nguồn chung. Công việc này bắt nguồn từ khái niệm “Systems Development Lifecycle” (RAND, 1975) — ngày nay thường được gọi là “Software Development Lifecycle” (SDLC), vốn xác định các giai đoạn sau:

AI đã biến bước vốn chậm và tốn kém nhất trước đây — triển khai (implementation) — trở nên nhanh nhất và rẻ nhất. Điều này kéo theo tác động ở các khâu hạ nguồn: gây quá tải cho những người chịu trách nhiệm cho tất cả các bước còn lại trong SDLC. Tình trạng này trải dài từ các nhà bảo trì mã nguồn mở bị "dội bom" bởi hàng ngàn pull request và issue, cho đến các kỹ sư vận hành (production engineers) đang cố gắng cứu hệ thống không bị sập khi tốc độ bàn giao phần mềm tăng lên theo cấp số nhân.

Tất cả chúng ta đều đang cố gắng cứu hệ thống, khách hàng và chính bản thân mình khỏi sự cẩu thả (slop).

Câu trả lời — một cách nghịch lý — là trao quyền cho các tác nhân (agents) để làm được nhiều việc hơn. Điều đó hoàn toàn công bằng! Bạn sẽ không bao giờ để một kỹ sư trong nhóm viết code, rồi lại mong đợi người khác phải xác thực, hợp nhất (merge), triển khai, trực ca vận hành và phân loại lỗi. Nhưng đó chính là điều hầu hết các công ty đang làm với các tác nhân hiện nay. Các mô hình đã cải thiện đáng kể và các tác nhân đang hoạt động trong khoảng thời gian dài hơn, có khả năng đảm nhận những nhiệm vụ lớn hơn nhiều. Tuy nhiên, chúng vẫn chưa được sử dụng đồng bộ trên toàn bộ SDLC.

Cloudflare coi các tác nhân như khách hàng của chúng tôi. Chúng có thể mua tên miền, tạo tài khoản tạm thời và sử dụng toàn bộ API của Cloudflare. Chúng tôi biết rằng các tác nhân cần API và công cụ để có thể quản lý toàn bộ SDLC thay mặt cho khách hàng của chúng tôi — chứ không chỉ là giai đoạn bắt đầu.

Và vì vậy, hôm nay chúng tôi giới thiệu bước khởi đầu của một bộ công cụ mới cho phép các tác nhân vượt xa việc chỉ tạo mã nguồn và đảm nhận nhiều phần hơn trong SDLC. Chúng tôi chia sẻ những gì mình đã xây dựng và học hỏi được khi cố gắng tự giải quyết vấn đề này:

Tuy nhiên, có một điều lớn lao hơn ở đây. Khi nhìn vào SDLC, ngay cả với sự tự động hóa tốt nhất, các giả định của nó cũng không thể mở rộng theo khối lượng mã nguồn mà các tác nhân có thể viết và tốc độ mà các nhóm phần mềm phải đạt được để cạnh tranh. Chúng tôi nghĩ đã đến lúc thay thế SDLC bằng ADLC — Agent Development Lifecycle (Vòng đời phát triển tác nhân).

SDLC dành cho các nhóm phần mềm. ADLC dành cho các nhà máy phần mềm (software factories).

Hiện tại, mọi người đều đang nói về việc xây dựng “nhà máy phần mềm” — các hệ thống do tác nhân điều khiển, tiếp nhận đầu vào và tự động xây dựng, cải tiến, triển khai và quản lý phần mềm. Nhận một đầu vào, cho dù đó là lỗi vận hành, báo cáo lỗi từ khách hàng hay ý tưởng cho một tính năng mới, và ủy quyền hoàn toàn cho một tác nhân.

Ngay cả với các tác nhân, hầu hết các dự án phần mềm vẫn bị hạn chế bởi các bước có sự tham gia của con người (human-in-the-loop). Con người phải nhắc lệnh (prompt) cho tác nhân, bảo chúng tiếp tục, hướng dẫn tác nhân áp dụng phản hồi từ code review, liên tục giám sát nhiều tác nhân và đưa ra chỉ dẫn. Trong hầu hết các nhóm phần mềm, con người vẫn quản lý từng bước trong mô hình SDLC — thay đổi duy nhất là họ ủy quyền các nhiệm vụ trong từng bước đó cho một tác nhân.

Và vì vậy, giấc mơ đằng sau các nhà máy phần mềm là: điều gì sẽ xảy ra nếu bạn hình dung lại cách tiếp cận này và xây dựng một nhà máy cho toàn bộ quy trình xây dựng phần mềm? Làm thế nào chúng ta có thể chuyển dịch thời gian của con người sang những việc thực sự đòi hỏi cảm hứng, gu thẩm mỹ và khả năng phán đoán của con người? Điều đó sẽ để lại cho chúng ta nhiều thời gian hơn để thiết kế, trò chuyện với khách hàng và mơ những giấc mơ lớn hơn.

Một nhà máy phần mềm phải quản lý các bước tương tự trong SDLC, nhưng nó đòi hỏi nhiều hơn từ nền tảng mà nó được xây dựng trên đó. Bởi vì khi bạn trao chìa khóa và để tác nhân cầm lái, mọi bước thủ công vốn dựa vào con người trước đây phải được điều chỉnh để trở nên:

Chúng ta cần một cái gì đó mới nếu muốn làm cho các nhà máy phần mềm an toàn khi sử dụng cho phần mềm vận hành thực tế. Các nhà máy phần mềm đối mặt với thách thức tương tự như các hệ thống tự hành khác như xe tự lái — thách thức trong việc chuyển từ hoạt động thành công 80% thời gian sang đạt được độ tin cậy cao hơn mức 99%.

Để trao chìa khóa điều khiển SDLC cho các tác nhân, bạn không thể đưa cho chúng một chiếc xe được thiết kế cho con người.

Một phương tiện tự hành được trang bị đầy đủ các cảm biến và công nghệ mà một chiếc xe thông thường không có. Cảm biến Lidar, camera, khả năng tính toán mạnh mẽ để chạy suy luận (inference) và khả năng kết nối với hệ thống chỉ huy trung tâm có thể tiếp quản từ xa nếu cần.

Để một phương tiện tự hành đạt hiệu suất lái xe bằng 80% con người, chúng ta có lẽ không cần tất cả những thứ này. Xe tự lái đã đạt mức 80% so với con người từ 10 năm trước. Nhưng đó không phải là tiêu chuẩn cần đạt được — tiêu chuẩn là phải tốt hơn và an toàn hơn nhiều so với tài xế con người. Đó là điều chúng ta mong đợi khi trao chìa khóa cho một cỗ máy, để cảm thấy an toàn khi chợp mắt trong lúc xe đang chạy trên đường 101 với tốc độ 60 dặm/giờ. Và đó là lý do tại sao các phương tiện tự hành có công nghệ được xây dựng chuyên biệt cho việc tự lái — đó là thứ tạo dựng niềm tin và xử lý các tình huống biên (edge cases) không thể thiết kế trước.

Điều tương tự cũng đúng với phần mềm tự lái. Hãy tự hỏi bản thân — tại sao bạn vẫn chưa để tác nhân của mình tự động phê duyệt và hợp nhất các PR của chính nó vào các dịch vụ vận hành của bạn? Càng đặt cược lớn vào những gì bạn xây dựng, danh sách lý do của bạn gần như chắc chắn càng dài.

Khi bạn bắt đầu phân tích không chỉ tất cả những thứ có thể gây ra thảm họa trong quy trình này, mà còn cả những thứ cần thiết để xây dựng đúng sản phẩm cho khách hàng, bạn sẽ thấy nó cực kỳ phức tạp. Nó không khớp với một tập hợp các bước tuyến tính trong tệp YAML của GitHub Actions, và nó vượt xa việc chạy các bài kiểm tra tự động truyền thống. Ngay cả một thay đổi nhỏ đối với bảng điều khiển (dashboard) cũng có thể bao gồm nhiều vai trò, chuyên môn và cấu trúc tổ chức, và những thay đổi mang tính chủ quan là khó kiểm thử và khó ủy quyền nhất. Hầu hết những thứ này hiện nay có lẽ không nằm trong quy trình CI/CD của bạn. Nhưng chúng sẽ cần phải có, nếu bạn muốn chúng vẫn diễn ra trong khi trao toàn quyền kiểm soát cho các tác nhân vận hành nhà máy phần mềm.

Để các tác nhân điều khiển toàn bộ quy trình, chúng ta cần một cách tốt hơn để điều phối chuỗi các bước năng động này. Chúng tôi nghĩ đó là Workflow, với khả năng tạo ra các container, tác nhân và trình duyệt. Một Workflow có thể thiết lập các feature flag và kích hoạt chúng cho người dùng thử nghiệm, điều tra nhật ký (logs) và dấu vết (traces), quan sát các chỉ số vận hành khi một thay đổi dần được triển khai, và thực hiện mọi thứ khác cần thiết để bàn giao một cách an toàn.

Một quy trình CI/CD chỉ là một Workflow. Nhưng một Workflow có thể làm được nhiều điều hơn thế rất nhiều.

Cloudflare Workflows cho phép bạn liên kết nhiều bước lại với nhau, tự động thử lại các tác vụ thất bại và duy trì trạng thái trong vài phút, vài giờ hoặc thậm chí vài tuần. Chúng được thiết kế để mã hóa các quy trình kinh doanh phức tạp và năng động thành một chương trình logic và dễ hiểu. Bài viết này phân tích lý do tại sao Workflows, kết hợp với Artifacts, làm cho việc định nghĩa và kích hoạt các quy trình CI/CD trở nên đơn giản hơn về cơ bản. Ví dụ:

Tuy nhiên, Workflows không chỉ dừng lại ở một loạt các bước tuyến tính. Chúng có thể được định nghĩa một cách năng động và có thể tạo ra các tác nhân hoặc các Workflow khác. Ví dụ này cho thấy một Workflow xem xét dữ liệu mới từ ngày hôm trước. Workflow có toàn quyền kiểm soát thời điểm và cách thức tác nhân được nhắc lệnh, và có thể truyền ngữ cảnh giữa các bước:

Một khi bạn thấy mô hình này và bị "nghiện Workflow" như Cloudflare, bạn bắt đầu tự hỏi: tôi còn có thể để Workflow xử lý việc gì khác cho mình không? Còn những bước nào khác đang bị nghẽn bởi con người mà tôi có thể ủy quyền cho sự kết hợp giữa Workflow + các tác nhân Flue?

ADLC hoàn chỉnh, trên nền tảng Cloudflare

Với việc Workflows có khả năng điều phối các bước phức tạp và Artifacts đóng vai trò là lớp lưu trữ cho mã nguồn, khi bạn nhìn vào các giai đoạn SDLC, mọi thứ một tác nhân cần để sở hữu toàn bộ quy trình xây dựng, bàn giao và bảo trì phần mềm đều có trên Cloudflare:

Giai đoạn SDLC

Cloudflare

Lập kế hoạchThiết kếTriển khai

Vite, Rolldown và Oxc — chuỗi công cụ nhanh nhất cho tác nhân của bạn; Phát triển cục bộ cho mọi thứ — những gì tác nhân thấy cục bộ chính là runtime và môi trường sẽ chạy trong môi trường vận hành; Local Explorer, Local Traces — tác nhân của bạn có cùng các API để gỡ lỗi cục bộ như khi ở môi trường vận hành; Remote bindings — cho phép tác nhân chạy code cục bộ trong khi sử dụng tài nguyên vận hành thực tế đang chạy trên Cloudflare; Preview URLs — cung cấp cho mỗi pull request một bản xem trước để tác nhân xác thực và sử dụng.

Kiểm thử

Browser Run — các trình duyệt không giao diện (headless browsers) có thể lập trình trên đám mây; Vitest — chạy các bài kiểm tra trong runtime của Workers.

Triển khai

Flagship — mỗi thay đổi đều có feature flag riêng; Triển khai dần dần (Gradual Deployments) — triển khai các thay đổi mã nguồn cho một tỷ lệ phần trăm lưu lượng truy cập, tăng dần theo thời gian.

Bảo trìNghỉ hưu

Workers Logs — cho phép tác nhân theo dõi nhật ký trực tiếp hoặc truy vấn ad-hoc để xác định các vấn đề cần sửa chữa tự động; Agent Traces — ghi lại mọi phiên làm việc của tác nhân và sử dụng nó để cải thiện; Cloudflare MCP Server — được hỗ trợ bởi Code Mode và Dynamic Workers; Analytics Engine — phân tích dữ liệu quy mô lớn được xây dựng trên Clickhouse, để cho phép các tác nhân truy vấn ai đang sử dụng cái gì.

Các nguyên mẫu để xây dựng nhà máy phần mềm của bạn

Hiện tại, những người đi đầu đang xây dựng các nhà máy phần mềm của tương lai. Cuối cùng, các nhà máy phần mềm sẽ trở thành cách thức bình thường mà mọi người xây dựng phần mềm, giống như cách các tác nhân và AI đang làm. Nhưng đối với hầu hết mọi người và hầu hết các tổ chức, chúng ta vẫn chưa đạt đến mức đó.

Chúng tôi muốn thay đổi điều đó.

Để làm được như vậy, những câu hỏi chúng tôi đã tự đặt ra là: làm thế nào chúng ta có thể làm cho mọi thứ trở nên đơn giản và dễ tiếp cận để mọi người trên Internet đều có thể hưởng lợi từ một sự thay đổi mô hình như thế này? Và đâu là những nguyên mẫu lớp nền tảng mà chúng tôi có thể mở ra cho tất cả mọi người, từ startup nhỏ nhất đến các nền tảng lớn nhất thế giới?