Spec-Driven Development (SDD)
Spec đứng ở giữa để con người thống nhất ý định; AI viết code, test và doc xoay quanh nó. Khi có gì sai, sửa spec trước rồi mới sửa code.
Đó là định nghĩa ngắn nhất. Spec trở thành giao diện làm việc giữa con người và AI: khi spec rõ, AI có chỗ bám để sinh code, dev mới có tài liệu để đọc, PO có nơi để phản biện, test có cơ sở để hình thành. Khi spec mơ hồ, mọi thứ phía sau cũng mơ hồ - chỉ khác là sự mơ hồ đó được chuyển thành code rất nhanh.
Bốn ý cốt lõi
- Spec là nơi team thống nhất “mình đang làm gì” - thay vì để câu trả lời nằm rải rác trong Slack, trí nhớ Tech Lead, hoặc code AI vừa sinh.
- AI là người thợ rất nhanh, không phải người chịu trách nhiệm cuối. Rule nghiệp vụ, đánh đổi kiến trúc, chính sách có hệ quả tiền bạc/pháp lý vẫn phải có con người xác nhận → AI-Assisted.
- Spec không cần hoàn hảo từ ngày đầu. Vòng đầu chỉ cần đủ rõ để bắt đầu, rồi lớn lên cùng hiểu biết của team → Iterative Improvement.
- Test là hàng rào bảo vệ. Khi spec có Acceptance Criteria, test map vào từng AC, nhờ đó AI regenerate code mà vẫn biết hành vi quan trọng có vỡ không → Test-Protected.
Nguồn gốc
Cuốn sách tổng hợp từ AI Unified Process (AIUP), GitHub Spec Kit, DDD và Hexagonal Architecture - nhưng phần đáng giá nhất đến từ những lần để AI chạy quá nhanh rồi phải quay lại tìm ý định ban đầu.
Đánh đổi cốt lõi
SDD chậm hơn ở tuần đầu (phải viết BR, use case, entity model), nhưng trả lại giá trị từ tháng thứ ba: refactor không còn sợ, dev mới onboard trong vài ngày, bug production truy ngược về một mục cụ thể trong spec.
Liên quan
- Vibe Coding - cách làm đối lập mà SDD ra đời để chữa
- Bốn tầng của yêu cầu - spec thật ra gồm những gì
- Sáu nguyên tắc Spec-Driven - kim chỉ nam áp dụng SDD
- SDD không phải Waterfall - gỡ hiểu nhầm phổ biến nhất
- Khi nào không nên dùng SDD - ranh giới của phương pháp