Buyer không cần cấm AI coding agent; buyer cần yêu cầu bằng chứng cho chất lượng và trách nhiệm. Bảy bằng chứng tối thiểu gồm truy vết yêu cầu đến code, test tự động, kiểm tra bảo mật, human review, tiêu chí hiệu năng, tài liệu vận hành và gói bàn giao quyền sở hữu. Nếu đội phát triển chỉ demo tính năng mà không cung cấp các bằng chứng này, phần mềm chưa sẵn sàng nghiệm thu.
AI viết code nhanh không đồng nghĩa phần mềm dễ nghiệm thu
Nghiên cứu và báo cáo ngành năm 2026 cùng chỉ về một thay đổi: giá trị của kỹ sư đang dịch từ gõ code sang thiết kế hệ thống, điều phối agent, review và xác minh. GitLab công bố khảo sát cho thấy tổ chức tạo code bằng AI nhanh hơn khả năng kiểm soát. Đây là dữ kiện từ khảo sát của nhà cung cấp và cần đọc trong bối cảnh đó, nhưng thông điệp thực dụng vẫn đúng: tốc độ tạo code không thay thế được trách nhiệm giao hàng.
Với buyer thuê outsourcing, câu hỏi không nên là đội có dùng AI hay không. Câu hỏi đúng là đội dùng AI ở bước nào, ai review, bằng chứng nào chứng minh yêu cầu đã được đáp ứng và doanh nghiệp nhận được gì khi hợp đồng kết thúc. Một nhà cung cấp tốt có thể dùng AI để tăng tốc nhưng vẫn giữ kiến trúc, test, bảo mật và quyết định phát hành dưới trách nhiệm của con người.
Bảy bằng chứng cần có trước khi ký biên bản nghiệm thu
- Ma trận traceability nối từng yêu cầu, user story hoặc acceptance criterion với pull request, test và bản phát hành.
- Bộ test tự động bao gồm đường đi chính, lỗi biên và regression quan trọng; báo cáo phải chạy được trong môi trường bàn giao.
- Kết quả security review cho dependency, secret, quyền truy cập, input validation và các luồng dữ liệu nhạy cảm.
- Dấu vết human review cho phần code quan trọng, bao gồm người duyệt và vấn đề đã yêu cầu sửa.
- Kết quả kiểm tra hiệu năng trên workload đã thống nhất, không dùng một demo lý tưởng làm đại diện.
- Runbook vận hành mô tả deploy, rollback, backup, monitoring, cảnh báo và cách xử lý sự cố phổ biến.
- Gói bàn giao gồm source code, tài khoản, biến môi trường, tài liệu kiến trúc, license dependency và quyền sở hữu trí tuệ.
Bảng nghiệm thu theo rủi ro
| Hạng mục | Bằng chứng | Dấu hiệu chưa đạt |
|---|---|---|
| Chức năng | Acceptance test | Chỉ demo bằng tay |
| Chất lượng | CI và regression test | Test không chạy lại được |
| Bảo mật | Review + dependency scan | Không rõ secret nằm đâu |
| Vận hành | Runbook + rollback | Chỉ một developer biết deploy |
| Sở hữu | Repo và tài khoản của buyer | Code nằm trong tài khoản cá nhân |
AI-generated code cần review khác gì code thường?
Nguyên tắc chất lượng không thay đổi, nhưng mật độ code được tạo nhanh hơn làm tăng nguy cơ review hời hợt. AI có thể tạo đoạn code đúng cú pháp nhưng sai giả định nghiệp vụ, dùng thư viện không phù hợp hoặc che lỗi bằng test quá sát implementation. Vì vậy reviewer phải kiểm tra từ yêu cầu và threat model, không chỉ đọc diff. Các thay đổi lớn nên được chia nhỏ, có giải thích kiến trúc và có test thất bại trước khi fix để chứng minh test thực sự bắt được lỗi.
Buyer nên ghi gì vào hợp đồng và statement of work?
- Cho phép công cụ AI nhưng nhà cung cấp vẫn chịu trách nhiệm đầy đủ về đầu ra.
- Không đưa dữ liệu, source code hoặc secret vào công cụ không được phê duyệt.
- Quy định artifact nghiệm thu ngay từ đầu sprint, không đợi cuối dự án.
- Định nghĩa severity lỗi, thời gian sửa và điều kiện rollback.
- Yêu cầu repository, cloud account và domain quan trọng thuộc buyer.
Golden Sea triển khai kiểm soát ra sao?
Trong dự án outsourcing, Golden Sea tách tốc độ sản xuất khỏi quyền quyết định phát hành. AI coding agent có thể hỗ trợ phân tích, tạo test, refactor hoặc triển khai phần việc rõ phạm vi. Kiến trúc, review, security boundary và acceptance vẫn do người chịu trách nhiệm. Buyer nhận artifact theo sprint để thấy tiến độ và rủi ro sớm, thay vì chỉ nhận một bản demo ở cuối.
Kết luận
AI coding agent làm thay đổi tốc độ phát triển, không làm biến mất nghĩa vụ nghiệm thu. Buyer tốt không mua số dòng code; buyer mua phần mềm chạy đúng, có thể kiểm soát và có thể tiếp tục vận hành sau bàn giao. Bảy bằng chứng trên biến chất lượng từ lời hứa thành thứ có thể kiểm tra.
Một buổi nghiệm thu tốt nên diễn ra thế nào?
Đội phát triển nên gửi trước release note, danh sách acceptance criterion và liên kết tới bằng chứng. Trong buổi nghiệm thu, buyer chọn mẫu một số yêu cầu để truy từ mô tả đến test và bản build, đồng thời thử đường đi lỗi thay vì chỉ đi theo kịch bản đẹp. Vấn đề được ghi theo severity, người xử lý và deadline. Hạng mục chưa có bằng chứng phải để trạng thái chưa đạt, không chấp nhận bằng lời hứa bổ sung sau.
Sau buổi demo, buyer cần tự chạy được bản build hoặc truy cập staging bằng tài khoản của mình. Một người ngoài đội triển khai nên thử đọc runbook và thực hiện thao tác cơ bản. Nếu mọi việc vẫn cần đúng developer ban đầu đứng cạnh, rủi ro bus factor chưa được giải quyết. Nghiệm thu không chỉ xác nhận tính năng hôm nay mà còn xác nhận khả năng vận hành ngày mai.
Áp dụng theo quy mô dự án
Với MVP nhỏ, artifact có thể gọn nhưng không được thiếu acceptance test, repository, hướng dẫn deploy và danh sách giới hạn đã biết. Với hệ thống có dữ liệu khách hàng hoặc thanh toán, cần threat model, phân quyền, backup và kiểm tra khôi phục. Với dự án dài hạn, nên audit ngẫu nhiên theo sprint để phát hiện sớm nợ kỹ thuật do agent tạo ra, thay vì chờ đến giai đoạn bàn giao mới kiểm tra toàn bộ.
