AI-DLC của Amazon: v1 và v2 thực sự khác gì nhau — và vì sao AWS viết lại từ đầu?

Hai thứ mang cùng một cái tên

AWS có một phương pháp tên AI-DLC — AI-Driven Development Life Cycle — và một repo hiện thực nó, awslabs/aidlc-workflows. Mình clone repo, đọc cả hai nhánh (v1 dừng ở 1.0.1, main ở 2.7.1) và bản spec "AI-DLC Workflows 2.0" dài 6 trang đi kèm.

Điều đầu tiên nhận ra: gọi là "v1" và "v2" dễ làm người ta nghĩ đây là nâng cấp. Không phải.

v1: một bản prompt rất nghiêm khắc

v1 là 34 file markdown, không có dòng code nào (VERIFIED). Trái tim là một file core-workflow.md 25 KB với những dòng như PRIORITY: This workflow OVERRIDES all other built-in workflows. Bạn tải file zip, chép folder vào .cursor/rules/ hay .kiro/steering/ — thủ công, cho từng IDE — rồi hy vọng model làm theo.

Model tự quyết stage nào áp dụng. Không có gì bên ngoài model biết được nó có làm đúng hay không.

v2: một engine gọi LLM

v2 là ~104.000 dòng TypeScript, 468 file test (VERIFIED). Một engine xác định quyết định bước tiếp theo; LLM chỉ thực thi từng stage. Từ 3 phase lên 5 phase, 33 stage; từ không có agent nào lên một đội 11 agent chuyên môn cộng agent review.

Cái giá phải nói thẳng: nguyên tắc "không cần cài gì" của v1 đã mất. v2 cần runtime bun trên mọi môi trường.

Vì sao viết lại — theo lời chính AWS

Trong spec, AWS viết (VERIFIED, trích nguyên văn):

"our prescriptive stage definitions proved too opinionated, and that is where adoption friction arose. For example, AI-DLC 1.0 treats Build & Test as one stage, but for almost all customers it spans multiple activities."

Tức là: họ ship một mô hình stage quá cứng, khách hàng dội ra vì "Build & Test" của họ là năm hoạt động chứ không phải một. PM nào từng triển khai một delivery framework đều có vết sẹo này — không riêng gì AI.

Nửa còn lại của lý do: nền tảng agent đã trưởng thành. Khi v1 ra đời, chưa có Skills, subagent hay lifecycle hook — nên nó chỉ có thể viết bằng steering rule.

Ý đáng "lấy về" nhất: hai kiểu kiểm tra

Spec v2 phân biệt hai cách kiểm tra đầu ra của một stage:

• Inferential — LLM tự chấm. Hợp với những thứ cần sắc thái. Nhưng AWS nói thẳng: một stage chỉ có kiểu kiểm tra này sẽ không tự dừng khi sai, vì cùng một model vừa làm vừa chấm sẽ "thoả mãn câu chữ của bài kiểm tra mà không thoả mãn ý định của nó".
• Computational — một chương trình chấm, không khoan nhượng. Ví dụ AWS đưa ra: không đường code nào được xoá CloudFormation stack trên production.

Dịch sang ngôn ngữ PM: một bước kiểm tra mà model tự chấm cho mình thì không phải là một cổng kiểm soát.

Điều không thay đổi

Phương pháp vẫn giữ nguyên, và người duyệt ở mỗi stage vẫn còn trong cả hai phiên bản. "Tự động hoàn toàn" là hướng đi, chưa phải thứ đã ship. Số lần con người phải can thiệp chỉ giảm nhanh bằng tốc độ tổ chức chuyển các quy tắc truyền miệng thành quy tắc máy kiểm tra được — và đó là một backlog, backlog của PM.

Chưa đọc được: bài blog gốc định nghĩa phương pháp trên aws.amazon.com và Method Definition Paper — cả hai bị chặn; ngày công bố gốc của phương pháp là UNVERIFIED. Mọi điều về hai bản hiện thực đều VERIFIED.