AI-Native SDLC · Tổng quan: Code nhanh rồi, sao team vẫn chậm?

Chào mừng bạn đến với Fx Studio. Bài này là tập mở đầu của loạt AI-Native SDLC: tấm bản đồ của playbook Anthropic, đọc bằng lời của mình, kèm năm việc làm được ngay và những chỗ playbook chưa trả lời.

Agent giờ viết code trong vài giờ. Vậy mà nhiều team vẫn ra tính năng chậm y như cũ. Ngày 21/8/2026, Anthropic đăng bài The AI-native SDLC playbook, và bài đó trả lời đúng câu hỏi này. Bài blog này là tấm bản đồ của playbook, đọc bằng lời của mình, đồng thời là tập mở đầu của loạt AI-Native SDLC trên Fx Studio.

Tóm ý: khi agent viết code nhanh, chỗ chậm dời sang các bước quanh code (plan, review, test, deploy), nên phải làm lại cả quy trình chứ không chỉ bước build. Playbook giữ nguyên mục tiêu của control nhưng giao phần cơ học cho máy, nối các bước bằng file commit vào git, và để con người đứng ở các approval gate.

Một quy ước cho cả loạt: chỗ nào playbook nói, mình ghi nguồn. Chỗ nào là nhận xét của mình, mình nói rõ.

Quy trình làm cho thời code đắt

SDLC (Software Development Life Cycle, quy trình phát triển phần mềm) có sáu bước: Plan, Design, Build, Test, Deploy, Maintain.

Mỗi bước gắn với một vai. Product Manager (PM) viết requirement, architect thiết kế, engineer code, Quality Assurance (QA) kiểm, team release đưa lên, team operations theo dõi. Việc chuyền tay nhau qua tài liệu, ticket và sign-off.

Quy trình này không sai. Nó được làm cho thời mà viết code là khâu đắt nhất. Product Requirements Document (PRD), estimation, security review đều có mặt để mọi người thống nhất với nhau trước khi bỏ ra vài tuần, vài tháng để code.

Có điều, mọi control trong quy trình đó ngầm giả định một chuyện: con người làm từng bước.

Nút thắt dời chỗ

Khi agent viết code trong vài giờ thay vì vài tuần, giả định “con người làm từng bước” gãy. Playbook chỉ ra ba hệ quả.

Một: nút thắt dời chỗ.

• Build nhanh lên, nhưng plan, review, test và deploy vẫn chạy ở tốc độ con người.
• Chỗ chậm giờ nằm ở hai bên bước build.

Hai: control không còn khớp.

• Đọc từng dòng code là hợp lý khi một người viết ra nó.
• Khi agent viết phần lớn diff, người review đọc không kịp.

Ba: governance đắt dần.

• Mỗi exception vẫn phải chờ review board họp, theo tuần, theo tháng.

Ví dụ trong bài là security team. Headcount của team này được tính theo lượng code con người viết ra. Agent nhân lượng code lên nhiều lần thì chỉ còn hai kết cục: review queue phình ra, hoặc code lên production khi chưa được soát kỹ.

Chuyện điểm nghẽn dời về đâu khi code rẻ đi, mình có viết riêng một bài: Code rẻ đi thì điểm nghẽn dời về đâu?

Giữ mục tiêu, đổi cách làm

Lời giải của playbook không phải là bỏ control. Accountability, separation of duties, auditability vẫn giữ nguyên.

Thứ đổi là ai thực thi những control đó. Máy làm phần cơ học, ngay lúc agent hành động. Người giữ phần cần phán đoán.

Và quy trình đổi hình.

• SDLC cũ là một đường thẳng, Maintain là điểm cuối.
• Bản AI-native là một vòng lặp: incident trên production được chẩn đoán, thành requirement mới, rồi đi lại từ đầu vòng.

Sợi chỉ là file trong git

Thứ nối vòng lặp AI-native lại với nhau là ý mình thấy đáng nhớ nhất của cả bài:

• Mỗi bước kết thúc bằng một file commit vào git, và bước sau bắt đầu bằng việc đọc file đó.
• intent.md thành spec.md, spec.md thành plan.md.
• Rồi tới diff và test, PR và review findings, incident record.
• Từ incident record lại ra một intent.md mới.

Mấy bước đầu dùng file markdown, vì người và agent cùng đọc, cùng sửa được một file.

Chuỗi file này làm hai việc một lúc:

• Bàn giao không cần họp. Bước sau đọc file là biết làm gì.
• Audit có sẵn. Ai yêu cầu gì, agent làm ra gì, ai duyệt, git ghi hết.

