Phát triển phần mềm thời AI: vibe coding, spec-driven và AI-DLC

1. AI đổi gì — và không đổi gì

Vòng đời phần mềm (SDLC — Software Development Life Cycle) vẫn là mấy giai đoạn quen: hiểu nhu cầu, thiết kế, làm, kiểm thử, đưa vào dùng, vận hành. AI không xoá các giai đoạn đó.

Cái nó làm là đổi giá từng khâu. Viết code từng tốn công nhất; giờ sinh nháp rẻ và nhanh hơn nhiều. Hai đầu đắt lên: nói cho đúng cái mình muốn (đầu vào) và kiểm chứng thứ máy làm ra (đầu ra).

Khi giá đổi, cách tổ chức việc cũng đổi. Dưới đây là các tên bạn sẽ gặp nhiều nhất năm 2025–2026.

2. Vibe coding — “cảm giác” thay vì đọc code

Vibe coding do Andrej Karpathy (cựu giám đốc AI của Tesla) đặt tên ngày 02/02/2025. Bạn mô tả bằng lời thứ muốn, để AI sinh code, rồi chấp nhận kết quả mà không đọc kỹ từng dòng. “Cảm” xem nó chạy không, chỉnh bằng lời, lặp lại.

Hợp khi dựng prototype (bản nháp chạy được) mang đi hỏi stakeholder (bên liên quan), thử ý tưởng cuối tuần, hay script dùng xong vứt.

Còn với sản phẩm thật thì tới 2026 câu chuyện đã khác so với lúc thuật ngữ này mới ra đời. Code do AI sinh dùng được cho hàng thật — với điều kiện kiểm soát được ba thứ: context đưa vào (bối cảnh, ràng buộc, code sẵn có), đặc tả đủ rõ, và có cách kiểm đầu ra. Thiếu ba thứ đó thì mới rơi vào cảnh quen thuộc: code trôi dần khỏi ý định ban đầu, bịa ra hàm không tồn tại, càng lớn càng khó bảo trì.

Nói cách khác, vấn đề không nằm ở chỗ máy viết code. Nó nằm ở chỗ bạn có đưa cho máy đủ thứ để viết đúng hay không — và đó chính là lý do những cách làm ở phần sau ra đời.

3. Spec-driven development (SDD) — đặc tả là nguồn sự thật

Spec-driven development (phát triển hướng đặc tả, SDD): thay vì coi code là nguồn sự thật duy nhất, đội coi bản đặc tả (specification) mới là nguồn sự thật. Đặc tả viết trước, quản lý phiên bản, rồi sinh kế hoạch và code. Sửa sản phẩm = sửa đặc tả rồi sinh lại — không vá code rồi quên tài liệu.

Hai mốc hay nhắc:

• AWS Kiro được bàn rộng từ khoảng 07/2025.
• GitHub Spec Kit công bố 02/09/2025 — toolkit mã nguồn mở cho SDD với AI (mã nguồn).

Sang 2026, hướng “viết spec cho máy đọc rồi sinh code” thành dòng chính ở nhiều công cụ lập trình AI.

Trung thực về định nghĩa

Định nghĩa SDD còn loãng. Mỗi hãng hiểu một kiểu. Một phần là đóng gói mới của ý cũ:

Điểm mới thật: máy đọc spec để sinh/sửa code quy mô lớn. Không cần học SDD như quy trình một hãng. Ý cốt lõi đơn giản: rõ ràng, không mâu thuẫn, có tiêu chí chấp nhận — thì AI và người mới làm đúng.

Với BA, đoạn này đáng để ý hơn cả. Nghề bạn đang học chính là viết ra thứ “đọc vào là làm được”.

4. AI-DLC — cái gần “vòng đời” nhất

AI-DLC (AI-Driven Development Lifecycle — vòng đời phát triển do AI dẫn dắt) do AWS giới thiệu 2025. Trong các tên bài này, đây là cái tự nhận là mô hình vòng đời.

Ba pha

Bolt thay cho sprint

Trong Scrum, sprint thường ~2 tuần. AI-DLC nói về bolt — chu kỳ giờ hoặc ngày. Khi AI sinh được phần lớn code, vòng “hiểu → làm → kiểm” quay nhanh hơn sprint cổ điển. Đội vẫn cần nhịp phê duyệt; đơn vị thời gian nhỏ hơn.

Đảo chiều hội thoại

Trước: người ra lệnh chi tiết, AI/dev junior chờ. AI-DLC: AI chủ động phân rã yêu cầu và đề xuất; người định hướng và phê duyệt. Bạn chọn hướng, chặn sai, quyết định đánh đổi — không viết từng bước vụn.

Mob Elaboration

Mob Elaboration (cùng làm rõ theo nhóm): cả đội rà soát câu hỏi và đề xuất của AI — giống mob programming nhưng đối tượng là yêu cầu và thiết kế. Bắt mâu thuẫn sớm, trước khi sinh hàng ngàn dòng sai.

Code là đầu ra của đặc tả

