Specification-Driven Development: Code Là Đầu Ra, Không Phải Điểm Khởi Đầu

Code không còn là vua. Đã đến lúc đặc tả lên ngôi.

Vấn Đề Cốt Lõi: Khoảng Cách Không Bao Giờ Hẹp Được

Hàng thập kỷ qua, chúng ta xây dựng phần mềm theo một logic quen thuộc: viết PRD để hướng dẫn development, tạo design doc để định hướng implementation, vẽ diagram để hình dung architecture. Nhưng tất cả những thứ đó đều chỉ là giàn giáo — chúng ta xây xong rồi bỏ đi khi "công việc thật sự" bắt đầu.

Code là sự thật. Đặc tả chỉ là ý định tốt đẹp.

Kết quả là một khoảng cách quen thuộc mà ai trong nghề cũng biết: spec viết một đằng, code chạy một nẻo. Chúng ta đã cố thu hẹp khoảng cách đó bằng documentation tốt hơn, quy trình chặt chẽ hơn, requirements chi tiết hơn. Tất cả đều thất bại vì chúng chấp nhận khoảng cách là tất yếu.

Specification-Driven Development (SDD) không cố thu hẹp khoảng cách đó — nó xóa bỏ nó hoàn toàn.

Đảo Ngược Quyền Lực

SDD thực hiện một sự đảo ngược căn bản: đặc tả không phục vụ code — code phục vụ đặc tả.

PRD không còn là tài liệu hướng dẫn implementation. Nó là nguồn sinh ra implementation. Technical plan không phải văn bản tham khảo cho lập trình viên — nó là định nghĩa chính xác tạo ra code.

Khi đặc tả và implementation plan trực tiếp sinh ra code, không còn khoảng cách nào để lo lắng — chỉ có sự chuyển hóa.

Điều này kéo theo một loạt thay đổi trong cách ta nghĩ về development:

• Maintain phần mềm nghĩa là evolve đặc tả, không phải vá code
• Debug nghĩa là sửa đặc tả và implementation plan đang tạo ra code sai
• Refactor nghĩa là cấu trúc lại đặc tả cho rõ ràng hơn
• Thêm tính năng nghĩa là quay lại đặc tả, tạo implementation plan mới

Code trở thành last-mile — đầu ra cuối cùng được sinh ra tự động, không phải điểm khởi đầu của mọi quyết định.

Tại Sao Bây Giờ?

Ba xu hướng hội tụ làm SDD không chỉ khả thi mà còn cần thiết:

Thứ nhất, AI đã đạt ngưỡng đủ dùng. Các mô hình ngôn ngữ lớn ngày nay có thể hiểu đặc tả ngôn ngữ tự nhiên và sinh ra code hoạt động được. Đây không phải về việc thay thế developer — mà là khuếch đại hiệu quả của họ bằng cách tự động hóa bước dịch thuật cơ học từ đặc tả sang implementation.

Thứ hai, độ phức tạp của hệ thống ngày càng tăng. Hệ thống hiện đại tích hợp hàng chục service, framework, và dependency. Giữ tất cả những mảnh ghép đó thẳng hàng với ý định ban đầu bằng quy trình thủ công ngày càng bất khả thi. SDD cung cấp sự căn chỉnh có hệ thống thông qua specification-driven generation.

Thứ ba, tốc độ thay đổi tăng tốc. Pivot không còn là ngoại lệ — nó là kỳ vọng. Với SDD, thay đổi yêu cầu trở thành workflow bình thường: cập nhật đặc tả, implementation plan tự động cập nhật theo, code được tái sinh. Không còn nợ kỹ thuật tích lũy từ những thay đổi vội vã.

Workflow Trong Thực Tế

SDD bắt đầu từ một ý tưởng — thường còn mơ hồ và chưa hoàn chỉnh. Thông qua đối thoại lặp đi lặp lại với AI, ý tưởng đó trở thành một PRD toàn diện. AI đặt câu hỏi làm rõ, xác định edge case, và giúp định nghĩa acceptance criteria chính xác.

Điều biến quy trình này mạnh mẽ hơn là bộ ba lệnh tự động hóa toàn bộ vòng lặp đặc tả → lập kế hoạch → phân công nhiệm vụ:

/speckit.specify — Biến Ý Tưởng Thành Đặc Tả

Lệnh này nhận một mô tả tính năng đơn giản và tạo ra một đặc tả đầy đủ, có cấu trúc:

• Tự động đánh số feature (001, 002, 003...)
• Tạo branch với tên ngữ nghĩa
• Sinh ra specs/[branch-name]/spec.md từ template chuẩn
• Đảm bảo mọi ambiguity được đánh dấu [NEEDS CLARIFICATION] thay vì đoán mò