Mỗi file được duyệt thì kích hoạt bước kế tiếp. Lúc đầu người vẫn bấm tay. Đích đến là một vòng lặp tự chạy, người đứng ở các approval gate.

Skill khuyên, hook ép

Vậy cái gì giữ cho agent làm đúng? Playbook tách rõ hai thứ: skill và hook.

Skill là hướng dẫn agent đọc khi làm việc. Skill làm vi phạm hiếm đi, nhưng không có gì ép session phải theo.

Hook là script chạy trước hoặc sau hành động của agent, và hook có ba lựa chọn: chặn (deny), cho qua (allow), hoặc hỏi người (ask). Bài viết gọi skill là advisory control, còn hook là deterministic layer đứng sau nó:

“A skill is an advisory control while a hook is the deterministic layer behind it.”

Doanh nghiệp quản lý chặt có thêm managed settings, do IT quản lý, engineer không tự tắt được. Team nhỏ thì skill và hook là đủ để bắt đầu.

Nguyên tắc rút ra: policy nào phải đúng mọi lúc thì phải có hook đứng sau skill.

Có một câu bài nhắc nhiều lần: agent được làm mọi thứ tới trước production gate, và không được vượt qua.

“The governing principle is that the agent may act up to the production gate and cannot pass it.”

Agent viết code cũng không tự duyệt code đó.

Người đứng ở cổng

Con người không biến mất. Vị trí của con người đổi: từ người làm từng bước, sang người đứng ở cổng.

• intent.md và spec.md thì product owner duyệt.
• plan.md thì engineer duyệt.
• PR qua code owner.
• Còn release lên production có một người được ghi tên.

Người duyệt không còn đọc từng dòng. Câu hỏi của người duyệt đổi thành hai câu:

• Thay đổi này có đúng ý của plan không?
• Rủi ro có chấp nhận được không?

Bắt đầu từ đâu

Không cần làm đủ sáu bước cùng lúc. Playbook chỉ ra năm việc không cần làm gì trước:

1. Viết một intent.md.
2. Viết CLAUDE.md cho repo.
3. Viết một skill cho một policy.
4. Cho agent một vòng self-verification.
5. Dựng một hook làm approval gate.

Việc lớn như đưa Claude vào CI/CD, hay khép vòng ở bước Maintain, thì chờ nền chạy trước. Có gate rồi mới tự động hoá thứ đi qua gate.

Nếu chỉ chọn một việc cho hôm nay, mình chọn CLAUDE.md. Agent làm sai một chuyện tới lần thứ hai thì ghi một dòng vào đó.

Chỗ playbook chưa trả lời

Từ đây trở xuống là nhận xét của mình, không có trong bài gốc.

• Nút thắt bị dời và nén lại, chứ không biến mất.
  • Phần phán đoán vẫn cần người, giờ dồn về ít gate hơn.
  • Team thiếu người có quyền duyệt thì playbook chỉ giúp được một phần.
• Bài chưa có số liệu kết quả.
  • Playbook đưa chỉ số để tự đo, không công bố số trước và sau của ai.
  • Nên mấy câu kiểu “từ vài tuần xuống vài giờ”, mình xem là kỳ vọng.
• Mobile gần như vắng mặt.
  • Build mobile chậm hơn, simulator khó chạy song song
  • Còn khâu review của App Store với Google Play thì nằm ngoài tầm tay.
• Chi phí ít được bàn.
  • Eval chạy định kỳ, nhiều session song song, đều tốn token.
• Nhiều công cụ trong bài còn đang thử.
  • Code Review là research preview, Claude Design và Claude Tag đang beta, Claude Security là beta cho gói Enterprise.
  • Mình tra ngày 14/10/2026.

Khung tư duy thì dùng chung được. Còn công cụ cụ thể thì nên thử trước khi cam kết.

Tạm Kết

Quy trình cũ không sai, nó được làm cho thời viết code đắt. Giờ code rẻ đi, thứ cần làm lại là mọi thứ quanh code.

Các tập sau của loạt AI-Native SDLC đi qua từng bước, bắt đầu từ Plan: biến ý tưởng thành intent.md.

Nguồn

• Louis Claxton, Anthropic, The AI-native SDLC playbook (21/8/2026): claude.com

Cảm ơn bạn đã đọc bài viết này!

Written by chuotfx

Hãy ngồi xuống, uống miếng bánh và ăn miếng trà. Chúng ta cùng nhau đàm đạo về đời, về code nhóe!