Buổi 5 — Quy trình làm việc AI-Driven
Slide cuối cùng của khoá học gói gọn trong một câu:
AI giúp chúng ta EXECUTE FASTER, nhưng HUMAN giúp chúng ta DECIDE BETTER.
Còn slide nội dung đầu tiên nói vì sao bốn ngày trước là cần thiết:
Thách thức cuối cùng không phải dùng AI tốt hơn. Mà là thiết kế hệ thống engineering mà AI có thể tham gia một cách an toàn.
Về bài viết này
Đây là ghi chép của tôi từ Ngày 5 — buổi cuối — khoá AI-Driven Software Development Life-Cycle, giảng viên TS. Bùi Thị Mai Anh, Trường Công nghệ Thông tin và Truyền thông (SOICT), Đại học Bách Khoa Hà Nội, tháng 7/2026. Khung tư duy là của cô; phần tóm tắt và câu chữ ở đây là của tôi.
Khác với Ngày 2–4, buổi này không có workbook — nửa thực hành là capstone project và thuyết trình, nên bài này không có mục prompt để trích.
Bài nối tiếp Buổi 1, Buổi 2, Buổi 3 và Buổi 4. Bài cũng có bản tiếng Anh.
AI-assisted là một vòng lặp; AI-driven là một hệ thống
Cách phân biệt mở đầu buổi học sắc hơn cặp từ khoá thường gặp.
AI-Assisted Activities là vòng lặp một người tự chạy: prompt → generate → review → test → fix, rồi quay lại. Nó chạy được. Chỉ là nó không tích luỹ được gì.
AI-Driven Engineering System được định nghĩa bằng năm thuộc tính thay vì năm động từ:
| Thuộc tính | Nghĩa là gì |
|---|---|
| Shared Context | Ngữ cảnh chung, thống nhất cho toàn bộ hệ thống |
| Traceability | Liên kết đầu–cuối giữa yêu cầu → thiết kế → code → test |
| Quality Gates | Các tiêu chí chất lượng ở từng giai đoạn |
| Human Decisions | Con người ra quyết định quan trọng |
| Continuous Update | Cập nhật liên tục theo phản hồi và dữ liệu thực tế |
Đặt hai danh sách cạnh nhau là thấy ngay sự dịch chuyển: cái đầu nói về cách bạn làm việc với AI, cái sau nói về thứ mà hệ thống của team bảo đảm, bất kể ai đang prompt.
Một change request, từ đầu đến cuối
Quy trình được đưa ra dưới dạng mười bước: understand → build context → update spec → impact analysis → plan → implement → verify → human review → release → update shared knowledge.
Điều đáng chú ý là các chốt kiểm soát nằm ở đâu. Không phải cả mười bước:
- Human xác nhận trước khi cập nhật spec, và một lần nữa trước khi thực hiện kế hoạch
- Artifacts → Evidence xuyên qua plan, implement và verify: code, tests, migration và docs ở một bên; test results, static analysis, security checks và traceability ở bên kia
- Quality Gate trước khi release
Và bước mười rất dễ bị bỏ mà không nên bỏ: cập nhật tri thức chung. Vòng lặp khép lại vào chính cái ngữ cảnh mà change request kế tiếp sẽ đọc.
Quality Gate ≠ tests passed
Đây là câu của Buổi 5 mà tôi sẽ dán lên tường:
Quality Gate ≠ Tests Passed. Quality Gate = Evidence đủ & đáng tin cậy.
Gate có ba phần. Thứ nhất, evidence collected — và mỗi mục phải có artefact và kết quả cụ thể, không phải một lời khẳng định: code (PR #123), tests (TC-01, TC-02…), migration (Migration #45), docs (ADR-015), test results (all passed), static analysis (no critical issues), security checks (no vulnerabilities), traceability (UC-042 / AC-01).
Thứ hai, các phép kiểm của gate — completeness (đủ tất cả artefact bắt buộc cho loại thay đổi này chưa?), consistency (spec ↔ code ↔ test ↔ docs có khớp nhau không?), quality (có đạt tiêu chuẩn không?), traceability (mọi thay đổi có truy vết được về spec, AC hay UC không?). Kết quả là PASS hoặc FAIL.
Thứ ba, human decision — approve (merge, deploy, cập nhật trạng thái) hoặc request changes (thiếu bằng chứng, không nhất quán, không đạt tiêu chuẩn).
Quy tắc nối ba phần lại: một thay đổi chỉ được đi tiếp khi vừa PASS gate vừa được con người approve. Hai điều kiện, không phải một.
Ranh giới tự chủ
Bên trong ranh giới, AI tự chủ thật — nó plan, implement, test, analyze, fix và retest, tự lặp lại đến khi đạt gate. Không ai review từng vòng.
Thứ bị rào là hai đầu. Trước: con người xác định intent, đặt ràng buộc và chính sách, duyệt kế hoạch. Sau: con người đọc kết quả gate và quyết định bước tiếp theo.
Bốn nguyên tắc giữ cái hàng rào đó: clear boundary giữa AI execution và human decision, full observability (mọi hành động của AI đều được log, đo lường và truy vết được), traceable accountability (mọi quyết định quan trọng phải có owner là con người), và constraints first (AI chỉ hành động trong phạm vi intent, policy và ràng buộc đã được phê duyệt).
Dẫn tới câu đáng nhớ còn lại của buổi học: automate execution, not accountability.
Điểm liên quan về checkpoint thì rất dễ thở: không phải human review tất cả output AI. Chỉ review ở decision boundaries — business approval sau requirement, technical decision sau architecture, code review sau implementation, quality gate trước release. Bốn checkpoint trên năm phase.
Vai trò con người đổi thế nào
| Vai trò | Trở thành | Chịu trách nhiệm |
|---|---|---|
| PO / BA | Define & Validate | Business intent, business rules, acceptance criteria, domain exceptions |
| Tech Lead | Guard Architecture | Technical review, ranh giới, ADR, AI decision boundary |
| Developer | Orchestrate Implementation | Context, AI guidance, code, giữ test ↔ AC khớp nhau |
| QA | Validate Behavior | Testability, edge case, behavior validation |
Câu tổng kết: trách nhiệm của con người dịch chuyển lên phía intent, decision và validation, còn AI đảm nhận nhiều hơn phần execution. Để ý chuyện xảy ra với vai "developer" — công việc được mô tả là điều phối, và sản phẩm bàn giao bao gồm việc giữ test gắn với acceptance criteria.
Repo là hệ điều hành của team
Một use case, ba view, ba thư mục:
/specs/UC-042 → INTENT vì sao làm? cần đạt điều gì?
/src/place-order-qr → IMPLEMENTATION làm như thế nào?
/tests/place-order-qr → EVIDENCE làm sao biết đã đúng?Intent định nghĩa "đúng" nghĩa là gì. Implementation hiện thực hoá intent. Evidence chứng minh nó. Cách nói trên slide: spec – code – test phản chiếu lẫn nhau.
Nếu chỉ lấy về một thay đổi cấu trúc sau năm ngày, thì lấy cái này. Nó cũng chính là thứ khiến sự cố ở Buổi 4 không thể giấu được: một use case mà thư mục evidence không có gì khớp với một acceptance criteria thì nhìn là thấy thiếu.
Năm quy tắc review cho thời AI
1 · Spec PR ≠ Code PR. Hai loại thay đổi khác nhau, hai kiểu review khác nhau, hai mục tiêu khác nhau. Spec PR đổi business rule, acceptance criteria, exception và scope; người review là PO/BA và tech lead, mục tiêu là intent/nghiệp vụ có đúng và đầy đủ không? Code PR đổi source, test, refactor và docs; người review là developer peer, tech lead và QA, mục tiêu là code có đúng, sạch, an toàn, hiệu quả không? Business intent thay đổi không phải cùng một sự kiện với code thay đổi.
2 · Truy vết mọi thay đổi: PR ↔ UC ID. Mọi thay đổi implementation phải trả lời được "tôi đang thay đổi hệ thống vì Use Case nào?" Chuỗi chạy UC-042 → spec → BR/AC → PR #247 → code → tests — và quan trọng là nó chạy ngược được. Khi có production incident, bạn đi code → PR → UC → business intent để tìm nguyên nhân, hiểu đúng intent và đánh giá impact.
3 · Spec là baseline của review. Mỗi behavior trong code phải được justify bởi spec hoặc bởi một quyết định của con người. Ví dụ minh hoạ rất đắt:
Spec nói khách VIP được deferred verification, khách non-VIP thì normal verification. Spec không nói gì về thời hạn deferred là bao lâu. Code sinh ra:
if (customer.isVIP()) {
verificationMode = DEFERRED;
verificationDeadline = now.plusHours(24); // 24h xuất phát từ đâu?
}Behavior trong code: VIP → 24h. Tìm trong spec? Không. Nguồn gốc quyết định? AI tự suy ra. Kết luận: unjustified business decision. Code compile được, đọc rất tự nhiên, và sẽ qua bất kỳ review nào chỉ hỏi "cái này trông có ổn không".
4 · Xác minh business behavior: AC ↔ Test. Đừng hỏi "có test chưa?" Hãy hỏi "mỗi acceptance criterion quan trọng đã có test chứng minh chưa?" Trong ví dụ, AC-01 và AC-02 ánh xạ tới test đang pass, còn AC-03 — quá 24h → suspend — không ánh xạ tới gì cả. Một khoảng trống, tìm ra bằng cách ánh xạ chứ không phải bằng cách đếm.
Quy ước đặt tên khiến việc ánh xạ thành cơ học:
UC-042: Deferred Verification
AC-01: VIP → Deferred Verification
└── TC-01 [UC-042][AC-01]: VIP được Deferred Verification
AC-02: Non-VIP → Reject
└── TC-02 [UC-042][AC-02]: Non-VIP bị Reject
AC-03: Quá 24h → Suspend
├── TC-03 [UC-042][AC-03]: Quá 24h thì Suspend
└── TC-04 [UC-042][AC-03]: Chưa quá 24h thì không SuspendNhét ID vào tên test là câu hỏi về coverage chuyển từ chuyện phải phán đoán thành chuyện grep được.
5 · Biết ai đã quyết. Review nguồn gốc của quyết định, không chỉ review artifact.
Checklist của reviewer là bốn câu: logic này có trong spec không? Nếu không, có ADR nào ghi nhận không? Nếu không có cả hai — AI tự suy luận? Và nếu AI tự suy luận thì phải làm rõ, xác nhận, hoặc yêu cầu ADR.
Mô hình tư duy, và chỗ series khép lại
Năm quy tắc gom lại thành một chuỗi:
Intent → Implementation → Evidence → Gate → Decision.
Xác định đúng vấn đề và mục tiêu. AI thực thi để tạo ra code, test, docs. Thu thập bằng chứng chứng minh behavior. Kiểm tra chất lượng, traceability và evidence ở gate. Con người quyết định bước tiếp theo.
Và thế là khép lại đúng cái vòng mà năm ngày đã đi. Buổi 1 chẩn đoán việc mất ngữ cảnh giữa các phase. Buổi 2 biến ngữ cảnh thành spec. Buổi 3 tiêu spec đó vào code và test. Buổi 4 cho thấy cái giá phải trả khi spec lỗi thời mà không ai đối chiếu. Buổi 5 đặt tất cả vào một vòng lặp và kẻ ranh giới cho những gì AI được phép làm chủ.
Tôi rút ra được gì
"Quality Gate = evidence đủ và đáng tin cậy" là định nghĩa tốt hơn mọi trạng thái CI. Pipeline xanh trả lời những phép kiểm tôi viết có pass không. Gate trả lời đã đủ bằng chứng đáng tin để biện minh cho một quyết định chưa — và Buổi 4 đã chứng minh khoảng cách giữa hai câu đó.
Tách spec PR khỏi code PR là thay đổi cấu trúc rẻ nhất trong danh sách này. Nội dung khác, người review khác, câu hỏi đặt ra khác. Gộp chúng vào một lượt review chính là cách "business intent thay đổi" được duyệt bởi một người đang soi thụt lề.
Nhét ID vào tên test. [UC-042][AC-03] biến "cái này đã được phủ chưa?" từ một cuộc tranh luận thành một lệnh grep. Một quy ước nhỏ khiến quy tắc 4 cưỡng chế được thay vì chỉ là mong muốn.
Hỏi quyết định đến từ đâu, không chỉ hỏi nó trông có đúng không. Ví dụ plusHours(24) là cả khoá học gói trong sáu dòng code: trông đúng, viết chuẩn, test pass, và truy về không ai cả.