Quy trình AI Driven

Một đội BrSE, lập trình viên và QA làm việc thế nào khi agent lo bản nháp đầu tiên của mọi thứ

Nhìn nhanh

• Vai trò áp dụng: BrSE, QA, lập trình viên, thiết kế, biên dịch
• Hình thức: Mỗi vai trò một plugin, cài riêng
• Trạng thái: QA dùng hàng ngày, các vai trò khác đang triển khai

1. Tài liệu cho agent đọc
2. Chuẩn hoá một lần
3. Testcase trước
4. Code theo testcase
5. Lỗi khép vòng lại

Lỗi lọt ra ngoài trở thành một testcase mới, và vòng lặp quay lại bước ba.

Vấn đề của cách làm cũ

Cách làm cũ tốn vài ngày cho mỗi tính năng

Hai con số đo từ chính đội mình, không phải lấy từ tài liệu bán hàng.

• QA mất khoảng hai ngày để viết testcase tích hợp cho một tính năng
• Lập trình viên mất thêm khoảng một ngày để chạy unit test bằng tay

Việc kiểm thử luôn bắt đầu quá muộn

Testcase có sau code nên không còn cơ hội định hình code.

• Lập trình viên làm xong tính năng trong khi chưa có testcase tích hợp
• Testcase do lập trình viên tự sinh thì mỏng, lỗi dồn sang khâu QA, tốn thêm thời gian log ticket và chạy quy trình xử lý

Mỗi người làm theo một tài liệu khác nhau

Lỗi âm thầm nhưng gây làm lại nhiều nhất.

• Lập trình viên và QA thường xuyên dùng hai phiên bản Basic Design khác nhau
• Mỗi bên lại tự nhờ AI tóm tắt tài liệu theo cách của mình, nên hai bản lệch nhau từ trước khi viết dòng code đầu tiên

Các bước

Viết tài liệu cho máy đọc, không chỉ cho người đọc

Tài liệu là đầu vào của mọi khâu phía sau nên agent phải đọc được.

• Dự án mới viết Basic Design bằng Markdown và giữ trong git để lịch sử thay đổi rõ ràng
• Yêu cầu thay đổi đi theo một mẫu ticket cố định thay vì viết tự do

Chuẩn hoá tài liệu một lần, ở một chỗ

Một bản chuẩn hoá duy nhất, làm một lần, mọi vai trò dùng chung.

• Tài liệu được kiểm theo quy ước nội bộ trước khi ai đó bắt đầu làm việc trên nó
• Tài liệu không đạt thì trả lại người viết, không cho chảy tiếp vào khâu code

Sinh testcase trước khi có code

Đây là bước đảo ngược thứ tự cũ, và cũng là bước quan trọng nhất.

• QA sinh testcase tích hợp từ bản đã chuẩn hoá rồi tự review lại
• Testcase sau review được merge vào một registry dùng chung, thành điểm tham chiếu cho cả tính năng
• Từ đó về sau, làm mới, đổi yêu cầu hay sửa lỗi đều phải cập nhật registry trước

Code theo testcase, không code theo cách hiểu riêng

Lập trình viên lấy thẳng testcase thay vì đọc lại tài liệu.

• Một MCP server mở registry ra để agent lấy testcase trong một bước, không phải đi vòng
• Code phải đáp ứng mọi case trong registry, chứ không phải đáp ứng cách lập trình viên hiểu tài liệu
• Trước khi bàn giao phải sinh và chạy test tự động đầu cuối, case nào bỏ qua thì ghi rõ lý do

Khép vòng lại khi có lỗi lọt

Một con bug được coi là một testcase còn thiếu, không chỉ là một khiếm khuyết.

• QA vẫn test tay, vì độ phủ do máy sinh ra không phải bằng chứng về chất lượng
• Nếu lỗi lọt do thiếu case thì bổ sung case đó vào registry
• Bản sửa sau đó sinh lại test tự động, nhờ vậy tài liệu, testcase, code và test luôn dính vào nhau

Nguyên tắc

Ra lệnh thay vì tự thao tác

Con người chuyển từ chỗ tạo ra kết quả sang chỗ giám sát kết quả.