/speckit.plan — Dịch Đặc Tả Thành Kế Hoạch Kỹ Thuật

Từ spec có sẵn, lệnh này tạo ra:

• Implementation plan chi tiết với rationale cho mọi technology choice
• Data model, API contracts
• Test scenarios
• Tài liệu tuân thủ architectural principles (qua "Constitutional Gates")

/speckit.tasks — Sinh Ra Danh Sách Task Thực Thi Được

Phân tích plan và các design document để tạo tasks.md sẵn sàng cho task agent thực thi, với các task độc lập được đánh dấu [P] để chạy song song.

So Sánh Thực Tế

Template Không Chỉ Là Mẫu — Chúng Là Bộ Lọc

Điểm thường bị bỏ qua: sức mạnh thực sự của SDD không nằm ở tự động hóa mà ở cách template điều khiển hành vi của LLM theo hướng có lợi.

Ngăn LLM nhảy vào implementation quá sớm. Template chỉ định rõ: tập trung vào WHAT và WHY, không phải HOW. LLM không được phép viết "implement bằng React với Redux" khi chưa xác định rõ user cần gì.

Bắt buộc đánh dấu điểm mơ hồ. Thay vì đoán rằng "login system" dùng email/password, LLM phải ghi [NEEDS CLARIFICATION: auth method not specified]. Điều này ngăn những assumption hợp lý nhưng sai lệch.

Tạo "unit test" cho đặc tả. Checklist trong template buộc LLM tự review output theo framework QA — không còn spec nào được cho qua mà thiếu testable acceptance criteria.

Kiểm soát độ phức tạo qua Constitutional Gates. Trước khi implementation bắt đầu, LLM phải trả lời: dùng ≤3 projects chưa? Có đang wrap framework không cần thiết không? Nếu không pass được gate, phải document lý do — tạo accountability cho mọi quyết định kiến trúc.

Hiến Pháp Kiến Trúc: Nguyên Tắc Bất Biến

Trung tâm của SDD là một constitution — bộ nguyên tắc bất biến định hình mọi đặc tả và implementation được sinh ra. Một số điều khoản quan trọng:

Article I — Library-First: Mọi tính năng phải bắt đầu như một standalone library. Không có ngoại lệ. Điều này đảm bảo modular design từ đầu.

Article III — Test-First Imperative: Không viết code trước khi có test. LLM phải sinh ra test đầy đủ, được approve, và confirmed FAIL trước khi viết bất kỳ dòng implementation nào.

Articles VII & VIII — Simplicity và Anti-Abstraction: Tối đa 3 projects cho initial implementation. Dùng framework trực tiếp thay vì bọc thêm layer. Mọi độ phức tạo thêm vào phải được document và justify.

Article IX — Integration-First Testing: Ưu tiên real database thay vì mock, actual service instance thay vì stub. Code phải hoạt động trong thực tế, không chỉ trong lý thuyết.

Sức mạnh của constitution nằm ở tính bất biến. Code sinh ra hôm nay và code sinh ra năm sau đều tuân theo cùng một triết lý. Nhiều LLM khác nhau vẫn tạo ra code architecturally compatible.

Đây Không Phải Về Việc Thay Thế Developer

SDD không tự động hóa sự sáng tạo. Nó tự động hóa bước dịch thuật cơ học.

Developer vẫn là người:

• Quyết định ý định — bài toán cần giải là gì
• Validate đặc tả có phản ánh đúng thực tế không
• Phê duyệt architectural trade-off
• Phán xét khi AI đưa ra giả định sai

Điều SDD giải phóng developer khỏi: viết boilerplate, duy trì sự đồng bộ giữa doc và code, propagate thay đổi thủ công qua toàn bộ codebase.

Team tập trung vào sáng tạo, thử nghiệm, và tư duy phản biện — thay vì dịch thuật.

Kết

Phát triển phần mềm luôn bị ám ảnh bởi một câu hỏi: làm sao để ý định và implementation luôn thẳng hàng?

Chúng ta đã thử mọi cách — documentation tốt hơn, quy trình chặt hơn, công cụ mạnh hơn. Tất cả đều chấp nhận rằng khoảng cách là không thể tránh.

SDD đặt ra câu hỏi khác: nếu đặc tả có thể sinh ra code, khoảng cách đó có còn tồn tại không?

Câu trả lời đang dần trở nên rõ ràng.

Bài viết được tổng hợp và biên dịch từ tài liệu gốc về Specification-Driven Development.