AI-First Software Delivery: Cân bằng giữa Đổi mới và Kỷ luật Kỹ thuật trong Kỷ nguyên Mới

Wes Reisz thảo luận về sự chuyển dịch sang mô hình phát triển phần mềm ưu tiên AI (AI-first), nhấn mạnh rằng quy trình tác nhân (agentic workflows) không phải là giải pháp chung cho mọi trường hợp. Ông giới thiệu mô hình chiến lược dựa trên tuổi thọ mã nguồn và khả năng xác thực tự động để lựa chọn giữa các tác nhân có giám sát và không giám sát. Bài viết cũng chia sẻ khung RIPER-5 để tối ưu hóa kỷ luật kỹ thuật khi làm việc với LLM.

Trong bối cảnh bùng nổ của Trí tuệ nhân tạo (AI), ngành công nghiệp phần mềm đang chứng kiến sự chuyển dịch mạnh mẽ hướng tới các mô hình phát triển ưu tiên AI (AI-First Software Delivery - AIFSD). Tuy nhiên, việc áp dụng AI vào quy trình phát triển phần mềm (SDLC) không đơn thuần là thay thế con người bằng các tác nhân tự động, mà đòi hỏi một chiến lược cân bằng giữa đổi mới sáng tạo và các thực tiễn kỹ thuật đã được chứng minh.

Wes Reisz, Technical Principal tại Thoughtworks, đã có bài chia sẻ sâu sắc về hành trình này tại hội nghị QCon AI. Ông nhấn mạnh rằng AIFSD không phải là giải pháp "một kích cỡ vừa cho tất cả" (one-size-fits-all). Tùy thuộc vào bối cảnh dự án, mức độ hiểu biết về lĩnh vực (domain knowledge) và cơ sở hạ tầng hiện có, các đội ngũ cần lựa chọn giữa các tác nhân có giám sát (supervised agents) và không giám sát (unsupervised agents) một cách khôn ngoan.

AI-First Software Delivery

Mô hình chiến lược: Khi nào dùng Agent nào?

Để trả lời cho câu hỏi tại sao không phải lúc nào cũng sử dụng quy trình đa tác nhân hoàn toàn tự động, Wes Reisz đề xuất một mô hình hai chiều (two-by-two model). Mô hình này giúp các kỹ sư quyết định cách tiếp cận phù hợp dựa trên hai trục chính:

Tuổi thọ của mã nguồn (Code Longevity): Mã nguồn này tồn tại trong bao lâu? Nó chỉ là mã tạm thời để thăm dò (POC) hay sẽ chạy lâu dài trong môi trường sản xuất (production)?
Mức độ xác thực tự động (Degree of Automated Verification): Chúng ta có thể tự động hóa việc kiểm tra (verify) mã nguồn đó hay không?

Dựa trên hai trục này, chúng ta có thể xác định bốn khu vực chiến lược:

Phát triển thăm dò (Exploratory Development): Mã ngắn hạn, xác thực thấp. Đây là giai đoạn "vibe coding" hoặc tạo POC nhanh để thu thập thông tin, không đưa vào production.
Cảm nhận lĩnh vực (Domain Sensing): Mã ngắn hạn, xác thực cao. Sử dụng các tác nhân nghiên cứu sâu (deep research agents) để hiểu về legacy codebase hoặc quy tắc kinh doanh khi mới bước vào một dự án mới.
Tác nhân có giám sát (Supervised Coding Agents): Mã dài hạn, xác thực thấp. Đây là giai đoạn mà đội ngũ của Wes đang áp dụng. Khi chưa có đủ kiến thức lĩnh vực để xây dựng các bài kiểm tra tự động toàn diện, việc sử dụng tác nhân có giám sát (lập trình cặp với AI) là an toàn nhất.
Tác nhân không giám sát (Unsupervised Coding Agents): Mã dài hạn, xác thực cao. Khi đã có đủ kiến thức và hệ thống kiểm thử chặt chẽ, đội ngũ có thể chuyển sang sử dụng các tác nhân tự động chạy ngầm.

Kỷ luật kỹ thuật và Khung RIPER-5

Một trong những thách thức lớn nhất khi làm việc với Mô hình ngôn ngữ lớn (LLM) là tính không xác định (non-deterministic). Để quản lý điều này, Wes giới thiệu khung RIPER-5, một phương pháp có cấu trúc để "đặt" LLM vào các chế độ tư duy cụ thể, tương tự như cách một kỹ sư tư duy. RIPER-5 bao gồm 5 bước:

Research (Nghiên cứu): LLM thu thập ngữ cảnh, đọc file, đặt câu hỏi làm rõ. Lưu ý: Trong bước này, LLM bị cấm đề xuất giải pháp hoặc viết mã.
Innovate (Đổi mới): LLM đưa ra các phương án triển khai khác nhau (ví dụ: 3 lựa chọn). Lưu ý: Chỉ đưa ra ý tưởng, chưa lập kế hoạch chi tiết hay viết mã.
Plan (Lập kế hoạch): Chia nhỏ đặc tả (spec) thành các nhiệm vụ (tasks) cụ thể. Lưu ý: Chỉ lập kế hoạch, chưa thực thi mã.
Execute (Thực thi): Viết mã dựa trên kế hoạch đã duyệt. Lưu ý: Không được phép lệch khỏi kế hoạch đã định.
Review (Xem xét): Kiểm tra lại mã so với kế hoạch ban đầu để phát hiện sự lệch pha (drift).

Khung này giúp biến LLM thành một đối tác lập trình (pair programming) hiệu quả thay vì một công cụ tạo mã hỗn loạn. Nó cũng giúp duy trì "hợp đồng" giữa kỹ sư và AI thông qua các đặc tả kỹ thuật (spec-driven development).

AI khuếch đại thực tiễn hiện có

Wes Reisz cảnh báo rằng AI không thay thế kỷ luật kỹ thuật, mà nó khuếch đại những gì bạn đang có. Nếu nền tảng kỹ thuật của bạn yếu kém, AI sẽ làm tình hình tồi tệ đi nhanh hơn. Ngược lại, nếu bạn có các thực tiễn tốt (sensible defaults), AI sẽ giúp bạn đi nhanh hơn.

Các thực tiễn "mặc định hợp lý" mà Thoughtworks duy trì trong kỷ nguyên AI bao gồm:

Phát triển dựa trên đặc tả (Spec-driven development).
Lập trình cặp (Pair programming) - vẫn cần thiết vì việc review mã do AI tạo ra rất mệt mỏi.
Phát triển dựa trên nhánh chính (Trunk-based development).
Tích hợp liên tục (Continuous Integration) và Phân phối liên tục (Continuous Delivery).

Kết luận

Hành trình chuyển đổi sang AI-First Software Delivery là một quá trình liên tục. Đội ngũ không cần phải áp dụng ngay lập tức các tác nhân tự động hoàn toàn nếu chưa sẵn sàng. Bắt đầu với các tác nhân có giám sát, áp dụng các khung quy trình như RIPER-5 và củng cố kỷ luật kỹ thuật là những bước đi vững chắc để tận dụng sức mạnh của AI một cách an toàn và hiệu quả.