• Agent lo bản nháp của tài liệu, thiết kế, code, testcase và cả phần review
• Việc của người là phán đoán kết quả và cải tiến agent cho lần sau tốt hơn

Mọi thứ tối ưu cho agent

Agent có mặt ở mọi khâu thì định dạng cũng phải hợp với agent.

• Markdown và JSON thay cho bảng tính
• Git thay cho ổ đĩa chia sẻ, vì lịch sử thay đổi cũng là một phần đầu vào
• Dựng sẵn MCP server thay vì bảo agent tự đi tìm dữ liệu

Giới hạn

• Cần ngân sách thật. Trên thực tế là mỗi người một tài khoản agent trả phí, nên đội nào không có kinh phí thì không áp dụng được.
• Cần được tự chọn quy trình và định dạng bàn giao. Nếu khách hàng quy định cả hai thì phần lớn nội dung ở đây không dùng được.
• Gắn với hệ sinh thái của một nhà cung cấp. Đội nào đã chuẩn hoá theo bộ công cụ agent khác thì phải dựng lại từ đầu.
• Agent có xu hướng bảo vệ kết quả của chính nó. Bảo nó tự kiểm tra thì phần nhiều nó sẽ biện minh chứ không tìm ra lỗi.
• Kết quả không ổn định giữa các lần chạy. Cùng một tài liệu, chạy lại cho ra bộ testcase khác, nên bắt buộc phải có người review trước khi merge.

Vì sao phải viết ra

Phần lớn đội đang dùng AI theo kiểu cá nhân. Một lập trình viên có một câu lệnh hay, một QA có câu khác, và không thứ gì hiệu quả với người này sống sót sang dự án sau. Chất lượng đầu ra lên xuống theo việc ai đang ngồi trước bàn phím.

Quy trình trong trang này sinh ra để xử lý đúng vấn đề đó. Nó không nói về kỹ năng ra lệnh của từng người, mà nói về cách làm cho cả đội cho ra kết quả nhất quán bất kể ai chạy, bằng cách cố định đầu vào, định dạng và thứ tự các bước.

Thứ thật sự đã đổi

Thay đổi quan trọng nhất là thứ tự. Cách cũ thì code có trước, testcase mô tả lại sau. Giờ testcase có trước và code phải viết sao cho thoả mãn nó. Mọi thứ còn lại trong quy trình tồn tại để phục vụ việc đảo ngược đó: một tài liệu agent đọc được, một bản chuẩn hoá duy nhất, và một registry mà agent của lập trình viên với tới được không cần người trung gian.

Nếu bạn định làm theo

Bắt đầu từ registry, đừng bắt đầu từ công cụ. Đám plugin có thể thay bằng thứ khác. Phần mang lại giá trị là việc có một bộ testcase thống nhất mà mọi vai trò cùng đọc và cùng ghi vào. Chỉ riêng thứ đó đã lấy được phần lớn lợi ích, còn không có nó thì công cụ nào cũng vô nghĩa.

Câu hỏi thường gặp

Quy trình này có thay thế QA không?

Không. Nó đẩy QA lên sớm hơn. QA giờ là người định ra tiêu chí nghiệm thu để lập trình viên code theo, và sau đó vẫn test tay. Thứ biến mất là hai ngày ngồi gõ, không phải phần phán đoán.

Làm sao ngăn agent bịa ra testcase?

Không ngăn được hoàn toàn. Vì vậy không có gì vào registry mà không qua người review, và registry nằm trong git đi theo quy trình pull request chứ không để agent ghi thẳng.

Lợi ích thật sự là gì?

Lớn nhất không phải tốc độ, mà là việc kiểm thử được đẩy lên trước khâu code. Phần đo được là hai ngày viết testcase và một ngày chạy unit test bằng tay cho mỗi tính năng mà cách làm cũ phải bỏ ra.

Dự án của tôi áp dụng được không?

Tuỳ vào ba điều: đội có ngân sách cho agent không, bạn có tự quyết được quy trình không, và định dạng bàn giao có do bạn chọn không. Điều nào bị bên khác ấn định thì chỉ áp dụng được một phần.