Code không phải thứ gõ từ dòng đầu. Code là sản phẩm đầu ra sau khi đặc tả đủ chắc. Đội vẫn đọc, review (rà soát), chịu trách nhiệm — điểm xuất phát là spec.

DDD và TDD trong lõi

Hai khung hay đi kèm khi để AI lập kế hoạch:

• DDD — Domain-Driven Design: thiết kế bám ngôn ngữ và ranh giới nghiệp vụ (domain = miền nghiệp vụ).
• TDD — Test-Driven Development: định nghĩa hành vi/kiểm thử mong muốn rồi mới có code thỏa mãn.

Không có khung thiết kế, máy dễ sinh file lộn xộn không biên giới. Mình thấy chỗ này fresher hay bỏ qua — rồi mới tá hoả khi repo phình ra không kiểm soát được.

Cảnh báo bắt buộc về số liệu AWS

AWS công bố tăng năng suất 10–15 lần, ROI (tỷ suất hoàn vốn) 300–500%. Đây là số liệu do chính nhà cung cấp công bố, chưa có nghiên cứu độc lập kiểm chứng công khai cùng thang đo. Đọc như lời chào hàng có kiểm soát — đừng chép vào báo cáo nội bộ như sự thật đã đo. Khi sếp hỏi “AWS bảo gấp 10, ta có được không?”, câu đúng của BA: đo trên việc thật của ta.

5. Agentic engineering và harness engineering

Agent: chương trình AI được giao mục tiêu, tự chia bước, gọi công cụ (sửa file, chạy test, mở pull request — đề nghị gộp code vào nhánh chính để người review).

Agentic engineering là điều phối nhiều agent theo đặc tả, còn người thì giám sát và quyết định. Nói ngắn: người lái, agent thực thi.

Harness engineering thì khác góc: dựng môi trường, đặc tả, hàng rào an toàn và vòng phản hồi để agent làm việc đáng tin — giống dây đai dẫn hướng, không để agent lang thang trong kho mã.

Cả hai rất mới (đầu 2026), chưa thành chuẩn. Biết để không bỡ ngỡ khi đọc tin; chưa cần học như chứng chỉ.

Hệ quả thực tế: khâu review phình to. Ít khi thiếu code; thiếu người hiểu nghiệp vụ để nói “nhìn chạy nhưng sai luồng”.

6. Công cụ: BA mở AI coding agent để làm gì?

Nghe tên AI coding agent — Claude Code, Codex, Antigravity — ai cũng tưởng đồ của dev. Thật ra đây đang là công cụ đáng giá nhất cho BA, và lý do không nằm ở chỗ nó viết code.

Khác biệt so với ngồi chat: agent làm việc thẳng trên cả thư mục tài liệu của bạn. Nó đọc được toàn bộ những gì đã có, sửa nhiều file một lúc, và giữ chúng khớp nhau. Còn chat thì mỗi lần bạn phải copy một đoạn vào, nhận một đoạn ra, rồi tự dán lại — làm mãi cũng được, nhưng tới file thứ mười là bắt đầu lệch.

Khi đóng gói thành bộ lệnh dùng lại được, agent phủ được gần trọn vòng đời phân tích nghiệp vụ:

• Từ ý tưởng sản phẩm ban đầu, research và làm rõ nghiệp vụ của từng tính năng.
• Vẽ sơ đồ — luồng nghiệp vụ, use case, sequence, ERD.
• Dựng wireframe và prototype bấm thử được để mang đi hỏi người dùng.
• Viết URD, SRS theo đúng mẫu team đang dùng.
• Đồng bộ sang Jira và Confluence thay vì chép tay.
• Theo dõi lượng token đã dùng, để biết mình đang tốn bao nhiêu.

Chỗ ăn tiền nhất là change request. Một yêu cầu đổi thường kéo theo cả chuỗi: sửa SRS, sửa use case, sửa sơ đồ, sửa test case, cập nhật ticket. Làm tay thì luôn sót một hai file, và ba tháng sau không ai biết bản nào mới nhất. Agent đọc được cả bộ tài liệu nên nó cập nhật đồng loạt những chỗ liên quan — việc của bạn chuyển từ sửa từng file sang duyệt xem nó sửa có đúng không.

Đổi lại, bạn phải học một ít thói quen mới: tổ chức tài liệu cho gọn để agent đọc được, viết yêu cầu rõ ràng, và đọc kỹ phần nó đề xuất trước khi đồng ý. Không có cái nào trong đó là kỹ năng lập trình cả — chúng đều là kỹ năng BA, chỉ là ở một nhịp khác.

7. Xếp lại cho khỏi nhầm

8. Bạn mang gì sang bài sau

Ba thứ mình muốn bạn giữ lại:

1. Đừng tìm “mô hình thay Scrum vì có AI”. Hỏi: spec đã đủ rõ để máy làm đúng chưa? và ai kiểm chứng đầu ra?
2. Vibe coding để học và thử. Sản phẩm thật cần spec, review, trách nhiệm người.
3. Khi ai khoe năng suất gấp 10: đo thế nào, trên việc gì, có bên thứ ba không?

Bài tiếp: AI đổi gì trong công việc của BA.