Buổi 1 — Từ SDLC truyền thống đến SDLC dẫn dắt bởi AI: chúng ta đang ở đâu?
Giờ phase nào trong vòng đời phần mềm cũng có một con AI chĩa vào. BA viết user story bằng AI. Architect phác phương án bằng một con khác. Developer sinh code, tester sinh test case, reviewer nhận comment tự động.
Vậy mà nhìn ở mức toàn bộ pipeline, năng suất gần như không nhúc nhích.
Đúng khoảng cách đó là toàn bộ nội dung Buổi 1. Không phải câu hỏi "AI viết code được không" — chuyện đó ngã ngũ rồi — mà một câu khó hơn: nếu AI đã tăng tốc gần như mọi hoạt động riêng lẻ, tại sao cả quy trình vẫn không nhanh hơn đáng kể?
Về bài viết này
Đây là ghi chép của tôi từ Ngày 1 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 và thiết kế workshop là của cô; phần tóm tắt và câu chữ ở đây là của tôi.
Bài này cũng có bản tiếng Anh.
AI thực sự giỏi ở đâu
Trước khi bàn AI nên đứng ở đâu trong quy trình, buổi học đặt nền bằng việc AI đóng góp được gì xuyên suốt mọi phase. Năm nhóm năng lực:
| Năng lực | Trong thực tế trông như thế nào |
|---|---|
| Hiểu và phân tích | Đọc yêu cầu, source code, log và các artifact sẵn có để rút ra ý nghĩa |
| Sinh nội dung | Biến một yêu cầu thành đúng artifact bạn cần — user story, schema, test, tài liệu |
| Chuyển đổi và tái cấu trúc | Đưa thông tin qua lại giữa các định dạng và mức trừu tượng (spec → thiết kế → code → test) |
| Đánh giá và phản biện | Phát hiện vấn đề sớm, đề xuất cải tiến, nâng chất lượng artifact |
| Đề xuất và hỗ trợ ra quyết định | Bày ra các phương án kèm đánh đổi để con người chọn nhanh hơn |
Đọc lại danh sách đó thì nghịch lý càng rõ. AI tham gia được vào gần như mọi hoạt động trong vòng đời. Vậy nút thắt không nằm ở năng lực.
Vì sao nhanh cục bộ không cộng lại thành nhanh tổng thể
Buổi học chỉ ra ba cơ chế biến cái lợi ở từng hoạt động thành con số không ở tổng thể.
1. Mỗi AI hiểu bài toán một kiểu. Mỗi nhóm tối ưu phase của mình bằng trợ lý của mình. Không có gì buộc các trợ lý đó hiểu giống nhau về thứ đang được xây.
2. Thông tin hao hụt sau mỗi lần bàn giao — context drift. Cái đi giữa các phase không chỉ là tài liệu. Đó là tri thức và quyết định: vì sao chấp nhận đánh đổi này, quy tắc nào không được phá, cái gì đã cố ý bỏ ra ngoài. Tài liệu thì qua được. Lý lẽ đằng sau nó thường thì không.
3. Tăng tốc cục bộ đẻ ra vòng lặp toàn cục. Chạy nhanh hơn ở một phase với hiểu biết thiếu hụt chỉ khiến kết quả sai đến sớm hơn. Rework là hệ quả của mất ngữ cảnh, và rework ăn hết phần tăng tốc.
Gốc rễ nằm dưới cả ba: mỗi AI chỉ nhìn thấy một lát của bài toán. Nó thấy đúng những gì bạn đưa, không hơn. Bài toán sản phẩm toàn diện chưa bao giờ nằm trong tầm mắt nó.
Chất lượng đầu ra của mỗi phase phụ thuộc vào ngữ cảnh nó nhận được từ phase trước. AI không tự giải quyết được bài toán phối hợp giữa các phase, và nó không thay thế việc trao đổi và xác nhận giữa con người với nhau.
AI xuyên suốt sáu phase
Điểm cốt lõi về mặt cấu trúc: hình dạng của SDLC không thay đổi. Yêu cầu, thiết kế, lập trình, kiểm thử, triển khai, vận hành — vẫn sáu phase đó. Cái đổi là cách làm, con người để làm gì, và các phase nuôi nhau ra sao.
Với mỗi phase, ba câu hỏi được đặt theo đúng thứ tự: AI đang làm gì, con người phải quyết gì, và AI cần ngữ cảnh gì thì mới hữu dụng.
Yêu cầu — Làm rõ
| AI làm gì | Con người quyết gì | AI cần ngữ cảnh gì |
|---|---|---|
| Làm rõ yêu cầu, sinh user story, use case, acceptance criteria; phát hiện yêu cầu thiếu hoặc mâu thuẫn | Mục tiêu nghiệp vụ, phạm vi, ưu tiên, các đánh đổi, quy tắc nghiệp vụ, phê duyệt cuối | Mục tiêu nghiệp vụ, quy trình nghiệp vụ hiện tại, quy tắc nghiệp vụ, các bên liên quan, ràng buộc |
AI giúp dựng yêu cầu. Con người vẫn chịu trách nhiệm yêu cầu đó có đúng và đáng làm hay không.
Thiết kế — Khám phá
| AI làm gì | Con người quyết gì | AI cần ngữ cảnh gì |
|---|---|---|
| Phân tích yêu cầu thiết kế, đề xuất phương án, sinh UML / API / database schema, đánh giá ưu nhược, kiểm tra tính nhất quán | Kiến trúc hệ thống, đánh đổi, lựa chọn công nghệ, yêu cầu phi chức năng, phê duyệt | Yêu cầu nghiệp vụ, kiến trúc hiện tại, yêu cầu phi chức năng, ràng buộc và tiêu chuẩn kỹ thuật |
Giá trị thật của AI ở đây là độ rộng — bày ra và đánh giá nhiều phương án hơn số mà một người kịp phác. Chọn phương án hợp với bối cảnh hệ thống thì vẫn là việc của người.
Lập trình — Hiện thực
| AI làm gì | Con người quyết gì | AI cần ngữ cảnh gì |
|---|---|---|
| Đọc và sinh code, refactor, viết unit test và tài liệu, phát hiện lỗi và đề xuất fix | Thiết kế chi tiết, logic nghiệp vụ, chấp nhận PR, quyết định merge, chất lượng code, trách nhiệm với production | Yêu cầu đã phê duyệt, thiết kế hệ thống, coding standard, source code hiện có, API contract, quy ước dự án |
Kiểm thử — Xác minh
| AI làm gì | Con người quyết gì | AI cần ngữ cảnh gì |
|---|---|---|
| Phân tích yêu cầu kiểm thử, sinh test case, test script và test data, phân tích lỗi và nguyên nhân, đề xuất regression test | Chiến lược kiểm thử, mức bao phủ, mức rủi ro chấp nhận được, ưu tiên sửa lỗi, đánh giá chất lượng | Acceptance criteria, yêu cầu nghiệp vụ, thiết kế hệ thống, source code, lịch sử lỗi, kết quả các lần kiểm thử trước |
AI sinh và chạy được rất nhiều hoạt động kiểm thử. Câu nó không trả lời được là "đã đủ chất lượng để phát hành chưa?"
Triển khai — Bàn giao
| AI làm gì | Con người quyết gì | AI cần ngữ cảnh gì |
|---|---|---|
| Sinh release note, dựng CI/CD pipeline, kiểm tra cấu hình triển khai, giám sát quá trình phát hành, phát hiện và phân tích sự cố, đề xuất rollback | Thời điểm phát hành, chiến lược triển khai, mức rủi ro chấp nhận được, quyết định rollback, chấp nhận phát hành | Kế hoạch triển khai, môi trường triển khai, CI/CD pipeline, cấu hình hệ thống, chính sách phát hành |
Vận hành — Tối ưu
| AI làm gì | Con người quyết gì | AI cần ngữ cảnh gì |
|---|---|---|
| Giám sát hệ thống, phát hiện bất thường, phân tích nguyên nhân sự cố, đề xuất tối ưu hiệu năng, phân tích phản hồi người dùng, gợi ý cải tiến cho phiên bản sau | Ưu tiên cải tiến, kế hoạch xử lý sự cố, mức ưu tiên cho phản hồi khách hàng, kế hoạch tối ưu và phiên bản tiếp theo | Mục tiêu vận hành, log và metric, phản hồi người dùng, lịch sử sự cố, hiệu năng hệ thống |
Vận hành là chỗ vòng lặp khép lại: AI biến dữ liệu vận hành thành tri thức nuôi yêu cầu cho phiên bản kế tiếp.
Đọc từ đầu đến cuối, sáu phase trở thành sáu động từ:
Làm rõ → Khám phá → Hiện thực → Xác minh → Bàn giao → Tối ưu
AI không thay thế con người ở bất kỳ động từ nào. Nó giúp con người quyết nhanh hơn, dựa trên nhiều thông tin hơn, với chất lượng cao hơn.
Ba mô hình cộng tác Human-AI
Nửa sau của buổi học nói về trao bao nhiêu quyền tự chủ, và giới thiệu ba mô hình.
Human-in-the-loop (HITL) — con người phải phê duyệt trước khi AI hành động, hoặc trước khi kết quả của AI được dùng. Hợp khi: quyết định rủi ro cao, tác động lớn tới khách hàng, có ràng buộc pháp lý, hoặc khó khôi phục nếu sai.
Human-on-the-loop (HOTL) — AI tự thực hiện; con người giám sát và chỉ can thiệp khi cần. Hợp khi: công việc lặp lại tần suất cao, kết quả đo lường được, có cơ chế rollback, và đã có quy trình rõ ràng.
Human-out-of-the-loop (HOOTL) — AI tự quyết và tự thực thi trong phạm vi chính sách đã đặt trước. Hợp khi: rủi ro thấp, quy trình đã chuẩn hoá, có audit đầy đủ, rollback được, và quyết định lặp lại.
Câu nặng ký nhất cả buổi:
Thứ quyết định chọn HITL, HOTL hay HOOTL không phải AI thông minh đến đâu. Mà là mức độ rủi ro, trách nhiệm và khả năng kiểm soát gắn với quyết định đó.
Câu đó chuyển quyền tự chủ từ câu hỏi năng lực thành câu hỏi quản trị — và đó là lý do "model giỏi lên rồi" tự nó không phải lý do để gỡ một chốt phê duyệt của con người.
Workshop: các bước thực hiện
Phần lý thuyết được dạy trên một case study xuyên suốt, làm theo nhóm. Đây là phần đáng chép lại nếu bạn muốn chạy cùng bài tập.
Case study
Một bệnh viện đa khoa đang vận hành hệ thống quản lý lịch khám và dịch vụ bệnh nhân. Bệnh nhân tìm bác sĩ và chuyên khoa, đặt lịch, đổi hoặc huỷ lịch, theo dõi trạng thái và nhận thông báo. Bác sĩ và nhân viên dùng hệ thống để quản lý lịch làm việc và điều phối khám bệnh. Khi một khung giờ trống ra — bác sĩ đổi lịch, hoặc bệnh nhân huỷ — nhân viên phải xử lý tay các thay đổi kéo theo. Lúc cao điểm, bệnh nhân không đặt được sẽ vào danh sách chờ.
Yêu cầu thay đổi: xây chức năng quản lý linh hoạt việc đổi lịch khám và danh sách chờ. Khi một khung giờ khả dụng, hệ thống cần xác định bệnh nhân phù hợp trong danh sách chờ và cung cấp khung giờ đó cho họ, cân nhắc mức ưu tiên, thời gian đã chờ, và độ phù hợp giữa nhu cầu khám với khung giờ. Bệnh nhân có thể chấp nhận hoặc từ chối; nếu từ chối hoặc không phản hồi trong một khoảng thời gian, khung giờ chuyển cho người khác. Hệ thống cũng phải xử lý việc đổi lịch do bệnh nhân, bác sĩ hoặc bệnh viện khởi tạo, hạn chế xung đột lịch, và thông báo cho các bên liên quan.
Cấu hình nhóm cố tình để theo lối truyền thống: BA tiếp nhận yêu cầu, architect thiết kế, developer hiện thực, tester viết test case, technical lead review trước khi triển khai. Ai cũng được dùng AI assistant riêng — ChatGPT, Claude, Copilot, Gemini — nhưng các trợ lý đó không chia sẻ ngữ cảnh với nhau.
Activity 1 — Phân tích quy trình hiện tại và tìm điểm đứt gãy thông tin (20 phút)
Mục tiêu là định vị context drift trong một quy trình bạn thấy quen.
Bước 1 — Chọn thứ thật sự cần đi tiếp. Đề bài cho sẵn artifact mà mỗi phase tạo ra: phân tích yêu cầu sinh ra business goal, functional requirement, business rule, user story, acceptance criteria, priority, ràng buộc, stakeholder; thiết kế sinh ra architecture decision, API contract, database schema, trách nhiệm component, ràng buộc thiết kế, technology stack, security design; lập trình sinh ra source code, logging, exception handling, configuration, known limitation, giả định kỹ thuật.
Với mỗi lần bàn giao — Yêu cầu → Thiết kế, Thiết kế → Lập trình, Lập trình → Kiểm thử — chỉ được chọn ba thông tin quan trọng nhất để mang sang làm đầu vào cho AI, và phải giải thích lựa chọn. Giới hạn ba chính là điểm mấu chốt của bài tập.
Bước 2 — Kiểm lại theo vai trò. Lần lượt với developer, tester và architect: họ cần nhất thông tin nào, và cụ thể kết quả từ AI hỏng ra sao nếu thiếu nó?
Bước 3 — Chốt. Thống nhất ba thông tin phải được duy trì xuyên suốt toàn bộ vòng đời, xếp hạng kèm lý do.
Bước 4 — Thảo luận. Bốn câu: Phase nào tạo ra nhiều thông tin quan trọng nhất, vì sao? Thông tin nào dễ mất nhất khi bàn giao? Nguyên nhân lớn nhất khiến phải rework là gì? Nếu mỗi phase dùng một AI assistant khác nhau, con nào chật vật nhất, vì sao?
Deliverable: 1 slide, trình bày 5 phút.
Activity 2 — Thiết kế mô hình cộng tác Human-AI (30 phút)
Activity 1 xác định ngữ cảnh nào phải sống sót. Activity 2 thiết kế quy trình quanh nó.
Bước 1 — Xác định AI nên tham gia ở đâu. Với mười hoạt động — phân tích yêu cầu, sinh user story, đề xuất kiến trúc, sinh API, sinh mã nguồn, sinh unit test, code review, security review, sinh tài liệu, release lên production — phân mỗi hoạt động vào AI không nên tham gia / AI hỗ trợ / AI có thể tự động. Rồi trả lời: AI mang lại nhiều giá trị nhất ở đâu, và rủi ro nhất ở đâu?
Bước 2 — Lập Human-AI Responsibility Matrix. Với từng phase (yêu cầu, thiết kế, lập trình, kiểm thử, code review, triển khai): AI chịu trách nhiệm gì, con người chịu trách nhiệm gì, và vì sao.
Bước 3 — Tách "quyết" khỏi "đề xuất". Với các quyết định nhóm theo mảng — requirement engineering, system design, development, testing & QA, code review & security, deployment & operations — phân mỗi cái vào AI có thể quyết / AI chỉ đề xuất / con người quyết. Vài cái cố tình gai góc: merge pull request, commit thẳng vào main, đóng bug, chấp nhận security risk, phê duyệt hotfix, rollback phiên bản.
Không có đáp án đúng duy nhất. Nhóm phân loại dựa trên rủi ro, trách nhiệm và tác động. Sau đó xếp hạng ba quyết định luôn luôn phải do con người chịu, kèm giải thích.
Bước 4 — Phân biệt HITL và HOTL. Phân loại các tình huống cụ thể: AI sinh user story, BA kiểm tra trước khi dùng. AI sinh mã nguồn, developer review trước khi merge. AI review pull request, developer chỉ xem các cảnh báo. AI sinh unit test, developer chỉ xem khi test fail. AI tự động deploy production. AI tự động rollback khi phát hiện lỗi.
Rồi đến câu chốt, cũng là câu đáng giá nhất: giả sử AI ngày càng chính xác hơn, điều kiện nào phải thoả trước khi một hoạt động được chuyển từ human-in-the-loop sang human-on-the-loop? Các tiêu chí ứng viên gồm độ chính xác cao và ổn định, có confidence score rõ ràng, giải thích được kết quả, có audit log, rollback được, đủ dữ liệu lịch sử, có cơ chế human feedback liên tục, có quy trình kiểm soát chất lượng, quyết định rủi ro thấp, và dễ khôi phục nếu sai. Chọn ba cái quan trọng nhất.
Deliverable: 1 slide gồm responsibility matrix, ba quyết định luôn thuộc về con người, ba hoạt động cần HITL, ba hoạt động nên chuyển sang HOTL, và bộ phát biểu AI Governance hoàn chỉnh — "AI chỉ được tự động quyết khi…", "các quyết định liên quan nghiệp vụ phải…", "mọi quyết định do AI thực hiện cần…", "khi AI và con người ra kết quả khác nhau thì…".
Tôi rút ra được gì
Dùng công cụ AI không đồng nghĩa với chuyển sang AI-driven SDLC. Thả một trợ lý vào từng hoạt động sẵn có thì hình dạng quy trình vẫn y nguyên — mà hình dạng quy trình mới chính là chỗ hao hụt.
Ngữ cảnh mới là artifact thật. Tài liệu đi giữa các phase rất dễ; quyết định và lý lẽ đằng sau chúng thì không. Cả người lẫn AI đều kém đi khi thiếu phần lý lẽ đó, nhưng AI kém đi trong im lặng — nó vẫn cho ra kết quả trôi chảy và tự tin từ ngữ cảnh thiếu hụt, và như thế còn tệ hơn là không cho ra gì.
Tự chủ là quyết định về quản trị, không phải về năng lực. Câu hỏi không bao giờ là "model đã đủ giỏi chưa". Mà là quyết định đó có đảo ngược được, có audit được, và đủ ít rủi ro để nới giám sát hay không.
Phần còn lại của khoá học xây tiếp trên nền này: nếu ngữ cảnh chung là nút thắt, thì việc đáng làm là dựng một lớp ngữ cảnh mà mọi phase — và mọi trợ lý — đều đọc được.