Viết và review code không còn là điểm nghẽn chính trong quy trình phát triển phần mềm hiện đại; vấn đề thực sự nằm ở sự mơ hồ khi giao tiếp với mô hình ngôn ngữ lớn (Large Language Model, LLM). Khi bạn dùng các công cụ như GitHub Copilot, Claude Code hay IBM Bob, việc chỉ dựa vào một prompt đơn lẻ thường cho kết quả thiếu ổn định. Spec-driven development (SDD) giải quyết đúng vấn đề đó. SDD là phương pháp viết một bản đặc tả (specification) chi tiết, được thống nhất và hoàn thiện trước khi bắt đầu viết code, đóng vai trò nguồn sự thật duy nhất (single source of truth) dẫn dắt AI agent.
Thay vì "vibe coding" — hy vọng AI tự hiểu ý đồ — SDD chuyển trọng tâm sang việc thiết kế các tài liệu kỹ thuật. Bạn không còn là người gõ phím thuần túy mà trở thành người điều phối các AI agent thông qua văn bản có cấu trúc. Cách làm này giữ được tính kỷ luật của kỹ thuật phần mềm truyền thống, trong khi vẫn tận dụng tốc độ của generative AI.
Spec-driven development là gì?
Spec-driven development (SDD) là phương pháp ưu tiên soạn thảo một bản đặc tả chi tiết trước khi AI tạo ra mã nguồn. Trong môi trường AI-assisted, spec là một ngôn ngữ chung có cấu trúc, hướng hành vi, giúp giảm tính không định hình (non-determinism) của LLM — không phải một tài liệu tĩnh nằm yên một chỗ. Đây cũng là điểm SDD kế thừa từ test-driven development (TDD) và behavior-driven development (BDD), nhưng đẩy yêu cầu lên mức đặc tả toàn bộ ý đồ triển khai.
Cần phân biệt rõ "spec" với "memory bank" (thường thấy ở các công cụ như Kiro hay Spec-kit). Nếu memory bank chứa các ngữ cảnh chung như quy ước coding style hay kiến trúc tổng thể của dự án, thì spec tập trung vào một task hoặc tính năng cụ thể. Một bản spec tốt là tài liệu có thể kiểm chứng (testable), mô tả chính xác hệ thống cần làm gì (intent) thay vì sa đà vào chuyện nó được triển khai ra sao (implementation).
Vì sao SDD xuất hiện: vibe coding và rủi ro nợ kỹ thuật
"Vibe coding" — lập trình dựa trên cảm hứng và các chu kỳ thử-sai với prompt ngắn — đang làm nợ kỹ thuật tích lũy rất nhanh. AI chỉ tốt ngang với chỉ dẫn mà nó nhận được. Khi thiếu một bản spec làm mỏ neo, codebase của bạn sẽ đối mặt với ba vấn đề quen thuộc:
- Context drift: sửa bug ở module này nhưng vô tình làm hỏng tính năng ở module khác, do AI không nắm được logic toàn cục.
- Fragmentation: mã nguồn mới không tuân theo các quy ước kiến trúc cũ, làm xói mòn khả năng bảo trì.
- Chi phí vận hành: bạn có thể tốn hàng ngàn token và nhiều giờ để prompt đi prompt lại những lỗi mà một bản spec tốt đã ngăn được từ đầu.
Hãy hình dung kịch bản áp lực deadline: bạn vội vã đẩy những thay đổi cuối cùng bằng AI cho một module Python. Code trông có vẻ chạy tốt, nhưng thực tế đã phơi bày vài lỗ hổng bảo mật (security vulnerabilities), xung đột dependency và bỏ quên hoàn toàn các edge case. SDD chính là chiếc phanh giữ cho quy trình đi đúng hướng.
Ba cấp độ của SDD: spec-first, spec-anchored, spec-as-source
SDD thường được phân loại thành ba cấp độ, dựa trên mức độ bảo trì và thẩm quyền của bản spec:
- Spec-first: bạn viết spec để AI tạo code cho một task, sau đó spec có thể bị bỏ rơi hoặc lạc hậu. Đây là điểm khởi đầu cho các team muốn thử SDD.
- Spec-anchored: spec tiến hóa song song với code. Khi requirements thay đổi, bạn cập nhật spec trước. Các automated test đóng vai trò cầu nối trong CI/CD, đảm bảo code luôn khớp với spec. Đây là mức thực dụng nhất cho phần lớn engineering team hiện nay.
- Spec-as-source: cấp độ cao nhất. Lập trình viên chỉ sửa spec, AI tự động cập nhật code, file code thường gắn tag
@generated - Do not edit. Đổi lại, cấp độ này đòi hỏi pipeline kiểm soát cực kỳ chặt, vì AI vẫn mang tính không định hình.
